Enterprise App Store

4 Ways to Prevent iOS Provisioning Profile Expiration

iOS provisioning profiles for in-house apps are only valid for 12 months. Their respective distribution certificates are valid for 36 months. The clock starts ticking the moment you generate either of them in the Apple Developer Center. Once the expiration date is reached, your app stops working. This is bad, as in-house app use cases are maturing from convenience (remember the Genentech Get-A-Room video?) to business critical.
Hence if the provisioning profile or, worse the distribution certificates expire, important business processes might get disrupted.

Often overlooked: the 12-month lifespan applies also to certificates required to send push notifications via the Apple Push Notification service (APNs). If you let an APNs certificate expire, the backend of the respective app won’t be able to send push notifications anymore.

 

1. Apple App Store

If your app (including all static content in the app’s bundle) can be exposed to the public, going through the App Store might be actually a good choice. Of course, there is always the review process to deal with. This process creates a number of challenges, ranging from introducing the risk of an important bug fix update being rejected, important features being impossible to implement due to the review guidelines, to additional delay into the release process, making continuous delivery difficult to achieve.

If your app is being built by a third party, you could also explore a path less traveled: Custom B2B. Custom B2B uses the Apple App Store but does not expose your app to the public. With the Custom B2B option (actually a checkbox in iTunes Connect), third-party developers can submit an app to the Apple App Store and limit visibility of the app to a list of designated Volume Purchase Program (VPP) Apple IDs.

If you have one of those Apple IDs, you can ‘purchase’ the app (the price can be set to zero), while everyone else will neither see the app on the Apple App Store nor in the VPP portal. You can then manage the distribution of your app just like you would manage the distribution of a public app purchased through VPP.

While Custom B2B lets you avoid all the problems related to the limited lifespan of provisioning profiles, it introduces a lot of complexities on its own and does not bypass the Apple review process. Hence few organizations seem to have adopted it.

 

2. Managing with Spreadsheets

A spreadsheet is not the worst start and should contain at least the following: App name, contact information of the app owner, App ID, provisioning profile expiration date, distribution certificate expiration date, and the APNs certificate expiration date if applicable. If you manage to start maintaining such a spreadsheet before the first incident caused by an expired provisioning profile, you get extra points for having a head start compared to a lot of other companies.

 

3. Automated Email Notifications

The drawback of the spreadsheet solution is that you have to develop and maintain a monitoring routine and manually send advance warnings to app owners affected by soon-to-expire provisioning profiles, distribution certificates or APNs certificates.

I’d instead recommend replacing the manual routine with an automated solution. If you’d rather buy than build, our own mobile app release automation software incapptic Connect can automatically notify relevant stakeholders, such as Apple Developer Enterprise Program team admins, app owners, and app developers, based on policies you define.

 

How do you get started?

It’s a good idea to assess where you currently stand. Create a report of all in-house apps in the field, and check provisioning profile, distribution certificate and APNs certificate expiration dates. You should also take a look at the renewal date of the Apple Developer Enterprise Program while you’re at it. Armed with this information, you can assess if anything is about to go wrong in the next 3 months, and contact the relevant stakeholders. Then decide which route you would like to take to prevent expiration incidents for the next 12 months. Let me know how it goes!


Installation von Enterprise Apps unter iOS 9

Das Over-the-Air (OTA) Installationsverfahren für Enterprise Apps wurde in iOS 9 von Apple verändert. Anwender der neuen Version des Apple-Betriebssystems müssen nach der Installation einer solchen App erstmal tief in die iOS-Einstellungen eintauchen. Erst dann lassen sich mit einem Enterprise-Zertifikat signierte Apps benutzen. Bisher reichte die beiläufige Bestätigung von zwei Dialogen aus, um eine Unternehmens-App zu installieren und gleich danach zu starten.

Installationsverfahren bisher (Siehe auch Apple’s support):

Ein erster Dialog erscheint gleich am Anfang der Installationsprozedur. Sie bestätigen darin, dass Sie wirklich eine App installieren wollten. Sofern Sie in diesem Dialog „Installieren“ auswählen, wird die App geladen und installiert.

Ein zweiter Dialog erscheint, wenn Sie die App das erste Mal starten. Sie werden gefragt, ob Sie den Entwicklern der App vertrauen wollen. Falls Sie „Vertrauen“, wird die App gestartet.
In den letzten Monaten gab es immer wieder Meldungen über iOS-Malware, die sich über diesen Mechanismus verbreitet hat. Vermutlich nicht zuletzt aus diesem Grund hat Apple in iOS 9 das Installationsverfahren modifiziert.

 

Das geänderte Installationsverfahren unter iOS 9:

Auch unter iOS 9 werden Sie in einem ersten Dialog gefragt, ob Sie tatsächlich eine App installierten wollten. Diesen Dialog hat Apple nicht verändert.
Wenn Sie dann allerdings versuchen, die installierte App das erste Mal zu starten, bekommen Sie zu lesen, dass die installierte App von einer Entwickler-Organisation stammt, der Sie bisher noch nicht vertraut haben. Anders als bisher können Sie diesen Dialog nur zur Kenntnis nehmen und schließen.

Um die App wirklich auszuführen, ist ein zusätzlicher Schritt notwendig: Sie müssen explizit in die Einstellungen > Allgemein > Profile navigieren und DORT Ihr Vertrauen gegenüber den Entwicklern Ihrer neuen App bestätigen. Sobald Sie das getan haben, können Sie Ihre neue App starten.

Die gute Nachricht: Sie müssen Ihr Vertrauen nur einmal je Entwickler-Organisation bestätigen. Und können dann ohne weitere Vertrauensbekundungen beliebig viele Apps aus dem gleichen Stall installieren. Die Entwickler-Organisation wird dabei über die Apple Developer Enterprise Program Team ID bzw. das Distribution-Zertifikat identifiziert, mit dem die App signiert wurde.

Die schlechte Nachricht: falls Sie Apps über eine gesicherte Website oder einen Enterprise App Store verteilen, müssen Sie Ihre Benutzer über den neu eingeführten Schritt aufklären, sonst werden Sie wohl viele Benutzer verlieren. Ein entsprechender Hinweis in einer Email an Ihre Mitarbeiter und auf der Installationsseite Ihrer Enterprise App bzw. Ihres Enterprise App Stores für iOS 9 Nutzer könnte in etwa lauten:

 

Deutsch:

Installieren Sie „‹Ihre App›“. Tippen Sie dazu „Installieren“ auf dieser Seite und bestätigen den Installationsdialog.
Wichtig: Tippen Sie dann auf „Einstellungen“ > „Allgemein“ > „Profile“ > „‹Ihr Unternehmen›“ und dann auf „ vertrauen“.
Starten Sie „App Catalog“ vom Home-Screen.

 

Englisch:

Download „‹Your App›“ from this web page by tapping „Install“. Confirm the installation dialog.
Important: tap „Settings“ > „General“ > „Profiles“ > „“. Then tap „Trust ‹Your Company›“
Launch „App Catalog“ from the home screen.

Übrigens: sofern Sie für die Verteilung von Apps ein Mobile Device Management System bzw. das MDM-Protokoll verwenden, entfallen unter iOS 9 ALLE oben genannten Schritte. Ist ein iOS 9 Gerät in einem MDM-System registriert, hält das Betriebssystem alle von dort zugeführten Apps automatisch für vertrauenswürdig. Zusätzlich können Sie aus solchen Geräten mit Hilfe einer neuen MDM-Restriction die Installation von Apps aus allen anderen Quellen unterbinden.