Has anyone experienced a silent hold this long recently? Many people have experienced delays far longer. Any advice on getting a response from App Review would be appreciated. There doesn't seem to be any lack of App Review responses. Those responses easily account for complaints #2 and #3.

you’re implying that my app might be a scam I am not. I recommend you review the App Store Transparency Report for context. I submitted as soon as Apple began accepting apps built with the tools required to support macOS 27. I’m not sure what more preparation would have changed here. I shipped changes to support macOS 27 almost two months ago. Or are you talking about some new feature in macOS 27?

There has never been any exact-name App Store search functionality. There's a search field. The search algorithm is not documented and proprietary. And search has never been one of Apple's strengths. This is not something that can be, or would ever be, addressed. Search results are evaluated on an aggregate basis. They sample a million search requests. Then tweak the algorithm. Sample another million. If the metrics improve, the changes stay. If not, they get rolled back. Individual results don't matter. That's just the way it works. Sorry.

I noticed that my new app's review is taking a substantially long time, unlike ever before. It's been 5 days Most people don't complain until 5 weeks.

But how on earth can an app remain “In Review” for this long? App can remain "In Review" for weeks. A classic scam tactic is to arbitrarily change app behaviour after a couple of weeks once an app has passed review. Then your AI Photo retouching app can morph into an astrology dating app with matchmaking prediction and betting module. Releases are planned around OS launches, marketing, customer expectations, and other deadlines. Then you should get your releases done earlier so you can set the App Store Connect flag to release on your own schedule. I seriously doubt Apple would accept this level of unpredictability from one of its own critical business partners. Sounds like you misunderstand your relationship with Apple. App Review is broken. App Review is functioning as designed. The purpose of a system is what it does. At some point, Apple needs to establish a greater level of trust with longtime developers who have been shipping reputable apps on its platforms for years. Some of the most dishonest developers I've ever encountered fall into that category. Otherwise, as legislation continues to open these platforms to alternative distribution, Apple shouldn’t be surprised when established developers choose to distribute outside the App Store simply to regain control over their own release schedules. You don't need to wait for legislation. That's already happened. Alternative markets exist right now. If you want to be free to ship on your own schedule, live the dream. There's nothing holding you back.

keeps one SQLite connection open while its process is alive. Don't do that. More specifically, can an existing open file descriptor or SQLite connection continue to reference an old filesystem object while a later lookup of the same Application Support path resolves to a restored or replacement object? You're well into "undefined" territory there. I'm certain that no such guarantees exist, and if they did, they should be dismissed out of hand. lifecycle invariant prevents it? Apple never documents system behaviour at that level, and if they did, you can guarantee it would be wrong. Does NSFileCoordinator participate when platform services restore private Application Support files? Obviously you couldn't use NSFileCoordinator on a file that you never close. That should be a big hint. SQLite also documents risks when an open database file is renamed or unlinked. risks I am not treating a raw rename or unlink test as equivalent to an Apple restore. I am explicitly excluding arbitrary unlink, rename, overwrite, or other direct same-container filesystem attacks. My question is only whether Apple's supported restore and container services can create an equivalent old-open-object versus newly-resolved-path condition while the same app process survives. Seems like you're going about this the wrong way. You should focus on arbitrary unlink, rename, and overwrites. Detect those conditions and gracefully recover. You can get started on this today and test it. Apple isn't going to tell you anything about how the system works. If they did, it would likely be obsolete in a matter of weeks.

What version of Xcode are you using? Apple has gotten much more aggressive about requiring current versions, which are incompatible with many older versions. Usually the App Store submission requirements are updated in April. You an see those notices at: https://developer.apple.com/news/ For full details, look at: https://developer.apple.com/xcode/system-requirements/ The only way you were still support iOS 12 would be if you are still running Xcode 15.4. That was bumped to iOS 15 in Xcode 16. It looks like the April 27 update will still allow iOS 15, but you're on borrowed time there.

Videos are for showing. Doing is for learning.

I don't know how you're going to handle this. Please follow up if and when it gets resolved. First of all, the fact that this is blocking Paid Apps for you is a Very Good Thing. If you didn't already know. The USA requires all US citizens to file income tax in the US, regardless of where they live. So this is more of a question for your lawyers and accountants rather than Apple. I'm a dual US/Canadian citizen. This is insanely complicated, both on the US and non-US sides. You'll need to find an accountant with international experience. That's your first step. Any other first step is guaranteed to be wrong.

I was wondering how queues fit together with concurrency They do not. I realized that the new class is in the same module, but introduced for macOS 26. I saw the WWDC25 video about it, but it assumed that I already knew about its result-builder connection setup. I don't; was it introduced in an earlier video? I think NetworkFramework is just a Swift-friendly wrapper, based on Swift concurrency rather than GCD. Unfortunately, these network frameworks are constantly in flux. If you're planning some relatively simple operation, there are likely some better APIs to use. A lot of times, I find a web article soon after some WWDC that explains how to actually a new API. I think that world is gone forever. Who's going to bother writing those web articles when the AIs just going to steal and launder it?

Ensure your Apple ID matches your tax residency country. When I see these kinds of posts, it turns out the OP is a citizen of A, lives in B, and has an Apple Account in C, and sometimes a shell company too.

Maybe that's just the way Pages does it. Pages does have a font menu where the fonts are displayed in the appropriate typeface. TextEdit displays the font names using the system typeface. If you want to do anything fancy in TextEdit you have to use the system controls. When I search for "font cache" on the Developer site, the only hit is this thread. So that suggests that the font cache, whatever it is or does, is an implementation detail. I think perhaps those apps are just using fonts incorrectly. I guess I'm using them incorrectly too. What they're supposed to do is use fond descriptors for referencing fonts and then only create an actual font when they need it. If they did that then, maybe, they would get an updated font without relaunching.

Isn't there also some kind of identify verification step? Have you done that? Most of the posts I've seen here in the forums are complaining about enrolment delays stretching into weeks. If you're still in "X days", then you're doing better than some.

I have seen them start to post a few more replies here in the forums.

It's true that it might take 48 hours. Might take 4.8 months too. There's no way to estimate these things. I see many similar posts on the forums. They're always the same - "We've done everything and heard nothing!" In some cases, there is a cryptic reply from Apple saying to check their e-mail. Then the OP states that they finally submitted the required documentation.