Is Development distribution still a thing?

Question

My goal is to use Development signing (Organizer -> Distribute App -> Development radio button) to distribute my app to internal testers during the development process. Note: this is explicitly different than "Developer ID signing". This is the flavor that requires a provisioning profile that enumerates all possible target Mac device UUIDs.

I have setup an app identifier, development certificate and a provisioning profile that contains the UUID of another Mac.
I have created a simple macOS test app using nothing more than Xcode-provided (11.13.1) code and resources.

When I use the Organizer -> Distribute App -> Development UI-based worflow to create a distribution for the Mac defined in the provisioning profile and attempt to run on the target Mac (running 10.15.2), I get the following error:

“SignTest” can’t be opened because Apple cannot check it for malicious software.

This software needs to be updated. Contact the developer for more information.

This looks like the same error you'd receive with a Developer ID signed app that was not notarized before running.

Code sign verification checks out:

λ codesign --verify --deep --verbose=3 SignTest.app

SignTest.app: valid on disk

SignTest.app: satisfies its Designated Requirement

While security assessment policy fails:

λ spctl -a -t exec -vv SignTest.app

SignTest.app: rejected

origin=Apple Development: William Sloat (VFFC883UQ2)

Xcode Organizer UI doesn't provide the option to "Upload/Send to Apple notary service" for Development signing like it does for Developer ID signing, so on a whim, I decided to see if using command line-based notarization would fix the issue and make the malicious software prompt go away, with the theory being that maybe Catalina expects both Development and Developer ID signed apps to be notarized (despite not being explicitly directed as such in the Organizer UI distribution workflow). After performing the following:

λ /usr/bin/ditto -c -k --keepParent "SignTest.app" "SignTest.zip"

λ xcrun altool --notarize-app --primary-bundle-id "com.aurorafoundry.SignTest" --file "SignTest.zip" --username XXXX --password XXXX

No errors uploading 'SignTest.zip'.

I ran xcrun altool --notarization-info and followed the URL provided by the LogFileURL field in the response. It contained two issues:

{

"severity": "error",

"code": null,

"path": "SignTest.zip/SignTest.app/Contents/MacOS/SignTest",

"message": "The binary is not signed with a valid Developer ID certificate.",

"docUrl": null,

"architecture": "x86_64"

},

{

"severity": "error",

"code": null,

"path": "SignTest.zip/SignTest.app/Contents/MacOS/SignTest",

"message": "The signature does not include a secure timestamp.",

"docUrl": null,

"architecture": "x86_64"

}

This response seems to imply that notarization is not expected/supported for a Development signed app. This leaves things in a bit of a conundrum. Notarization isn't supported for Development signed apps, but Catalina is acting like it needs to validate the notarization. Am I missing something or is Development signing no longer really supported on 10.15 and beyond?

Thanks in advance!

Josh

1.3k

Posted by

joshsloat

Reply

Add a Comment

Answer 1

This response seems to imply that notarization is not expected/supported for a Development signed app.

Correct. Notarisation is only for Developer ID products.

Am I missing something or is Development signing no longer really supported on 10.15 and beyond?

This isn’t anything new. If you distribute your app in a way that puts the app in quarantine, it will be checked by Gatekeeper. Gatekeeper requires that the app be signed by either the Mac App Store or Developer ID signing identity. It’s never been satisfied with an Apple Development signing identity (or its predecessors).

How you proceed here really depends on your goals. If your goal is to test the notarisation / Gatekeeper process, you should sign with your Developer ID, notarise it, and then install it via a channel that sets quarantine. If you don’t care about notarisation / Gatekeeper, but just want to test other parts of your app, you should distribute the app in a way that doesn’t set quarantine (I typically use

scp

for this) or, if that’s not appropriate, either manually remove the quarantine or just bypass Gatekeeper.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Posted by

eskimo

Add a Comment

Answer 2

I'm running into the same issue. Previously we used development signing, which was necessary to our QA process because the first time we notarized our app, it crashed on some version of OSX because of the harnded runtime. Now that that is a requirement again, we need to figure out how to fix it, or if there are certain verisons of OSX we can no longer support.

You said "If your goal is to test the notarisation / Gatekeeper process, you should sign with your Developer ID, notarise it, and then install it via a channel that sets quarantine."

What do you mean by a channel that sets quarantine? Since we can't send an OSX app to Testflight how can we distribute our app internally for testing before we submit it to MAS?

Posted by

clockworkcrow

Add a Comment

Answer 3

I'm running into the same issue. Previously we used development signing, which was necessary to our QA process because the first time we notarized our app, it crashed on some version of OSX because of the harnded runtime. Now that that is a requirement again, we need to figure out how to fix it, or if there are certain verisons of OSX we can no longer support.

The hardened runtime was never not a requirement. Apple just give developers an extra grace period so they would have time to fix any hardened runtime issues.

You seem to be mixing up development distribution and developer ID. Development distribution is for apps in the Mac App Store. This allows you to test things like receipt validation, in-app purchase, and all of the other Mac App Store things in the (Mac App Store and macOS) sandbox(es).

Developer ID is for apps that aren't in the Mac App Store. There is no point in trying to do both.

For Development apps, just right click and choose open, remove the quarantine flags, or download via cURL or something else that doesn't set quarantine.

For Developer ID apps, there are two issues - hardened runtime and notarization. You can sign using the hardened runtime and test that without bothering with notarization. Testing notarization is simple. If the app launches and loads shared libraries, you should be good to go.

Posted by

john daniel

Add a Comment

Answer 4

the first time we notarized our app, it crashed on some version of OSX because of the harnded runtime.

I encourage you to figure out the root cause of this, regardless of everything below. While the hardened runtime isn’t required by the Mac App Store, it’s still a good idea in general.

What do you mean by a channel that sets quarantine?

If you download the app via a user-facing mechanism, like Safari or Mail, that quarantines the app. Many lower-level mechanism, like

curl

and

scp

, do not. In addition, quarantine is easy to remove from the command line [1] and can even be modified via an API [2].

how can we distribute our app internally for testing before we submit it to MAS?

There are two standard approaches here:

If the test audience is small, you can add all of the Macs to your team and then use Development signing (A).
If not, use Developer ID (B).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] It’s store in an extended attribute, which you can remove with

xattr

.

[2] Namely the

quarantinePropertiesKey

on `URL.

Posted by

eskimo

Add a Comment

Is Development distribution still a thing?

Replies