I’m looking for some advice regarding the usage of temporary exception entitlements in Mac App Store apps. Specifically the Apple Event Temporary Exception to communicate with other third party applications (not first-party macOS system apps): The Best Practices for Submitting Scriptable and AppleScript Apps to the Mac App Store section is a bit vague (how to 'request' a temporary entitlement?) and I couldn't find it mentioned in the Review Guidelines. Before designing, implementing and testing functionality based on the Apple Event Temporary Exception I’d like to know if these entitlements would: A. Always be rejected on the Mac App Store B. Only accepted in highly specific use cases C. Accepted if there is a clear use case and sufficient argumentation For this particular use case I’d like to send Apple Events to Adobe Illustrator and QuarkXPress. The application helps the user with some design tasks in their documents. The app requests the currently open documents and accesses document content to process used design elements. This is optional functionality that the user must explicitly enable in the app. I’m aware that the com.apple.security.scripting-targets entitlement is preferred. (Side question: are these always allowed or can they also be rejected for third party app scripting?) However, many third party applications don’t offer any scripting access groups in their definition, including Adobe Illustrator and QuarkXPress in this case. So before spending a lot of time implementing this feature I’d like to have some indication whether it is unlikely that sending Apple Events to third party apps will be allowed on the Mac App Store. Thanks for any insights!

I submitted my last macOS application with IAP on Oct. 23rd, 2025. I was able to test-purchase a non-consumable product with the StoreKit configuration file at that time. These days, every time I test a new macOS application with the configuration file, a purchase process fails. The thing is they all now fail if I test the store with existing applications that were once working. Xcode shows the following debugging error. Purchase failed with error: systemError(Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service created from an endpoint was invalidated from this process." UserInfo={AMSDescription=An unknown error occurred. Please try again., AMSURL=http://localhost:53272/WebObjects/MZBuy.woa/wa/inAppBuy, NSDebugDescription=The connection to service created from an endpoint was invalidated from this process., AMSStatusCode=200, AMSServerPayload={ All my iOS apps don't exhibit the same problem. This StoreKit fiasco only happens for macOS applications. And I'm thinking that it all started to occur after I began using Xcode 26. Not a single line of code has changed. But the applications that were once able to process IAP all now fail. And I'm suspecting that it's Xcode 26 that is responsible for this failure. My Xcode version is 26.2, by the way. Any macOS application developer experiencing the same problem?

Update: Turns out it works for others, apparently, and I also found one of my Macs where it does work, too. So it must be something pertinent to my systems. Oddly, though, the same ones where it now fails used to work because I had TestFlight enabled there before. I have TestFlight set up on App Store Connect, and I have already about 50 testers subscribed. Today, I found that the Public Link does not work any more: Once TestFlight.app is installed, and one clicks the link to add my app to TestFlight, it always shows the error ""Unable to Open Link" in TestFlight.app: I've tried this on several Macs (Ventura and Sonoma), and with different Accounts, both where the app was already added or not. Is something generally broken, i.e. do others see the same issue with their TestFlight links, or is it just me? How do you suggest I get this resolved? Here's an example link I set up for this purpose - it only allows a handful of subscribers, so please do not actually subscribe but just see if you even get allowed to, or if you get the same error if you must try: https://testflight.apple.com/join/oV8NNojg And here's how it's set up:

I have a macOS App Store app with a lifetime non-consumable IAP. I can’t do a normal App Store app transfer, so the app will be re-released as a new app under a different Apple Developer Team. That means users’ old purchases won’t automatically carry over. I want to let existing customers keep their lifetime access in the new app, but I want to do it in an Apple-approved way and avoid anything that would look like a custom license-key unlock flow. A few questions: Is there any Apple-supported way for the new app to recognize a user’s purchase from the old app? If not, is the safest App Review-compliant option to make the new app’s equivalent IAP temporarily free or discounted? Would a custom migration/recovery flow for prior customers be allowed, or would that likely violate 3.1.1? Has anyone handled this kind of migration before? Thanks.

Hi, I’m hoping someone can help clarify the correct entitlement format for the Enhanced Security capability in a macOS App Store build. Context Our app is a sandboxed macOS app built with Xcode 26.4. We enabled the Enhanced Security capability in Signing & Capabilities, and we configured the entitlements based on the current documentation. What’s confusing me The Xcode 26.4 release notes say apps that already adopted Enhanced Security should remove: com.apple.security.hardened-process.enhanced-security-version com.apple.security.hardened-process.platform-restrictions and replace them with: com.apple.security.hardened-process.enhanced-security-version-string with value 1 com.apple.security.hardened-process.platform-restrictions-string with value 2 Reference: https://developer.apple.com/documentation/xcode-release-notes/xcode-26_4-release-notes The entitlement reference pages also seem consistent with that: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.enhanced-security-version-string https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.platform-restrictions-string So our app currently uses the new -string entitlements with values "1" and "2". Our App Review rejection said: The app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Entitlement "com.apple.security.hardened-process.enhanced-security-version-string" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions-string" value must be boolean and true. That’s the part I can’t reconcile with the documentation. Questions For a Mac App Store submission built with Xcode 26.4, should these two entitlements use the new string-based form, or Boolean true? If the expected format has changed, is there any updated guidance beyond the Xcode 26.4 release notes and current entitlement reference? If Apple staff or anyone familiar with this can clarify what format is currently expected, I’d really appreciate it. Thanks.

Hi everyone, We are facing a critical blocker with our macOS app processing. Since March 5, 2026, every single build we have uploaded (8 builds total) has been stuck in the "Processing" state for over 4 days. For our project, due to the large binary size, processing usually takes about 4 to 6 hours normally. However, we now have a long queue of builds that haven't transitioned to "Ready to Submit" for up to 80+ hours. Stuck Builds List: 1.0.0 (444): Mar 8, 3:09 PM (Processing) 1.0.0 (443): Mar 8, 5:36 AM (Processing) 1.0.0 (440): Mar 7, 6:37 AM (Processing) 1.0.0 (438): Mar 6, 5:01 PM (Processing) 1.0.0 (434): Mar 6, 12:04 AM (Processing) 1.0.0 (433): Mar 5, 6:26 PM (Processing) 1.0.0 (432): Mar 5, 10:51 AM (Processing) 1.0.0 (431): Mar 5, 6:11 AM (Processing) (Note: The last successful build was 1.0.0 (429) on March 4, which processed within the expected 6-hour window.) There have been no changes to our project settings, Info.plist, or entitlements since the last successful build. This is completely halting our scheduled update release. Is anyone else experiencing a similar backlog with large macOS binaries? Or is there a known issue with the App Store Connect pipeline for the macOS platform recently? Any help or investigation from Apple engineers would be greatly appreciated. (Feedback ID: FB22156358)

Hello everyone, I’m facing an unusually long app review delay and would appreciate any insight from the community. My app has been stuck in the "Waiting for Review" status since February 10, 2026, with no updates or feedback. App details: App ID: 6756574744 Case Number: 102824473424 During this time, I have: Submitted several support requests Filed multiple expedited review requests Tried contacting through email and the support section Attempted to follow up on the case status Despite all of these efforts, I have not received any response, acknowledgment, or update regarding its review progress. I understand that review times can vary, and delays sometimes happen. What concerns me more is the complete lack of communication. At this point, it feels like the app might be stuck in the queue. Has anyone else experienced long "Waiting for Review" times recently? Is there anything else I can do to get clarification or make sure the submission is not blocked for some reason? Thanks in advance for any insight!

Hello everyone, My app has been in “Waiting for Review” status since February 4, 2026, and there has been no progress or update since then. Normally, my previous submissions were reviewed within a few days, but this time it has been significantly delayed. There are no messages in the Resolution Center, and I have not received any communication from the App Review team. Has anyone else experienced similar delays recently? Is there anything I can do to follow up or escalate this review? Any guidance would be greatly appreciated. Thank you.

I'm trying to test the update process for an app containing an FSKit module that I'm distributing on the Mac App Store. (I'm also distributing the same app directly with Developer ID, but here I'll focus on App Store because that's the behavior I've been looking at first.) To do that I'm using an internal tester group on TestFlight and then testing an update with TestFlight. Below is the behavior I'm seeing on macOS 15.7.2 (24G325). I've noticed that if an app update is triggered while a disk is mounted using the FSKit extension, the disk is automatically unmounted without warning (FB21287341). That's already undesirable itself in my opinion, but on top of the unmount, there are two other problems: That unmount doesn't seem to be a "clean" unmount and doesn't call functions like synchronize (FB21287688). Now, in my case, my app only provides read-only access, so that doesn't actually matter much in my case. However, I'd imagine if I were to add write access at some point in the future, this would go from "doesn't matter" to "very bad." I've seen a few cases where quitting or crashing the FSModule process while a volume is mounted without actually doing a clean unmount causes a lot of "disk-related actions" (for lack of a better term) to freeze (FB21305906). For example, a use of the mount(8) command or trying to mount a disk at all freezes, and opening Disk Utility stalls on a "Loading disks" spinning indicator. This happens until the Mac is rebooted. I did notice this issue once while testing updates via TestFlight a few times. The same applies if I simply delete the app with Finder instead of updating it. Is there a way to prevent the extension's process from terminating in this case and/or another workaround I could use without waiting for a macOS update to hopefully change this behavior? And does observing this kind of behavior with TestFlight's update behavior suggest the same thing could happen on the App Store with its automatic updates? I'm concerned that pushing an update via the App Store will unexpectedly unmount disks or cause the system-wide issues described in FB21305906 at a random time, which is a pretty big disruption for users.

I understand that private APIs are not permitted under Apple’s App Review Guidelines. However, our application requires I²C communication, and we are currently using the following APIs: IOAVServiceReadI2C IOAVServiceWriteI2C IOI2CSendRequest.These api's are not permitted by apple. I didnt found any alternative public api to achieve I²C communication. please suggest any public api's for the same or any chance to use this private api.

We're developing an Electron app for MacOS App Store. When updating our app through TestFlight, TestFlight prompts "Close This App to Update", and when I click "Continue" our app would be "Terminated" for update. Now this is where things go wrong. On MacOS 15 our app seems to be gracefully terminating (We attached it with lldb and it shows that our app returns with 0 when we click "Continue") which is fine. However for MacOS 26 though, it seems that TestFlight just directly SIGKILLs our app (indicated by lldb), which means that all of our app's child processes are left orphaned. Even worse, our app is singleton, which means that when the app relaunches it fails, because the leftover child processes from the previously SIGKILLed session is still alive, and even if we want to kill those orphaned child processes we can't because our app is sandboxed thus cannot kill processes outside of the current sandbox. We captured output from log stream (app name redacted): 12-02 22:08:16.477036-0800 0x5452     Default     0x5a4a7              677    7    installcoordinationd: [com.apple.installcoordination:daemon] -[IXSCoordinatorProgress setTotalUnitsCompleted:]: Progress for coordinator: [com.our.app/Invalid/[user-defined//Applications/OurApp.app]], Phase: IXCoordinatorProgressPhaseLoading, Percentage: 99.454 123: Attempt to set units completed on finished progress: 214095161 2025-12-02 22:08:16.483056-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:connection] Received termination request from [osservice<com.apple.installcoordinationd(274)>:677] on <RBSProcessPredicate <RBSProcessBundleIdentifierPredicate "com.our.app">> with context <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N re portType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:08:16.488651-0800 0x53ba     Default     0x5a5c9              167    7    runningboardd: (RunningBoard) [com.apple.runningboard:ttl] Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd(274)>:677] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N" ID:167-677-1463 target:system attributes:[ 2025-12-02 22:08:16.489353-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [app<application.com.our.app.485547.485561(501)>:2470] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N reportType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:10:23.920869-0800 0x5a5a     Default     0x5a4c6              674    14   appstoreagent: [com.apple.appstored:Library] [A95D57D7] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:32.027304-0800 0x5ae5     Default     0x5a4c7              674    14   appstoreagent: [com.apple.appstored:Library] [BEB5F2FD] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:36.542321-0800 0x5b81     Default     0x5a4c8              674    14   appstoreagent: [com.apple.appstored:Library] [185B9DD6] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} The line "Terminating with context" seems suspicious. This line is not seen on MacOS 15, only MacOS 26. Is this documented behavior? If so, how can we handle this?

I understand that private APIs are not permitted under Apple’s App Review Guidelines. However, our application requires I²C communication, and we are currently considering the following APIs: IOAVServiceReadI2C IOAVServiceWriteI2C IOI2CSendRequest Could you please confirm: Is there any provision to use these APIs in a Mac App Store–approved application? Are there public alternatives available for achieving I²C communication on macOS? Thank you for your guidance.

We have initiated the development of a new application, which is exclusively compatible with Apple silicon chips. As our application utilizes artificial intelligence, it is not operational on Intel-based systems due to specific technical constraints. Using the Transporter app, we tried to submit a package that only supports arm64 but we received the following message: "Validation failed (409) Invalid bundle. The “live-mac.moises.ai.pkg/Payload/Moises Live.app” bundle supports arm64 but not Intel-based Mac computers. Your build must include the x86_64 architecture to support Intel-based Mac computers. For details, view: https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary. (ID: 8b93f8c7-ac3d-4665-934a-e1a81832cc18)" Upon reviewing your documentation, I noticed that: "To only support Macs with Apple silicon, your application must require a minimum OS version of macOS Monterey 12 or later and must never have supported Intel-based Macs." Given that we launched a universal package as our initial version, I would like to inquire if there are any alternative approaches that would allow us to limit the distribution of this application to exclude Intel chips.

I received the email from Apple entitled "Final reminder: Answer the updated age ratings questions." However if I login to App Connect, or click on the link in the email to go directly to App Connect, there are no questions. There are 6 tabs/sections in App Connect, flicking through them, there are no questions about age ratings. Even if I could find these questions, if there are no apps actually released to the App Store (and no plans to release any) is answering these questions necessary? The Apple email sounds quite threatening in its tone, hinting at consequences if you don't comply, but I can't comply because no questions in App Connect are being presented.

Why can’t sandboxed mac app store apps have full disk access available in the system settings for full disk access? I discovered mac app store apps in release mode cannot access the ai auggie command line program and other command line programs like opengrep on your system. Debug builds fine. I came up with a workaround: Since I have an ssh client built in for connecting to remote servers, why not connect to ssh on the same local machine… Ask the user for their username and password in a popup. To do this, you have to enable remote login on your mac in system settings -> sharing. In addition you must grant full disk access to cli ssh in system settings: add /usr/libexec/sshd-keygen-wrapper It all works, but I don’t see the cli program in mac settings. To remove the cli program you must run a command line program to remove all full disk access support from all apps. No way to just undo ssh. So my question is, even though I got CodeFrog all working for a mac app store release, should I not do it because it’s insecure or too complicated with the system settings? Should I instead sell the app off the store like Panic Nova? Need some advice. I have not implemented in app purchases yet. Should I just have a reality check and sell the app off the store, or try for app store approval? Bummer… Maybe I’m ahead of my time, but perhaps Apple could review the source code for apps requesting full disk access and make sure there’s nothing fraudulent in them. Then, developer tools app store apps could be in the store with the user’s assurance that nothing is happening behind the scenes that is scary. From: https://blog.greenrobot.com/2025/11/10/i-have-a-decision-to-make/ Related post: https://developer.apple.com/forums/thread/806187 I submitted a code level tech support question for this. They directed me here.

I attempted to create an ad campaign for an app in the MacOS App Store, but the Apple ads website does not seem to allow this. The Apple ads website seems to assume that my app is in the iOS App Store. Clearly the MacOS App Store is not a priority, but this has been unreasonably difficult and confusing. Can someone please tell me if Search ads in the MacOS App Store are supported, and if so, how can I access this support?

Dear App Review & App Store policy team, I am writing as an independent macOS developer who has spent more than the last six months building TilesWM, a full‑featured window‑manager that rivals existing products such as Magnet, Divvy and BetterSnapTool. The app works exactly like those solutions: it uses the Accessibility (AX) API to move and resize arbitrary windows, registers global hot‑keys, and stores user preferences locally in ~/Library/Application Support/<bundle‑identifier>. When I attempt to submit TilesWM through App Store Connect the validation process failed with two errors, one of which was relatively easily solvable with the help of "ssmith_c" and "Quinn". The other, the hard blocker: Sandbox not enabled – the app does not contain the required com.apple.security.app-sandbox = true entitlement. but: The same accessibility entitlement is absent from the binaries of Magnet, Divvy, BetterSnapTool and other window‑manager apps that are already available on the Mac App Store. Those applications were on the Store before Apple introduced the mandatory sandbox requirement (≈ macOS 10.7.3-ish). Consequently, they continue to operate without a sandbox while new entrants are forced either to abandon the platform or to distribute outside the App Store. This situation creates an uneven playing field that contradicts Apple’s stated commitment to an open and competitive ecosystem. All developers pay the same $99 annual fee and should follow identical review guidelines; yet legacy window‑manager apps enjoy a privileged exemption that new developers cannot obtain, effectively granting them a perpetual non‑compete advantage. What I am asking for Clarification: Is a missing Sandbox entitlement truly unsupported for Mac App Store distribution or is there a way to "request" an exception? Policy action: Please evaluate an option to provide a concrete path forward so that TilesWM can be submitted without having to abandon the App Store. Point of contact – If this issue falls outside the scope of App Review, kindly direct me to the team or individual responsible for macOS sandbox policy decisions. I remain committed to distributing my app through the Mac App Store because it is the primary channel users trust and expect. I believe that a fair resolution will benefit developers, Apple, and end‑users alike by expanding the selection of high‑quality window‑management tools. Thank you for your attention to this matter. I look forward to a constructive response and to working together toward an equitable solution. Respectfully, Denis Steinhorst Full‑Stack Engineer & macOS enthusiast Bundle ID: dev.steinhorst.tileswm

Hi, I am facing a very weird issue where I am unable to download our own application from TestFlight for testing. This issue only happens for one of our applications; we are able to download our other applications without any issues. Furthermore, this only happens on one of our MacBooks; the game downloads fine on our other MacBook (macOS 15) and can run our application. When running the console, I noticed this error being thrown when the TestFlight fails the download: I have tried reinstalling TestFlight, clearing all instances of our application as what Finder can find, restarting the MacBook but nothing worked. Is there anyone that faced this similar issue, or any Apple staff that could help with this? OS version: macOS Tahoe (26 Beta) latest TestFlight was able to download on this version previously, until one day it couldn't (and not sure why), tried downloading latest version but did not solve the issue. Note: We noticed that we are unable to install our own application from the Appstore as well, on this MacBook that has the TestFlight issue.

We’ve been using the new Icon Composer–generated app icons for our existing universal bundle (iOS + Mac Catalyst) app. The icons work perfectly for iOS on the App Store. On macOS Tahoe (macOS 26), however, the App Store listing doesn’t display the app icon — it just shows placeholder while downloading. After the app is installed, the icon displays fine everywhere (Dock, Finder, Launchpad, etc.). Setup: using .iconset generated via Icon Composer, bundled with .png inside the .icon file. On older macOS App Stores, the app icon shows as expected. On Tahoe App Store only, the issue appears. Could this be because the App Store expects .svg variants inside the .icon file for proper display in the Store? Or is there any updated requirement for Mac App Store metadata icons vs. bundled app icons? Any guidance would be much appreciated.

Hello, I have a question regarding the Mac App Store deployment and App Review process. Our macOS app will also be distributed on the Steam platform. In our current build setup, the App Store build output (inside Contents/MacOS/) may still contain Steam-related dynamic libraries (e.g., libsteam_api.dylib) and metadata/configuration files (such as .txt files used only by Steam) These files are not used in the App Store version. Users will not see any Steam-related information, functionality, or UI when the app is running. Their presence is simply a byproduct of the current packaging process. My concern is whether including such unused Steam-related files in the App Store submission could be considered a violation of App Store Review Guideline 2.3.10, or otherwise lead to rejection during review. Would Apple recommend that we strictly separate the build targets so that the App Store submission does not contain any Steam-related files, even if they are unused and invisible to the user? Thank you very much for your guidance.