Führen Sie Ihre iOS App aus, ohne die App Store Version zu überschreiben

Manchmal, wenn Sie eine neue Version Ihrer iOS-App entwickeln, möchten Sie diese auf Ihrem iPhone oder iPad ausführen und trotzdem die aktuelle Version, die im App Store veröffentlicht wurde, nutzen können. Wenn Sie Ihre App von Xcode aus auf Ihrem Gerät ausführen, überschreibt sie in der Regel eine bereits vorhandene Version. Wenn Sie dann wieder zu der Version aus dem App Store wechseln möchten, müssen Sie die Entwicklungsversion löschen und erneut aus dem App Store herunterladen. In diesem Blogbeitrag beschreibe ich, wie Sie eine Testversion Ihrer App neben Ihrer Produktionsversion ausführen können. Diese Methode funktioniert auch, wenn Sie Erweiterungen (wie das Heute-Widget oder die WatchKit-App) in Ihre App eingebettet haben oder wenn Sie Ihre App mit Apples TestFlight einem Betatest unterziehen möchten.

Es gibt zwei verschiedene Möglichkeiten, dies zu erreichen. Die erste Methode besteht darin, ein neues Ziel in Ihrem Projekt zu erstellen, das dieselbe App ausführt, aber mit einem anderen Namen und einer anderen Kennung. Mit iOS 8 ist es nun möglich, Erweiterungen in Ihre App einzubetten. Da diese Erweiterungen in das App-Ziel eingebettet sind, funktioniert dieser Ansatz nicht, wenn Sie Erweiterungen haben. Daher beschreibe ich nur die zweite Methode, die auf benutzerdefinierten Einstellungen in der Build-Konfiguration basiert. Bevor ich ins Detail gehe, hier eine kurze Erklärung, wie das funktioniert. Xcode erstellt bereits zwei Build-Konfigurationen für uns: Release und Debug. Durch Hinzufügen einiger benutzerdefinierter Einstellungen zu den Build-Konfigurationen können wir die Debug-Konfiguration mit einer anderen Bundle-Kennung als die Release-Konfiguration ausführen. Dadurch wird im Wesentlichen eine separate App auf Ihrem Gerät erstellt, wobei die App aus dem App Store (die mit der Release-Konfiguration erstellt wurde) intakt bleibt. Um die Beta-Verteilung der mit der Debug-Konfiguration erstellten App zu erleichtern, erstellen wir mehrere Schemata.

Die Grundlagen

Befolgen Sie diese Schritte genau, um eine Testversion auf Ihrem Gerät neben Ihrer App Store Version auszuführen. Diese Schritte basieren auf Xcode 6.1.1 mit einem Apple Developer Account mit Admin-Rechten. Klicken Sie im Projektnavigator auf Ihr Projekt und stellen Sie sicher, dass das Hauptziel ausgewählt ist. Unter den beiden Registerkarten Allgemein und Info finden Sie den Bundle-Bezeichner. Wenn Sie diesen Namen ändern und Ihre App ausführen, wird eine neue App neben der alten erstellt. Fügen Sie -test zu Ihrem aktuellen Bundle-Bezeichner hinzu, so dass Sie etwas wie com.example.myapp-test erhalten. Xcode wird Ihnen wahrscheinlich mitteilen, dass Sie kein Bereitstellungsprofil haben. Lassen Sie Xcode dieses Problem für Sie beheben und es wird ein neues Entwicklungsprofil mit dem Namen iOSTeam Provisioning Profile: com.example.myapp-test erstellen. Wir sind also bereits in der Lage, eine Testversion unserer App neben der App Store-Version auszuführen. Es ist jedoch nicht sehr praktisch, die Bundle-Kennung ständig manuell zu ändern. Der Bundle-Bezeichner ist Teil der Info.plist und wird nicht von einer Eigenschaft der Build-Konfiguration abgeleitet, wie zum Beispiel der Bundle-Name (der standardmäßig ${PRODUCT_NAME} aus der Build-Konfiguration verwendet). Daher können wir nicht einfach einen anderen Bundle-Bezeichner für eine andere Build-Konfiguration angeben, indem wir eine bestehende Eigenschaft verwenden. Aber wir können dafür eine benutzerdefinierte Einstellung verwenden. Gehen Sie zur Registerkarte Build-Einstellungen Ihres Projekts und klicken Sie auf die Schaltfläche +, um eine benutzerdefinierte Einstellung hinzuzufügen. Nennen Sie die neue Einstellung BUNDLE_ID und geben Sie ihr den Wert der Test-Bundle-Kennung, die Sie zuvor erstellt haben (com.example.myapp-test). Klicken Sie dann auf das kleine Dreieck vor der Einstellung, um die Einstellung zu erweitern. Entfernen Sie den Teil -test aus der Release-Konfiguration. Am Ende sollten Sie etwas wie dieses Ergebnis erhalten:

Gehen Sie nun auf die Registerkarte Info und ändern Sie den Wert des Bundle-Identifikators in ${BUNDLE_ID}. Auf der Registerkarte Allgemein sehen Sie immer noch den korrekten Bundle-Identifikator, aber wenn Sie darauf klicken, sehen Sie, dass der Text leicht ausgegraut ist, was bedeutet, dass er aus einer Einstellung der Build-Konfiguration stammt.

Um zu testen, ob dies funktioniert, können Sie das aktuelle Schema bearbeiten und die Build-Konfiguration der Aktion Ausführen von Debug auf Release ändern. Schließen Sie das Schema-Fenster und wechseln Sie erneut auf die Registerkarte Allgemein, um zu sehen, dass der Bundle Identifier in die Release BUNDLE_ID geändert wurde. (Wenn Sie die Registerkarte Allgemein noch geöffnet hatten und die Änderung nicht sehen, wechseln Sie zu einer anderen Registerkarte und wieder zurück; das Panel lädt den Bezeichner neu). Stellen Sie sicher, dass Sie die Build-Konfiguration in Ihrem Schema anschließend wieder auf Debug zurücksetzen. Wenn Sie jetzt eine App archivieren, bevor Sie sie für den App Store freigeben, wird die korrekte Kennung aus der Release-Konfiguration verwendet und wenn Sie die App über Xcode auf Ihrem Gerät ausführen, wird die Kennung zum Testen verwendet. Auf diese Weise überschreibt sie nicht mehr Ihre App Store Version auf Ihrem Gerät.

App-Name

Sowohl unsere App Store-App als auch unsere Test-App haben immer noch denselben Namen. Das macht es schwer zu erkennen, welche die richtige ist. Um dieses Problem zu lösen, suchen Sie den Produktnamen in den Build-Einstellungen und ändern Sie den Namen für die Debug-Konfiguration in einen anderen Namen, z. B. MyApp Test. Sie können sogar ein anderes App-Symbol für Ihren Test-Build verwenden. Ändern Sie einfach den Asset Catalog App Icon Set Name für die Debug-Konfiguration.

Beta-Verteilung

Was ist, wenn Sie eine Version der App für Beta-Tests (über TestFlight oder etwas Ähnliches) an andere Personen verteilen möchten, die ebenfalls nicht ihre Version im Apple Store überschreiben sollen? Unsere Archiv-Aktion verwendet die Build-Konfiguration Release. Wir könnten diese manuell in Debug ändern, um die Test-Bundle-Kennung zu erhalten, aber dann würden wir alle Debug-Einstellungen in unsere App übernehmen, was wir nicht wollen. Wir müssen eine andere Build-Konfiguration erstellen. Gehen Sie zu den Projekteinstellungen Ihres Projekts (also nicht zu den Zieleinstellungen). Klicken Sie auf die Schaltfläche + unter Konfigurationen und duplizieren Sie die Release-Konfiguration. Nennen Sie die neue Konfiguration AdHoc. (Möglicherweise haben Sie aus anderen Gründen bereits eine solche Build-Konfiguration. In diesem Fall können Sie diesen Schritt überspringen und diese für die nächsten Schritte verwenden.) Gehen Sie nun zu den Build-Einstellungen Ihres Hauptziels und ändern Sie den AdHoc-Wert der benutzerdefinierten Einstellung BUNDLE_ID auf denselben Wert wie den Debug-Wert. Dasselbe gilt für den Produktnamen, falls Sie diesen im vorherigen Schritt geändert haben. Wir könnten bereits jetzt ein Beta-Test-Archiv erstellen, indem wir die Konfiguration der Archivierungsaktion manuell auf Debug ändern. Es ist jedoch einfacher, wenn wir dafür ein neues Schema erstellen. Gehen Sie also zu Schemata verwalten und klicken Sie unten links auf die Schaltfläche +, um ein neues Schema zu erstellen. Vergewissern Sie sich, dass Ihr Hauptziel als Ziel ausgewählt ist und fügen Sie dem Namen "Test" hinzu, so dass Sie am Ende so etwas wie "MyApp Test" haben. Aktivieren Sie auch das Kontrollkästchen Freigegeben, wenn Sie Ihre Schemata in Ihrem Versionskontrollsystem freigeben.Doppelklicken Sie auf das neue Schema, um es zu bearbeiten und ändern Sie die Build-Konfiguration der Aktion Archivieren in AdHoc. Jetzt können Sie mit dem ausgewählten Schema MyApp Test archivieren, um eine Testversion Ihrer App zu erstellen, die Sie an Ihre Tester verteilen können, ohne dass deren App Store-Version überschrieben wird.Um Verwirrung darüber zu vermeiden, welche Build-Konfiguration von welcher Schema-Aktion verwendet wird, sollten Sie auch die Konfiguration der Aktion Profil in AdHoc ändern. Und in Ihrem normalen Nicht-Test-Schema können Sie die Build-Konfiguration aller Aktionen in Release ändern. Dadurch können Sie die App in beiden Modi Ihres Geräts ausführen, was manchmal notwendig sein kann, z.B. wenn Sie Push-Benachrichtigungen testen müssen, die nur für die normale Bundle-Kennung funktionieren.

Erweiterungen

Wie bereits in der Einleitung erwähnt, ist der Hauptgrund für die Verwendung mehrerer Schemata mit unterschiedlichen Build-Konfigurationen und benutzerdefinierten Einstellungen im Gegensatz zur Erstellung mehrerer Ziele mit unterschiedlichen Bundle-Kennungen der Einsatz von Erweiterungen, wie der Today-Erweiterung oder einer WatchKit-Erweiterung. Eine Erweiterung kann nur Teil eines einzigen Ziels sein.Erweiterungen machen die Sache noch komplizierter, da ihrem Bundle-Bezeichner der Bundle-Bezeichner der übergeordneten App vorangestellt werden muss. Und da wir diesen gerade dynamisch gemacht haben, müssen wir auch den Bundle-Bezeichner unserer Erweiterungen dynamisch machen.Wenn Sie noch keine Erweiterung haben, erstellen Sie jetzt eine neue. Ich habe die unten beschriebene Vorgehensweise mit Today-Erweiterungen und WatchKit-Erweiterungen getestet, aber sie sollte auch mit jeder anderen Erweiterung funktionieren. Die Schritte, um einen dynamischen Bundle-Bezeichner für die Erweiterungen zu erhalten, sind sehr ähnlich wie die für das Hauptziel, daher werde ich hier nicht zu sehr ins Detail gehen. Öffnen Sie zunächst die Registerkarte Info des neuen Ziels, das für die Erweiterung erstellt wurde, z.B. MyAppToday. Hier sehen Sie, dass der Anzeigename des Bundles nicht vom PRODUCT_NAME abgeleitet ist. Das liegt wahrscheinlich daran, dass der Produktname (der vom Zielnamen abgeleitet wird) nicht so benutzerfreundlich ist wie MyAppToday und man davon ausgeht, dass Sie ihn ändern werden. Im Falle der Heute-Erweiterung werden beim Ausführen einer Testversion der App neben der App Store-Version auch 2 Heute-Erweiterungen in der Heute-Ansicht des Telefons erstellt. Um zwischen den beiden unterscheiden zu können, machen wir auch den Bundle-Anzeigenamen dynamisch. Ändern Sie den Wert in ${BUNDLE_DISPLAY_NAME} und fügen Sie dann eine benutzerdefinierte Einstellung für BUNDLE_DISPLAY_NAME mit unterschiedlichen Namen für Debug/AdHoc und Release hinzu. Sie haben vielleicht bemerkt, dass der Bundle-Bezeichner der Erweiterung bereits dynamisch ist, etwa com.example.myapp.$(PRODUCT_NAME:rfc1034identifier). Ändern Sie dies in ${PARENT_BUNDLE_ID}.$(PRODUCT_NAME:rfc1034identifier) und fügen Sie eine benutzerdefinierte Einstellung für PARENT_BUNDLE_ID zu Ihren Build-Einstellungen hinzu. Die Werte der PARENT_BUNDLE_ID sollten genau den Werten entsprechen, die Sie in Ihrem Hauptziel verwendet haben, z.B. com.example.myapp für Release und com.example.myapp-test für Debug und AdHoc. Das war's. Jetzt können Sie Ihre App mit Erweiterungen ausführen und archivieren, deren Bundle-Identifikator der Bundle-Identifikator des Elternteils vorangestellt ist.

App Gruppen Berechtigungen

Vielleicht haben Sie eine Erweiterung, die UserDefaults-Daten oder Kerndatenspeicher mit der Hauptanwendung teilt. In diesem Fall müssen Sie sowohl in Ihrer Hauptanwendung als auch in den Erweiterungen übereinstimmende App-Gruppen-Berechtigungen haben. Da wir dynamische Bundle-Kennungen haben, die unterschiedliche Bereitstellungsprofile verwenden, müssen wir auch unsere App-Gruppen dynamisch machen.Wenn Sie noch keine App-Gruppen-Berechtigungen (oder andere Berechtigungen) haben, gehen Sie zur Registerkarte Fähigkeiten Ihres Hauptziels und aktivieren Sie App-Gruppen. Fügen Sie eine App-Gruppe in der Form off group.[Bundle-Bezeichner] hinzu, z.B. group.com.example.myapp. Dies erzeugt eine Entitlements-Datei für Ihr Projekt (MyApp.entitlements) und setzt die Code Signing Entitlements Ihrer Build-Einstellungen auf etwas wie MyApp/MyApp.entitlements. Suchen Sie die Entitlements-Datei im Finder und duplizieren Sie sie. Ändern Sie den Namen der Kopie, indem Sie " Kopie" durch "Test" ersetzen (MyAppTest.entitlements). Ziehen Sie die Kopie in Ihr Projekt. Sie sollten nun zwei Entitlement-Dateien in Ihrem Projekt haben. Öffnen Sie die Datei Test entitlements im Eigenschaftslisten-Editor von Xcode und fügen Sie unter com.apple.security.application-groups zum Wert von Element 0 "-test" hinzu, um ihn mit dem Bundle-Bezeichner abzugleichen, den wir zum Testen verwendet haben, z.B. com.example.myapp-test. Gehen Sie nun zurück zu den Build-Einstellungen und ändern Sie die Debug- und AdHoc-Werte der Code Signing Entitlements so, dass sie mit dem Dateinamen der Test-Entitlements übereinstimmen.Wiederholen Sie alle diese Schritte für das Ziel Extension. Xcode generiert auch die Entitlements-Datei im Erweiterungsordner. Am Ende sollten Sie zwei Berechtigungsdateien für Ihr Hauptziel und zwei Berechtigungsdateien für jede Erweiterung haben. Die Anwendungsgruppen für das Testen müssen zu den Bereitstellungsprofilen hinzugefügt werden, was Xcode automatisch für Sie erledigt. Möglicherweise werden Sie während des Erstellens gewarnt oder gefragt, ob Sie dies tun möchten.

Fazit

Es mag etwas Arbeit sein, all diese Schritte zu befolgen und alles zum Laufen zu bringen, aber wenn Sie Ihr normales iPhone für die Entwicklung nutzen und gleichzeitig eine stabile Version Ihrer App verwenden oder zeigen möchten, ist es das auf jeden Fall wert. Und Ihre Beta-Tester werden es Ihnen auch danken.