Hello, We are currently using Apple Notarization (notarytool) for distributing a macOS app, and we are experiencing very long notarization times for large app bundles. [Issue] For apps with large binary sizes, notarization consistently takes around 3.5 to 4.5 hours from submission to completion. This delay is causing practical issues in our release pipeline, especially when: A hotfix or urgent update is required Multiple builds must be notarized in a short time CI/CD-based distribution is expected to complete within a predictable timeframe [Environment] Platform: macOS Notarization method: notarytool Distribution: Outside Mac App Store App size: 100 GB~ (compressed ZIP) Signing: Hardened Runtime enabled, codesigned correctly Submission status: Successfully accepted, but processing time is very long [What we have confirmed] The notarization eventually succeeds (no failures) Re-submitting the same build shows similar processing times Network upload itself completes normally; the delay is in Apple-side processing Smaller apps complete notarization much faster [Questions] Is a 3–4+ hour notarization time expected behavior for large macOS apps? Are there recommended best practices to reduce notarization processing time for large binaries? For example, splitting components, adjusting packaging, or specific signing strategies Is there any official guidance or limitation regarding notarization queueing or processing based on app size? Are there known service-side delays or regional differences that could affect processing time? Any insight or confirmation would be greatly appreciated, as this directly impacts our production release workflow. Thank you.

Hello, According to documentation, the App Store does not re-download the entire app when updating, but instead generates an update package containing only the changed content compared to the previous version. I’d like to clarify the following points: 1. Granularity of file changes If only part of a large file changes, does the update package include the entire file, or does it patch only the modified portions within that file? 2. Guideline on separating files The documentation recommends separating files that are likely to change from those that are not. How should this be interpreted in practice? 3. Verifying the diff result Is there a way for developers to check the actual diff result of the update package generated by the App Store without submitting the app? Is there a diff command tool or comparison method closer to the actual App Store update process? 4. Estimating update size during development For apps with large-scale resources, minimizing update size is critical. Are there any tools or best practices to estimate the size of the update package before submitting to the App Store? Any clarification or reference materials would be greatly appreciated. Thank you.

Hello, I’m preparing a macOS app for App Store submission, and I have a question regarding whether including an extra executable inside the app bundle is permitted under the App Store Review Guidelines. My app would include a command-line tool placed inside the bundle, such as: MyApp.app/Contents/MacOS/ or MyApp.app/Contents/Resources/ The purpose of this tool is to help users collect hardware/system information for troubleshooting or error reporting. Importantly: The app never launches this executable automatically. It never runs in the background. It is intended to run only when the user chooses to run it manually. The intended workflow is: The executable is shipped inside the app bundle. When needed, the app simply informs the user where the tool is located. The user manually executes it—either by double-clicking in Finder or by running it from Terminal. The executable runs independently, and the app does not trigger, spawn, or control the process. My questions are: Is this approach allowed under the macOS App Store Review Guidelines? Could this be considered “executing external code,” a sandbox violation, or otherwise lead to rejection during App Review? Does App Review allow a tool that is bundled with the app but executed manually by the user outside of the app itself? Additionally, if there is any official documentation or guideline from Apple that specifically addresses this scenario—or similar restrictions around including executables inside a macOS App Store app bundle—I would greatly appreciate a link. If anyone has experience with this or knows how App Review typically handles this type of setup, I’d be grateful for any insight. Thank you!

Hello, On macOS 26 (Tahoe), when building a OSX app that includes GameKit code, calling GKLocalPlayer.local.authenticateHandler shows the "Sign In to Game Center" alert (e.g. didShowFullscreenSignIn) — even if the app does not have the Game Center capability enabled or any related entitlement (com.apple.developer.game-center). This alert only appears when the user is not signed in to Game Center in system settings. However, when testing the same code path on iOS app built with macOS 26 (Tahoe), the alert does not appear unless the proper capability and entitlement are included. This behavior is different from macOS 15 (Sequoia) + Xcode 15.x. Prior to the update, Game Center features did not work at all even with the OSX app without Capability and Entitlements. Steps to Reproduce Create a new OSX app target (App Sandbox enabled, no Game Center capability). Add minimal GameKit code: GKLocalPlayer.local.authenticateHandler = { _, _, _ in } Build OSX app and run on macOS 26 (Tahoe). Ensure Game Center is signed out in System Settings. Observe: “Sign In to Game Center” alert appears automatically. Expected Behavior When Game Center capability and entitlement are not present, authenticateHandler should fail silently, and no signIn alert should appear. Actual Behavior On OSX app, the Game Center signIn UI appears even without any Game Center capability or entitlement. On iOS app, this alert does not appear. *Build Configuration: built with the same condition. (macOS 26 + Xcode 26) Question Could you please confirm whether this behavior is an intentional change in macOS 26 or a bug only for OSX apps in the GameKit authentication flow? Thank you.

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.

Hello, When testing GameKit "Manage Game Progress" in Xcode 26: On iOS devices, achievements, leaderboards, and party code data display and work correctly. On macOS devices, none of these data appear in "Manage Game Progress." Is this a known issue with macOS GameKit, or is there a limitation compared to iOS? If it is not a bug, is there any additional configuration needed to make achievements and leaderboards visible on macOS? I also included the GameKit bundle in my macOS app and enabled Enable Debug Mode in GameKit Configuration in the scheme options. Thank you.

Hello, I found an issue with the Games app on macOS 26 (Tahoe) when viewing achievements: In App Store Connect, each achievement has different values set for the pre-earned description and the post-earned description. When testing with GameKit directly (GKAchievementDescription), both values are returned correctly. However, in the macOS Games app, the post-earned description is shown even before the achievement is earned. This seems to be a display issue specific to the Games app on macOS. Could you confirm if this is a known bug in the Games app, or if there is a reason why pre-earned descriptions are not being shown? Thank you.

Hello, I found an issue with the Games app on macOS 26 (Tahoe) when viewing achievements: In App Store Connect, each achievement has different values set for the pre-earned description and the post-earned description. When testing with GameKit directly (GKAchievementDescription), both values are returned correctly. However, in the macOS Games app, the post-earned description is shown even before the achievement is earned. This seems to be a display issue specific to the Games app on macOS. Could you confirm if this is a known bug in the Games app, or if there is a reason why pre-earned descriptions are not being shown? Thank you.

The app comes with its own login/signup service and several other social login services. Even though our app has its own login/sign-up service, if we provide at least one social login service, should we provide Apple Login or another login service with a privacy policy as an equivalent option? Can you please answer whether I should include the sign in with apple service or the login service with privacy protection in my app?

Hello. I would like to provide both self-login/sign-up service and social login service to the app. According to the guidelines, if an app provides a social login service, it must provide Apple Login or another login service with equivalent privacy protection features. So, even if the app provides the company's own login/signup service, if it also provides any other social login service, do the above app review guidelines need to be considered? Or, if we provide our own login, can we ignore the above guidelines even if we provide social login? I don't really understand the guidelines, so I'm asking a question to get a clear answer. Thank you for reading my long question.