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.

If you have these kinds of fixed schedules, then the traditional app release schedule is not going to work. You have no control over that. You have a few options: Get the release done and submitted earlier and use manual release. How much earlier, you ask? I recommend a month, a minimum. Redesign the app to be network or API driven. Then your app's release schedule is independent from app events. PS: Apple even has an Events API to support this behaviour. Just use a website.

My app review is taking so much longer than it usually does How long does it normally take and how long have you been waiting? Some people are waiting weeks just in "waiting for review" and then more weeks "in review". Not sure why this is and the whole purpose of expedited review is to ensure crucial updates get pushes That was the original purpose. But since then, it's become an automatic click whenever people's submissions get rejected.

I only see one setting under Display Zoom. It's just "larger text" on or off. In the Simulator/Device Hub "Device" menu, you can change text size under "Accessibility". If you're happy with your app's text sizes when you adjust it there, that one Display Zoom adjustment should be fine too.

66 hours definitely doesn't qualify as "stuck". Nor does one week really. Many people are complaining about multi-week delays both "waiting for review" and "in review". But 66 hours, and even a week, have always been within the normal range, even before all these new AI slop delays.

What URL did you (and others) submit to Apple? I recently discovered a similar problem. My website is hosted on AWS Cloud Front. I've got custom language-matching logic for non-anglo users. When I published an app recently, either my privacy policy or support links were language-specific - something like example.com/en/support.html But when published, Apple just stripped that last component from the URL and called that my company website. But my language-switcher wasn't configured to handle just "example.com/en/" and the link didn't work. It was easy enough to fix, but I didn't know it happened until after the fact. Had there been some other level of post-munging URL verification, I would have failed that verification.