How to manage provisioning for development team

I've been developing a macOS app as part of a small team of developers for a year now. The app is not going to be distributed through the App Store. Our Xcode configuration has Debug, Release, and Dist configurations, and we manually manage signing. Debug and Release are set to "sign to run locally". Dist uses our Developer ID Application cert. None of the configurations have a provisioning profile and all use our team's developer account Team identifier.

This setup has worked fine -- developers can clone the project and build it without changing project settings or downloading profiles / certificates, and I am able to build, sign, and notarize the app for distribution.

We would now like to support universal links to our app, which requires the Associated Domains entitlement. This creates a problem because Xcode requires a provisioning profile that includes the Associated Domains feature.

I can create a provisioning profile with our Developer ID Application cert and use it for the Dist configuration. This works fine. However, for Debug and Release, it seems I cannot create a provisioning profile that will work with the "sign to run locally" setting. I can create an Apple Development certificate and use it, but that certificate has my name and ID on it, not my organization's team name and ID. That means for another developer on my team, they would need to clone the project, then adjust the project settings to select their provisioning profile with their signing certificate. This creates an obvious problem for our repository management.

I can imagine a few ways I might fix this, but don't see how to make any of them work. Can I make an Apple Development certificate for my team that we can all use? Or can I make a provisioning profile that will allow signing to run locally? Or is there some other solution?

Up vote post of diverdi Down vote post of diverdi
2.3k views
Posted by
diverdi
Reply
Add a Comment

Replies

I strongly recommend against Sign to Run Locally for day-to-day development. This creates an ad hoc signature, meaning your product doesn’t have a stable signing identity, and that causes all sorts of weird problems. For example, if you create a keychain item with build N of your app and then access it with build N+1, you’ll get an authorisation dialog because the system doesn’t know that both builds are the same app.

What I recommend instead is that:

  • Have each member of your team create an Apple ID.

  • Invite that Apple ID to your team.

  • Have them create an Apple Development signing identity.

  • Configure your project with your team and Apple Development signing. This will automatically pick up that team member’s Apple Development signing identity.

  • Using the Product > Archive > Organizer export workflow for building your final app (or its equivalent xcodebuild commands if you’re automating that).

  • Restrict access to your Developer ID signing identity because those are precious.

This setup will also help with your provisioning profile issue.

There is, however, one thing to watch out for, namely that your Apple Development signed builds and your Developer ID signed builds will be considered different apps by the keychain and various other subsystems. When testing, it’s best to use one or the other, not mix’n’match. In my case, I generally restrict my development Mac to Apple Development signed builds and use a VM to test my Developer ID signed builds.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment