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!

the issue lies with Apple's payment system, maybe their fraud prevention on payments. Maybe. Remember, Apple is a California company. There's a very large number of payment methods, carriers, systems, and cards across the world. Many of those are specific to local or regional markets. Those methods are unlikely to work for Apple. You'll need to choose more "brick and mortar" establishments. And if that fails, go up to "glass and steel".

As a digital banking provider, we work to our clients’ launch timelines, so these delays directly affect dates they’ve committed to their members. Then being the Apple software experts, it's your responsibility to stay on top of relevant platform issues and keep your clients informed of potential schedule impacts.

As of 14:45 UTC on Friday, October 30, 2026, this is still happening. It's been happening for about 10 years now. People are just going to have to wait a couple of days.

I am at a loss what to do - The only thing I can think of is potentially try buy an app in the existing space that has already been approved then updating it to be more like my idea. Although that once again comes with it's risks, what if I update it and it gets rejected. Thoughts? I think that would be the least of your worries at that point. If there exists a marketplace of similar apps, that should be a Big Red Flag, complete with klaxon alarm. I say cut your losses. I know it's painful, but you gotta move forward. This app is a dead end. Not enough developers consider the business issues. Or at least, not enough legitimate developers. That's one of the ironies of this "review crisis". I think most of the people posting these complaints are honest, but unaware of business issues and the broader market. For professional scammers and fraudsters, the app is irrelevant. It's only about the money. These people aren't getting rejected. They're professionals. They know how to work the system. Unlike all these people in the forums asking "has anyone ever encountered this before?", seemingly ignorant of the previous 10,000 identical posts, professional scammers are well aware of what Apple's doing. They stay on top of these things. Apple's new review regimen is not a barrier or blocker for them. But it does raise their costs, and that's a problem because, for them, it's only about the money. It makes the web and other mobile platforms more attractive. There is a happy medium. Developers can build innovative, new apps and make money with them. Users will love that. They'll pay for it. Apple will love that because they'll make money too. It's a win for everone. But it's not easy. And it takes time. For all these people complaining about weeks of waiting, just wait until they find out how long writing a decent app takes! Unfortunately, it seems that lots of developers have only put in the technical effort, neglecting the business research. They've written a great app. But that's irrelevant. The market for those apps is saturated. No one's ever going to see that great app. The Big Players have cornered the market and they're advertising. You're simply not going to break into that market with any level of technical expertise. To quote an old fight between my parents, "If Howard Horton could've made any money on that chicken farm, he wouldn't have sold it to you". My mom's logic is still valid in the age of AI. (name changed to protect business-savvy chicken farm seller.)

So the problem isn't limited to macOS 27.2. That might be worth adding to your report. I forgot to add that it behaves the same in Sequoia.

Then Apple should fix the issue. And if they don't? By reporting issues. That's what this forum is for. This is a discussion forum for Apple developers. It's a separate service from Apple's Feedback Assistant. I'm not sure why you're here. I like to help other developers with practical, real-world solutions. But you can't help 'em all. So file that feedback report. Hopefully Apple will fix the problem real soon.

A method that is not depecrated should work as intended. And what if it doesn't? If developers don't hold Apple to basic standards, no one else will. How do you suggest we do that? We have no power over Apple. We only have power over our own code. Apple only has power over the hardware, the operating system, and the APIs. In many cases, especially with respect to user interface controls, developers still have a lot of freedom to make their own implementations. NSSegmentedControl style is not deprecated, neither is ObjC. No, but you aren't going to see them in any WWDC anytime soon. These are not areas where Apple is putting any focus, except in the manner that you're complaining about. Your options are 1) live with it or 2) reimplement it.

I did broaden what I was discussing, but the "this" was about having a secondary standalone executable in the app bundle being granted Accessibility permissions along with the main executable. Does that work? Maybe you should narrow the question a bit. I don't know anything about Accessibility APIs. But from what little I do know, these APIs would interact with the user, the user's software, and the user's logged in session. Since a daemon runs as root, it seems like that wouldn't work. So even if you could inherit those TCC permissions from the app, it's a different user. And on macOS root isn't as much of a "super" user as it is elsewhere. I like software that makes things as clear as possible. Having the secondary process being named something like "MyApp System Service" or similar would make it a lot clearer An app-like bundle should provide that functionality. I have a launch agent I'm developing and it shows up as you would like. However, this particular area of the operating system is not clear at all. The process name is irrelevent. The domain and label are the important parts. And depending on the OS, the user may see these structures much differently, and never clearly. Look at System Settings > General > Login Items & Extensions > Background App Activity. This display has had a few different names and a few different designs. what you are describing is something that is badly designed and implemented, which is why I am critical of it I understand that you don't like it. No one does. I'm just suggesting that you may not understand the actual intended outcomes that this design supports. I'm not saying I have any insider knowledge. I don't. I simply have some dark-pattern conspiracy theories about it. I'm afraid this isn't a useful suggestion. Ah, but it is useful. You're talking about an app for a niche platform, with a niche market, and high-friction user experience. And I'm willing to bet that you actually aren't talking about accessibility. That's simply the API that Apple provides that, as a side effect, grants certain low-level system access. This is not so much a technical problem as a business problem, and I'll leave it at that.

an automated coding-agent execution environment (Cody/Codex) Ah! Probably should've led with that. I only need to ... understand why code-signature verification sometimes fails in the automated execution context. It doesn't. Could you recommend the most useful read-only diagnostics for comparing the two execution contexts? Are you sure you really want to dig into this? The short answer is your AI software is doing it wrong. And I'm not even sure what "it" is or why it would be trying to check code signatures. I don't know what to tell you. There do exists different execution contexts. Sometimes, a given execution context requires a logged-in user session. Usually this is because some command-line tool is trying to break through the user interface/command-line barrier. That's only possible when there is a user logged in to the machine, and using Terminal. But when logged in via ssh remotely, it's a different execution environment and those boundary-crossing operations will fail. All that being said, when I try this on a remote ssh connection, codesign works fine. So while there is an conceptual artifact that corresponds to what you're describing, the cause is probably something else. I wouldn't be at all surprised if they just vibe-coded it.