Search results for

“codesign”

3,221 results found

Post

Replies

Boosts

Views

Activity

System-wide deadlock in removexattr from revisiond / APFS
System-wide deadlock in removexattr from revisiond / APFS We're experiencing a deadlock on certains systems when our software is installed, which is causing side effects in our process (and likely others) such as blocked queues and increased memory usage. According to the spindump, revisiond appears to be holding an exclusive lock within the kernel. Process: revisiond [426] UUID: 5E9B9E04-984B-31AD-A4FF-A1A90B7D53A1 Path: /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/Support/revisiond Codesigning ID: com.apple.revisiond Shared Cache: 25AE5A2A-FE2A-3998-8D4E-F3C5C6E6CEB6 slid base address 0x189834000, slide 0x9834000 (System Primary) Architecture: arm64e Parent: launchd [1] UID: 0 Sudden Term: Tracked Memory Limit: 50MB Jetsam Priority: 40 Footprint: 6225 KB Time Since Fork: 1740319s Num samples: 940 (1-940) Num threads: 5 Note: 1 idle work queue thread omitted [...] Thread 0xc0616d 940 samples (1-940) priority 46 (base 4) last ran 241692.754s ago 940 start_wqthread + 8 (l
19
0
520
7h
Network Extension "Signature check failed" after archive with Developer ID — works in Xcode debug
I have a macOS VPN app with a Network Extension (packet tunnel provider) distributed outside the App Store via Developer ID. Everything works perfectly when running from Xcode. After archiving and exporting for Developer ID distribution, the extension launches but immediately gets killed by nesessionmanager. The error: Signature check failed: code failed to satisfy specified code requirement(s) followed by: started with PID 0 status changed to disconnected, last stop reason Plugin failed What makes this interesting: the extension process does launch. AMFI approves it, taskgated-helper validates the provisioning profile and says allowing entitlement(s) due to provisioning profile, the sandbox is applied, PacketTunnelProvider is created — but then Apple's Security framework internally fails the designated requirement check and nesessionmanager kills the session. Key log sequence: taskgated-helper: Checking profile: Developer ID - MacOS WireGuardExtension taskgated-helper: allowing entitlement(s) for com.xx.xx.W
3
0
64
17h
ApplicationMusicPlayer.shared player.play() permission denied in app sandbox (Tauri)
Hi, I'm developing a Tauri V2 app on MacOS, and am wanting to implement playback controls. It seems that Apple locks down playback, requiring a signed application. My app also has capabilities to get currently playing track, and I confirmed this works; Apple produces a popup triggered by my await MusicAuthorization.request() call. It returns nil, of course, because I can't get anything to play via the ApplicationMusicPlayer; only through the system's Apple Music app. I understand SystemMusicPlayer is not available on MacOS, which is fine. I'm just a little confused as it seems pretty standard to need to test playback controls quickly without having to codesign and do some provisionprofile embedding acrobatics each time Rust re-compiles target/debug. This slows down development a lot. I do have these entries in my Entitlements.plist: com.apple.security.personal-information.media-library com.apple.developer.music-kit com.apple.security.app-sandbox In my tauri.conf.json, I have: macOS: { entitlements
3
0
408
2d
DeviceActivityMonitor extension rejected by App Store Connect validator — NSExtensionPointIdentifier "com.apple.deviceactivity.monitor" invalid (IrisAPI -19241)
Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid. Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedde
3
0
140
3d
Apple Pay In-App Provisioning – HTTP 500 (HTML) on broker endpoint in production (TestFlight)
We are implementing Apple Pay In-App Provisioning (EV_ECC_v2) for our EU app. The same codebase and encryption logic works successfully for our main app (different bundle ID and Adam ID), but the EU app consistently fails with HTTP 500. Environment: Entitlement: Granted (Case-ID: 18772317) Encryption scheme: EV_ECC_v2 Issue: During In-App Provisioning, the iOS app successfully obtains certificates, generates cryptographic material (encryptedCardData, activationData, ephemeralPublicKey), and POSTs to Apple's broker endpoint. The request fails at: Endpoint: POST /broker/v4/devices/{SEID}/cards Response: HTTP 500 with an HTML error page (not a JSON business error) 500 Internal Server Error 500 Internal Server Error Apple Key observations: Our main app (different bundle ID/Adam ID) uses identical encryption code, private keys, and key alias — and works correctly in production. Manual card provisioning through Apple Wallet on the same device succeeds. The entitlement com.apple.developer.payment-pass-provisioni
1
0
36
6d
Reply to Securing XPC Daemon Communication from Authorization Plugin
I’m still not entirely sure what stage you’re at here. You started this thread talking about manually checking requirements, which is not what I recommend when dealing with XPC. Rather, you should apply the requirement directly to the XPC connection, as explained in this forums post. With that in mind, it’s a question of crafting the right requirement. There are two parts to this: Identifying your clients Identifying your code loaded into system clients Identifying your clients should be straightforward. You start with the DR of those clients and then adjust the Boolean logic to suit your specific needs. It’s not possible to identify your code loaded into system clients, so the best you can do is identify those systems clients themselves. And there’s no good way to do that: You could use the client’s designated requirement (DR), but that might break if the system changes the context in which it loads your authorisation plug-ins (as has happened in the past). You could use a much broader requirement, like anch
1w
Reply to Securing XPC Daemon Communication from Authorization Plugin
[quote='881033022, robonaren, /thread/819553?answerId=881033022#881033022, /profile/robonaren'] Here are the specific requirement i've tried [/quote] So anchor apple generic is definitely wrong. Consider this quote from Code Signing Requirement Language: For Apple’s own code, signed by Apple, you can use the short form anchor apple For code signed by Apple, including code signed using a signing certificate issued by Apple to other developers, use the form anchor apple generic If your goal is security, you don’t want to mix these up! [quote='881053022, robonaren, /thread/819553?answerId=881053022#881053022, /profile/robonaren'] Here are the specific requirement i'm using from the Authorization Plugin (xpc client) [/quote] From the client? Maybe I’ve misunderstood this, but that seems backwards. You want to apply these constraints on the server for connections coming from the client. Consider this: % csreq -r '=anchor apple and (identifier com.apple.authorizationhosthelper.arm64 or identifier com.apple.authoriz
1w
Reply to Securing XPC Daemon Communication from Authorization Plugin
Thanks for the detailed information. I’ll take a look and follow up. _It’s hard to say what’s going on there without seeing the specific requirement you’re using_ Here are the specific requirement i'm using from the Authorization Plugin(xpc client) com.apple.SecurityAgentHelper.arm64, com.apple.loginwindow, com.apple.authorizationhost, com.apple.SecurityAgent, bash-3.2$ codesign --display -r - /System/Library/CoreServices/loginwindow.app Executable=/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow designated => identifier com.apple.loginwindow and anchor apple I attempted to apply a loose constraint (accepting any Apple-signed code), but it still fails. Please let me know if I’m approaching the loose constraint correctly. I was able to block other applications(created a custom app) trying to connect to my daemon. However, during the login and lock screen flows, it fails with error -67050 (errSecCSReqFailed). Is there a way to identify whether the client originates from Author
1w
Reply to Does signed macho binary with teamID is signed by Apple root certificate
[quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] I need to support both use case (exec and dylib). [/quote] OK. [quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] [Library validation] does not apply in my scenario since the library is provided by a third party [/quote] I’d like to better understand that. It’s quite common for Mac apps to use libraries created by other developers, and they retain library validation by re-signing those libraries. Is there something preventing you from doing that in this case? The most obvious case where folks need to disable library validation is that their app supports in-process plug-ins, where those plug-ins are built and shipped by other third-party developers in a way that’s completely independent of the main app’s vendor. Is that what’s happening here? Because if you’re managing these plug-in releases then it’d be better to have you re-sign the plug-in and leave library validation enab
1w
Reply to Securing XPC Daemon Communication from Authorization Plugin
[quote='819553021, robonaren, /thread/819553, /profile/robonaren'] my understanding is that root daemons typically don’t run sandboxed [/quote] Correct. While it is possible to enable the App Sandbox on a daemon, folks don’t normally do that. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The plugin only connects to the legitimate daemon [/quote] The canonical way to do that is by setting the privileged flag. I have a link to an explanation of that in XPC Resources. You could also validate the peer’s signature. Again, I have a link to info about that in XPC Resources IMPORTANT This works in this direction because you control the daemon’s main executable. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The daemon only accepts connections from trusted clients [/quote] There isn’t a good way to achieve this goal, presuming that this set of trusted clients includes an authorisation plug-in. The issue is that authorisation plug-ins are in-memory plug-ins, so you don’t control
1w
Reply to Inquiry regarding Local Push Connectivity Entitlement
Dear Quinn, In February 2021, when an Entitlement was added to Team ID WEJZZZZZZZ, I received the following email from Apple and learned how to add the Entitlement to a provisioning profile: Hi, Does Apple add entitlement to my team ? (== App ID: WEJZZZZZZZ) Yes, the entitlement was actually added to your “team”. That gives you the ability to add the entitlement to any app that’s managed by your “team”. Here is the configuration information you can use to check the current status and/or configure your own project: -To use the entitlement, you need to codesign your app with a provisioning profile that includes it. In the Apple developer portal website, you’ll need >to do the following: In the “Provisioning Profiles” section, click the “+” and to create a new profile In the “What type of provisioning profile do you need?” section, select “iOS App Development” Walk through the creation process and directly after the “Select devices.” section, you should see a new section titled “Do you need additiona
Topic: App & System Services SubTopic: General Tags:
2w
Developer ID / Notarization / Account Access Issue – No Support Response for 2+ Months
I’m looking for guidance from anyone who has experienced a similar situation. I’m a new Apple Developer Program organization member, and this was my first attempt to notarize a macOS app distributed outside the Mac App Store. What happened: My notarization submissions started failing with statusCode 7000 and the message: “Team is not yet configured for notarization.”. I created a support ticket and received the following reply: “We have escalated this issue to our internal team for further investigation and review.” This was more than 2 months ago, and I have not received any further updates since. About 3 weeks later macOS began rejecting my signed app: codesign --verify --deep --strict --verbose=4 succeeds (reports valid signing identity) spctl -a -vv --type exec returns CSSMERR_TP_CERT_REVOKED Around the same time, I also lost access to the Apple Developer portal. When signing in at developer.apple.com/account, I am redirected to the account access support form instead of the dashboard. My app has
1
0
112
2w
ppq.apple.com returning 502 Bad Gateway - Unable to verify developer apps on device
Since this evening (March 10, 2026), I'm unable to launch any developer-signed app on my physical device (iPhone 16 Pro Max, iOS 26.4 beta 23E5223k). The error is: Unable to launch [app] because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user. On the device itself, it shows: Unable to Verify App - An internet connection is required to verify the trust of the developer. What I've tried: Created a new Apple Development certificate Deleted and reinstalled the app Restarted the device Tested on both Wi-Fi and cellular Confirmed Developer Mode is enabled Removed all third-party CA certificates from the device Verified the code signature is valid (codesign -dv shows correct Authority chain) The root cause: https://ppq.apple.com is currently returning 502 Bad Gateway. I confirmed this both from my Mac (curl -s -o /dev/null -w %{http_code} https://ppq.apple.com → 502) and from Safari on the device. This affects all developer-signed apps, no
141
0
12k
2w
Notarization Requests In Progress
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 preven
1
0
131
2w
System-wide deadlock in removexattr from revisiond / APFS
System-wide deadlock in removexattr from revisiond / APFS We're experiencing a deadlock on certains systems when our software is installed, which is causing side effects in our process (and likely others) such as blocked queues and increased memory usage. According to the spindump, revisiond appears to be holding an exclusive lock within the kernel. Process: revisiond [426] UUID: 5E9B9E04-984B-31AD-A4FF-A1A90B7D53A1 Path: /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/Support/revisiond Codesigning ID: com.apple.revisiond Shared Cache: 25AE5A2A-FE2A-3998-8D4E-F3C5C6E6CEB6 slid base address 0x189834000, slide 0x9834000 (System Primary) Architecture: arm64e Parent: launchd [1] UID: 0 Sudden Term: Tracked Memory Limit: 50MB Jetsam Priority: 40 Footprint: 6225 KB Time Since Fork: 1740319s Num samples: 940 (1-940) Num threads: 5 Note: 1 idle work queue thread omitted [...] Thread 0xc0616d 940 samples (1-940) priority 46 (base 4) last ran 241692.754s ago 940 start_wqthread + 8 (l
Replies
19
Boosts
0
Views
520
Activity
7h
Network Extension "Signature check failed" after archive with Developer ID — works in Xcode debug
I have a macOS VPN app with a Network Extension (packet tunnel provider) distributed outside the App Store via Developer ID. Everything works perfectly when running from Xcode. After archiving and exporting for Developer ID distribution, the extension launches but immediately gets killed by nesessionmanager. The error: Signature check failed: code failed to satisfy specified code requirement(s) followed by: started with PID 0 status changed to disconnected, last stop reason Plugin failed What makes this interesting: the extension process does launch. AMFI approves it, taskgated-helper validates the provisioning profile and says allowing entitlement(s) due to provisioning profile, the sandbox is applied, PacketTunnelProvider is created — but then Apple's Security framework internally fails the designated requirement check and nesessionmanager kills the session. Key log sequence: taskgated-helper: Checking profile: Developer ID - MacOS WireGuardExtension taskgated-helper: allowing entitlement(s) for com.xx.xx.W
Replies
3
Boosts
0
Views
64
Activity
17h
ApplicationMusicPlayer.shared player.play() permission denied in app sandbox (Tauri)
Hi, I'm developing a Tauri V2 app on MacOS, and am wanting to implement playback controls. It seems that Apple locks down playback, requiring a signed application. My app also has capabilities to get currently playing track, and I confirmed this works; Apple produces a popup triggered by my await MusicAuthorization.request() call. It returns nil, of course, because I can't get anything to play via the ApplicationMusicPlayer; only through the system's Apple Music app. I understand SystemMusicPlayer is not available on MacOS, which is fine. I'm just a little confused as it seems pretty standard to need to test playback controls quickly without having to codesign and do some provisionprofile embedding acrobatics each time Rust re-compiles target/debug. This slows down development a lot. I do have these entries in my Entitlements.plist: com.apple.security.personal-information.media-library com.apple.developer.music-kit com.apple.security.app-sandbox In my tauri.conf.json, I have: macOS: { entitlements
Replies
3
Boosts
0
Views
408
Activity
2d
DeviceActivityMonitor extension rejected by App Store Connect validator — NSExtensionPointIdentifier "com.apple.deviceactivity.monitor" invalid (IrisAPI -19241)
Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid. Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedde
Replies
3
Boosts
0
Views
140
Activity
3d
Apple Pay In-App Provisioning – HTTP 500 (HTML) on broker endpoint in production (TestFlight)
We are implementing Apple Pay In-App Provisioning (EV_ECC_v2) for our EU app. The same codebase and encryption logic works successfully for our main app (different bundle ID and Adam ID), but the EU app consistently fails with HTTP 500. Environment: Entitlement: Granted (Case-ID: 18772317) Encryption scheme: EV_ECC_v2 Issue: During In-App Provisioning, the iOS app successfully obtains certificates, generates cryptographic material (encryptedCardData, activationData, ephemeralPublicKey), and POSTs to Apple's broker endpoint. The request fails at: Endpoint: POST /broker/v4/devices/{SEID}/cards Response: HTTP 500 with an HTML error page (not a JSON business error) 500 Internal Server Error 500 Internal Server Error Apple Key observations: Our main app (different bundle ID/Adam ID) uses identical encryption code, private keys, and key alias — and works correctly in production. Manual card provisioning through Apple Wallet on the same device succeeds. The entitlement com.apple.developer.payment-pass-provisioni
Replies
1
Boosts
0
Views
36
Activity
6d
Reply to Securing XPC Daemon Communication from Authorization Plugin
I’m still not entirely sure what stage you’re at here. You started this thread talking about manually checking requirements, which is not what I recommend when dealing with XPC. Rather, you should apply the requirement directly to the XPC connection, as explained in this forums post. With that in mind, it’s a question of crafting the right requirement. There are two parts to this: Identifying your clients Identifying your code loaded into system clients Identifying your clients should be straightforward. You start with the DR of those clients and then adjust the Boolean logic to suit your specific needs. It’s not possible to identify your code loaded into system clients, so the best you can do is identify those systems clients themselves. And there’s no good way to do that: You could use the client’s designated requirement (DR), but that might break if the system changes the context in which it loads your authorisation plug-ins (as has happened in the past). You could use a much broader requirement, like anch
Replies
Boosts
Views
Activity
1w
Reply to Securing XPC Daemon Communication from Authorization Plugin
[quote='881033022, robonaren, /thread/819553?answerId=881033022#881033022, /profile/robonaren'] Here are the specific requirement i've tried [/quote] So anchor apple generic is definitely wrong. Consider this quote from Code Signing Requirement Language: For Apple’s own code, signed by Apple, you can use the short form anchor apple For code signed by Apple, including code signed using a signing certificate issued by Apple to other developers, use the form anchor apple generic If your goal is security, you don’t want to mix these up! [quote='881053022, robonaren, /thread/819553?answerId=881053022#881053022, /profile/robonaren'] Here are the specific requirement i'm using from the Authorization Plugin (xpc client) [/quote] From the client? Maybe I’ve misunderstood this, but that seems backwards. You want to apply these constraints on the server for connections coming from the client. Consider this: % csreq -r '=anchor apple and (identifier com.apple.authorizationhosthelper.arm64 or identifier com.apple.authoriz
Replies
Boosts
Views
Activity
1w
Reply to Securing XPC Daemon Communication from Authorization Plugin
Thanks for the detailed information. I’ll take a look and follow up. _It’s hard to say what’s going on there without seeing the specific requirement you’re using_ Here are the specific requirement i'm using from the Authorization Plugin(xpc client) com.apple.SecurityAgentHelper.arm64, com.apple.loginwindow, com.apple.authorizationhost, com.apple.SecurityAgent, bash-3.2$ codesign --display -r - /System/Library/CoreServices/loginwindow.app Executable=/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow designated => identifier com.apple.loginwindow and anchor apple I attempted to apply a loose constraint (accepting any Apple-signed code), but it still fails. Please let me know if I’m approaching the loose constraint correctly. I was able to block other applications(created a custom app) trying to connect to my daemon. However, during the login and lock screen flows, it fails with error -67050 (errSecCSReqFailed). Is there a way to identify whether the client originates from Author
Replies
Boosts
Views
Activity
1w
Reply to Does signed macho binary with teamID is signed by Apple root certificate
[quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] I need to support both use case (exec and dylib). [/quote] OK. [quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] [Library validation] does not apply in my scenario since the library is provided by a third party [/quote] I’d like to better understand that. It’s quite common for Mac apps to use libraries created by other developers, and they retain library validation by re-signing those libraries. Is there something preventing you from doing that in this case? The most obvious case where folks need to disable library validation is that their app supports in-process plug-ins, where those plug-ins are built and shipped by other third-party developers in a way that’s completely independent of the main app’s vendor. Is that what’s happening here? Because if you’re managing these plug-in releases then it’d be better to have you re-sign the plug-in and leave library validation enab
Replies
Boosts
Views
Activity
1w
Reply to Securing XPC Daemon Communication from Authorization Plugin
[quote='819553021, robonaren, /thread/819553, /profile/robonaren'] my understanding is that root daemons typically don’t run sandboxed [/quote] Correct. While it is possible to enable the App Sandbox on a daemon, folks don’t normally do that. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The plugin only connects to the legitimate daemon [/quote] The canonical way to do that is by setting the privileged flag. I have a link to an explanation of that in XPC Resources. You could also validate the peer’s signature. Again, I have a link to info about that in XPC Resources IMPORTANT This works in this direction because you control the daemon’s main executable. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The daemon only accepts connections from trusted clients [/quote] There isn’t a good way to achieve this goal, presuming that this set of trusted clients includes an authorisation plug-in. The issue is that authorisation plug-ins are in-memory plug-ins, so you don’t control
Replies
Boosts
Views
Activity
1w
Reply to Inquiry regarding Local Push Connectivity Entitlement
Dear Quinn, In February 2021, when an Entitlement was added to Team ID WEJZZZZZZZ, I received the following email from Apple and learned how to add the Entitlement to a provisioning profile: Hi, Does Apple add entitlement to my team ? (== App ID: WEJZZZZZZZ) Yes, the entitlement was actually added to your “team”. That gives you the ability to add the entitlement to any app that’s managed by your “team”. Here is the configuration information you can use to check the current status and/or configure your own project: -To use the entitlement, you need to codesign your app with a provisioning profile that includes it. In the Apple developer portal website, you’ll need >to do the following: In the “Provisioning Profiles” section, click the “+” and to create a new profile In the “What type of provisioning profile do you need?” section, select “iOS App Development” Walk through the creation process and directly after the “Select devices.” section, you should see a new section titled “Do you need additiona
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
2w
Developer ID / Notarization / Account Access Issue – No Support Response for 2+ Months
I’m looking for guidance from anyone who has experienced a similar situation. I’m a new Apple Developer Program organization member, and this was my first attempt to notarize a macOS app distributed outside the Mac App Store. What happened: My notarization submissions started failing with statusCode 7000 and the message: “Team is not yet configured for notarization.”. I created a support ticket and received the following reply: “We have escalated this issue to our internal team for further investigation and review.” This was more than 2 months ago, and I have not received any further updates since. About 3 weeks later macOS began rejecting my signed app: codesign --verify --deep --strict --verbose=4 succeeds (reports valid signing identity) spctl -a -vv --type exec returns CSSMERR_TP_CERT_REVOKED Around the same time, I also lost access to the Apple Developer portal. When signing in at developer.apple.com/account, I am redirected to the account access support form instead of the dashboard. My app has
Replies
1
Boosts
0
Views
112
Activity
2w
ppq.apple.com returning 502 Bad Gateway - Unable to verify developer apps on device
Since this evening (March 10, 2026), I'm unable to launch any developer-signed app on my physical device (iPhone 16 Pro Max, iOS 26.4 beta 23E5223k). The error is: Unable to launch [app] because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user. On the device itself, it shows: Unable to Verify App - An internet connection is required to verify the trust of the developer. What I've tried: Created a new Apple Development certificate Deleted and reinstalled the app Restarted the device Tested on both Wi-Fi and cellular Confirmed Developer Mode is enabled Removed all third-party CA certificates from the device Verified the code signature is valid (codesign -dv shows correct Authority chain) The root cause: https://ppq.apple.com is currently returning 502 Bad Gateway. I confirmed this both from my Mac (curl -s -o /dev/null -w %{http_code} https://ppq.apple.com → 502) and from Safari on the device. This affects all developer-signed apps, no
Replies
141
Boosts
0
Views
12k
Activity
2w
Notarization Requests In Progress
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 preven
Replies
1
Boosts
0
Views
131
Activity
2w