at the very least the documentation should be updated to document Good luck with that. It's kinda funny how much they've standardized on using URLs instead of file paths. But URLs are incredibly complicated and very poorly documented. They seem simple, but they aren't at all.

I’m trying to verify one specific distribution boundary before finalizing the onboarding flow Yeah. I get it. It's like you can ship a Powerpoint document with your app if you want. The user can double-click that. If they have Powerpoint, or some other app that can open Powerpoint documents, then they can open the document. If not, I think they'll get a prompt to search the App Store. If that's the experience you're talking about, then it should be fine. But if that bundled document of yours does something else, and leads the user to install some other app, then you've likely got a problem. I’m mainly trying to determine whether this pattern is something Apple has previously accepted or whether there is a specific guideline that would prohibit it. Neither of those is relevant. The previous submission history of any other app from any other developer (or even your own app) is irrelevant to any future submission. And funny enough, the guidelines are also irrelevant. Sometimes it seems like people have those paragraph numbers memorized or something. But they don't really matter. The individual guidelines are just guidelines. They are there to help developers plan which apps to develop and how to implement them. They are a way to categorize and talk about specific kinds of apps from an App Review perspective. But App Review can reject your app for any reason, regardless of whether there is a specific guideline or not. They will usually tell you the guideline just so you know what to do. But they can also just say, "LOL, no!"

Never use the comments. They hide your replies. I'm not sure Apple Developer Support will be able to help. They tend to avoid any App Review questions. However, Apple does regularly hold "Meet with Apple" sessions where you can talk directly to App Review. But generally speaking, if you're worried that App Review is going to reject your app, you're probably right.

Anxious for the fix to come soon. (CVE-2023-24329) No need to worry. Sounds like apple_chat_bot is on the case!

The documentation says it returns an empty string, not nil. Just so you know, manually traversing URLs is always tricky. Sometimes you'll get a reference URL, which can't be traversed. And sometimes you'll get a ".nofollow" URL, which is undocumented.

We need a sandboxed Mac App Store app to install its bundled, sandboxed SMAppService LaunchDaemon through one in-app action and the required native approval. The LAN listener must be unprivileged and remain available after logout and at boot. Can't do that in the Mac App Store. LaunchDaemons run as root.

does Guideline 4.3(b) prevent an app that is already approved and live from shipping updates? Each new submission is evaluated independently of all previous submissions of the same app, and all previous submissions of all other apps from all other developers. Any guidance from App Review, or from developers who have faced 4.3(b) on an update rather than a first submission, would be very welcome. By guidance, I assume you mean suggestions for getting the app approved. Sorry, but I don't have any such suggestions. I can tell you that developers obsess far too much over the guidelines. The fact that so many developers have memorized the individual paragraph numbers is amazing, but sad. They're just "guidelines". It isn't any kind of law, regulation, or policy. Apple can, and will, reject your app without citing any guideline at all. This is a power relationship problem. Apple has all the power, developers have none. Getting rejected is a signal that you need to do things differently. Trying to beat down a door for 288 accounts is a waste of your time. The fact that they are citing a specific guideline is a suggestion regarding what you need to do differently on your next app idea.

It will be a few days before I can test that on 13-26 and remove the XPC service. An unsandboxed launch agent contained in a sandboxed app does seem to work, with XPC, on versions 13, 15, and 27. Haven't tested the other versions. I'm unaware of any specific change over the past two years to get sandboxed XPC working to this extent. Obviously this isn't for the Mac App Store. But it will simplify things. Ironically enough, now I can get rid of a bunch of XPC.

From what other people have posted, there can be a substantial delay before search results get updated.

Would a Mac App Store application be permitted to: Apple never pre-approves apps. Sometimes it's obvious (to everyone except the developer) that a given app idea would be immediately rejected. I'm not familiar with any of these AI platforms. Can you explain more about what this thing does? It sounds like you'll need to explain that to App Review too. The .mcpb and the helper executable it contains From what I've heard, I doubt the bundled helper executable would be sandboxed. If not, then you can't include it. And even if it is sandboxed, it would still have to comply with Mac App Store guidelines. If that leads the user to a situation where the app "presents its own installation", then that would be right out.

I’m not sure why you had problems with this, but I’ve done this myself and it worked for me. Your relationship to these technologies and APIs is much different than mine. I will only ship, and recommend, those techniques that I can get to work. It took me about 2 years, 1.5 apps, significant effort, and many attempts to get a sandboxed app to talk to a sandboxed launch agent via XPC. I have utterly no idea why I couldn't get it working at first. As far as I know, I'm not doing anything differently now. There must have been some subtle difference or bug, but I don't know what. I just tried turning sandbox off on my launch agent on macOS 27 and it worked! So I guess I've continued to make subtle improvements. It will be a few days before I can test that on 13-26 and remove the XPC service. This stuff ain't rocket science. In my experience, putting satellites in orbit is much easier than this.

Anyone else have this issue? Use encryption that isn't provided by the operating system? No way. Why is Apple telling me "they don't have the right tools" to investigate the App Encryption Documentation on their own AppStoreConnect? I think they just mean that they don't have any visibility into the progress of any individual investigation. If you self-select yourself out of the the automated flow, all you can do is wait.

The API has been deprecated since macOS 11, not 10.6 Sorry. I read it wrong. But that's still Big Sur. The oldest reasonable OS these days is Ventura. many users (designers) depend on this functionality What's the functionality? Why does your app need this function? How would you do whatever this functionality is on iOS? Just curious: in the proposed workaround the sandboxed app submitted to the Mac App Store would only try to create an XPC connection to a mach service with the app group identifier (user opt in). My understanding was that this is allowed, due to the app group. The app is still fully sandboxed and the user can optionally download an external Helper. Setting aside the App Review complications, that's a bit tricky. I tried to see if I could implement something like this in an app I'm developing. I could not get a sandboxed app to talk directly to a non-sandboxed launch agent, even if both were in the same app group. This was a technical limitation. If the launch agent is sandboxed, then it works. The launch agent can have a non-sandboxed XPC service. But then you're back to App Review concerns. App Review certainly won't test this functionality. And that means you won't be able to mention it on the App Store or lead users to the external download. Yet you MUST mention it in the App Review notes. Otherwise, that's a risk of "hidden functionality", which can lean to full developer account termination action. And even if you make it through all that, you still have to explain it to the users.

what would be the correct place for a Login Item app? Contents/Library/LoginItems/ Here is some documentation, and some older docs. The LaunchItems surely isn't it I'm not aware of that folder. Another option would be to convert this to a Launch Agent. Launch Agents can be kept alive if they crash, or run on a schedule. And they have a few other neat tricks like XPC. It can be a bit tricky to setup.

My macOS app Find Any File contains another app inside its Resources folder. Executables shouldn't go in the Resources folder. What kind of artifact is this? Is it a launch agent? A login item? Are you changing the NSApplication activationPolicy?