I think Apple Business Manager is for the client side. Here is a description of the process.

I'm hesitant to terminate and lose my current escalation status. I'm pretty sure the expedited review process doesn't work the way people think it does. Pretty much every post I see here in the forums says they request an expedited review. If every rejection is doing that, then the expedited queue eventually becomes the "problem" queue.

Could you please tell me the usual review waiting time For people who post here on the forums, the usual review time seems to be about 4 weeks. There's no way to know review times for people who don't post about it. there is any way to check the current status You'll be notified via e-mail if the status changes estimated review time for my submission? I estimate a few more weeks. Also note that if your app ends up being rejected, the speed with which you resubmit will have no bearing on your subsequent review cycles. If anything, it seems that the faster the submission after a rejection, the longer the delay.

I would simply appreciate confirmation that the submission is progressing normally and that no action is required from me. All indications are that your app's review is progressing identically to other, similar apps submitted over the past several months.

Well, it's not spam, it's not any of that, it's a legit health-care/health-data system, so it's queued incorrectly. Sorry, I was just making a statistical point. I don't know anything about how Apple runs its internal review queues. Obviously there is some "expedited" process. I was simply making the observation that if every rejection results in a an expedited review request, then, at some point, the "expedited" queue becomes longer than the "normal" queue. If you feel your app has been incorrectly categorized as spam, then I don't see how an expedited review would solve that problem. Perhaps it will only "expedite" another rejection and termination of your developer account. There are other avenues available to help you clarify your app's behaviour with App Review, and I've listed those.

Has anyone seen an accepted expedited review remain in “Waiting for Review” this long? There are many posts here in the developer forums describing virtually identical scenarios of rejection, resubmission, and expedited review request. Typical wait times are much longer. Offhand, I don't recall any posts where anyone followed up to report that their expedited review request was successful. Is there any recommended way to request a manual queue check without withdrawing and resubmitting the version and losing its current position? It seems you are following typical practice. However, I don't see any evidence that this practice is effective.

Just to clarify, this is our first App Store submission for Virtual Pro Association. The app has not been rejected before and has never entered review yet. That's good then. It has simply remained in “Waiting for Review” since September 28. So it hasn't even been waiting a week yet. I've seen many people report getting a message from Apple specifically telling them that their first submission is going to take longer than normal. I think a sub-week delay would have always been in the "normal" range, even before the deluge of AI slop. Someone else was recently complaining about being rejected under the 4.3 spam category. It's always a bad sign when people know the specific paragraph number of a rejection and expect everyone else to know that too. So I ran the numbers based on the most recent Apple App Store Transparency report.. If every 4.3 spam rejection results in a resubmission with expedited review request (as it sometimes seems here in the forums), then given the number of those rejections, the expedited review queue would have over 1,100 requests just from 4.3 spam rejections - per day. And that 4.3 spam rejection isn't even the most common rejection. And that transparency report is from last year, before the flood of AI slop. It's going to be a challenging time until the AI fad fades.

The concern is how frequently that recovery becomes necessary. In our tests, an ordinary external folder rename reproduces the problem on FAT32/exFAT, while the same workflow appears to work on APFS. If it was me, then I wouldn't worry about it. Foreign file systems are always problematic. While the app remains running, its existing file descriptor still tracks the renamed folder. On exFAT, we traced creation of the replacement security-scoped bookmark to an open() failure with EPERM. Reselecting that same folder through the system picker allows bookmark creation and subsequent access after relaunch. Two questions: What are you doing with this folder? It sounds like you're keeping a file descriptor open on it for a long time. That's risky. Ideally, you're going to wrap each access in a file coordination block. In theory, that should guard against some level of external manipulation. Are you doing that? (Note: my own file coordination experience is strictly theoretical. I've never seen it do anything really.) At a fundamental level, if you're app is saving a folder URL and the user trashes, renames, or moves the folder, that's a user problem. Your app should have no expectation of recovery. I realize end users may have different expectations. They do tend towards cognitive dissonance. Saving the last known URL could help guide the user through recovery, but would not itself restore authorization or establish that a folder subsequently found at that path is the original resource. No. It wouldn't. It's more for developer and user convenience. Also, it's important to note that you're specifically talking about folders here, correct? Folders aren't completely supported by security-scoped bookmarks, even on APFS. Perhaps you just haven't found the gaps yet. 😄 The remaining question is whether repeated reselection after ordinary renames is unavoidable under these constraints: a sandboxed app, public APIs, and authorization limited to the selected folder. Have you encountered this specific FAT32/exFAT rename scenario, and do you know an approach that avoids repeated reselection? Usually the best solution is an app design that steers the user towards manual selection as part of a normal app flow. Security-scoped bookmarks are fundamentally about accessing files outside of your sandbox. Avoid that at all costs. There's another important plot point here with respect to "support", public APIs, and authorization. None of these are designed to facilitate access. They're specifically designed to block access. The barriers they introduce aren't side effects, they're design goals. If you haven't already heard, Full Disk Access is next on the chopping block. Even if you don't use or access this feature, the changes that Apple is going to implement will likely require some coding changes. So my advice is not to put much effort into any feature that depends on security-scoped bookmarks as that it likely to be a source of user annoyance. Try to structure your app around documents and/or data in your sandbox.

Has anyone with a professional tool in a crowded category been approved after a 4.3(b) rejection? I have seen posts here in the forums where there was an approval after a spam rejection. But to be honest, I only remember seeing one such follow-up. If you've met with App Review or appealed to the Board, what information helped them understand your app? But on the other hand, I've also seen a recent report where someone did just that, got direct confirmation that their app wasn't spam, and still got rejected as spam again. And let's be honest here. You're using the "wizard" emoji. Your name is "my zen star 365". I Googled both "Zi Wei Dou Shu" and "BaZi". I'm sure you know what I found. What else did you say? client case management: client records, consultations and payments in one place OK. That sounds fine. filtering across cases (by chart features, life events or payment status) Data filtering is always good. Charts - great. Everyone loves payments. But life events??? statistics to review the business That's great! traditional rules relate to their own cases. It also generates charts, which users interpret themselves, and on iPad two pages can be viewed side by side. Unless those traditional rules come from governments or standard accounting principles, it sure sounds like astrology to me. The latest rejection noted that repeated submissions may lead to extended review times, and that accounts that repeatedly submit non-compliant apps may be removed from the Apple Developer Program Apple can do a little fortune telling of its own, eh? Honestly, if you have an app that would help practitioners in a wide array of small consulting businesses, that would be welcome. Charts, scheduling, payments, client contacts, newsletters, it's all good. Just ditch the astrology. If you want to press the issue with Apple, that's really your only option and you'll have to work very hard to convince them of your sincere desire to do that. Even so, for all I know, there's a ton of consultant business management apps and you'll still get a spam rejection even without the astrology angle.

I'm posting this here because sources say that Apple personnel have been peeking in here and I hope that's true, and can provide some guidance. There's no "peeking". There are several Apple developer support engineers who openly, and regularly, respond to technical questions here in these forums. However, they only provide technical assistance. They aren't App Review and they make a point to avoid any and all App Review questions. There are a very small number of replies from App Review here in the forums. Those replies are always virtually content free because doing anything more than that would be privacy infringement. Just because so many developers beg to have their failures discussed in an open forum doesn't mean that Apple should oblige them. I've got an app that was rejected for "Guideline 4.3(a) - Design - Spam". It isn't. It really isn't. It's not an ad generator. It's not a PII collector, etc. It's a legit application. That's what they all say. No, seriously. All Spam rejections say that. I found a process to upgrade it to expedited at least a week ago, and did that. Yes. They all do that. Seriously, they all do. And by any reasonable point of view, there's no way to provide any kind of "expedited" review when so many people have requested it. I'd love some guidance, even if that means sitting on a phone call on hold for a while in a queue or something. Any reasonable suggestions? Thanks! Apple does have "Meet with Apple" sessions directly with App Review. Apple also has an appeals process for app and developer account rejections. And there are direct developer support requests. You've already found the developer forum. But to get back to my primary point here - all spam rejections take all of those paths. So no matter what that "something" might be that you want to try, you're going to have to wait in a queue of all the other 4.3 spam rejections. And if you look at Apple's published App Store Transparency Reports, you'll see that the spam rejection queue is over 1,100 rejections - per day.

So what's your question? It sounds like you've been more successful in adapting to new realities than most people posting in these developer forums.

A week and a half after we started the validation process for our app, we’re still stuck with just one response every 24 to 48 hours, and now there are only three days left before the game’s release. The testers aren’t replying, even though I reply politely and send videos to show them how to do it. They test the wrong version, no send of video problem, etc. Three years’ work is at risk because the testers aren’t replying or aren’t reading my messages. Can you clarify? Are you talking about interactions with your own testers or with App Review? Because App Review is what it says on the tin. It isn't a testing service. Testing is the developer's responsibility. Apple has built a substantial TestFlight architecture to support that effort. If you are talking about App Review, then your response times of 24-48 hours are orders of magnitude better than what most people complain about here in these developer forums. The game was tested during 3 month no problem Perhaps that's part of the problem. App Review isn't going to test your app for 3 months. You'll be lucky to get 3 minutes. You won't even get that until your app passes a cursory review and comparison against similar games. If App Review can't figure it out from your description, screenshots, and website, they aren't going to expend any effort trying to learn. It's your responsibility to clarify those issues that they don't understand. our game has been announced and is due to be released on 8 October Perhaps that was premature. Expecting a 10 day review for a brand new is very optimistic. In the last year of your 3 year development effort, the world has been turned upside down by AI slop. Whether you used AI or not is irrelevant. You are now subject to the world that AI created. In this new world. New developers and new apps experience extra-long review times. Think weeks or months, not days. Apple provides options to specify your own release dates, but that requires substantial pre-planning and scheduling on your part. Should you decide not to take that option, then you have to accept that Apple will release the app on Apple's own schedule.

Our TestFlight build 148 (version 1.1.1) has been in Waiting for Review for a while now. Please quantify "a while now". Has anyone encountered a similar delay or name mismatch? These developer forums have been overwhelmed with posts reporting delays and constantly seeking validation from other people experiencing anything similar. We previously (about a week ago) had no issue with this and everything was pretty streamlined Does this translate to saying that your TestFlight review has been delayed for a week? I don't know anything about TestFlight or its expected review times. But if you can more accurately quantify your experiences, then perhaps you might attract more meaningful replies.

Has anyone experienced a similar delay recently Yes. There are multiple identical posts here in the forums every day. especially after an expedited review was granted? There is no "especially". Virtually all of those posts indicate that an expedited review was also requested. It's become automatic. As such, it can no longer possibly be considered "expedited" in any sense as it's constantly full of problematic apps that have experienced multiple rejections. Is there anything else we should do, or should we simply keep waiting? You should keep waiting. Regardless of your reasons for seeking an expedited review, the long-term solution is the same. Do a better job of pre-release testing to ensure the app won't be rejected and won't require an expedited review in the future. You don't have to wait for that. You can start code reviews and test plans right now. Even in the worse case, Apple will complete the review before you can get a better code-review-test-release pipeline going. Don't believe what you've been told about software development for the past 30 years. The Waterfall model is, and always was, the Gold Standard. Big companies like Google, Apple, etc. control their markets and users in ways that small developers don't. We aren't like them.

Reselection works, but requires user intervention This is the only part that matters and the correct resolution. Any questions you have regarding API behaviour or support status are irrelevant, as are any answers. The operating system is under constant development and system behaviour with respect to these bleeding edge cases can change from day-to-day. Security-scoped bookmarks should never be considered persistent or stable. There's literally a function for telling you when a valid security-scoped bookmark is stale. Pretty much all the other functions are useful for identifying when security-scoped bookmarks aren't valid. Security-scoped bookmarks should be considered a user convenience. They save the user from having to re-select files and folders in many cases. As a 3rd party developer, you should save the persisted URL separately so you can assist the user in re-establishing access when, not if, the security-scoped bookmark resolution fails.