Hey Apple Friends, We currently have an enterprise version of our app for debugging and internal distribution. Our release configuration uses our App Store account. However, it appears you cannot add a 'Declared Age Range' to the Enterprise app as a capability making it impossible to debug because we have added the 'Declared Age Range API' locally, but we cannot add it as a capability on the dev portal. Is there any work around for this?

Hello, I'm currently trying to upload a new version of an existing application. But each time I try to validate the archive of the application, I got the following error in Xcode (v16.2) : Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “37CG5MY799.com.example.app” value for the com.apple.application-identifier key in “com.example.app.pkg/Payload/app.app/Contents/MacOS/app” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. I suspect that there is a problem with the App ID Prefix (that is 37CG5MY799 for the app) when our team ID is E4R7RJ7LA3 but I cannot find a solution. I asked the Apple Developer Support for help and I have read the documentation they sent but it couldn't solve this problem so they redirected me to the forums. https://developer.apple.com/library/archive/qa/qa1879/_index.html https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-OVERVIEW https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-TNTAG33 There isn't any obvious App ID Prefix mismatch in the entitlement between the Application's signature entitlement and the Embedded provisioning profile entitlement . Application's signature entitlement : <dict> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> </dict> Embedded provisioning profile entitlement : <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> <string>E4R7RJ7LA3.*</string> </array> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>keychain-access-groups</key> <array> <string>37CG5MY799.*</string> </array> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> </dict> The app also have a browser extension that correctly use the Team ID. How to solve this problem ? Thanks for your time, Qeg

I'm facing a persistent issue with provisioning profiles not including the com.apple.developer.in-app-purchase entitlement, even though the In-App Purchase capability is clearly enabled in the Developer Portal for my app. What I’ve already done: Confirmed that the In-App Purchase capability is enabled in the App ID configuration Deleted all provisioning profiles locally (~/Library/MobileDevice/Provisioning Profiles) Regenerated both Development and App Store provisioning profiles from scratch Tried Xcode's automatic signing (after properly registering the device) Verified the provisioning profiles via Terminal (security cms -D -i ...) — the IAP entitlement is missing every time Recreated valid distribution and development certificates Cleaned the Xcode project and settings The result: Every attempt to build or archive the app in Xcode returns: Missing entitlement: com.apple.developer.in-app-purchase I've also opened a support case with Apple, but so far I’ve only been redirected to general documentation. Has anyone encountered this recently? Is there a known delay or sync issue on Apple’s side when enabling capabilities? Can the provisioning profile or entitlement data be manually refreshed by Apple? Is there any workaround that worked for you in this situation?

Hello Apple Developer Community, I'm experiencing a persistent issue with App Groups configuration for an iOS app extension that I can't resolve despite trying multiple approaches. I hope someone can help identify what I'm missing. Problem Description I'm getting this error when trying to build my iOS App Extension: Provisioning profile "iOS Team Provisioning Profile: com.idlrapp.Spleeft.SpleeftDataSaver" doesn't include the com.apple.developer.app-groups entitlement. My Setup Main App Bundle ID: com.idlrapp.Spleeft Extension Bundle ID: com.idlrapp.Spleeft.SpleeftDataSaver App Group ID: group.com.idlrapp.spleeft.shared Extension Type: Action Extension (Share Sheet) What I've Verified App Group Creation ✅ Created App Group group.com.idlrapp.spleeft.shared in Apple Developer Portal ✅ App Group shows as "Active" in the portal App ID Configuration ✅ Both App IDs (com.idlrapp.Spleeft and com.idlrapp.Spleeft.SpleeftDataSaver) have "App Groups" capability enabled ✅ Both App IDs are configured with the same App Group: group.com.idlrapp.spleeft.shared Entitlements Files Main App (Spleeft.entitlements): <key>com.apple.developer.app-groups</key> <array> <string>group.com.idlrapp.spleeft.shared</string> </array> Extension (SpleeftDataSaver.entitlements): <key>com.apple.developer.app-groups</key> <array> <string>group.com.idlrapp.spleeft.shared</string> </array> Xcode Configuration ✅ Both targets use "Automatically manage signing" ✅ Same Apple Developer Team selected for both ✅ App Groups capability shows correctly in Signing & Capabilities for both targets The Issue When I examine the downloaded .mobileprovision file, I can see it contains: <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.idlrapp.spleeft.shared</string> </array> <!-- Other entitlements... --> </dict> However, Xcode expects to find: <array> <string>group.com.idlrapp.spleeft.shared</string> </array> What I've Tried Multiple regenerations of provisioning profiles: Deleted all local provisioning profiles Toggled "Automatically manage signing" off/on Downloaded manual profiles from Developer Portal Verified App Group configuration: Double-checked App Group exists and is active Confirmed both App IDs have App Groups capability enabled Verified App Group assignment in both App IDs Entitlements cleanup: Ensured consistent App Group IDs across all files Removed duplicate/conflicting entries Clean builds and cache clearing: Product → Clean Build Folder Derived Data deletion Xcode restart Key Observation The provisioning profile contains com.apple.security.application-groups (which appears to be macOS-style) but Xcode expects com.apple.developer.app-groups (iOS-style) for the App Extension. Questions Is there a known issue with App Groups entitlement generation for iOS App Extensions? Should the provisioning profile contain com.apple.developer.app-groups instead of com.apple.security.application-groups? Is there a way to force regeneration of provisioning profiles with the correct entitlements? Are there additional steps required for App Extensions that differ from main apps? Any guidance would be greatly appreciated. This is blocking our App Extension development and we've exhausted our troubleshooting options. Thank you for your time and assistance.

I'm attempting to upload an updated version of our macOS app for distribution via the App Store. We've done this without issue before, but I am now receiving a warning when I upload the app via Transporter: "Cannot be used with TestFlight because the signature for the bundle at “AXON Studio.app” is missing an application identifier but has an application identifier in the provisioning profile for the bundle. Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight." (90886) I just recently started seeing this warning when I upload our application via Transporter. Before this warning started happening, I was using the exact same process and scripts to build/package/codesign our application. NOTE: we are not using Xcode to build our application, so we can't take advantage of any codesigning/packaging automation provided by Xcode (the app is written in C#/.NET 6.0), so we are doing all build/package/codesign steps using the appropriate macOS command line utilities. Also, I have verified that the app bundle and its contents have valid signatures. Does anyone have any idea what may have changed to cause this warning, or how I might go about determining the root cause so I can fix it?

Hi, I recently created and installed new code signing certificates/keys on my main Mac. How to easily copy these certificates/keys to my another Mac with the same Apple ID? Earlier Quinn suggested: "The easiest way to do this is use Xcode’s import/export feature. Launch Xcode, choose Xcode > Settings, select Accounts, select the account in question, then choose Export Apple ID and Code Signing Assets from the action (…) menu." And it worked fine in 2020-2021. However import/export options are no longer available in XCode 16 anymore. Please suggest a simple solution.

Command failed: codesign --sign 142DA07B8371F5C9BCE0FFEC6B23CDEB84F48E52 --force --timestamp --options runtime --entitlements /Users/mymac/Desktop/ElectronApp/node_modules/app-builder-lib/node_modules/@electron/osx-sign/entitlements/default.darwin.plist /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper: replacing existing signature /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper: resource fork, Finder information, or similar detritus not allowed failedTask=build stackTrace=Error: Command failed: codesign --sign 142DA07B8371F5C9BCE0FFEC6B23CDEB84F48E52 --force --timestamp --options runtime --entitlements /Users/mymac/Desktop/ElectronApp/node_modules/app-builder-lib/node_modules/@electron/osx-sign/entitlements/default.darwin.plist /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/ I'm not entirely sure what's causing this issue. Has anyone else encountered this error while signing their macOS app? I’d really appreciate any guidance or solutions you can share.

I'm experiencing an issue when exporting an Enterprise distribution certificate where the certificate and private key won't export together - the private key keeps getting left out. I'm running macOS Tahoe. Has anyone encountered the same issue or know of a solution? Any help would be appreciated.

Hi guys, I am new to publishing apps on Apple Store. I used python, pyside6, torch, pyinstaller to build an app for Apple Store. For codesigning, I used the correct "Developer ID Application" to sign the code. When I validate the .app file (codesign -vv --strict ), I got the following my_app.app: valid on disk my_app.app: satisfies its Designated Requirement Next, I used ditto to "ditto -c -k --sequesterRsrc --keepParent my_app.app my_app.zip" to zip it. Then, I submitted this my_app.zip file for notarization with "xcrun notarytool submit ..." and got the following "accepted" message. Received new status: Accepted Current status: Accepted............... [20:08:54.530Z] Info [API] Submission in terminal status: Accepted Processing complete After that, I want to staple it with "xcrun stapler staple my_app.app", but I got the following Could not validate ticket for my_app.app The staple and validate action failed! Error 65. To further investigate it, I ran "spctl -a -vvv my_app.app" and got my_app.app: rejected source=Unnotarized Developer ID origin=Developer ID Application... I don't know why this would happen after notarization accepted. Could someone help me understand this issue? Thanks!

I have a pass type id that expired. I created a CSR in keychain access on my Mac. I uploaded the CSR and generated a new cert. I downloaded the new cert and imported into keychain access. I don't see the associated private key and I cannot export a .p12 certificate. It's possible I started with the wrong key to generate the CSR or maybe I inadvertently deleted key while trying to locate the cert after importing. I'm not sure how to determine which. I do still have the private key from the cert that expired. But, I cannot figure out how to sign a cert again, my only option now is download. I've been searching the forum and while there may be an answer, I may just be looking for the wrong thing. I could use some help if anybody would be so kind.

Hello everyone, I'm currently experiencing repeated "Invalid Binary" rejections when submitting my Flutter-based iOS app ("Master Tere") through App Store Connect. I've followed all the expected steps and guidelines, but the rejection contains no additional explanation beyond the "Invalid Binary" status. Here’s my current setup: Built using Flutter and Xcode 15.3 WebView-based app loading a professional portfolio site Runner target is signed automatically using Xcode Managed Profiles Certificates: Apple Development and Apple Distribution (auto-managed) Bundle ID: com.actuain.mastertere1 Version: 1.0.0, Build: 6 Deployment target: iOS 18.0 Device family: iPhone only All signing identities and provisioning profiles match for Debug and Release In my Info.plist, I’ve cleaned up legacy keys that might cause conflicts: ✅ Removed <key>UIMainStoryboardFile</key> (no storyboard is used) ✅ Removed <key>CFBundleSignature</key> as it was set to ???? ✅ Display name and Bundle ID align with Xcode project settings Despite all this, every time I upload through Xcode Organizer, I get an "Invalid Binary" error after processing. No issues are shown during archive validation. I suspect the issue may be related to: Flutter WebView integration with latest iOS SDKs Residual metadata in the archive from unused iOS storyboard references Possibly missing entitlements or capabilities not flagged by Xcode Questions: Are there any known issues affecting Flutter WebView apps recently (especially around Xcode 15.3 or iOS 18 SDK)? Is it mandatory to remove Main.storyboard from the project bundle even if it's not used? Could this issue be related to background modes, UIRequiredDeviceCapabilities, or entitlements even if not directly flagged? I’d appreciate any insights or experiences from others who’ve faced this issue recently. Thanks in advance! Luis Antonio Pinto Acosta

The capability associated with "FAMILY_CONTROLS" could not be determined. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator.

Hello all, I am attempting to notarize my newly made Mac OS application using the notarization command in VS Code. "/Users/teejgotit/Desktop/Cursor Workspace/Rust CutContour v2/cutcontour-app/src-tauri/target/release/bundle/dmg/CC Studio_0.1.0_aarch64.dmg" \ --key "/Users/teejgotit/AppleCerts/AuthKey_MATVLX3.p8" \ --key-id "MATVLX9" \ --issuer "887ba428-aa39-4fb3-a3dc-f83b9145cab0" \ --wait Only to be met with a continual "Current State: In Progress.." for what has been about 1 day and 16 hours now. Current status: In Progress........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ My app and project are rather small and was curious if this is a normal thing for this to day takes for a first time notarization? Would love any help or feedback.

I've developed a Mac app distributed through the App Store that uses NSAppleScript to control Spotify and Apple Music. I'm experiencing inconsistent behavior with automation permission prompts that's affecting user experience. Expected Behavior: When my app first attempts to send Apple Events to Spotify or Apple Music, macOS should display the automation permission prompt, and upon user approval, the app should appear in System Preferences &gt; Security &amp; Privacy &gt; Privacy &gt; Automation. Actual Behavior: Initial permission prompts work correctly when both apps are actively used after my app download. If a user hasn't launched Spotify/Apple Music for an extended period, the permission prompt fails to appear when they later open the music app. The music app doesn't appear in the Automation privacy pane too. Once this happens, permission prompts never trigger again for that app Steps to Reproduce: Fresh install of my app Don't use Spotify for several days/weeks Launch Spotify Trigger Apple Events from my app to Spotify No permission prompt appears, app doesn't show in Automation settings If you're using Apple Music during this time it runs without any problems. Troubleshooting Attempted: Used tccutil reset AppleEvents [bundle-identifier] - no effect Verified target apps are fully launched before sending Apple Events Tried different AppleScript commands to trigger permissions Problem occurs inconsistently across different Macs Technical Details: macOS 13+ support Using standard NSAppleScript with simple commands like "tell application 'Spotify' to playpause" App Store distribution (no private APIs) Issue affects both Spotify and Apple Music but seems more prevalent with Apple Music Questions: Is there a reliable way to programmatically trigger the automation permission prompt? Are there timing dependencies for when macOS decides to show permission prompts? Could app priority/usage patterns affect permission prompt behavior? I use MediaManager to run the functions and initialize it on AppDidFinishLaunching method and start monitoring there. Any insights or workarounds would be greatly appreciated. This inconsistency is affecting user onboarding and app functionality.

Hi, I was sent here by Apple developer account, it seems here is the only option for me, so your help is very much appreciated! Basically we are building a chromium based browser on iOS, we applied the "com.apple.developer.web-browser" entitlement, and it shows up in our identifier, profile etc. The app is signed with the new entitlement and published to the app store. However it is not listed as an option for default browser, doesn't matter which device I tried. I did verified that the Info.plist contains http/https urlschemes as required. In fact a few of us checked all available documents multiple times and still couldn't see why.

Unable to notarize Electron-based application. All notarization attempts fail with "The signature of the binary is invalid" for main executable and Electron Framework, despite passing local codesign verification. ENVIRONMENT: macOS: 24.6.0 (Sequoia) Hardware: Apple M4 Max (arm64) electron-builder: 26.0.12 Electron: 36.9.5 (also tested 37.10.2, 38.2.0) Certificate: Developer ID Application: AS LIVE MEDIA SP Z O O Team ID: 2KJ532SU3G Certificate validity: Oct 7 2025 - Oct 8 2030 PROBLEM: Every notarization submission fails with identical error for two binaries: Contents/MacOS/PresentClic Desktop Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework Error message: "The signature of the binary is invalid." Architectures affected: Both x86_64 and arm64 CRITICAL CONTRADICTION: ✅ Local verification PASSES: $ codesign --verify --deep --strict "PresentClic Desktop.app" Result: valid on disk, satisfies Designated Requirement ❌ Apple notarization service FAILS: Error: "The signature of the binary is invalid" LATEST SUBMISSION ID: 11e1a452-4ea7-4562-ac8e-5e76c39eeb6c Local verification output shows all components validated: Electron Framework: validated ✅ All helper apps: validated ✅ All frameworks: validated ✅ Main executable: valid on disk ✅ Authority chain: Developer ID Application → Developer ID CA → Apple Root CA ✅ Timestamp: Present ✅ Runtime Version: 15.4.0 ✅ CONFIGURATION: Entitlements (build/entitlements.mac.plist): com.apple.security.cs.allow-jit: true com.apple.security.cs.allow-unsigned-executable-memory: true com.apple.security.cs.disable-library-validation: true com.apple.security.cs.allow-dyld-environment-variables: true com.apple.security.automation.apple-events: true Standard device/network/file entitlements Build configuration: hardenedRuntime: true gatekeeperAssess: false (tested both true and false) entitlements and entitlementsInherit: properly configured TROUBLESHOOTING STEPS ATTEMPTED (ALL FAILED): ✅ Updated electron-builder from 24.13.3 to 26.0.12 ✅ Downgraded Electron 38 → 37 → 36 ✅ Tested x86_64 and arm64 separately ✅ Regenerated certificate via Xcode (new cert generated 23/11/2025) ✅ Configured App Store Connect API for notarization ✅ Tested multiple entitlements combinations ✅ Manual component-by-component re-signing ✅ Removed all metadata files (._ files) ✅ Tested both ZIP and DMG formats ✅ Automatic electron-builder notarization ✅ Manual notarization via xcrun notarytool ✅ Custom afterSign hooks for re-signing ✅ gatekeeperAssess true and false ✅ Clean builds (removed dist/ directory) ALL attempts result in identical failure. Local codesign verification ALWAYS passes. QUESTIONS: Why does local codesign --verify pass but Apple notarization service fails? Is there a known issue with Electron Framework notarization on macOS Sequoia + Apple Silicon? 3. Are there undocumented requirements for Electron apps that could cause this? 4. Could this be a bug in the notarization service for this specific configuration? ADDITIONAL CONTEXT: Multiple notarization attempts over 24+ hours Different certificates, configurations, architectures - all fail identically No similar reports found in forums or GitHub issues Application functions correctly when Gatekeeper is bypassed This is blocking production distribution to macOS users This appears to be either: A bug in Apple notarization service for Electron apps An incompatibility between electron-builder 26 + Electron 36/37 + macOS Sequoia + Apple Silicon The fact that local verification passes but notarization fails suggests the issue is with the notarization service validation logic, not the actual code signatures. REQUEST: Need guidance on resolving this issue. Standard documentation and troubleshooting steps have not resolved the problem. Thank you for any assistance. Staszek Pliszko

Hello, when building and signing my application in a Github actions workflow, I am facing an issue on the latest version of xCode (16.4). This issue is resolved by downgrading to 16.3. My CI/CD pipeline is running headless and installing provisioning profile to ~/Library/MobileDevice/Provisioning Profiles.

I submitted a mac app for Notarization. For the first few tries the Notarization failed with an error "Team is not yet configured for Notarization" but few days after my account started to show "ENROLL" option again even though my membership was set to expire on 2026. I am doubting my account has been suspended. I have not received any emails from apple regarding the suspension. I have contacted support but no help yet ! This was the second year, i was paying for the membership. Could you please help me to - Help me get the account unsuspended (if it is, as there is no notification or information regarding this) If the account is suspended due to my app being submitted for Notarization then help me identify the reason so that i can fix them. Mac App is Time Tracking application that runs in background and capture periodic screenshot backlsh.com (NOTE - I am doing this after taking user consent)

Hello, we are currently encountering a similar issue. We need to inject our capabilities into a third-party app by re-signing it (not a full re-signing process—just requiring the provisioning profile and certificate to match). However, this seems to affect the functionality of universal links. We've found that this issue only occurs on iOS 18. We noticed that when re-signing the app, the entitlements related to associated domains are changed to a wildcard: [Key] com.apple.developer.associated-domains [Value] [Array] [String] * However, this doesn’t cause any issues on iOS 17. Through further testing, we discovered that in order for universal links to work properly, we need to restore the original value of com.apple.developer.associated-domains and use a provisioning profile that matches the app's bundle ID. This means our previous re-signing approach using a certificate and provisioning profile from another bundle will no longer work. We’d like to ask: is this a new restriction introduced in iOS 18? If we manually restore the original com.apple.developer.associated-domains entitlement and use a provisioning profile that matches the app’s bundle ID, will universal links function correctly going forward?

I submitted a Mac application for a safari ad blocker extension about 15 hours ago and it's still in progress. Is it normal for notarization to take this long? It's my first time submitting something for notarization so maybe that's why it's taking longer than expected? ID: 8BDB3D5E-3A42-469F-9479-AC76229C6BB5