The device UDID was registered to the developer account 40 hours ago, the STATUS column was "processing" in the first 24 hours, then turned to empty. But I still can't run my app (with distribution method "development"), when I try to run it after download it through my OTA URL, it prompts “the app cannot be installed because its integrity could not be verified” but everything runs good on a iPhone which was registered a month ago. What should I do now? keep waiting?

I've tried to notarize my app recently and got the error:{ "logFormatVersion": 1, "jobId": "...", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization", "statusCode": 7000, "archiveFilename": "myapp.dmg", "uploadDate": "2019-06-20T06:24:53Z", "sha256": "...", "ticketContents": null, "issues": null }I've never heard about "team configuration for notarization" previously. What are the steps to resolve that issue?Thanks in advance.

We have an app with the default email entitlement that was granted several years ago. During our latest deployment, we received an error from our pipeline. When testing a manual submission in Xcode, we saw this error: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We checked the provisioning profile, and the default email entitlement is still present. It is visible on the certificate portal and also in the embedded.mobileprovision file. Can you suggest what we can do to release a new version of our app?

Hi, My understanding from this information: " https://developer.apple.com/support/certificates/ iOS Distribution Certificate (in-house, internal-use apps) Users will no longer be able to run apps that have been signed with this certificate. You must distribute a new version of your app that is signed with a new certificate. " is that even if I re-sign the app with a new Provisioning Profile based on a new Distribution Certificate the apps will stop working. I need to re-build my apps with a new Distribution certificate+Provisioning profile, when distributing in-house, right? I can see that the apps continue to function when I re-sign them with a new Provisioning Profile, but according to the information above they will stop working the day (day after) the Distribution certificate they were built with expires. /Rikard

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires provisioning under an Apple Enterprise Developer account. This introduces considerable operational complexity, as it would require us to maintain separate signing and distribution paths alongside our existing Apple Developer Program membership. Before pursuing that path, we wanted to understand Apple's perspective on the following: Is there a supported or recommended approach for preserving Associated Domains entitlements when an app is re-signed by a third party (e.g., a cloud testing platform)? Are there any provisioning or entitlement configurations that would allow Universal Links to function correctly in re-signed builds without requiring an Enterprise Developer account? Does Apple have documented best practices for validating Universal Link–based flows in automated or cloud-based testing environments? Are there any alternative deep linking patterns that would be more resilient to re-signing while still meeting App Store and platform security requirements? Any guidance or recommendations from Apple on how to handle this within the bounds of the standard Apple Developer Program would be greatly appreciated. Thank you for your time.

Yestoday， I got problem createdDate: 2026-03-17T09:06:38.486Z id: d1c679af-5f41-437b-9ca1-4c96047a58fb name: easyclaw.app.zip status: In Progress -------------------------------------------------- createdDate: 2026-03-17T03:30:38.278Z id: fe1bb550-7f42-41c8-8d38-40ac7f9e7c91 name: easyclaw.app.zip status: Accepted And retry today monring，waiting again： Successfully received submission history. history -------------------------------------------------- createdDate: 2026-03-18T02:17:44.322Z id: 141b0dcb-d0fe-464e-9167-3a15e59aec87 name: easyclaw.app.zip status: In Progress

Hello everyone, I’ve been stuck for weeks on an issue with Family Controls + Device Activity entitlements in my iOS app, and Apple Developer Support has not provided a solution so far. I’m hoping someone here who has successfully implemented Family Controls + Device Activity can point me in the right direction. About the App • The app is a Digital Wellbeing app called Breakloop. • It lets users select apps they want to block, requires them to complete a positive affirmation before opening those apps, and can re-block apps after a set time (e.g., 10 minutes). • This functionality exactly matches the purpose of Family Controls and Device Activity APIs. What Works So Far • Family Controls capability is enabled in the main app target in Xcode. • We have valid Apple Developer certificates (Apple Development) and a team account. • The main app builds and runs fine when using Family Controls alone. • We have App IDs for: • bl.Breakloop (main app) • bl.Breakloop.BreakloopMonitorExtension • bl.Breakloop.BreakloopShieldConfigurationExtension The Problem The provisioning profiles for the extension targets (BreakloopMonitorExtension and BreakloopShieldConfigurationExtension) do not include the com.apple.developer.device-activity entitlement even though: • The App IDs in the Developer Portal have Family Controls (Development) enabled. • The extensions have the correct entitlements file with both: com.apple.developer.family-controls com.apple.developer.device-activity • Xcode Signing & Capabilities points to the correct provisioning profile + certificate. Because the provisioning profiles don’t include the entitlement, the build fails with: Provisioning profile doesn't include the com.apple.developer.device-activity entitlement. What Apple Support Said Apple Support told me: • “Family Controls grants access to Device Activity.” • They cannot enable it manually or guarantee that profiles will include the entitlement. • They sent links to the documentation but no further assistance. What I Need Help With 1. Has anyone successfully built extensions using Family Controls + Device Activity? 2. Do I need to request any additional approval for Device Activity, or should it appear automatically once Family Controls is enabled? 3. Is there a known Xcode or Apple Developer Portal configuration issue that causes the entitlement to be missing in provisioning profiles? 4. Any working example of a project setup that uses Family Controls + Device Activity in extensions would be extremely helpful. Extra Info • We use the latest Xcode + iOS SDK. • Tried recreating certificates, profiles, and App IDs multiple times. • Followed Apple’s docs for Family Controls + Device Activity exactly. I would greatly appreciate any guidance, especially from someone who has this working with iOS app extensions. Thank you!

Hello, I am following up on several notarization requests in order to understand the process better. I submitted my first notary request yesterday and it took several hours to complete (where I submitted two other requests along the way thinking they may be stuck). They were all accepted after ~3 hours had passed since the first request was made. In that time I discovered a bug and had to rebuild/codesign, and submitted to notarize again. I've now had two requests with the new build (.zip file) "in progress" for ~18 hours. The bug fix I made between builds was innocuous and I'm wondering if my jobs are getting flagged due to recent account lockouts when I was first setting up my organizations' developer account. I've seen several replies here in the forum from DTS Engineers - hi Quinn :), so I'm aware of the possibility of 'rare' in-depth analysis, however I've experienced it in 100% of my requests. What is causing my requests to always require in-depth analysis and is there anything I can do to prevent it? My notarytool history is below for reference. Thank you in advance. createdDate: 2026-03-15T22:59:23.053Z id: 9c7ecc81-daf4-4cae-afe9-7f8186067f79 status: In Progress -------------------------------------------------- createdDate: 2026-03-15T21:10:04.576Z id: a1df8b50-c897-49f5-ad0d-f2264a03f145 status: In Progress -------------------------------------------------- createdDate: 2026-03-15T20:41:24.946Z id: 640e7cd6-035f-437b-9eab-9a3db415911a status: Accepted -------------------------------------------------- createdDate: 2026-03-15T18:40:26.944Z id: 00b9e907-04eb-4561-8353-dae7520202e0 status: Accepted -------------------------------------------------- createdDate: 2026-03-15T17:16:48.426Z id: 3163ba2b-e3c8-4216-ae8a-bac351b82f8a status: Accepted

Hello, Recently our team requested the "Notification (NSE) filtering" capability. Our request was rejected but we sent a new request with a more detailed explanation of our need. However if we go check the status of the request in the Capability Requests tab the status is "No requests". We sent the new request yesterday. Is it even possible to request a capability after a rejected request? We really need the capability and the absence of it is blocking our progress.

I have an app for iOS already on the AppStore and I'm trying to add a macOS version of it. The AppID prefix for this app is different than my Team ID. This mismatch was always fine for submitting my iOS app. However for some reason, the macOS version gets rejected when I upload it. It tells me the AppID prefix must match my Team ID. I do not control my TeamID and I do not control my AppID prefix, they are both given to me by Apple. Yet the error message tells me they must match. How do I get past this? Here is the error message: Validation failed Invalid code signing entitlements. Your application bundle's signature contains code signing entitlements that aren't supported on macOS. Specifically, the "APPID_PREFIX.MY_BUNDLE_ID" value for the com.apple.application-identifier key in "MY_PACKAGE" isn't supported. This value should be a string that starts with your Team ID, followed by a dot ('"), followed by the bundle ID. (ID: 930b77ae-099f-4798-a14a-2803f2a9be9e) Thanks in advance for any pointer.

I am trying to notarize my first macOS app for direct distribution outside the Mac App Store using Developer ID Application signing. Team ID: 32S6XVAQPY Environment: macOS app distributed via Developer ID notarytool with a saved keychain profile archive exported locally, app zipped with ditto What I already verified locally: The archived app is signed with: Developer ID Application: (32S6XVAQPY) codesign --verify --deep --strict passes spctl shows: source=Unnotarized Developer ID syspolicy_check distribution only reports the expected missing notary ticket Hardened runtime is enabled The app bundle and nested Sparkle executables were re-signed and now have valid Developer ID signatures with secure timestamps Important note: I previously had a real signing issue in nested Sparkle binaries, and Apple rejected that submission quickly as Invalid. I fixed those signatures, and now new submissions no longer fail quickly but remain stuck In Progress. Submission IDs currently stuck: bea6c4b3-b107-4c81-8042-6c58b1cf5087 5489e29c-d583-4779-a125-ca0fbd9cad0b Earlier invalid submission with a concrete Sparkle signing error: 10df648b-eca8-428f-98d6-4cb4096153ad Apple reported invalid Developer ID / missing secure timestamp on: Sparkle.framework/Versions/B/Updater.app/Contents/MacOS/Updater Sparkle.framework/Versions/B/Autoupdate Sparkle.framework/Versions/B/XPCServices/Downloader.xpc/Contents/MacOS/Downloader Sparkle.framework/Versions/B/XPCServices/Installer.xpc/Contents/MacOS/Installer That Sparkle issue has since been fixed locally and re-verified. Question: Is there currently a notarization backlog or any known issue affecting first-time macOS notarizations or Developer ID submissions? At this point the remaining submissions appear valid locally but sit In Progress for a very long time.

I have a macOS app that captures screen images. The first time I run this application, a dialog is shown directing the user to give my app Screen Recording permission. Is there a way I can trigger this dialog earlier and detect whether the permission was granted?

Hi - appreciate your help in advance! Building a simple habit tracking app. I got approval for FamilyControls distribution. After creating a new provisioning profile with those capabilities enabled, when I try and build in xcode (16.4) using that Profile I get an error stating: "Provisioning profile "CreateMoreFamilyControlsv2" doesn't include the com.apple.developer.deviceactivity and com.apple.developer.deviceactivity.reporting entitlements" I've confirmed bundle identifier matches, Team etc Similarly when i do automatic signing see 3rd screenshot. Not sure what to do at this point, I've heard deviceActivity is automatically applied when family controls is approved but still running into this issue.

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.

Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.

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?

Seeing my notarizations getting stuck. This is becoming a blocker for releasing. What's strange is that earlier versions of the same app (very similar) passed notarization very quickly. Any advice or recourse?

How do you renew a "Developer ID Application" certificate? Should there be a "renew" button on the expiration date? Or can you renew it sooner? Or are you required to create a new certificate? Does this count against your limit of five Developer ID Application certificates? I thought there was a way to renew it, but I don't see that option. I also couldn't find any Apple documentation about how to renew, only how to create and how there's a limit to how many you can create.

Hi everyone, I am attempting to generate an Ad Hoc provisioning profile for my iOS app that includes MusicKit capabilities, but the generated .mobileprovision file consistently lacks the required entitlement, despite the configuration appearing correct in the developer portal. The Issue: I have enabled MusicKit under the "App Services" tab for my App ID. I have saved this configuration, verified it is checked in the UI, and then regenerated and downloaded my provisioning profile. However, when I inspect the internal contents of the .mobileprovision file, the Entitlements dictionary does not contain the com.apple.developer.music-kit key. It only contains the standard keys (Team ID, App ID, etc.). Steps Taken: Created a brand new App ID to rule out legacy data issues. Explicitly enabled "MusicKit" under the App Services tab for this new identifier. Created a fresh Ad Hoc Distribution profile linked to this new ID. Downloaded the profile and inspected the file structure: the MusicKit entitlement is completely absent. Attempted toggling the service off and on, saving, and regenerating the profile multiple times. Has anyone experienced a specific bug where "App Services" (like MusicKit) fail to propagate to the Provisioning Profile generator? Is there a secondary "Capability" (e.g., Media Library) that must also be enabled to trigger the inclusion of the MusicKit entitlement? Any guidance would be appreciated.

Hey, Just recently I realized something I have been overlooking in my build pipelines. I thought that by adding the the "hardened runtime", I disable 3rd-party library injection (I do not have the disable-library-validation entitlement added). However, I was using some checks on my code and I noticed that the "library validation" code signature check fails on my applications (e.g. adding the .libraryValidation requirement via the LightweightCodeRequirements framework) - with codesign -dvvvv /path/to/app I can check it doesn't have the CS_REQUIRE_LV flag: [...] CodeDirectory v=20500 size=937 flags=0x10000(runtime) hashes=18+7 location=embedded [...] then I used in Xcode the "Other Code Signing Flags" setting and added the -o library option, which added the flag: [...] CodeDirectory v=20500 size=937 flags=0x12000(library-validation,runtime) hashes=18+7 location=embedded [...] Is this flag something I should be explicitly setting? Because I was under the impression enabling hardened runtime would be enough. Popular Developer ID distributed applications (e.g. Google Chrome, Parallels Desktop, Slack) all have this flag set.