What is the correct workflow for scaling a development team? Automatically Manage Signing?

Question

Created May ’22

Replies 3

Boosts 0

Views 1.1k

Participants 2

Hi all, first post. :)

We're trying to unravel technical debt with our approach to building our iOS app. Back in the day everything was done very quickly and roughly because of pressure on the team.

For example, people were sharing developer credentials and we didn't use Automatically Manage Signing, so the provisioning profiles were shared as well. You can imagine that this was difficult to maintain.

Now we are trying to be smarter. Every dev who works on the app uses their own account. The first dev to try this had a developer provisioning profile created for him by an admin in our Apple Developer account (as per https://help.apple.com/developer-account/#/devf2eb157f8), and all works fine.

But we now see that only admins can create developer provisioning profiles, and that doesn't seem scalable; it seems like a better idea to use the Automatically Manage Signing feature of XCode.

The problem with that is that the bundle identifier was created way back as expected for a mature app in the App Store, and Automatically Manage Signing fails because it expects to create the bundle identifier.

I see lots of Stack Overflow "answers" with "change the bundle identifier and it will work", but this feels hacky and brittle.

What's the best practice for a small and growing team like ours? Should an admin really create the development provisioning profiles for every developer? Should developers use Automatically Manage Signing and munge the bundle identifier every time? Something else?

Your insights will be appreciated, thanks in advance.

Boost

Answer 1

DTS Engineer OP

Apple

May ’22

I am, in general, a huge fan of automatic code signing. It handles the vast majority of cases well.

But we now see that only admins can create developer provisioning profiles

That’s not quite true. I recommend that you bookmark Apple > Developer > Support > Apple Developer Program Roles. Looking at the table, there’s a Create development provisioning profiles row that shows that the Account Holder, Admin, App Manager, and Developer roles can all created profiles, the last two having some limitations.

The problem with that is that the bundle identifier was created way back as … and Automatically Manage Signing fails because it expects to create the bundle identifier.

That’s not true. I just ran this sequence:

In Certificates, Identifiers & Profiles I created a new App ID, where com.example.apple-samplecode.Test706332B is the bundle ID part and the App ID prefix defaults to my Team ID.
I enabled the Personal VPN capability on this App ID, to prove a point later in this process.
In Xcode I created a new project called Test706332B. My Organization Identifier field defaults to to com.example.apple-samplecode, so the final bundle ID matches my App ID.
The project defaults to automatic code signing, which works just fine.
In Signing & Capabilities I added the Network Extensions capability. Xcode did its automatic repair and, again, everything just works.
I clicked the info button next to Xcode Managed Profile. It shows both the Personal VPN and Network Extensions capabilities. The former is present because Xcode has used the App ID that I created in step 1 and configured in step 2.

The only potential wonkiness here is if your app uses a unique App ID prefix (rather than your Team ID). I’m not sure what automatic code signing will do in that case and it’s hard for me to test. However, if you are using a unique App ID prefix, it’s a good idea to migrate to using your Team ID anyway (although that presents some challenges).

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

0

Answer 2

antgelgrad OP

May ’22

Thanks for that very useful answer! I didn't know that the Team ID prefix was a thing - as I said we're just getting our house in order. Our bundle identifier is simply com.ourcompany.ourapp and asking users to migrate and losing history isn't an option. Nonetheless, fixing the developer permissions should get us a long way towards where we want to be.

Edit: If it's not true that Automatically Manage Signing fails because it tries to create the bundle ID every time, how can we debug why it fails?

0

Answer 3

DTS Engineer OP

Apple

May ’22

Our bundle identifier is simply com.ourcompany.ourapp asking users to migrate and losing history isn't an option.

This is not about changing your bundle ID, it’s about your App ID prefix. An App ID has two components, the App ID prefix and the bundle ID. For example, my test project has an App ID of SKMME9E2Y8.com.example.apple-samplecode.Test706332, where SKMME9E2Y8 is the App ID prefix and com.example.apple-samplecode.Test706332 is the bundle ID. For modern apps the App ID prefix matches the TeamID. For old apps the App ID prefix may be a unique code. Given that you have an old app, you need to check which style of App ID prefix it uses because, going forward, you’ll be better off using a Team ID.

Also note that changing the App ID prefix does not necessarily result in losing keychain items: There are two sections in that post (Migrate From a Unique App ID Prefix to Your Team ID and Transfer Your App to Another Team) and you’re dealing with the first, nicer case.

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

0