No response as of today, several business days later Organization accounts can take some time for verification and setup. And then you'll likely need to setup tax forms and banking. Even in a best case scenario, it's usually measured in weeks. The flood of AI slop has added additional delays this year.

Dividing an app-level outcome by an event-level count does not give you a per-app probability. What's the app-level outcome? The transparency report calls them all "app submissions". I'm not disputing that a single app can be the source of multiple submissions, multiple rejections, and even multiple approvals. My point is that such apps are a lot of work for a reviewer. I've been a university instructor myself, so I know that poor submissions result in more work for the reviewer. A well-done submission is fast and easy to mark. Apple is a business, not a school. They run on a pass/fail system. So once a submission has failed, why waste any more time on it? That's especially true when there are 15000 other submissions to mark that day. An if someone repeatedly submits failing work, does the reviewer want to be the one who ultimately passed them? Reviewers do sincerely want to see submissions improve, so maybe they decide to give them more time to work on it.

why did the previous versions not get rejected? Maybe they just missed it? isn't it a base practice in the App Store to use the title formate "xxx for xxx"? It's certainly common practice. I don't work for Apple, so I can't explain why they allow some apps and reject others. I can't imagine all of these apps have approval from the respective owners of the icons, names, and brands. It's a mystery. It's pretty much the same anytime one gets caught violating any kind of law or guideline. A defence that other people have been able to get away with similar violations is a guaranteed fail in all circumstances, even if it's 100% true. The problem is that they aren't going to release you so they can go off and try to catch someone else who did what you did first. You're already caught. Nor are they going to change the law or guideline. What do you recommend in this situation? Come up with a better idea that you can own. It's always a bad idea to build an app that depends on anyone else. That makes you dependent and beholden on that other entity. Is it worth to make an appeal? I say no. One reason is that there are so many rejections and they all appeal. So that's probably just going to delay your eventual rejection. Do I have to live with it and change my app name? Sounds like you may need to change more than that. Did I just have bad luck with the reviewer? Are you asking if you should keep trying and hope to get through? That might work, considering there are so many apps like this already. It might also get you terminated from the developer program altogether. I certainly wouldn't do it.

My understanding is that it only should take a few days to get a review. It depends. How can I get clarity as to when my app will be reviewed? You will get an e-mail when your app goes into review.

I'm extremely disappointed with my experience trying to change my Apple Developer account to a business account in Spain. I think that's the problem. Why would an existing company have an individual account? Converting account types is something that someone does when they incorporate. I think Apple's doing you a favour here. Assuming they accepted that document you're offering, how long do you think the transfer would take? Do you really want to keep your company in developer limbo for that long? It sounds like you should create a new company account. If you're able to stay in the automated flow, you might be able to get that done in a few weeks to a few months. The only downside would be if you had existing apps that you want to transfer. They might not be transferable in the first place. And if they are, that would certainly take some time too. Unfortunately, that's the cost of using an individual account for a company in the first place.

Has anyone experienced this kind of prolonged, piecemeal review? There are many similar complaints. Is there a way to request that App Review complete the review and provide the full set of outstanding information or concerns at once, rather than continuing with individual requests days apart? No. App Review is not quality control. If you find yourself needing to explain how your app works, then you may need to consider reworking your app. If App Review can't figure it out, customers might not fare any better.

no apparent ownership of the overall case There is no ownership or "client" system on Apple's side. There's no way to tell which reviewer you will get. So if you're trying something that needs a lot of explanation, it's better to re-work the idea so that it's more clear to anyone who might encounter it. no meaningful way to reach someone who can actually resolve it. As the developer, it's your responsibility to resolve it. I can’t get a complete review. There's no such thing as a complete review. Apple reviews 15,000 submissions every day. Once there's a reason to reject, Apple doesn't spend any more time on it. In an educational setting, a low-quality paper takes forever to mark because there's so much to identify, correct, and total. Work that's done well earns a high score and is really fast to do. But Apple operates on a pass/fail basis. Once they've decided that you fail, they're going to spend their time on other submissions that have a chance of passing. At some point, “review” stops being quality control App Review has never been about quality control. It's about customer safety, legal issues, blocking scams, and contractual requirements.

For the Bouncing Ball, that is the correct link. I thought it was pretty popular so I did not sent the link for it. Sorry, I had never heard of Lottie until you mentioned it. Judging by how poorly it implements a simple bouncing ball, I wouldn't touch it. Apple platforms lean very heavily on the main thread. Internally, they may do a lot of work on background threads. But for the 3rd party developer, trying to circumvent inefficient main thread code by doing it on a background thread is definitely "there be dragons" territory. There are 3 main problems with this approach: You aren't doing anything to address the actual problem of inefficient main thread code. You're introducing a delay that's going to be visible, all because of a delay that's visible. These APIs were, in most cases, never designed to be used off the main thread. If they work at all, that's just bad luck. I say bad luck rather than good luck because it will encourage you to keep going down this path that can only lead to failure. I suggested a quick and easy trick, which you can't use because of the cross-platform framework. And yet, it's the cross-platform framework that's creating this problem in the first place. Maybe review why you are using the framework in the first place. See what you could do without it. Or look for a different framework. I would expect this to be a great use case for AI.

NSPinnedDomains shipped with iOS 14, lives in the ATS dictionary and has its own documentation page. If a first-party API in the system configuration is inappropriate for the App Store, that seems worth someone at Apple knowing. There are many developers who ship iOS apps not using the App Store. Originally, it was only enterprise developers doing this, but apparently, anyone in the EU can do that now. Apple does not document which APIs work in the App Store and which do not. This is a much bigger problem for Mac apps, but it could happen on iOS too. If you explain why you need this capability, and if it seems like you really do need it, and you gracefully handle a failure, then you may be able to use it. But it might also require a more thorough, and lengthy, review period. Also note that when I say "explain", I mean explain to App Review. You're wasting your time trying to argue with me. I don't care. I'm just trying to give you another perspective. What did move today: two TestFlight builds approved, hours apart. Same binary, same certificate pinning, same everything — reviewed, passed, distributing. So the artefact was never the question. What we are waiting on is a queue, which is what I said on day seven. The perspective that I'm offering is someone who reads these forums on a regular basis. I can tell you, with great confidence, that TestFlight is a different path. I can also tell you, with great confidence, that a 7 day app review delay is normal, and has always been normal. In today's AI slop world, some people are waiting weeks. And there does appear to be a correlation between rejections and very long wait times. And here's another perspective I can offer. I've also read Apple's App Store Transparency reports. The two most relevant data points are the number of submissions, the number of rejections, and the number of approvals after rejection. In 2025, Apple reviewed 9,100,620 submissions. 2,093,244 were rejected. That's 23%. 387,087 were approved after rejection. So if your app gets rejected, there's an 81.5% chance that it will not be approved. So therefore, if you have 9 million submissions a year, or 25,000 a day, it makes sense to put any rejection onto a slow queue so that you can more quickly approve those 19,000 apps that don't have a problem. As the numbers clearly show, getting approved after a rejection is possible, just not common. But if you are going to do it, you'll likely need more time. So try to look at your app from a different perspective and don't give App Review any reason to reject it. That's a good use of your time, no arguing with people on the internet.

one of the simplest Lottie files, Bouncing Ball, creates a hierarchy of around 10 layers with 7 animations added. I would classify that as "minuscule". But even so, when I search for Lottie Bouncing Ball, I get hundreds of them. Are you talking about this one? https://lottiefiles.github.io/lottie-docs/breakdown/bouncy_ball/ I don't see how that would be 10 layers. It looks like 1 layer and 3-4 animations. That issue you referenced was from 2022. They were trying to do animations in a table view while scrolling. That's really not a good idea. But someone in that thread did mention hundreds of layers taking several seconds. That seems unreasonable. Most likely they are simply doing something fundamentally wrong. I'm not familiar with that project. But CoreAnimation is very fast. It's more likely the slowdown is coming from something else, like reading JSON files. Putting tasks on a background thread because they take too long, especially configuration tasks, is a bad idea. Typically Apple solves these kinds of issues by eliminating the configuration task and configuring structures on-the-fly, as needed. Core Animation is good for objects that need to interact with the UI. If you're trying to do something that Core Animation can't handle, maybe you need to look at gaming APIs like SpriteKit.

No one here knows anything about you, your app, or your submissions. Certainly many apps are being approved within the 48 hour estimate. Those people aren't complaining. I was replying to someone this morning who insists the problem started two weeks ago because that's when they first got rejected. But there are thousands of identical reports starting from earlier this year, about when AI slop really took off. It seems that Apple just turned around and leveraged AI on the review side. Please note - I'm not asking for additional details. Please don't provide them.

That’s why we submitted the update on August 25. Six days? Including a weekend? Apple provides a service where you can get an app reviewed and approved ahead of time, and then release on your schedule. But you'll need to start the process weeks ahead of time. The unusual review delay has only started happening over the past two weeks. I regularly review this forum. This started several months ago, in early 2026. It sounds like you may have been one of the lucky ones until now. Obviously those people don't complain. But now that you are stuck in the queue, it might be a good idea to review some previous posts. There are thousands of them.

Yes. User accounts and paid subscriptions. Pinning is standard for that, and Apple ships a first-class API for it — NSPinnedDomains inside the ATS dictionary. Strange thing to be asked to justify. Apple has many APIs that are inappropriate or impossible for the App Store. As I said, if this were a banking app or some highly regulated industry, then certificate pinning might be expected. But pretty much all apps these days have user accounts and subscriptions. Apple Developer support describes certificate pinning as a "two edged sword". An offline notice is what Gmail, Instagram and Apple’s own apps show when the network dies. If "check your connection" counts as evading review, the whole store is evading review. By your own admission, your app didn't do that. Apple itself isn't subject to App Review. Google and Meta are well-known, established developers. For the record, since it is the only part of this anyone can actually verify: a reviewer ran the new build this afternoon. It started normally on their device and they browsed it for several minutes, with zero errors on our side. Which is roughly what week one should have looked like. So the process is working and the review is making forward progress then.

I recommend contacting Dun & Bradstreet directly about this problem. They are likely to be much more responsive than Apple.

Could someone from the App Review team please confirm whether my submission is correctly queued for review or help escalate the existing support case? If it says "waiting for review" then it is correctly queued. There are many similar reports here in the forums.