App not launch on an M1 mac

have you tried using the codesign tool to verify the code signature and notarization status of your app?

Looks like Ad-hoc Development export to send the MacOS App to tester is no longer possible for Apple M1 (Mac OS 12). VERY BAD !!!

` codesign --force --deep -s - "APP1.app" APP1.app: replacing existing signature

` This is not a solution because the app is a sandbox app and after the new codesign it's no longer a sandbox app.

Looks like Ad-hoc Development export to send the MacOS App to tester is no longer

Ad hoc code signing and development code signing are two different things. You can see this in Xcode, where Signing & Capabilities lists two options:

• Sign to Run Locally (Xcode’s term for ad hoc code signing)

• Development

Both options should allow you to create an app that you can give to your internal testers to try out [1]. There are some caveats:

• Ad hoc signing doesn’t support restricted entitlements, that is, entitlements that must be allowed by a provisioning profile. For more on this, see What exactly is a provisioning profile?.

  Notably, the App Sandbox entitlement (com.apple.security.app-sandbox) does not fall into this category.

• Development signing requires that you include the internal tester’s device in your provisioning profile.

• Your internal tester must bypass Gatekeeper. The easiest way to do that is for you to transfer the app using a mechanism that doesn’t quarantine it (like scp). Alternatively, they can remove the quarantine extended attribute.

As to what’s going on here, it’s hard to say, but my first guess is that you’re bumping into Gatekeeper.

Finally, don’t use --deep. For an explanation as to why, see --deep Considered Harmful. For more details on how to manually sign, see Signing a Mac Product For Distribution. However, my expectation is that this is all irrelevant because you shouldn’t need to re-sign the app.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] The story is different if you want to distribute your app to a wide range of beta testers. I’m happy to discuss that, but it seems off-topic here.

Thanks for the info.

The Xcode capabilities / sandbox settings are only:

• outgoing connections (client)
• user selected file (read/write)

The testers machine UUIDs are in the provisioning profile.

I think you have overseen one important thing. This is an M1 issue only because the exported test app works on an intel machine.

This is an M1 issue only

Apple silicon has certain differences, like requiring that all code be signed, but I can’t think of anything that fundamentally changes this story.

Is the app built for both Apple silicon and Intel architectures?

After putting the app on the target Apple silicon machine, please do the following:

• Check that no part of it is quarantined.

  % find Test694784.app -print0 | xargs -0 xattr | grep com.apple.quarantine
  

• Check that the signature verifies:

  % codesign -v -vvv Test694784.app
  

• Check that the device’s provisioning UUID is listened in the app’s profile:

  % system_profiler SPHardwareDataType | grep "Provisioning UDID"
        Provisioning UDID: UUUUUUUU-UUUUUUUUUUUUUUUU 
  % security cms -D -i Test694784.app/Contents/embedded.provisionprofile | grep UUUUUUUU-UUUUUUUUUUUUUUUU 
      <string>A545CA26-80D7-5B38-A98C-530A798BE342</string>
  

• Check that the app’s signing certificate is also listed in the profile:

  % codesign -d --extract-certificates Test694784.app
  …
  % xxd codesign0 
  00000000: 3082 05c4 3082 04ac a003 0201 0202 107e  0...0..........~
  …
  000005c0: 0038 7e82 b4e2 f290                      .8~.....
  % security cms -D -i Test694784.app/Contents/embedded.provisionprofile > embedded.plist
  % /usr/libexec/PlistBuddy -c "Print :DeveloperCertificates:0" embedded.plist > profile0.cer
  % xxd profile0.cer 
  00000000: 3082 05c4 3082 04ac a003 0201 0202 107e  0...0..........~
  …
  000005c0: 0038 7e82 b4e2 f290 0a                   .8~......
  

  Note that PlistBuddy adds a new line at the end, which is surprisingly hard to remove with macOS’s built-in shell commands.

  Also, if DeveloperCertificates has more than one certificate, you’ll want to iterate through them all until you find a match.

• Check that every entitlement claimed by the code signature is authorised by the provisioning profile:

  % codesign -d --entitlements :Test694784.entitlements Test694784.app
  Executable=/Users/quinn/Library/Developer/Xcode/DerivedData/Test694784-acdsynfichrddecioqafdaimplsz/Build/Products/Debug/Test694784.app/Contents/MacOS/Test694784
  % bbedit Test694784.entitlements 
  % plutil -p Test694784.entitlements 
  {
    "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test694784"
    "com.apple.developer.networking.custom-protocol" => 1
    "com.apple.developer.team-identifier" => "SKMME9E2Y8"
    "com.apple.security.get-task-allow" => 1
  }
  % /usr/libexec/PlistBuddy -c "Print :Entitlements" embedded.plist  
  Dict {
      com.apple.developer.team-identifier = SKMME9E2Y8
      com.apple.developer.networking.custom-protocol = true
      com.apple.application-identifier = SKMME9E2Y8.com.example.apple-samplecode.Test694784
      keychain-access-groups = Array {
          SKMME9E2Y8.*
      }
  }
  

IMPORTANT On macOS, some entitlements don’t need to be authorised by a profile. For more on this,h see What exactly is a provisioning profile?.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello,

thanks for the answer.

• com.apple.quarantine -> CHECK
• codesign -v -> CHECK
• UUID -> CHECK
• extract-certificates -> CHECK
• codesign -d -> CHECK

But no success.

here my commandline to build my app

xcodebuild -archivePath ~/aaa.xcarchive -workspace ~/aaa.xcworkspace -scheme aaa archive -configuration Release -destination 'platform=OS X'

xcodebuild -exportArchive -archivePath ~/aaa.xcarchive -exportPath ~/aaa -exportOptionsPlist ~/exportOptionsMacDev.plist

exportOptionsMacDev.plist ->

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>destination</key>
	<string>export</string>
	<key>method</key>
	<string>development</string>
	<key>provisioningProfiles</key>
	<dict>
		<key>com.aa.aaa</key>
		<string>DEV-profile</string>
	</dict>
	<key>signingCertificate</key>
	<string>Apple Development</string>
	<key>signingStyle</key>
	<string>manual</string>
	<key>teamID</key>
	<string>XXXX</string></dict>
</plist>

[lots of CHECKs]

But no success.

Weird. At this point I’ve exhausted all the ‘obvious’ reasons and I recommend that you open a DTS tech support incident so I can allocate the time to dig into this in more detail.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

TSI Support is not for free. The App works correct on all Intel test devices. I'm no longer able to test the release version of the App. Only debug in Xcode is working. TestFlight for internals is not possible. TestFlight for externals is not a solution.

Sorry but this is not acceptable!

TSI Support is not for free.

Correct.

You have a choice here:

• You can open a TSI and I will help you investigate the issue one-on-one.

• You can continue to research this issue independently.

You have to balance the cost of a TSI against the cost of the time that you expect to spend investigating this on your own. Keep in mind that there are two ‘free’ TSIs bundled with your developer account, so the former is only a cost if you have used, or plan to use, both these TSIs this year.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"