macOS application renaming

App & System Services General
ilis544 OP
Created
Replies 2
Boosts 0
Views 50
Participants 3

Hello,

We are developing a macOS application with many different components that are required for our business features. We distribute the product outside the App Store and sign it with our Developer ID certificate.

Rebranding an app is a rare case, but sometimes it happens. My question is:

Does Apple have any guide or recommendations on how to rebrand an app properly, other than distributing a completely new product?

I am asking because our application has a complex structure:

  1. UI app (MyApp1, bundle ID = com.myApp1.osx.app)
  2. Helper tool (MyApp1HelperTool, bundle ID = com.myApp1.osx.HelperTool)
  3. Privileged daemon (MyApp1Daemon, bundle ID = com.myApp1d)
  4. System Extension, Transparent Proxy (MyApp1Proxy, bundle ID = com.myApp1.osx.proxy)

As you can see, the brand name is used not only in the bundle and product names, but also in the bundle IDs. At some point, I need to change the product name from MyApp1 to MyApp2. Ideally, I would also like to change the bundle IDs to match the new brand. After rebranding, end users should not see MyApp1 anywhere in the system, only MyApp2. Also, components that are already installed and approved (System Extension, proxy configuration, helper tool, etc.) should stay approved. We would like to avoid showing the approval prompts again to all our end users.

I did some research and found that bundle IDs technically cannot be changed. To solve this, I would need to release a new app and implement an in-app update mechanism that updates MyApp1 to MyApp2.

However, even with a new app and an in-app update mechanism, I did not find a way to avoid user prompts for approving the new extension, the proxy, and possibly the privileged helper tool. For macOS, these will be new components that require explicit user approval.

MDM is not a solution for us: some of our customers use MDM, but many of them do not. We want the update to be as smooth as possible.

Thank you!

Answered by DTS Engineer in 910841022
Written by Etresoft in 910786022

It all depends on how deep you want that rebranding to go.

Right. I see two aspects to this:

  • App names versus bundle ID.
  • Changing your code signing team.

As you noted:

  • You can change your app name as you see fit.
  • But you can’t change a bundle ID because a new bundle ID makes for a new app.

Generally this doesn’t matter because users don’t see your bundle ID in day-to-day use. It’s not secret, a user can uncover it quite easily, but it’s not immediately obvious either.

So, as Etresoft said, it depends on how much you care about a user accidentally stumbling across the old name. That could be a serious problem — imagine a scenario where you’re legally not allowed to use the old name — or could just be a minor annoyance.

If the rebranding involves changing teams, that’s trickier. For a Mac App Store app you can do an app transfer, but you’re direct distributing with Developer ID signing. In that case there really is no good way to change teams, because lots of the system has associated your bundle ID with your team (the keychain, app and app group containers, and so on). The only reasonable option in that case is to change bundle ID and make a whole new app.

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

Replies  2
Boosts 0
Views  50
Participants  3
Etresoft OP

It all depends on how deep you want that rebranding to go.

As you describe, changing the bundle ID(s) is a fresh start. That's a whole new app.

If you change the physical bundle name, that might still have some impacts. Customers may have scripts. MDMs may use that name, etc.

If you only really care about a superficial branding, you can simply add a localized name. Users will only see the old name if they're using the Terminal or something else relatively low-level.

DTS Engineer OP
Apple
Recommended
Written by Etresoft in 910786022

It all depends on how deep you want that rebranding to go.

Right. I see two aspects to this:

  • App names versus bundle ID.
  • Changing your code signing team.

As you noted:

  • You can change your app name as you see fit.
  • But you can’t change a bundle ID because a new bundle ID makes for a new app.

Generally this doesn’t matter because users don’t see your bundle ID in day-to-day use. It’s not secret, a user can uncover it quite easily, but it’s not immediately obvious either.

So, as Etresoft said, it depends on how much you care about a user accidentally stumbling across the old name. That could be a serious problem — imagine a scenario where you’re legally not allowed to use the old name — or could just be a minor annoyance.

If the rebranding involves changing teams, that’s trickier. For a Mac App Store app you can do an app transfer, but you’re direct distributing with Developer ID signing. In that case there really is no good way to change teams, because lots of the system has associated your bundle ID with your team (the keychain, app and app group containers, and so on). The only reasonable option in that case is to change bundle ID and make a whole new app.

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