Die Entwicklung der Anwendung hat in einem Team stattgefunden, dessen Erfahrungsschatz hauptsächlich auf der .NET-Entwicklung beruht. Dank Xamarin musste dabei Visual Studio als Entwicklungsumgebung nicht verlassen werden, obwohl für die Plattformen iOS und Android entwickelt wurde. Allenfalls das einmalige Setup der Debug-Umgebung für die iOS-Anwendung, erforderte eine kurzzeitige Arbeit des Entwicklers mit einem Mac. Nachdem die Entwicklungsphase abgeschlossen war, musste die Anwendung getestet werden und sollte anschließend in die Stores deployed werden. Xamarin selbst bietet hierzu bereits je einen Guide für die beiden Stores an, wobei jeweils das Store Deployment Schritt für Schritt für iOS und auch für Android beschrieben wird. Doch war das schon alles? Musste lediglich eine „Checkliste“ abgearbeitet werden, und man hat die Anwendungen im Store? Leider fingen die Probleme mit dem Abarbeiten dieses Guides erst an.

Fallstricke beim Deployment der iOS-Anwendung

Während der Entwicklung der Anwendung wurde deren Build zum Debuggen allein von Visual Studio aus gesteuert. Jedoch besteht von Visual Studio aus nicht die Möglichkeit, ein Paket für den Store zu erstellen. Folglich muss dieses im Xamarin Studio auf dem Mac erstellt werden. Auffällig war dabei insbesondere, dass die Auswahl bei den Build-Einstellungen zwischen Visual Studio und Xamarin Studio leicht abweichend ist. In Xamarin Studio stehen beispielsweise exakt die installierten SDKs und verfügbaren Compiler-Optionen (z. B. auch ARM64 und ARM7s) zur Auswahl, während in Visual Studio nur eine pauschale Auswahl (z. B. bei den Compiler-Optionen nur ARMv6 und ARMv7) zum Debuggen, oder gar keine Auswahl – abgesehen von dem Wert „Standard“ – zur Verfügung steht. Auch weicht die Anordnung und Verteilung der Optionen voneinander ab, sodass diese in Xamarin Studio erneut zu suchen und zu prüfen sind. Dies lässt sich auch im nachfolgenden Screenshot nachvollziehen:

Nach erfolgreicher Erstellung des Pakets in der Release-Konfiguration ist zusätzlich die Verwendung von Xcode erforderlich, um das Publishing in den Apple App Store durchzuführen.

Eine weitere Besonderheit der iOS App stellt die Information Property List (Datei “Info.plist”) dar. Die Info.plist ist eine Zusammenfassung von Eigenschaften der Anwendung, die in deren Paket beim Übersetzen integriert und auch zum Übersetzen verwendet sowie vom Store ausgelesen und ausgegeben werden. Die meisten dieser Eigenschaften lassen sich in der UI für die Projekteigenschaften über den Reiter iOS Application bearbeiten. Manche dieser Eigenschaften müssen jedoch von Hand in die Info.plist eingefügt werden; so etwa die Sprache, die im App Store angezeigt werden soll.

   1: <key>CFBundleLocalizations</key>

   2: <array>

   3:     <string>de</string>

   4: </array>

   5:  

   6: <key>CFBundleDevelopmentRegions</key>

   7: <string>German</string>

Fallstricke beim Deployment der Android-Anwendung

Das Deployment der Android-Anwendung in den Google Play Store hingegen hat sich zunächst einfach gestaltet. Später hat sich noch herausgestellt, dass der vom Xamarin Visual Studio Plugin verwendete Algorithmus zur Paketsignierung nicht von jedem Android-Gerät unterstützt wird. Einige Geräte gaben bei der Installation lediglich die Fehlermeldung „Package file was not signed correctly.“ zurück. Um dies zu beheben, musste das Paket unter Nutzung eines anderen Algorithmus signiert werden: In einem herkömmlichen Android-Projekt wird dazu die build.xml angepasst. In Xamarin ist dies jedoch nicht möglich. Hier muss das Paket als Release erstellt sowie von Hand mit den entsprechenden Tools aus dem jeweiligen JDK und Android SDK signiert werden. Dazu finden sich nachfolgend die erforderlichen Kommandos an unserem Beispiel mit aktuellen Tool-Versionen:

"Y:PathToourJavajdk1.8.0_31injarsigner.exe" -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore %KeyStoreFileName%.keystore %AppPackageFileName%.apk %KeyAlias%

"Y:PathToourandroid-sdkuild-tools21.1.2zipalign.exe" -v 4 %AppPackageFileName%.apk %AppPackageFileName%.signed.apk

Abgesehen davon ist beim Android Deployment die Möglichkeit zu erwähnen, im Google Play Store spezifische Geräte zu deaktivieren, die von der Anwendung nicht unterstützt werden. Dies ist insbesondere deshalb relevant, weil es derzeit allein über 2102 Android Tablets gibt, die unterstützt werden müssen. Soll jedoch ein Formfaktor wie insbesondere z. B. von kleinen Geräten (Phablets) nicht unterstützt werden, können diese Geräte hier explizit deaktiviert werden. Möchte man diese dennoch unterstützen, bietet sich die Xamarin Test Cloud an, diese zuvor zu testen.

Fazit

Insgesamt hat sich das Store Deployment mit Xamarin problemlos hinsichtlich des Aufwands gestaltet. Selbst die Dauer des Freigabeprozesses hat sich mit ein paar Stunden bei Android und ca. zwei Wochen bei Apple relativ kurz gestaltet. Folglich ist die Anwendung nun sowohl im Apple App Store als auch im Google Play Store zu finden.