It's not designed for experienced developers. It's designed for you to ask your AI to build it for you.

That's either "Log Noise" that you should ignore, or some subtle, but critical, error that's going to break your app on a future minor OS release. To answer your question, yes. I see it too. I also see: Ignoring request to entangle context after pre-commit Ignoring request to entangle context after pre-commit Ignoring request to entangle context after pre-commit Entangling fence requested after pre-commit cannot add handler to 2 from 2 - dropping As far as I know, I haven't made any such requests. I try to avoid entanglements. PS: Just to clarify, I'm not making a joke. I recently got bit by one of those subtle errors. My app was running fine for years, but I wasn't aware that a certain API call was an out-of-process XPC request to a system service. Then, in a recent minor update to Tahoe, it stopped working when called too early in the app lifecycle. The app locked up. I'm slowly coming to the realization that I should avoid Apple APIs whenever possible. If I can reimplement something on my own, then I should. Unfortunately, I'm running out of time more rapidly than I'm making these realizations. Popovers are known to be flaky in many respects.

I'm planning to create a font management app in due course, so want as much info as possible. This is one of those situations where I ask, "how would you develop this app for iOS"? Because for all practical purposes, macOS hasn't existed as a distinct operating system for a few years now. So if you struggle to figure out how you would write a 3rd party font management app for iOS, then you might have a long row to hoe there.

I'm desperately looking for a way to purge the contents of the Local Network allowlist in System Settings. Every version of a test app I've ever used gets an entry in there, and apparently so does each build of Chrome and Claude Code. How are you building your app? I've looked into this issue with regards to Chrome. From what I understand, the cause is due to various Chrome helpers that reuse bundle ID and low-level UUID in the app binaries, and then don't delete old versions of same. Google has known about the problem for years ( https://issues.chromium.org/issues/376742636 ), but blames Apple (FB15681423).

That function's been deprecated since 10.6. This is why people shouldn't sit on deprecated functions. Maybe you could have come up with a workaround, or filed an enhancement request for an alternative. You can include a non-sandboxed XPC, but the entire function could go away. And your Mac App Store route is a whole different can-o-worms. It's one thing to have a technical barrier, now you're talking policy, user experience, and App Review barriers. That's bad. What does this function actually do for you?

Is there currently a bug with uploading app screenshots? Currently? What you're describing is normal behaviour for the past 15 years or so. they just disappear when I go to upload them in my new version. Do you need new screenshots? If not, keep the old ones. Screenshots are a Big Deal and huge time sink. If you don't really need new ones, don't do them. If you do need new screenshots, then you just have to live with App Store Connect. It's always been very fragile. Clear your caches. Close all browser tabs. Close all browsers. Restart. Try a different time of the day. Try a different day. Try a different browser. Try a different computer.

It's now "Device controls and data access".

I gave it a try, and—as expected—it didn't work. I have seen recent reports here in the developer forums where certain enrolment problems were fixed by restarting and/or private browsing. Apple really likes Javascript-heavy websites. But Apple isn't as skilled as others in handling cache problems after updates. it won't accept my passport/ID simply because it's not from the same region my Apple account is set to. Americans apparently can't imagine a situation where one could live abroad. The developer ecosystem is more sensitive to scams and frauds than other, more consumer-type activity. Americans are definitely aware of living abroad. But they're aware of it being an extraordinarily difficult, multi-year process for most regular people. The expectation is that you would have some kind of documentation from your host country regarding your right to live and work there. And if not, well, let's just say it's not a developer's market right now.

Apple has all these stats about how fast they are to respond but if its just a quick fast initial generic response thats not really a response and its just a way for them to claim a high efficiency. It's an average across over 9 million submissions every year. That's 15,000 every day. Obviously it's only the people who have delays that complain about it. Has anyone else encountered this? Obviously yes. They've taken over the developer forums for the past few months since the start of AI slop. How long and how much back and forth should I expect publishing a basic app? Probably less than you fear. From what I see here in the forums, Apple seems to have found a way to avoid lots of "back and forth". If an app looks like it's going to generate lots of rejections, then they may give you a few weeks to work on it next time. It seems that some developers feel that a quick turnaround and resubmission after a rejection should result in an equally quick re-review. But no such correlation has ever existed. And lately, it seems like the opposite is more likely.

You've asked what!? Which app of yours? You've said it's your only app. I think the OP was expecting app review to list the other apps from other developers that are similar to the OP's (singular) app. Has anyone successfully resolved a 4.3(a) flag in a similar situation? I just saw someone post that they had successfully challenged a similar rejection. So it is possible. But every situation is unique.

Are others seeing this? I see no change. It doesn't seem to work very well. But it works as well as it did in Sequoia. It works better than it did in Ventura. However, I only tested using a Mail attachment as you describe. I seem to recall drag and drop of app-level objects like this going through at least a couple of re-architectures over the years. It's possible you're using some 3rd party app that failed to properly implement the design du jour. Can't say that I blame them. The last time I tried it was quite difficult.

Clearing the font cache using atsutil has been a thing for decades. So there is clearly some sort of font cache. I never said there wasn't. I said it was an implementation detail. atsutil does have a "databases" command that will remove font database "along with any cache files". It seems to be a universal behaviour that any app will load the fonts it needs from the disk, and then keep them in memory. TextEdit does it, Affinity Designer does, Word does it. If apps are doing it wrong, they all are. I was just referencing something I noticed in the documentation during my search for information about font caches. I'm not going to use font descriptors like that. Apparently no one else does either. And there's no guarantee that it would change anything anyway. That's why something that's an "implementation detail" is such a big deal and shouldn't be touched. Even the things that Apple documents and recommends are often impractical and frequently flat-out wrong. If I change the font file on disk, that new version will be used by any app that launches. Apps already running will continue to use their old copy in memory. Now that's behaviour that has been around for decades. I'm just curious how it's supposed to work. Apple never documents system behaviour to this level of detail. Modifying fonts is real 1990s kind of behaviour. I can't see it undergoing any significant change in expected user behaviour at this point. If Apple is comfy with every app loading their own copy of all the font resources that they might need, rather than pointing to a single instance, then there we are. You're talking about two different Apple apps, and possibly 3rd party apps. How Apple choses to implement its apps is Apple's decision to make and they aren't going to explain it in any way. But this is a developer forum for people writing their own apps. Personally, I wouldn't be concerned with users changing fonts while my app is running. If any complain, I'll tell them not to do that. I'm also not going to use font descriptors everywhere. The only time I use them now is to get around limitations and partial implementations in other font APIs like NSFont. There's no way I would ever try to support fonts changing at runtime. No way - no how.

Two weeks and counting, the macOS In Reviews have been going into blackhole while iOS and visionOS submissions are approved in less than 24 hours. You realize that 99.983% of complaints on this forum are the opposite?

Has anyone observed the intermittent issues with the AppStore Connect site? Only people who have used the site at any point over the last 15 years or so. “Please accept these terms and conditions” That's something difficult. Apple regularly updates the terms and conditions. In most cases, you can clear that from the developer site. I wouldn't recommend trying to clear it from App Store Connect as that site is always so flaky anyway. Could this explain why some apps remain in review or seem to wait indefinitely Nope. suppressed technical bugs or errors in the site’s processing of changes, where end-to-end flows fail to complete what would otherwise yield a finished review? No. It's AI slop. The only way Apple can manage it is to setup two systems, one for real submissions, and one for slop.

Don't use the comments. People will miss your replies. Honestly, the videos aren't very good. They're sometimes dated and wrong. Plus, they're exclusively focused on how to use Apple APIs. While those APIs are often challenging, they're the least important part of a great app. In many cases, they'll lead you down a dead-end path. People spend so much time coding the APIs they forget to actually write code for the app to do something. Think of what you want to do. Even if it's a simple demo app for learning - a "hello world" app, think of the core functionality of the app. Write a command-line version. Don't spend too much time on the I/O. It's just an exercise. Then write an app to do that. Add a little more. Repeat 10,000 times. If you're just starting out, pretty much any API you learn at this point is wasted. By the time you're knowledgeable and skilled enough to make a decent app, all the APIs will be radically different by then. What you want to focus on is learning how to learn.