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.

I work on a MacBook Pro M3 Max 36GB RAM I am running macOS Tahoe Version 26.1 Beta (23B5042k) The last few days I had a couple of situations where Blender 4.5 LTS Froze and I had to forcequit, I noticed Blender would get Deleted with no notification after the forcequit, it was nowhere to be found on the Application List, Finder. Thought it was a blender issue because I run a special module with it. However around 30min ago I was using Mem and the App froze and I had to ForceQuit, The app also got removed, is not on the list of application and nowhere to be found however the icon on the dock which remained shows a Question Mark. I think this is an OS Behavior I just dont know what to attribute it to.

Dear Team, We have developed a macOS app using Unity (6000.0.51f1) that includes learning activities, assessments/tests, audio recording, and video playback functionalities. For security and content protection, we want to restrict the ability for users to capture screenshots or screen recordings of the app (especially via the built-in Cmd+Shift+5 / Screenshot toolbar). We have attempted several approaches, but they have not been reliable. We would appreciate guidance from Apple or the developer community on the feasibility of this requirement. Our requirements: Block or disable screenshots/screen recordings (particularly the built-in Cmd+Shift+5) for the app. Preferably achieve this using public APIs so that the app remains App Store compatible and passes review. If full blocking is not possible, then at least ensure that any captured content appears blank/black for sensitive sections of the app. Additionally, we would like our app’s window behavior to work like other apps do: Red button → Close the application completely. Yellow button → Minimize the application to the Dock. Green button → Maximize to full screen while still allowing access to the Dock and menu bar. Any advice, best practices, or references to relevant documentation would be highly valuable. Thank you for your support.

Hi Everyone, I’ve recently launched a utility app focused on cleaning, optimizing, and improving device performance while protecting user privacy. It includes features like Junk cleaning, Duplicate/Large/Old file removal, App Uninstallation/Updater, Browser cleanup, and Startup Management tips. I’m trying to better understand how App Store search ranking works for this type of app so it can feature higher in search results. Specifically, I’d like to know: What factors influence whether an app shows up at the top for keywords like “storage cleaner”, “duplicate finder”, or “privacy cleaner”? How important are title, subtitle, and keyword fields compared to downloads, ratings, and reviews? Does keyword repetition in the description improve ranking, or does Apple ignore that? Are there any proven strategies for utility apps (like system optimizers/cleaners) to compete with big, established apps in search visibility? Does localization (multiple languages) significantly improve search exposure, even if the app is English-first? I want to make sure I’m optimizing everything correctly—title, subtitle, keywords, and descriptions—without wasting character space or doing anything that Apple might flag. Any guidance, best practices, or resources on App Store search optimization (ASO) specifically for cleaner/duplicate/optimizer apps would be hugely appreciated! https://apps.apple.com/us/app/dustbyte/id6751766823 Thanks in advance 🙏

Is it possible to create a sandboxed app that uses accessibility permission? And if so, how do I ask the user for that permission in a way that is allowed by the App Store? Im creating a small menubar app and my current (rejected) solution is to create a pop-up, with link to Security &amp; Privacy &gt; Accessibility and the pop-up asks the user to manually add the app to the list and check the checkbox. This works in sandbox. Reason for rejection: "Specifically, your app requires to grant accessibility access, but once we opened the accessibility settings, your app was not listed." I know it's not listed there and it has to be added manually. But its the only solution I've found to this issue. Is there perhaps any way to add the app there programmatically? Im a bit confused since I've seen other apps in App Store that work the same way, where you have to add the app to the list manually. Eg. Flycut. :man-shrugging: I know about this alternative solution, and it's not allowed in sandboxed apps. It also adds the app to the accessibility list automagically: func getPermission() { AXIsProcessTrustedWithOptions([kAXTrustedCheckOptionPrompt.takeUnretainedValue():true] as CFDictionary). } Does anyone have a solution for this? Best regards, Daniel

Hi, I want to detect if there is a fullscreen window on each screen. _AXUIElementGetWindow and kAXFullscreenAttribute methods work, but I have to be in a non-sandbox environment to use them. Is there any other way that also works? I don't think it's enough to judge if it's fullscreen by comparing the window size to the screen size, since it doesn't work on MacBook with notch, or the menu bar is set to 'auto-hide'. Thanks.