A/B testing: Is it allowed under Guideline 2.5.19 to A/B test paywall designs, subscription or consumable offers, and some content features with a server-side remote configuration service (e.g. Firebase Remote Config), so that different users see different variants? You might want to consider a "Meet with Apple" session to ask the App Review team directly. There's very little App Review participation in this forum.

NSBundle is just an object that you instatiate with a URL. You can reference the "mainBundle" static object that always points to your app. There are methods that allow you to reference any resource files that are included with the app. Translocation is kind of like a mini sandbox. NSBundle provides access to any of those files within the app itself. All resources do need to go inside the app bundle. Otherwise, you're talking about a situation where some sort of installation process is necessary. Generally speaking, there's nothing wrong with that, but it precludes allowing users to run a downloaded app from the Downloads folder. I'm not sure what you mean about "resources are common for the same app for 2 other platforms." In this forum, "platform" usually refers to macOS vs iOS, and maybe some oddball tvOS, watchOS, etc. There's no problem including any kind of "foreign" resources inside an app bundle. The data may be duplicated and the zip files may be larger, but that's life. A user editable .ini file is really not a good idea. It would be better to describe what you're trying to accomplish with this .ini file. There are probably other ways to achieve the same end result - maybe user defaults, maybe an onboarding UI, maybe a network request.

This mounted volume actually belongs to the intended disk image. If these are your own images, you can create your own hidden files with reliable, unique identifiers. What supported macOS API or command should a script use to establish this relationship reliably? There are a number of APIs that may prove useful: Disk Arbitrarion URL resource values statfs Maybe IOKit From what you're describing, #1 and #2 should be sufficient. Can we rely on specific fields from hdiutil info -plist and diskutil info -plist <device>? If so, where are their meanings and limitations documented? hdiutil is deprecated, so there's that. While diskutil does have a machine-readable "-plist" option, the details of what those values mean is often not well documented. Plus it's an external tool you'd have to run. Disk Arbitration would be preferable. I sometimes use these tools, and "system_profiler", but normally that's to poke around in Apple's business. If these are disk images that your software is creating, you have much more liberty to just create your own metadata for them.

Well, now that you mention it, bundles are your friends too. Create a demo app using the Xcode app template. Archive it to disk. Make sure your app is organized like that.

NSBundle is your friend

Given that, would people be up for posting their time submitted and (once they receive a review) editing to include the time it took? Posts can only be updated for 1 hour after creation.

Has anyone faced this issue? Yes, of course. There are many identical posts here in the forums. But the more important question is why anyone would ever want to do this in the first place. Is there some web site, podcaster, or AI chatbot recommending that people set up shop in Wyoming? It's 2026. The internet's not true.

@andyoneil, Don't use the comments. They hide your replies. Beyond frustrating that apple has had zero communication, and there appears to be no other way to escalate this or discuss with a human to review the situation. Apple has multiple methods of escalation. For a rejection, you can reply to comments. You can appeal a rejection. You can request an expedited review. You can contact developer support. You can sign up for a "Meet with Apple" session and discuss unique issues directly with the App Review team. We were not aware of the time delays/backlog - so its very much unexpected stress. You might want to review the 2025 App Store Transparency report. In 2025, Apple rejected over 2 million submissions. That's over 5000 rejections a day. Apple approved 20,0000 a day. But even that relatively small number of rejections is sufficient to completely swamp all of those escalation methods that I mentioned above. And that 2025 report was from before the deluge of AI.

It all depends on how deep you want that rebranding to go. As you describe, changing the bundle ID(s) is a fresh start. That's a whole new app. If you change the physical bundle name, that might still have some impacts. Customers may have scripts. MDMs may use that name, etc. If you only really care about a superficial branding, you can simply add a localized name. Users will only see the old name if they're using the Terminal or something else relatively low-level.

Why can't I be this lucky when playing the lottery @wrensey, don't use the comments. They hide your replies. Apple just updated the forum UI too, but they kept the comments feature? <sigh> App Review is not a statistically random system. In the past, it was driven by the metadata, attributes, and quality of the submitted apps. Over time, the information used for review has clearly expanded to include other developer activity. And more recently, Apple is acknowleding that it now uses AI. So any developer activity is going to be fed back into the system and used to try to make the app review system more efficient in terms of publishing app updates. If the AI thinks your submission is likely to be rejected, it makes sense that it should prefer other submissions that it thinks are more likely to succeed. To be clear, I don't work for Apple and I have no idea how the system works. I'm simply speculating on how I would design an ideal app review system. But I admit that, in most cases, Apple systems are far from my conceptual ideals.

And the 99.2%???? Where did you get that number? At least you’re seeing status. Tell us where… or are you just making it up? I'm getting it from the 2025 App Store Transparency report and my own review of activity in the developer forum. Apple reviews about 25,000 submissions every day. The developer forum shows 10 pages of 20 threads per page. A single day's activity fills up about 10 pages. So at worst, there are 200 complaints per day, or 0.8%. Of course, there are statistical caveats all over the place. But the raw volume of App Store submission activity clearly downs all of it out. I'm not seeing any status. I'm only posting here in the forums because I have so much personal stuff going on that I can't focus on my work very well. My last submission was a couple of months ago. I waited for review for about an hour and a half, and then the review itself completed in about an hour. Logically, if my experience was that far from the norm, there should be even more complaints. I do see a few complaints on slack channels. Those are typically from people who self-identify as "indie" developers. Make of that what you will.

Is this a common experience lately for resubmissions? Yes. What you describe has been described by other people here in the forums, over 100 times a day, for about the past 300 days. Any insight on what causes a resubmission to take significantly longer than a first review would be appreciated. Apple has publicly said that it's using AI for reviews now. So any developer activity could be a source of training data. So which submission should the AI engine pass to a human reviewer? A submission that's already failed 3 times, or a submission that hasn't already failed? In the first case, a reviewer has looked at 3 submissions with nothing to show for it. Had that reviewer spent those 3 sessions on other apps that didn't fail, they could have published 3 updated apps. So it would make sense for the resubmission queue to be slower. I don't know if Apple's app review system actually works this way, but if it did, it would result in more submissions being approved. From what I see here in the forums, developers try to resubmit as quickly as possible. They also submit multiple developer support requests. And they submit expedited review requests for updates that aren't time-sensitive. The result seems to be ever-longer wait times. My recommendation would be to try to break that cycle. Instead of resubmitting quickly, take the opportunity to honestly pre-review the app and address any potential problems. After all, it's not like it's going to be reviewed anytime soon anyway. May as well get some value from the delay by improving the app. And maybe that will result in a different pattern for the AI and a different result going forward.

Is anyone actually actively reviewing apps right now, or is there a major system backlog/glitch? Has anyone managed to get through to the review team recently or found a way to resolve this kind of delay? The App Store review process seems to be running smoothly the 99.2% of submissions that aren't complaining about it here in the developer forums.

An expedited app review request was also submitted. Your post is one of the few legitimate expedited review requests that I've seen here in the forums. Unfortunately, AI slop has hit the App Store very hard. Every post I've seen here in the forums complaining about delays and rejections also indicates they've submitted an expedited review request. The few posts that actually have a deadline tend to submit their apps only a few days before said deadline. Hopefully you'll get approved in time. But if anyone is reading this in the future and has a legitimate deadline, perhaps it would be better to submit two months in advance.

Were you eventually able to enroll your company under its existing legal name? If so, what process did you follow, and which Apple team helped resolve the issue? This thread is over four years old.