Apple has introduced the Wireless Insights Service Predictions capability in iOS 26. After prior alignment with Apple engineers, we are working to integrate this capability into the Douyin App, and intend to provide a TestFlight build for Apple engineers to validate and debug the integration. We have encountered a blocking issue with entitlement configuration: We use our Apple Developer Enterprise Program account to build and submit TestFlight builds. When we manually create and configure provisioning profiles via the Apple Developer Portal, the required entitlement key com.apple.developer.wireless-insights.service-predictions is not available for selection or inclusion in the profile's Entitlements. This completely blocks us from enabling, using, and validating the Wireless Insights Service Predictions capability. For comparison, when we use our Apple Developer Program individual account, the entitlement com.apple.developer.wireless-insights.service-predictions is fully available. It is automatically included in provisioning profiles generated for local debugging, and can also be manually added to custom provisioning profiles via the Apple Developer Portal without issues. We request assistance to resolve this entitlement access discrepancy for our Enterprise Program account, so that we can complete the integration and provide the TestFlight build for validation as planned.

Hi, I have two notarization submissions that have been stuck in "In Progress" status for several hours with no resolution. Submission IDs: 2158329b-8beb-400b-aa80-f8c2a5f30106 (submitted ~9 hours ago) 73174908-3ed9-4a85-afe0-a3c3b0722a61 (submitted ~3 hours ago) Both submissions show "In Progress" indefinitely and no log is available for either. The notarytool --wait --timeout 30m timed out on the second submission with exit code 124. The app is signed with a valid Developer ID Application certificate, all binaries including frameworks and dylibs are individually signed with --options runtime and --timestamp. A previous submission returned valid on disk / satisfies its Designated Requirement via spctl --assess. Could you please investigate whether these submissions are stuck on your end, and advise on next steps? Thank you.

I'm distributing a macOS .pkg installer signed with Developer ID Installer and notarized via notarytool. On macOS 26.3 (Tahoe, Build 25D125), the package is rejected by Gatekeeper when downloaded from the internet. What works: pkgutil --check-signature → signed, Developer ID Installer, full chain (G2 intermediate + Apple Root CA) xcrun stapler validate → "The validate action worked!" xcrun notarytool info <id> → status: Accepted The .app inside the .pkg passes spctl -a -vvv → "accepted, source=Notarized Developer ID" What fails: spctl -a -vvv --type install mypackage.pkg → rejected, origin=Developer ID Installer Raw assessment: assessment:remote = true, assessment:verdict = false Double-clicking the downloaded .pkg shows only "Move to Trash" / "Done" (no "Open" option) syspolicyd log: meetsDeveloperIDLegacyAllowedPolicy = 0 (expected, since the cert is new), but no "notarized" match is logged Certificate details: Developer ID Installer, issued Feb 28, 2026, valid until 2031 OID 1.2.840.113635.100.6.1.14 (Developer ID Installer) — critical OID 1.2.840.113635.100.6.1.33 — timestamp 20260215000000Z Intermediate: Developer ID Certification Authority G2 (OID 1.2.840.113635.100.6.2.6) security verify-cert → certificate verification successful Build process: productbuild --distribution ... --sign <SHA1> (also tried productsign) Both produce: Warning: unable to build chain to self-signed root xcrun notarytool submit → Accepted xcrun stapler staple → worked Workaround: xattr -d com.apple.quarantine ~/Downloads/mypackage.pkg allows opening the installer. Question: Is spctl --type install assessment expected to work differently on macOS 26 Tahoe? The same signing and notarization workflow produces .app bundles that pass Gatekeeper, but .pkg installers are rejected. Is there a new requirement for .pkg distribution on macOS 26? Environment: macOS 26.3 (25D125), Xcode CLT 26.3

Hello We have a pkg installer whose signing certificate is expiring next month. It has a trusted timestamp on it. As per https://developer.apple.com/support/certificates/ it states Developer ID Installer Certificate (Mac applications) If your certificate expires, users can still install packages that were signed with this certificate as long as the package includes a trusted timestamp. Previously installed apps will continue to run. However, new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate. If your certificate is revoked, users will no longer be able to install applications that have been signed with this certificate. Wanted to check on behavior for new installations post expiration date. Since the installer has a trusted timestamp we would not need to release a new installer with new cert ?? Any guidance here would be much appreciated.

I have gotten all necessary entitlements for all my extensions,

When I create an archive file and attempt to upload the app using the "Distribute App" button, the upload fails with the error "Automatic signing cannot update bundle identifier...". (The detailed message is below.) When creating an archive file in Xcode, I unchecked "Automatically Manage Signing" and proceeded with the archive. The message says "Font Enumeration," but other apps with the same option enabled upload successfully. Therefore, I believe the "Font Enumeration" option is not the issue. I tried creating a new provisioning file, but it still doesn't work. I deleted all DerivedData files from my Mac storage, restarted Xcode, and tried again, but it still doesn't work. This keeps happening only for certain targets (specific apps) in Xcode. Does anyone know how to fix this? Xcode is the latest version. Message: Automatic signing cannot update bundle identifier "com.xxxxxx.xxxxxx". Automatic signing cannot update your registered bundle identifier to enable Font Enumeration. Update your bundle identifier on https://developer.apple.com/account and then try again.

Context: I am building an iOS productivity app using EAS Build. The project has 4 targets: the main app and 3 extensions (ShieldAction, ShieldConfiguration, ActivityMonitorExtension). The Issue: I have officially received approval from Apple for the Family Controls (Distribution) entitlement for my main Bundle ID. However, the build still fails during the Xcode phase. The Errors: Xcode reports that the generated provisioning profiles do not include the com.apple.developer.family-controls entitlement. For example: Provisioning profile "*[expo] com.*.** AdHoc 177247892...." doesn't support the Family Controls capability. All 3 extensions are failing with the exact same error. What I've done: Confirmed approval from Apple for com.*.**. Enabled Family Controls and App Groups on the Apple Developer Portal for all 4 Identifiers. Cleared EAS local and remote cache using eas build --clear-cache. Deleted existing profiles on both Expo.dev and Apple Portal to force regeneration. The Question: Even with official approval, why does EAS continue to generate "empty" profiles for my Ad-Hoc development build? Do I need separate approval for each extension's Bundle ID, or is there a way to force EAS to sync these "Managed Capabilities" correctly?

the iOS app store package's entitlements file has an issue. After updating to a new version to fix the entitlements file, the app still crashes upon opening but can function normally after a restart. What methods can the app side use to resolve this entitlements file issue without requiring a restart to open and use the app properly?

I requested the Family Controls (distribution) capability but am not sure if I did it correct. I applied, answered the questions why i needed it and submitted. Its been about 2 weeks since applying. In the app configurations, it on apple dev site, it shows in the request history that I submitted it on March 17, but I can click the request (+) button and request it again. Just want to make sure I didn't mess anything up--it seems like they would prevent me from sendin another request if I had already requested it. It hasn't taken them this long to get back to me in the past which is why I am confused. If anyone knows how to speed up the process, please let me know! Thanks.

I'm submitting a native macOS app (Swift/SwiftUI, arm64) that includes Sparkle.framework for auto-updates. All binaries are signed with a Developer ID Application certificate using --options runtime and --timestamp. I've submitted 12+ times over the past two days, both from local notarytool submit and from GitHub Actions CI. Every submission uploads successfully and returns a valid submission ID, but then stays at "In Progress" indefinitely — none have resolved to Accepted or Invalid. Two early submissions did eventually come back "Invalid" — Apple's rejection log showed the Sparkle nested binaries had ad-hoc signatures (they were being signed as individual Mach-O files instead of bundle directories). I fixed this with proper inside-out bundle signing. Since the fix, local codesign --verify --deep --strict passes cleanly, but all ~10 subsequent submissions remain stuck at "In Progress". 9UT54V24XG Would appreciate any guidance, or if someone from the notary team could check our queue. Happy to provide specific submission IDs.

Hello, I’m currently in the process of app notarization, but my status is stuck in the "In Process" state, and I’m unsure how long this should take. I’d appreciate any advice or insights. Issue Description After submitting my app for notarization, the status has been stuck in "In Process" for an extended period. There seems to be no progress, and it’s taking longer than I expected for the process to complete. The status hasn’t changed, and it’s been 5 days since I submitted the app. Has anyone encountered a similar issue? How long does the notarization process usually take? Any advice on how to resolve this or if there’s something I might be missing? Thanks in advance for your help!

This is my submission, my earliest submission has be stuck for a couple of days can someone please help. This is blocking our launch. -------------------------------------------------- createdDate: 2026-03-01T15:57:46.893Z id: 4cd9bb60-67eb-4f59-be9b-952248da33cf name: Snip-1.0.0-arm64.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-01T15:07:04.101Z id: fc88fa42-6ffe-4fee-86b2-0cec44c4391b name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-28T06:48:58.307Z id: e6cabf68-2963-4971-a057-fb4c5a1bdb4c name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T17:02:33.195Z id: 4e038aab-e429-4dfa-abcd-afcd49241a31 name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T17:02:21.907Z id: 4a908c50-812b-48c1-949d-8d6d4c9dec40 name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T14:28:38.585Z id: bccbc5bc-1cc7-4417-ab57-545b0cc6cc7b name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T08:35:47.185Z id: 4219d594-ee41-4905-8ea5-af89dc924b4f name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T08:07:51.982Z id: 08fce978-8dc1-45bb-aac1-ea932bd08b02 name: Snip.zip status: In Progress

Successfully received submission history. history -------------------------------------------------- createdDate: 2026-02-28T06:48:58.307Z id: e6cabf68-2963-4971-a057-fb4c5a1bdb4c name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T17:02:33.195Z id: 4e038aab-e429-4dfa-abcd-afcd49241a31 name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T17:02:21.907Z id: 4a908c50-812b-48c1-949d-8d6d4c9dec40 name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T14:28:38.585Z id: bccbc5bc-1cc7-4417-ab57-545b0cc6cc7b name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T08:35:47.185Z id: 4219d594-ee41-4905-8ea5-af89dc924b4f name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T08:07:51.982Z id: 08fce978-8dc1-45bb-aac1-ea932bd08b02 name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T07:25:12.257Z id: dcba81a6-f9a5-42bd-9e04-bffa2aeabb10 name: Snip.zip status: Invalid the first submission failed becuase i suse the wrong certificate type, however subsequent submissions are stuck for very long

We've got an in-house Swift macOS desktop app with a FileProvider extension, which has been working fine on various machines up through Sonoma (and still does). We've just installed it on a Sequoia machine, and on it the FileProvider extension has lost the ability to access the shared app group. It can neither log to the Group Containers folder under ~/Library, nor access the pipe to the main app. The group name is formatted as group.XXXXXXXXXX.com.orgname.appname in both targets. I'm not sure why it combines the iOS and macOS conventions, with both the group prefix and the teamIdentifier one -- it was first built some time before the point in 2025 when macOS supported iOS-style groups -- but again, it's been working. For the record, The provisioning profile for EMPFileProvider has the App Groups capability enabled, and the App Groups capability is present in both build targets in Xcode. The existing group identifier is registered on the website; I've also manually registered the team-ID-less group name, so I can migrate. The question is, is this actually the right approach? Will such a change break the app on pre-Sequoia machines? And if I proceed, what do I need to do to complete the migration? The app was built back in Xcode 12.5; will I need to update the entire build environment to take advantage of Xcode 16.3's explicit support for iOS-style group names, or can I get away with it since I've manually registered the new group?

I've seen a few posts about this online and it seems that Xcode generates random team ID's with it's automatic signing system. But I haven't seen any way to make this work properly. If I log into the dev portal and look at my account, in the upper right I can see my team ID. If I manually generate a cert, I get a totally different one. Question: How can I generate a cert with my proper team ID (my paid account) where the ID's on my certs, identifiers and profiles all match? I've never had this issue before and am unsure how to solve it.

Every recent attempt to create a Installer certificate has failed, and now we've hit the maximum. We can't revoke them either — the portal only shows "Download," not "Revoke." Xcode also fails with: "Signing Certificates Error: There is a problem with the request entity. You already have a current Developer certificate or pending certificate request." This is completely blocking notarization and distribution of our macOS app. Has anyone resolved this, or does it require Apple to intervene on the backend? (This is a relatively new issue, we have successfully done this in the past hundreds of times over the years.)

I've submitted a few first notarizations for my electron app - I've verified with all the QA and resources that I am doing the correct thing - but its silently just holding all my notarization requests on apples side with no logs. I'm trying to launch my app this week - how should I proceed?

Two months ago I requested the subject entitlement. I'm still waiting for it to be added to our account. Who or how can I find out what going on with it. I have no correspondence from Apple yet saying it was denied and why. https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.persistent-content-capture?language=objc Thank you.

Hello, I am attempting to request the endpoint-security.client entitlement for my app using the following form: https://developer.apple.com/contact/request/system-extension/ After submitting the form, I consistently receive an HTTP 500 error from Apple’s servers. Could you please provide guidance on whether this is a known issue or if there is something I may be doing incorrectly? I appreciate your assistance.

Made a notarization request a few hours ago and woke up to check the history and it's no longer available. Not rejected/accepted just not found. I have gone ahead to make another request but I have no confidence because I expect the same thing to happen again. Any guidance? See logs below: daramfon@MacBook-Pro-3 frontend % xcrun notarytool history --apple-id "$APPLE_ID" --password "$APPLE_APP_SPECIFIC_PASSWORD" --team-id "$APPLE_TEAM_ID" Successfully received submission history. history -------------------------------------------------- createdDate: 2026-02-20T23:53:14.066Z id: 6f2fadc0-2e8f-4331-a253-68f81334ebc6 name: Speakeasy AI-0.1.0-arm64.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-20T23:47:12.897Z id: 435aec4f-5356-49a5-898d-48aaafb7949f name: Speakeasy AI.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-20T22:35:23.947Z id: 95896757-873a-4e54-a527-03dc767c9cb5 name: Speakeasy AI.zip status: In Progress daramfon@MacBook-Pro-3 frontend % xcrun notarytool history --apple-id "$APPLE_ID" --password "$APPLE_APP_SPECIFIC_PASSWORD" --team-id "$APPLE_TEAM_ID" No submission history. daramfon@MacBook-Pro-3 frontend % xcrun notarytool info 6f2fadc0-2e8f-4331-a253-68f81334ebc6 --apple-id "$APPLE_ID" --password "$APPLE_APP_SPECIFIC_PASSWORD" --team-id "$APPLE_TEAM_ID" Submission does not exist or does not belong to your team. id: 6f2fadc0-2e8f-4331-a253-68f81334ebc6