As soon as you start deploying your carefully crafted app to a real device you inevitably clash with one of Apples most infamous mechanisms: the Provisioning-Procedure that is also known as How the hell is this working? I better not touch it.
Following a yearly tradition, Apple announced changes to the AppStore Policies and the binary distribution and provisioning system at WWDC 2017. This alone is reason enough to take a clarifying tour into this micro-cosmos and look for the answer to a somewhat easy question: what is a bundle identifier, what is an app identifier, and how are those connected to each other?
The bundle identifier
A bundle identifier precisely identifies a single app. […] For example, Game Center and In-App Purchase use a bundle ID to identify your app when using these app services.
Due to the nature of precisely identifying a single app, it is not possible to install two apps that utilize the same bundle identifier on a single device. Also, bundle identifiers are unique inside the Apple eco-system, one of the reasons why they are a popular part of third-party-app-plugin-licensing.
Bundle identifiers have to be a uniform type identifier that should be in reverse-DNS format, e.g.
Things to know about bundle identifiers:
- BundleIDs cannot include wildcards
- BundleIDs are case-sensitive
- BundleIDs cannot be changed after the app is uploaded to the app-store
The app identifier
An app id is a two-part string used to identify one ore more apps from a single development team.
App IDs consist of two strings: the Team ID (your developer account) and a bundle-identifier search-string. Notice the term bundle identifier search string – the second part does not necessarily have to a bundle-identifier.
In fact, providing an explicit bundle identifier in the second part of the App ID would turn it into a so called explicit App ID, an ID that is only valid for this exact app.
Things to know about app identifiers:
- Their second string is a search string, meaning wildcard asteriks are possible. Developers should utilize this fact and create App IDs like
- It’s best practice to name your App IDs the same as their corresponding search strings, to make things easier. However, replace any dots by spaces.
- The wildcard asterisk has to be replaced by at least one character, so if your wildcard is
com.mycompany.*your bundle-identifier cannot be
- App IDs are part of the provisioning profiles and process, and carry your accounts ID. Keep that in mind before sharing any information regarding them.
How to ease the pain
We’ve all been there. The developer portal is flooded with certificates, and the swamp of explicit AppIDs is only topped by the sea of wildcard AppIDs.
Here are some tips i found useful:
- Create a separate App ID for in-house testing using a wildcard asterisk
By using a separate App ID for your development process, you gain several advantages like being able to quickly create spin-offs of your app that can be installed side-by-side on your development devices, being able to freely choose development-suffixes for your development builds and minimize the risk of accidentally deploying a binary that is eligible to replace your already published app.
- Reference your bundle identifier inside your code
If possible, try creating a global getter for your bundle’s identifier, this way your notification / network / file-storage code seamlessly adapts to different versions of the same apps. This is insanely useful when using e.g. BackgroundSessions or local notifications.
Anything to add to this list? Please feel free to shoot me a mail and provide some feedback and / or more tips and tricks regarding bundle identifiers!