This has me wondering now, is this is supported behavior? What is "this"? I think you two might have different concepts of what "works" means in this case. You can absolutely put a launch daemon executable alongside the main app. That's the default and expected configuration. Making it into an app-like bundle is more complicated. The process seems easy enough but it sure took me a long time and many attempts to get it right. But that just gives you standard launch daemon behaviour. You may not be getting the TCC and Accessibility behaviours that you're asking about. This has the disadvantage though of having the helper process and main process have the same name in Activity Monitor, which I think will be confusing to users. So in short, is there a supported way for a bundled application with its own CFBundleName / CFBundleDisplayName key to run as a launch daemon and also inherit Accessibility permissions from its parent app bundle? Or is this, and only this, what you're asking about? If you're happy with the current TCC and Accessibility behaviour, then I recommend you just ignore Activity Monitor. If users vandalize your processes, tell them not to do that or else it won't work. There are tons of duplicate process names in Activity Monitor. Why would they care about yours? the process of granting permissions in macOS is a mess, so I feel like my bug report would be a lot more comprehensive than that Again, I think you're talking about different things. That flow and all those barrers aren't bugs. They are by design. They are "the feature". And they're very fragile and often change. They should be tested in any beta or new OS release, no matter how minor. Code defensively. My recommendation is to focus on your core app features and treat any of those extras that require user assent as "nice to have". Accessibility looks great from a marketing perspective, but you shouldn't depend on it. I have one app that does some of that and it's really annoying. I would greatly prefer if the app were just stand alone didn't nag me with all those accessibility and integration settings. They're broken half the time anyway. And this is a really high-quality app otherwise. These things are almost anti-features.

In the normal graphical Terminal, code-signature checks for /usr/bin/true and the installed Python 3.13 executable succeed. What kind of checks? Please be specific. In an earlier, different execution context, trust verification reported CSSMERR_TP_NOT_TRUSTED. Different in what way? purchasing a paid developer membership What are you really trying to do there then? There's nothing wrong with not having paid membership. But after a certain point, you may be in territory that goes beyond the expected free use-cases. So what is your use case?

Don't use the comments feature. That hides your replies. And ideally, add a @Cam_3344 tag to trigger an e-mail notification. apps in certain categories are getting auto rejected and some good apps (I include my app) are getting auto rejected without being looked at properly. That's certainly true. But developers need to be pro-active. Certain app categories are extremely high risk. Why put in any effort, even vide-coding, in a category that's already saturated? One problem is that developers are focused on thier own apps. Maybe they've used a certain app category before and they think they can do better. Maybe they can. They did some research (not enough, though) and found some existing apps. So they throw their hat into the ring. What's the worst that can happen? But Apple's ~500 app reviewers are looking at 25,000-45,000 apps every day. That's 92 apps per day per person. Even with any amount AI or clever scheduling, app reviewers are still seeing all the apps. They don't look at any of the apps properly! They check for obvious scams, obvious malware, obvious policy violations, obvious crashes, and that's it. Next! But in the case of that 4.3(b), they don't have to do any of that. You're saving them time because they've seen literally thousands of such apps. One look at the metadata and screenshots is all it takes for the fastest possible review and rejection. So why give them that? No amount of documentation or feature list is going to change their minds. It's Apple. If Apple thought the app idea was worthwhile in the first place, they would have already included it in the operating system itself. I've been there myself. I've submitted an app, literally thinking to myself "what's the worst that could happen?" It's worse than you imagine. Don't put yourself in that spot. Write a different app. Don't give them any reason to reject it. Take the money and run.

Every single review cycle before this took about 2 weeks. It has now been over 15 days since my Oct 13th submission Technically speaking, I guess that is worse.

Average 2-3 days for Review in 2025, so maximum (with 84% up) 4-6, not several weeks/months. It's not a linear scale. For one thing, Apple is now using AI for reviews. I have no idea how Apple manages App Review, but I do have a (conspiracy) theory. I think that Apple is slowing review times for new developers and developers with rejections. I've seen people quote messages from Apple confirming the first part. The second part is my speculation. This allows reviewers to approve more apps in the same amount of time. So the average review time is likely going down, not up. Rejections are time consuming and wasteful. Neither the developer nor Apple gets anything out of it. So rather than waste time rejecting apps, clogging up the expedited review queue, and clogging up the appeal queue, Apple just identifies those submissions that are more likely to be approved, and approves them quickly. When you think about it, that's really the only logical explanation. Why else would some developers wait for minutes and others wait for weeks?

I can understand why apple is cracking down on a lot of apps because they must get thousands of spam trash apps submitted every day.. According to the App Store Transparency report for 2025, Apple got 25,000 submissions per day in 2025. According to one report I've seen on the internet, from an industry journal, not Reedit, AI slop has increased submissions by 84% in 2026.

I'm not sure what legacy platform you're referring to You're writing a Mac app in Objective-C. If you encounter problems with that combination, you're usually going to have to figure out a solution yourself. There aren't many other people doing that. OK, it appears that the new role property of NSSegmentedControl is what changes the appearance under macOS 27. Apple should make clear that the style property is ineffective. Documentation isn't Apple's priority. There's 25 years of legacy UI documentation and behaviour that is going to be different depending on 1) the Xcode SDK you're using, 2) your minimum deployment version, and 3) the OS version your app is running on. You can see this very clearly in NSSegmentedControl's documentation. There's lot's of it, isn't there? But it's not complete. Certain properties, methods, and enums don't seem to have any. If you click on them, you'll see why. Anything that was introducted in 10.13 or later isn't documented. That's 9 years now that Apple's stopped updating the documentation. For modern systems, the expectation is that you'll use SwiftUI. I'm not saying you should do that. I tried it for a new app and gave up after six months. Never finished the app either. You can still use the legacy languages, targets, and platforms, but it will be your responsibility to understand how they work and test them on all supported OS versions. Sometimes you can use virtual machines anything before 26. But 26+ adds so much GPU-heavy UI that you really need real hardware for testing. These APIs and behaviours on different OS versions can and will change, even with minor versions. As I said before, the best way to insulate yourself is to write your own code. If you don't like the new behavout of NSSegmentedControl, you'll have to re-implement it. It wouldn't be difficult. It's a simple control.

my XCode install (Version 27.1, macOS 27.2 Welcome to the bleeding edge my objC app with the latest XCode makes the NSSegmentedControl style Those are some legacy languages and platform there The control appears stuck with a style that implements a blue background for the selected segment I do see that behaviour for an NSSegmentedControl in view content. However, an NSSegmentedControl in a toolbar looks radically different. What kind of style are you trying to change? And if it's a minimalistic app, why do you care? Generally speaking, I am finding myself reimplementing a lot of already-provided functionality these days. The higher-level the API, the more likely I am to re-write it.

the licence doesn't make clear whether a commercial app may redistribute it The license clearly says, "distribute the Apple Software solely for non-commercial purposes "

That’s not true. @Peace1, what's not true? If you're going to reply to some specific statement, you need to quote it and, ideally, include a user id to have the forum ping the person you're replying to. I genuinely hope someone from the App Review team sees this Apple is aware of these threads. But that doesn't necessarily mean that Apple sees any problem that needs fixing. Our client Now you're talking. That's what this is - a business. It's Apple's business. They're Apple's users, Apple's developers, and Apple's App Store. There is no Developer Bill of Rights. We exist at the pleasure of Apple. The first step in getting control of a situation is understanding it. If you have clients, you have to remember it's a business for you too. Make sure you factor these issues into your contracts. Apple isn't your problem and you have no control over them. Make sure you get paid regardless.

The automation is written in Python You asked for an API, in the Apple Developer forum. So I answered. However, those APIs really aren't suitable for Python. Maybe Python can call native methods. I really don't know. But that's a side issue. My question to you is how would you implement this Python solution on a Linux system? What parts of that do you find missing on macOS? So far, you haven't given any indication of any blocker. I don't see any reason why you couldn't write the script on Linux, with minor changes for macOS to create and mount Mac disk images. I don't see any requirement for any kind of low-level, APFS/macOS-specific access to filesystem, device, or disk image details. Just create some hidden directories with some UUIDs and off you go. If you've got a malicious user somehow making byte-for-byte copies to confuse your app, tell your users not to do that.

Well, I posted a suggestion here that was reviewed and not approved. Didn't break any rules, either, but was admittedly inconvenient for Apple. I doubt it. Moderation in this forum is pretty rare. Takes them a couple of days to delete blatant spam. It sounds like you had posted a link to a non-Apple website. That's a forum bug/feature. It doesn't allow using the link tool with a non-Apple link. You can still include non-Apple links. Just paste the link in plain text and it will be converted to a clickable link when you post. That does make sense. Otherwise, people could replace the text on a malicious link with something nice. Apple is aware of the "waiting for review" problem. I even got a reply in my thread about it. There's a feedback number and everything! My issues are that 1) these posts clutter up the forum with identical complaints, and 2) there's nothing I can do about it. There are possible fixes in App Store Connect, like an estimated wait time, or a position in queue. There are possible forum fixes, like sticky threads, subscriptions, and private messages. There are possible Developer support fixes, like changing the boilerplate text to reflect reality, or actually replying to questions. But all that takes effort. At least we have an improved editor window in the forum. Apparently it even supports attachments now?

Yes, we recognise that this situation is less than ideal and we’re working on ways to improve things (r. 190253666). So Apple is listening. I have no details as to what that’ll be, or any sort of timeline to share. Yes. I do understand. Any solution that I can dream up with involves some kind of software change or new feature, if not in the forum back-end, then in App Store Connect. Both are fraught with peril. But changes are possible. I'm using the new editing tool right now and that's really nice! Thanks! There are existing support channels for these things I've also recommended "Meet with Apple" session for those cases where I think it could be useful. I've never done that for App Review myself, but I did for technical issues and it was very useful. But I think one important aspect is that people are posting here in this forum as a last resort. They don't feel they're being heard through those other channels. An ideal solution might involve App Store Connect displaying a more accurate estimated wait time or position in queue. I don't get the sense that people inside Apple truly understand what it's like on the outside. When I first setup my account in 2015, I waited 5 months for Apple to fill out a one-page form for Canada Revenue Agency. So when people complain about long wait times with no feedback, I really do understand that frustration. I've also been on the receiving end of a complicated rejection, so I understand that too. It's frustrating to see the same old rejection complaints day after day. But then again, I did setup my account over a decade ago, and I had a personal account before that. When younger people see those 2 day support response estimates, or the 90% in 24 hours review estimates, they don't seem to understand the scale or reality. That's just boilerplate text that can easily be changed. To learn about new threads, plug the forums RSS feeds into your RSS reader of choice I did use RSS feeds with the Apple Support Community years ago, but then they took that feature away and replaced it with "My Subscriptions". These days, my Apple social media activity is much more casual than it was back then. This current "situation" is curious and morbidly fascinating. But I have other things I need to be doing. That's the challenge for an org like Apple trying to run a forum. A bunch of new people are actively engaging. Other people like me are fading away. Where do you choose to allocate your resources for support?

Never mind. Screwed up.

Sorry, but mostly that's all gibberish to me. I've been seeing a number of similar posts recently here in the forums. It kind of reminds me of game developers. I want to use Metal for image processing, but first I have to learn the language and terminology of game developers, which is totally different than traditional software development. So what specific domain are you coming from? Security? failed to open root directory: /: 1 At least this much makes sense. What are you trying to do with root? Apple's file system is horribly complicated, poorly documented, and generally read-only. Apple considers the whole thing to be an "implementation detail". App developers have their app sandbox and some system APIs. They generally aren't welcome messing about in other Apple places. If they aren't in the Mac App Store, then it's (mostly) allowed, but there be definitely lots of hidden dragons.