Migration of BundleIDs and certificates

Question

Created Oct ’24

Replies 4

Boosts 0

Participants 2

Good day. As part of a business unit separation, we are required to have our product with a different name, bundle IDs and certificates than our current configuration.

The product contains network extensions and requires Full Disk Access. We distribute this product to our customers who either support MDM or not.

I know from previous experience that a product can be transferred to a different account, which is something we could do only for some parts of our product (only a couple of Bundle IDs).

My question is what's the best way to do this. I can imagine that having a scripted scenario where the other business unit's product is removed from customers and ours is installed, in a different folder.

The main issue I can foresee is that because our architecture uses several network extensions that are installed as plugins (bad design I know), we would be asking the users for authorisation, again, to use those extensions, plus full disk access.

What options do I have?

Answered by DTS Engineer in 809021022

Thanks for confirming. That brings me back to this:

As part of a business unit separation, we are required to have our product with a different … bundle IDs … than our current configuration.

The bundle ID change is the kicker here. Apple platforms primarily identify apps by their bundle ID [1]. You can’t change an app’s bundle ID; rather, something with a different bundle ID is a completely different app as far as macOS is concerned.

If you’re absolutely forced to change the bundle ID, I don’t see any good path forward here. Your users will have to install the app from scratch because this is a new app.

ps It’s better if you reply as a reply; I’m not notified of replies in the comments. See Quinn’s Top Ten DevForums Tips for this and other titbits.

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

[1] Not the App ID. The App ID contains an App ID prefix and a bundle ID. The App ID prefix can change and the system is expected to understand that the app didn’t change. OTOH, the bundle ID part of the App ID can’t change.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’24

This is going to be tricky.

It sounds like everything here is Mac stuff that’s distributed directly, using Developer ID signing. Is that right?

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

0

Answer 2

DTS Engineer OP

Apple

Oct ’24

Accepted Answer

Recommended

Thanks for confirming. That brings me back to this:

As part of a business unit separation, we are required to have our product with a different … bundle IDs … than our current configuration.

The bundle ID change is the kicker here. Apple platforms primarily identify apps by their bundle ID [1]. You can’t change an app’s bundle ID; rather, something with a different bundle ID is a completely different app as far as macOS is concerned.

If you’re absolutely forced to change the bundle ID, I don’t see any good path forward here. Your users will have to install the app from scratch because this is a new app.

ps It’s better if you reply as a reply; I’m not notified of replies in the comments. See Quinn’s Top Ten DevForums Tips for this and other titbits.

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

[1] Not the App ID. The App ID contains an App ID prefix and a bundle ID. The App ID prefix can change and the system is expected to understand that the app didn’t change. OTOH, the bundle ID part of the App ID can’t change.

1

Answer 3

sbenitez-mwb OP

Oct ’24

What would be the path if we stick to the same bundle ID but sign with a different certificate? Do we need to remove the identifier from one account and create it again in another account?

We have bundle IDs such as com.xxxx.one-flavour for one BU and com.xxxx.other-flavour for the other BU. Could we in theory remove one flavour and recreate it in the other account (or transfer)?

Also, if we did it this way, and the two BUs become separate companies, are there any implications (with respect to Apple's handling of identifiers) in differently named products having the same base domain name as part of the bundle ID?

0

Answer 4

DTS Engineer OP

Apple

Oct ’24

What would be the path if we stick to the same bundle ID but sign with a different certificate?

That could have some benefits, but it’s also potentially more confusing. If you change the bundle ID then everything is new, so the user path is:

Remove the old.
Install the new.

They can even skip the first step and have both installed, and then only use the new.

The issue with changing the signing identity is that it changes the designated requirement (because the DR encodes the Team ID). macOS uses the DR to track the ‘identity’ of your code, so changing it can result in non-obvious problems. Indeed, this came up recently in another thread.

For more background on DRs, see TN3127 Inside Code Signing: Requirements.

Could we in theory remove one flavour and recreate it in the other account (or transfer)?

First up, with Developer ID there’s no app transfer process.

Regarding the remove and add, the key issue here is your use of restricted entitlements, that is, entitlements that must be authorised by a provisioning profile. To get these to work you must have created a profile for your product, and that means you must have registered its App ID. I don’t think you’ll be able to delete that App ID because there are products shipping with it [1].

But, even if it did, you’d still end up with a new Team ID and thus the DR issue outlined above.

Also, if we did it this way, and the two BUs become separate companies, are there any implications (with respect to Apple's handling of identifiers) in differently named products having the same base domain name as part of the bundle ID?

AFAICT that’s not the case. The Developer website doesn’t care what bundle IDs you use [2]. What matters is that they’re unique [3], and that’s something that the App ID registration process does enforce.

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

[1] I’m more familiar with the App Store side of this, where you can’t delete an App ID once App Store Connect is aware of it. I’ve never actually explored this on the Developer ID side.

[2] IIRC it prevents you from using the com.apple. prefix though (-:

[3] Also an app extension’s bundle ID must be an immediate ‘child’ of the container app.

0