You definitely don't want to call out to a separate process. You can get this value from UserDefaults.standard.persistentDomain(forName: "com.apple.universalaccess"). Combine that with NSCursor.current.image.size to get the visible size. However, this isn't really an API. The old army joke goes, "If the army had wanted you to have a wife, we would have issued you one." Apple is the same. If Apple had wanted you to have a given piece of data, they would have given you an API. If you have to use hand-coded string, and query values that aren't documented and don't have enum definitions, you're taking a risk. That being said, it does seem to work, and in a sandboxed app no less. But it looks like it would be forbidden in the Mac App Store. Any use of UserDefaults requires a privacy manifest for NSPrivacyAccessedAPICategoryUserDefaults and there isn't an entry in the reasons list for reading accessibilty settings. Personally, I wouldn't bother with it. Don't forget the corrolary to the previous joke, "If Apple really cared about accessibility, they would have given you a decent API".

Don't use the comments. They hide your replies. Ideally, just add a reply and tag the person you're replying to, like so: @ItsARedApple_PLSHelpMe these are people who are trying to make progress towards getting their apps released... So waiting, for however long, to possibly run into issues during the submission means more time to correct it and more time to update their submission to resubmit it for review. Yes, of course. But you're glossing over the details with "run into issues". They're not "running into issues", they're getting rejected. It's fine if people want to use AI chatbots, but they should recognize that App Review isn't an AI chatbot. Should developers choose to treat it as such anyway, it sounds like Apple is returning the favour by switching it to AI mode. There is a solution here. Developers can do research. They can select projects that aren't automatic rejects. They can build high-quality apps that don't get immediately rejected. Unfortunately, if the expedited review request is, in fact, being spammed, It's quite likely that the majority of them were already showing the "waiting for review" status for an extended period of time.🙂 It's not even "quite likely". They are freely admitting it. That makes sense. If they didn't do research on their app idea, didn't do research on app review, didn't do research on software development, why would they do any research on expedited reviews? Besides😁, me personally? I think the spamming of the expedited review request would contribute far less complication moving forward, rather than people deciding to delete their submissions with intentions to resubmit them. Why? Maybs in hopes that it fixes any potential systematic issues or errors. This is where it starts to get subtle and complicated. In theory, expedited review isn't for rejections at all. One of its primary purposes is specifically for apps that were already approved, but the developers noticed a major bug. Well, to be honest, said developers should have done more testing, shouldn't they? But yes, things are obviously chaotic right now in the forums. But it's important to remember that there are over 60 million developers. If there were a problem affecting more than a tiny fraction of developers, it would be much worse. And aha, yes, i will charge my phone now. 🥳😂 lol I'll take the W.

Mapping data in China is highly regulated by the government. That is the source of everything you're asking about.

You will either have to transfer the app to your new account or use a different bundle ID.

So is that why so many people are spamming the expedited review? Because an AI chatbot told them to? I guess that makes sense. PS: charge your phone.

I wonder if other Xcode users experience the same? I haven't noticed this problem. But then I don't have that much RAM either. Xcode uses a lot of RAM. While you have a lot of RAM, RAM isn't RAM anymore. It's all virtual now. The most likely explanation would be that you're running out of free storage. And I mean "free" storage, not Apple's "available" concept. And because you have so much RAM, your VM demands are probabaly pretty high too. I recommend keeping 100 GB of free storage. Once you get below 50 GB, you'll start to notice a performance hit. Or at least, a normal person would. With your 64 GB RAM, it would probably be worse with you. Plus, Apple's really struggling with storage in particular, and the OS in general these days. Last week, at 10:27am, I had 466 GB free storage. But for some reason, the dasd process went insane and started taking 100% CPU and eating up storage. Because I had so much free, I didn't notice a problem until 2pm, which I had less than 10 GB free. Of course, I can fix all that relatively easily. This is just a single example from my recent experience. It could be anything. But my bet is storage.

No such method exists in Xcode 26.2.

I found and removed any use of NSLayoutManager. So I'm definitely on TextKit 2 now. I'm using NSTextAttachmentView, but I discovered a couple of things that may also apply to NSTextAttachmentContainer. First of all, it's good that you're using Objective-C. These APIs haven't been updated for modern Swift. I hacked it a couple of places but finally gave up and re-did it in Objective-C. My first attempt worked fine on macOS 27, but then crashed on macOS 15. I figured out how to fix that. But probably the most important thing is that you may have to figure this out on your own. For NSTextAttachmentView at least, none of this is documented. What documentation I found on the internet was completely wrong. And quite a bit of Apple's API is wrong too. I don't want to give away too much in this age of AI. But I was very pleased to see AIs be so confidently wrong.

Does removing a submission to add a new build restart the review wait? Yes. Has anyone else run into this? Yes. Our app has been in review since late September. Has it? Among the many hundreds/thousands of identical posts, one trend that I've noticed is people aggregating all of their wait times from multiple submissions and rejections into one wait time. That is, each submission has a 3 week wait time until rejection. The app's been rejected 3 times. They say they've been waiting 9 weeks. The new submission didn't go into the same review thread. It shows up as a completely separate submission. Yes. Reviewers have the ability to re-check an app after requesting and receiving some small change. But there's no guaranteed timeline there. They could complete the review the next day, or wait 6 weeks. But a new submission is a completely new cycle. You may even get a new reviewer. Your app could get rejected for all the same reasons it was before. Our first review took about 3.5 weeks OMG! I was right! I actually hadn't read through your full post before I started this reply. It was just a stream of conciousness thing. Has this happened to anyone? In 2025, Apple reviewed over 9 million app store submissions. Then, AI slop hit. I've seen one independent trade report saying submissions have increased 84% in 2026. So yes, I can confidently say that your experience isn't new. Did your resubmission keep its place or did the wait start over? Resubmissions are always a fresh start. It's been this way since the App Store began. Also, is there anything I can do so the reviewer still sees our earlier replies? I don't know how Apple works internally. I assume they would have access to your previous submissions. But I admit that sometimes Apple's data management practices leave me mistified.

If you want to release two different versions of the same app, make sure to use a different bundle ID for each.

I think i found an answer for you. Someone asked the exact same question on Stack Overflow 14 years ago: https://stackoverflow.com/questions/8558853/nstextattachmentcell-is-a-mile-high But I still have to debug my own text views. It looks like I may be inadvertenly triggering a TextKit 1 fallback. Thanks for opening this can-o-worms for me. It's better that I find out about it now before I ship.

Are you actually running on macOS 10.13? I tried to do this using NSTextAttachmentViewProvider and I couldn't get it to work. That requires macOS 12. But apparently, this TextKit 1/2 logic is quite flaky and delicate. So Perhaps you're actually running on TextKit 2 and that's what you should be seeing due to some bug. Once something is a lightly documented at custom text attachments, it's risky. I'll try again with an NSTextAttachmentCell. Just because views are (theoretically) supported doesn't mean the cell shouldn't still work.

Thanks for the follow-up, and for finding that information. Very interesting.

It was created in a certain way to be the only version of this type of app that actually works correctly and is user friendly and completely different than what anyone else has done before - But the issue is on the surface it may look similar to other apps, but I can say for a fact it categoricaly is 10x better than any app in that industry at the moment - but the reviewers won't even use the app lol... and may think other apps do what mine does, but they don't do it properly. How would reviewers know any of that? Even if they had approved the app, they wouldn't have ever "used" it. It's simply not that kind of review. It's actually been in planning for nearly 2 years now. I've got one that I've been working on for over 10 years. But I finally made the difficult realization that my current app, which I would dearly love to abandon, has some tiny bit of market presence. The new app would be starting from zero. In financial terms over the next two years, I can make more money with the current app, due to nothing more than its existing market presence. So I put the old one on hiatus and I'm updating the current one to make it even more marketable. this app was specifically made with the "business" in mind That's not necessarily a good thing. Businesses are awful customers, just awful. In theory, there are other avenues that you could take to market to these customers - consulting, white label, unlisted, etc. But I wouldn't recommend it. They don't care that it's 10x better than other apps. They only care if it's 10x cheaper. And even if it were cheaper, they would only use your app as a bargaining chip to get a 10% better price from their current vendor, and maybe a free round of golf at the club. That's the reality here. You're offended that Apple has rejected your app. You think it could be successful. Have you considered the possibility that Apple actually understands all of this a lot better than you do? My current app was once rejected from the Mac App Store (ejected, actually) on far flimsier criteria than 4.3(b). But in hindsight, I wish I had never added that feature that Apple demanded I remove. In the new version, I have removed it. Apple already knew then what has taken me 5 years to figure out myself.

I'm using scrollWheel(with:) rather than NSPanGestureRecognizer The scrollWheel(with:) method is really what it says on the tin. It's for supporting the scroll wheel on your mouse. Then when Apple got rid of the physical scroll wheel on the mouse and replaced it with a touch-sensitive mouse, it became a half-way gesture. And as you have seen, it's halfway supported. as far as I'm aware, AppKit's NSPanGestureRecognizer can recognize drags but not scrolls (please correct me if I'm wrong) I don't know if you're wrong, because I've never used that API either. I used the older, mouse-based methods. But you don't want to fall into API dependency. That seems pretty common these days. If Apple doesn't provide some clearly named method or enum for something, people assume it's impossible. It's never impossible. A pan gesture requires touching the trackpad. That makes it a drag. You can reposition the view from that. But that's really getting off-topic. The main point is that you're somehow triggering some odd behaviour by attempting to use only scrollWheel(with:). I've never seen what you're describing. I took another look at your demo app. This time, I did what I should have done the first time. I ripped out the vast majority of your code and replaced it with the equivalent structures in InterfaceBuilder. I kept the livescroll notificiations. I also kept the custom scroll view with the no-op override. No problem. No scrolling artifacts. All notifications arrive as expected. My best guess is that somehow you didn't setup scrolling elasticity correctly. Or perhaps it was something else about the scroll view. I don't know. I normally don't setup scrollview hierarchies in code. But it just so happens that I am doing that now, so I'll take another look at the problem your describing once I get to a point where I can test it.