Hello,
I've been developing a mac app built with Electron Builder. In August, I was successfully notarizing my app and able to send it to testers without them receiving a malware warning. I took a two month break. When I came back in October, I am not able to distribute my app without the malware warning.
I can't for the life of me figure out what I could be missing, unless my developer account was flagged by Apple for some reason. All the diagnostics I run on my app package show that it is properly signed, notarized, and stapled.
Here are some diagnostics I have run on the app:
Command: codesign -dv --verbose=4 "/Volumes/Form Desktop 1/Form.app"
Output:
Executable=/Volumes/Form Desktop 1/Form.app/Contents/MacOS/Form
Identifier=co.Form.desktop
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=763 flags=0x10000(runtime) hashes=13+7 location=embedded
VersionPlatform=1
VersionMin=720896
VersionSDK=917504
Hash type=sha256 size=32
CandidateCDHash sha256=cedcaef933c003c01b4d9ef6925a413fe6b4a585
CandidateCDHashFull sha256=cedcaef933c003c01b4d9ef6925a413fe6b4a585bf61e19751e8158775600b00
Hash choices=sha256
CMSDigest=cedcaef933c003c01b4d9ef6925a413fe6b4a585bf61e19751e8158775600b00
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=16384
Executable Segment flags=0x1
Page size=4096
CDHash=cedcaef933c003c01b4d9ef6925a413fe6b4a585
Signature size=8973
Authority=Developer ID Application: Jacob LEELAND (92D98F49FU)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Nov 14, 2025 at 8:25:09 PM
Notarization Ticket=stapled
Info.plist entries=30
TeamIdentifier=92D98F49FU
Runtime Version=14.0.0
Sealed Resources version=2 rules=13 files=35090
Internal requirements count=1 size=176
RESULT: ✅ SIGNED WITH DEVELOPER ID
✅ NOTARIZATION TICKET STAPLED
✅ HARDENED RUNTIME ENABLED
----------------------------------------------------------------
Command: spctl --assess --verbose=4 --type execute "/Volumes/Form Desktop 1/Form.app"
Output:
/Volumes/Form Desktop 1/Form.app: accepted
source=Notarized Developer ID
RESULT: ✅ GATEKEEPER ACCEPTS APPLICATION
----------------------------------------------------------------
Command: xattr -l "/Volumes/Form Desktop 1/Form.app"
Output:
(No extended attributes)
----------------------------------------------------------------
Command: stapler validate "/Volumes/Form Desktop 1/Form.app"
Output:
Processing: /Volumes/Form Desktop 1/Form.app
The validate action worked!
RESULT: ✅ NOTARIZATION TICKET VALID
[signing-verification-report.txt](https://developer.apple.com/forums/content/attachment/45b41936-6e7a-4f4f-8e80-bc1e3136c84e)
code-block
I have attached a more complete diagnostic text file as well. I have tried notarizing the .dmg in addition to the app bundle, but no combination seems to work as far as I can tell.
I appreciate any help or point in the right direction. I've wasted many days of development time on this, lol.
Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I suddenly started to receive the following email with the error in it stating that my uploaded app is not available to be used in TestFlight:
ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at “MyApp.app/Contents/PlugIns/MyAppWidgetExtension.appex” 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.'
It was all working fine and now I am not sure even where to start looking. Signing, provisioning and everything else is managed automatically.
Hi everyone,
Has anyone seen notarization behave like this?
We have one specific app (let’s call it App A) with a Network Extension system extension. Whenever we submit App A for notarization:
• Its submission stays “In Progress” indefinitely
• The provisioning profile for its system extension becomes Invalid on its own
• All our other apps suddenly fail notarization
• And the whole team immediately gets:
StatusCode 7000 – “Team is not yet configured for notarization.”
Apple Support restored notarization once(Case 102738171569), and we confirmed other apps notarize fine — until we submit App A again, which instantly triggers the same team-wide block. This cycle has repeated twice.
We verified:
• Hardened runtime
• Proper system extension signing
• No private API usage
• No get-task-allow
• No ATS violations
What’s confusing is that this doesn’t look like a normal notarization rejection. Normal failures don’t invalidate provisioning profiles or disable notarization for the entire team. It feels more like an automated security heuristic or misclassification.
My questions:
1. Can a single app or system extension trigger an automated team-wide notarization disable?
2. Can an entitlement or NE configuration issue cause StatusCode 7000 instead of a standard rejection?
3. If this could be a false positive, is there a specific team at Apple who can manually review/clear it?
Any insight would be greatly appreciated.
Hello, We are currently using Apple Notarization (notarytool) for distributing a macOS app, and we are experiencing very long notarization times for large app bundles.
[Issue]
For apps with large binary sizes, notarization consistently takes around 3.5 to 4.5 hours from submission to completion.
This delay is causing practical issues in our release pipeline, especially when:
A hotfix or urgent update is required
Multiple builds must be notarized in a short time
CI/CD-based distribution is expected to complete within a predictable timeframe
[Environment]
Platform: macOS
Notarization method: notarytool
Distribution: Outside Mac App Store
App size: 100 GB~ (compressed ZIP)
Signing: Hardened Runtime enabled, codesigned correctly
Submission status: Successfully accepted, but processing time is very long
[What we have confirmed]
The notarization eventually succeeds (no failures)
Re-submitting the same build shows similar processing times
Network upload itself completes normally; the delay is in Apple-side processing
Smaller apps complete notarization much faster
[Questions]
Is a 3–4+ hour notarization time expected behavior for large macOS apps?
Are there recommended best practices to reduce notarization processing time for large binaries?
For example, splitting components, adjusting packaging, or specific signing strategies
Is there any official guidance or limitation regarding notarization queueing or processing based on app size?
Are there known service-side delays or regional differences that could affect processing time?
Any insight or confirmation would be greatly appreciated, as this directly impacts our production release workflow.
Thank you.
In our local test configurations, a developer can sign test apps for device installation using any key associated with the company team. However, if a developer accidentally chooses an identity from some other team, installation fails with no information about the problem. It just mentions that no provisioning profile could be found, leaving everyone in the dark about what is wrong.
Instead, we would like to pre-validate the selected signing identity by checking the team name or id. This could be done, for example, by extracting the x509 certificate from the signing identity and checking the "OU" field (which is set to the team id). However, none of the apple commands will divulge the x509 certificate from a developer id. So far our best options is to create a fake app, sign the app, then use command:
codesign --display --extract-certificates
This solution seems excessively serpentine. Is there no direct command that will accept the sha of a signing identity and return a nice .pem containing the associated certificate chain? Or, better yet, is there a command that takes the signing identity and simply returns the name or id of the associated team?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Is there a way to check your app signature to verify if any one has tampered with the ipa file. I want to know specifically how to determine and handle this type of situation. How can i do a check for this in code(swift).
The mentioned way of setting up complications does not work. We can't create the identifier according to the guideline mentioned in the WWDC session.
https://developer.apple.com/videos/play/wwdc2020/10049/?time=1021
Timestamp: 17:04
Error:
An attribute in the provided entity has invalid value
An App ID with Identifier '.watchkitapp.complication' is not available.
Please enter a different string.
To clarify - the non masked identifier is not used on another property inside our dev program.
Without creating the identifier our tests result in not working push notifications.
Error message while testing: discarded as application was not registered.
Is the way mentioned in the WWDC session still valid?
BR
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Bundle ID
Watch Complications
I have multiple submissions for an app notarization. The goal is to distribute the DMG on my website rather than the app store (which I also have a submission in review for). These are the notarization logs:
--------------------------------------------------
createdDate: 2025-06-23T20:26:46.597Z
id: 75972c58-bc83-44a9-b3af-4aff1b1839c3
name: Mira-Assist-Fresh.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T17:53:11.825Z
id: 4bccdfb6-6663-41d3-89bc-c0a15fbdd4b8
name: Mira Assist.zip
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T17:45:10.342Z
id: fedca538-7619-4a7f-bcc8-3199d6e4b1a6
name: Mira-Assist-1.0.0-Hardened.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T02:51:04.289Z
id: 19a866b9-e664-4641-b137-6ac852c14ac9
name: Mira Assist-1.0.0.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T02:44:25.372Z
id: 455209e5-91dd-4324-aac0-d582f88efc95
name: Mira Assist-1.0.0.dmg
status: In Progress
The earliest of which occured more than 18 hours ago.
This is my first time submitting an app for notarization. I also have a developer account that was created ~1-2 days ago.
From what I've read online, notarization usually occurs in less than 10 minutes.
When querying for the logs, it juts says that the submission ID is invalid or the logs aren't available yet.
Submission log is not yet available or submissionId does not exist
id: 75972c58-bc83-44a9-b3af-4aff1b1839c3
Hello,
My project fails to build/run on a physical device or archive, due to a persistent provisioning error.
Exact Error: Provisioning profile "iOS Team Provisioning Profile: com.huiwan.Ohra-Journal" doesn't include the BGTaskSchedulerPermittedIdentifiers entitlement.
I have already performed extensive troubleshooting, and all local configurations appear to be correct:
Capabilities: "Background Modes" with the "Background processing" option is enabled in the target's "Signing & Capabilities" tab.
Info.plist: The Permitted background task scheduler identifiers key is present in the target's Info.plist, and it contains the correct task identifier (com.huiwan.ohra-journal.refresh).
Entitlements File: The .entitlements file is correctly configured by Xcode.
Full Reset: I have tried a complete reset procedure, including deleting ~/Library/Developer/Xcode/DerivedData and ~/Library/MobileDevice/Provisioning Profiles/, restarting Xcode, and letting the automatic signing system regenerate the profile from scratch. The issue persists.
Despite all these correct local settings, the provisioning profile automatically generated by Xcode is consistently missing the required entitlement. This strongly suggests a server-side issue with the provisioning service for my App ID (com.huiwan.Ohra-Journal).
I filed a bug report on the Feedback Assistant (FB20268285) a week ago but have not received a response. This issue is completely blocking my development and ability to submit the app.
Could you please investigate the status of my App ID and the provisioning services associated with it?
Thank you.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Xcode Server
Xcode
Signing Certificates
Developer ID
We have an application which keeps throwing the error "application is damaged and cannot be opened. You should move it to Trash"
I have already referred to the documentation: https://developer.apple.com/forums/thread/706379 and https://developer.apple.com/forums/thread/706442
I have checked the following possible root causes:
Codesign of the application using the codesign command
Notarization of the application using the spctl command
Executable permissions
Checked for the presence of "com.apple.quarantine" flag for the application using xattr -l <path to executables"
Checked the bundle structure
None of the above listed items seemed to be a problem and are as expected.
Can you please help us understand what could cause this issue and how to resolve this without recommending an uninstall/reinstall of the application?
Hi folks,
I'm trying to generate a provisioning profile that includes both Healthkit and MusicKit entitlements.
The healthKit pieces if fine, and included in the profile. However, despite selecting Musickit under services in the ID setup, the entitlement doesn't seem to be included in the profile.
Other steps taken: Setup the app in App Store Connect, generated a media ID and Key. Tried both automatic and manual signing.
Are there specifics tricks to getting this one to work?
Tried notarizing my app yesterday afternoon via Mac terminal, and when I came back to work this morning it was still "In Process...". I closed terminal, and checked appleid.apple.com, and it was asking me to reset my password- maybe because the notarization timed out?
Either way, I reset my password, generated a new app-specific password and tried notarizing the app again, but it's now been 3 hours and it's still "In Process..." again.
When I check the status via terminal, nothing seems off- and the status is In Progress.
How can I determine if there's a bigger issue I need to fix before notarizing?
UUID: e7ae29c8-2478-41a3-93b4-3f274de643d0
Topic:
Code Signing
SubTopic:
Notarization
I'm trying to enable Music Kit for my key however I keep seeing this message "There are no identifiers available that can be associated with the key" even though my identifier has music kit enabled. Can someone help out with this?
Hi,
This is my first time notarizing an app with Developer ID.
I have submitted multiple notarization requests, and all of them have been
stuck in "In Progress" status. The oldest one was submitted over 24 hours ago.
Is this normal for first-time submissions?
How long should I wait before contacting support?
Thanks!
Topic:
Code Signing
SubTopic:
Notarization
I got an email with the subject "Action Needed: Developer ID Application Certificate Expires in 30 Days"
But on the cert page it's not exactly clear to my how to renew the cert or generate a new one.
Confused by the fact that I already have half a dozen ...somehow?
Any help or guidance appreciated.
Hi Apple Developer Community,
I'm trying to resolve the following Xcode build error:
*"Provisioning profile 'iOS Team Provisioning Profile: ' doesn't include the com.apple.developer.live-activities entitlement."
To fix this, I understand I need to add the Live Activity capability to my App ID and ensure it’s included in the provisioning profile.
However, when I go to Certificates, Identifiers & Profiles, select my App ID, and click Edit under "App ID Configuration," the Live Activity capability is not available in the list of capabilities. As a result, I can’t proceed with enabling the entitlement or regenerating a correct provisioning profile.
I’ve confirmed:
My App ID is explicit (not a wildcard).
The app’s deployment target is set to iOS 16.1 or later.
I’m signed in with the correct Apple Developer Team account.
etc.
Has anyone experienced this? Is there a prerequisite that I might be missing?
Thanks in advance for your help!
Best regards,
David Winograd
Rokfin, Inc.
Hey devs,
I have a really weird issue and at this point I cannot determine is it a Big Sur 11.1 or M1 issue or just some macOS settings issue.
Short description
programatically (from node, electron) I'd like to store x509 cert to keychain. I got the following error message:
SecTrustSettingsSetTrustSettings: The authorization was denied since no user interaction was possible. (1) I could reproduce this issue on: a brand new mac mini with M1 chip and Big Sur 11.1
another brand new mac mini with M1 chip and Big Sur 11.1
a 2018 MacBook pro with Intel chip and Big Sur 11.1
I couldn't reproduce this issue on: 2020 MacBook pro with intel i9 chip and Big Sur 11.1
2020 MacBook pro with intel i9 chip and Big Sur 11.0
How am I trying to store the cert
node test.js
test.js
const { exec } = require('child_process')
exec(
	`osascript -e 'do shell script "security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /Users/kotapeter/ssl/testsite.local.crt" with prompt "Test APP wants to store SSL certification to keychain." with administrator privileges'`,
	(error, stdout, stderr) => {
		if (error) {
			console.log(error.stack)
			console.log(`Error code: ${error.code}`)
			console.log(`Signal received: ${error.signal}`)
		}
		console.log(`STDOUT: ${stdout}`)
		console.log(`STDERR: ${stderr}`)
		process.exit(1)
	}
)
testsite.local.crt:
----BEGIN CERTIFICATE
MIIDUzCCAjugAwIBAgIUD9xMnL73y7fuida5TXgmklLswsowDQYJKoZIhvcNAQEL
BQAwGTEXMBUGA1UEAwwOdGVzdHNpdGUubG9jYWwwHhcNMjEwMTE3MTExODU1WhcN
NDEwMTEyMTExODU1WjAZMRcwFQYDVQQDDA50ZXN0c2l0ZS5sb2NhbDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANM08SDi06dvnyU1A6//BeEFd8mXsOpD
QCbYEHX/Pz4jqaBYwVjD5pG7FkvDeUKZnEVyrsofjZ4Y1WAT8jxPMUi+jDlgNTiF
jPVc4rA6hcGX6b70HjsCACmc8bZd+EU7gm4b5eL6exTsVzHc+lFz4eQFXgutYTL7
guDQE/gFHwqPkLvnfg3rgY31p3Hm/snL8NuD154iE9O1WuSxEjik65uOQaewZmJ9
ejJEuuEhMA8O9dXveJ71TMV5lqA//svDxBu3zXIxMqRy2LdzfROd+guLP6ZD3jUy
cWi7GpF4yN0+rD/0aXFJVHzV6TpS9oqb14jynvn1AyVfBB9+VQVNwTsCAwEAAaOB
kjCBjzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIC9DA7BgNVHSUENDAyBggrBgEFBQcD
AQYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgwHQYDVR0O
BBYEFDjAC2ObSbB59XyLW1YaD7bgY8ddMBkGA1UdEQQSMBCCDnRlc3RzaXRlLmxv
Y2FsMA0GCSqGSIb3DQEBCwUAA4IBAQBsU6OA4LrXQIZDXSIZPsDhtA7YZWzbrpqP
ceXPwBd1k9Yd9T83EdA00N6eoOWFzwnQqwqKxtYdl3x9JQ7ewhY2huH9DRtCGjiT
m/GVU/WnNm4tUTuGU4FyjSTRi8bNUxTSF5PZ0U2/vFZ0d7T43NbLQAiFSxyfC1r6
qjKQCYDL92XeU61zJxesxy5hxVNrbDpbPnCUZpx4hhL0RHgG+tZBOlBuW4eq249O
0Ql+3ShcPom4hzfh975385bfwfUT2s/ovng67IuM9bLSWWe7U+6HbOEvzMIiqK94
YYPmOC62cdhOaZIJmro6lL7eFLqlYfLU4H52ICuntBxvOx0UBExn----END CERTIFICATE
testsite.local.key:
----BEGIN RSA PRIVATE KEY
MIIEpQIBAAKCAQEA0zTxIOLTp2+fJTUDr/8F4QV3yZew6kNAJtgQdf8/PiOpoFjB
WMPmkbsWS8N5QpmcRXKuyh+NnhjVYBPyPE8xSL6MOWA1OIWM9VzisDqFwZfpvvQe
OwIAKZzxtl34RTuCbhvl4vp7FOxXMdz6UXPh5AVeC61hMvuC4NAT+AUfCo+Qu+d+
DeuBjfWnceb+ycvw24PXniIT07Va5LESOKTrm45Bp7BmYn16MkS64SEwDw711e94
nvVMxXmWoD/+y8PEG7fNcjEypHLYt3N9E536C4s/pkPeNTJxaLsakXjI3T6sP/Rp
cUlUfNXpOlL2ipvXiPKe+fUDJV8EH35VBU3BOwIDAQABAoIBAQDDGLJsiFqu3gMK
IZCIcHCDzcM7Kq43l2uY9hkuhltrERJNle70CfHgSAtubOCETtT1qdwfxUnR8mqX
15T5dMW3xpxNG7vNvD/bHrQfyc9oZuV6iJGsPEreJaV5qg/+E9yFzatrIam0SCS7
YL6xovPU58hZzQxuRbo95LetcT2dSBY33+ttY7ayV/Lx7k6nh0xU6RmTPHyyr8m7
yHpoJoSxdT/xv5iBSZ8mM9/2Vzhr14SWipVuwVVhDSfbn8ngHpIoQDkaJLMpWr+m
4z3PqfftAwR6s6i96HnhYLnRir618TQh4B9IEngeEwCMn4XAzE3L+VTaKU1hg9el
aMfXzPERAoGBAPa+sJ2p9eQsv0vCUUL8KeRWvwjDZRTd+YAIfpLMWrb0tMmrBM4V
V0L2joF76kdDxt1SAlHoYCT/3Rn8EPmK0TN3MEskiXQ7v57iv+LZOZcpe0ppG/4A
ZihF9+wUjFCDw4ymnRQD463535O6BgZV+rcZksFRD2AwvEjt1nYm93VXAoGBANsh
AYM+FPmMnzebUMB0oGIkNkE9nVb9MPbQYZjEeOeHJqmt1Nl6xLuYBWTmWwCy7J4e
QPtnuMCdO6C1kuOGjQPBFIpeyFMzll+E3hKzicumgCpt5U8nTZoKc/jZckRD7n3p
lbYYgHOR3A/3GCDK5L3rwziWpSRAGMSCQylvkOC9AoGBAKLfZL3t/r3LO8rKTdGl
mhF7oUYrlIGdtJ/q+4HzGr5B8URdeyJ9u8gb8B1Qqmi4OIDHLXjbpvtFWbFZTesq
0sTiHCK9z23GMsqyam9XbEh3vUZ082FK6iQTa3+OYMCU+XPSV0Vq+9NPaWGeHXP5
NTG/07t/wmKASQjq1fHP7vCpAoGBAK4254T4bqSYcF09Vk4savab46aq3dSzJ6KS
uYVDbvxkLxDn6zmcqZybmG5H1kIP/p8XXoKCTBiW6Tk0IrxR1PsPHs2D3bCIax01
/XjQ1NTcYzlYdd8gWEoH1XwbJQWxHINummBTyowXguYOhVhM9t8n+eWbn1/atdZF
2i+vS3fhAoGAYKw6rkJfTSEswgBKlQFJImxVA+bgKsEwUti1aBaIA2vyIYWDeV10
G8hlUDlxvVkfwCJoy5zz6joGGO/REhqOkMbFRPseA50u2NQVuK5C+avUXdcILJHN
zp0nC5eZpP1TC++uCboJxo5TIdbLL7GRwQfffgALRBpK12Vijs195cc=----END RSA PRIVATE KEY
What I've already found
If I run the following command from terminal It asks my password first in terminal and after that It asks my password again in OS password prompt.
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /Users/kotapeter/ssl/testsite.local.crt
It looks like I'm getting the above error message because osascript hides the second password asking dialog.
The cert always gets stored in keychain but when I get the error message the cert "Trust" value is not "Always Trust".
References
StackOverflow question: https://stackoverflow.com/questions/65699160/electron-import-x509-cert-to-local-keychain-macos-the-authorization-was-deni
opened issue on sudo-prompt electron package: https://github.com/jorangreef/sudo-prompt/issues/137
I've been trying to have an app I've built notarized by Apple. The processing hangs there for hours just waiting.
I even tried with a tiny 1KB test file, it has been stuck for 25+ minutes, and I have 7 real submissions stuck for 24+ hours.
Any Apple representative can help please? I need to publish and release my app asap.
Topic:
Code Signing
SubTopic:
Notarization
We've been creating iOS apps for a few years now, but when I tried last month, I got an error in my XCode that says:
No profiles for 'com.os.hub.mth2' were found
Xcode couldn't find any iOS App Development provisioning profiles matching 'xxx.xxx.xxx.xxx'.
I'm not sure if it's the cause or not, but when I look at the signing certificates, the Developer ID Application Certificate says:
Missing Private Key
The weird part of that is that I see a private key with this name in my Keychain access, so I'm not sure what's wrong.
There has been a significant time gap between now and the last time we created a mobile app, so I'm not sure if something changed in XCode/MacOS to cause this issue, or if something expired.
I'd appreciate any advice.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
App Store Connect
Notarization
Developer ID
Hello, I sent this in as a feedback several weeks ago about watchOS 26.2 beta 2 but since the issue is still active now that watchOS 26.2 is in production I'm reposting here for the community. I would also like to submit a DTS about this issue but honestly don't know the best way to go about it and would appreciate advice about that.
There seems to be an issue with VPP distribution for our app on watchOS 26.2. When our watchOS companion app is launched after being installed through VPP to a supervised iPhone, it encounters a dyld error before main() or any application code is even called. The same app launches correctly in every other circumstance we could imagine and test:
– Installed through VPP on supervised devices running watchOS 26.1.
– Installed from the app store (using an apple id) on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2.
– Installed through Testflight on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2.
– Installed through the app store on unsupervised devices running watchOS 26.1 and 26.2.
This strongly appears to be a VPP signing issue because we even did the following experiment:
Install iPhone and Watch apps through the App Store on a supervised device pair running public iOS 26.2 beta 2 / watchOS 26.2 beta 2.
Verify that both apps launch successfully.
Use an MDM command to install from VPP over the existing installations
Verify that the watch app fails to launch (the iOS app is unaffected)
My feedback included some crash logs which I won't be reposting publicly here. Any feedback or ideas appreciated.