Anyone who’s built an iOS app knows Apple makes you jump through more hoops to build and submit an app to the App Store than any other platform. Their additional requirements to generate and gather P12’s and Provisioning Profiles can be cumbersome even to seasoned publishers. But what many don’t consider is the chore of having to maintain this distribution collateral, which only intensifies once your organization begins to manage multiple applications from the same Apple Developer Account.
Over the course of my tenure I have managed upwards of fifty Apple Developer Accounts. Some customers manage to maintain their accounts well, while for others, the words ‘chaotic, vulnerable, and disorganized’ would be an understatement. Hopefully the following lessons will teach you how to properly maintain your organization’s developer-collateral going forward.
1. Determine your Organization’s level of security and access
Organizations take varying approaches here. While not recommended, some companies simply choose to provide employees or vendors their Apple Developer account credentials. Other organizations invite users to their Apple Developer Portal with limited or full permissions, generating developer collateral on their own and having the customer resign the build with distribution collateral. Still others rely on their own developers for generating collateral in response to both internal and external requests. My recommendation is this: never provide your Apple Credentials to vendors or employees. This could lead to collateral being revoked unintentionally, potentially taking a production app down with it. An organization’s best option is always to generate its own collateral (assuming it possesses the necessary skills).
Secondly what’s important here is consistency throughout the organization. I’ve been in meetings where a security team takes a firm stance against providing their distribution p12’s (or distribution provisioning profiles) only to be “back-doored” by a developer who hands over the company’s Apple Credentials along with the keys to the castle.
2. Never tie your Organization’s Apple Developer Credentials to an individual
Rather than create a separate Enterprise Apple Developer Account, it’s common practice for developers to simply leverage their own personal developer accounts when building apps for their employer-company. This practice is not in the company’s best interest. Here’s why: if the developer leaves the company without first providing his credentials, the company will henceforth be unable to maintain (or renew) the collateral. Worse yet, it will be impossible to republish the application once the Apple collateral expires. Further, a disgruntled employee could reject your collateral via the Developer Portal.
Instead, tie your company’s Apple Developer account to an email distribution group within your organization. This way, should an employee leave the company you’re not forced to track him down or leverage his personal account indefinitely.
3. Establish a redundant creation process and follow it each time
If you find yourself managing multiple applications within the Developer Portal, it’s especially helpful to follow a process for creating and hosting your collateral that is familiar to your group. As detailed above, first establish how collateral is to be created. Set an internal set of expectations (in terms of turnaround) around creating and providing collateral. Most importantly, develop a two-tiered system, and designate two Macs to import collateral onto (housed in Keychain and XCode). Collateral should never be housed in just one place. Far too often companies go searching for their Private P12 but can’t recall which Mac it was initially created on. A good way to counteract this is to post all collateral on a share directory in an organized fashion, as you will likely have to refer back to it later (i.e. in a year).
4.Name your BundleID and Provisioning Profiles based on your app
While this may seem obvious, far too often do I see cryptic naming conventions within an organization’s Developer Portal. Make it easy on yourself and fellow developers, especially since you will likely login only once or twice a year. Best-practice is to name a Provisioning Profile based on the app name, year, and organization, especially if you’re a vendor (e.g. “Propelics Event App 2015”). Similarly, name your Bundle ID’s to match these Provisioning Profiles. Again naming convention best-practice would be: organization name followed by app name (e.g. “com.propelics.eventapp”). While you have the ability to utilize a wildcard Bundle ID it is best to leverage it for development and testing purposes only. I have seen companies deploy multiple in-house apps using a wildcard and it inevitably creates confusion when renewing collateral, in terms of trying to determine which names for which apps had been used in place of the wildcard.
5. Document and plan for Apple collateral expirations
Most importantly, keep track of when your Distribution P12 and Provisioning Profiles are scheduled to expire. This is especially important if you have an Enterprise Account and are deploying apps in-house. Avoid the last minute scramble to renew your collateral and redeploy with your app down until it is recompiled and redeployed.
If you also happen to be a vendor, it’s also not a bad idea to keep track of the expiration dates of your client’s collateral. Create an email task a year in advance to remind you or your group to renew the collateral. This one simple step alone will save you a lot of hassle and embarrassment down the line.
Senior Project Manager & Scrum Master at Propelics