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.

I realize comments here are basically only seen by the person being "commented" to. Not even by them. I just know about the problem. I regularly check my previous posts to see if anyone has used a comment. That's the only way to tell. Wish Apple would fix that, or just get rid of comments. Agreed. I even double-checked preferences just know. I have all email notifications enabled. Comments don't trigger those. But the new edit window is nice! Regarding your question, the reason is to get past the bugs in the prior release (for me, Device Hub was constantly crashing or misbehaving). I intentionally skip Xcode betas and RCs to avoid headaches like this. I skip a lot more than that. My primary development, and exclusive submission, machine is Sequoia with Xcode 26. And even that has caused problems. Use of the 26 SDK opted my app into Liquid Glass which, for whatever reason, made my toolbar items completely obscured on 26/27. Kinda the opposite of the intended effect. This is a legacy app anyway, so now I build on my older Ventura machine with whatever Xcode that is. But this is not an App Store submission. When Apple tightens the screws in April next year, I'm going to need a separate machine just for App Store submissions. I'm happy to let all you folks work out the bugs for me. I didn’t realize there was a delay between a public Xcode release and when its builds are accepted in the App Store. It’s clearly not obvious, given the “me too” posts piling up on at least one Twitter thread I found. It's actually an inconsistency. You can use late beta builds when submitting for a major new marketing version. But even then, there's a delay of a couple of day. People just accept it and forget it about. But it's the same delay. Having to watch yet another page when you’re desperate for bug fixes pushes the onus onto thousands of app devs. A simple "App Store Connect" status on the Download page would fix that, possilby like this: There's no way Apple could manage to do that.

Don't use the comments. They hide your replies. Ideally, tag someone with @Bikrrr, to send out an e-mail notification. I swear I’ve pushed builds soon after public Xcode releases before I'm sure you have. But in most cases, I've seen very similar comments in similar venues. Personally, I don't see why anyone would ever want to do that. Apple's been known to make last-minute changes in the past. These days, there are very significant changes in app behaviour based on Xcode version (via SDK version).

I updated my report with your info that it's occurring on Sequoia too. But that's actually bad news. It means this is established code that isn't likely to be changed. The problem here is that this problem is due to old mouse scroll wheel support being used for a trackpad. That was originally designed when trackpads were novel. But now trackpads are the standard and mice are unusual. That means that you need to focus on properly supporting gestures. Then add this fallback logic. That will then support the relatively advanced modifier behaviour that you're seeing in Pixelmator Pro and Maps. I mentioned before that I only use this method as a crude hack. In once place I have a scroll view embedded inside another scroll view. That tends to result in such crude hacks. But I wasn't telling you the whole truth. I was thinking about the app I'm currently working on that uses mainly standard controls. I have another app that in development/on hiatus for several years. In that other app, I do use this method: // Handle a scroll wheel event. override func scrollWheel(with event: NSEvent) { if event.modifierFlags.intersection(.shift) == .shift { scrollWheelMagnify(with: event) } else { super.scrollWheel(with: event) delegate?.didChangeFrame() } } This is a mapping app, so it's using shift to zoom the way Maps does. But more importantly, this is stricly for mouse scroll wheel support, or modifier support. The app has much more extensive gesture support at the view controller level. For this operation on iOS, I'm using a subclass of UIPanGestureRecognizer. On macOS, I'm using the older mouseDragged(with:) style of user interaction APIs rather than NSPanGestureRecognizer. I'm not sure why. But perhaps I was just using the APIs I was most comfortable with at the time. But that's irrelevent. The important part is that I have another layer of API support that properly handles the gesture. The scrollWheel method itself is simply insufficient. You don't need those "liveScroll" notifications at all.

What is the recommended Apple-supported way to diagnose a discrepancy where codesign verification of the same system executable succeeds in a normal GUI Terminal but fails in another execution context? Are you using AI to write these replies? That's a problem, because the bug is in your AI.

This API is starting to seem like a downgrade from placing a plist file in /Library/LaunchDaemons because at least that was able to work very reliably. I'm sure that if you move the executable to a new location, the old system would have also failed to find it. it doesn't have an entry for my app in the Applications folder. But that's where its launch daemon is trying to start from, and that's where the entry for it is listed if I run sfltool dumpbtm. This suggests to me that it's not actually the default copy from Launch Services that determines where it runs. Am I correct, and if so, any idea where it's actually getting the path of the app that's associated with the launch daemon? Does it matter? Trying to code for underlying implementation logic usually has a poor outcome. I've seen many funky little aspects to launchd. Any one of them could potentially be the cause. But because it has so many of these oddball behaviours, it's very unlikely to be changed. And if it does get changed, it'll be certain your break your hand-crafted solution. For an app that has system-level dependencies like this, there's nothing wrong with restricting it to /Applications. Some people will complain, of course. They always do. You can simply blame Apple. People will generally accept that. That's why so many developers use that strategy. In the past, a launch daemon would have probably required a package installer. You can still do that, and install into /Library/LaunchDaemons and some other stable, hidden path. And you can also check for error conditions. Check the location you're running from and then check the path that launchd is trying to use. Tell the user about it and let them handle it. Oh, wait, you'd have to use launchctl to get the path, wouldn't you? Sorry, that's not API. But if only there was an API for such things. There used to be. It's still there, but deprecated and never replaced. Maybe next year!