Cordova-Integration in Visual Studio (Part 4) – iOS Build lokal

Wer Crossplatform Development betreibt, möchte auch in der Lage sein, für die gängigsten mobilen Ökosysteme liefern zu können. Die drei großen Namen sind hier wohl Android, iOS und Windows Phone. Aber auch wenn es nun für Visual Studio Entwickler möglich ist, auf ihrem Entwicklungssystem zentral für diese Plattformen zu entwickeln, so sieht die Welt schon wieder anders aus, wenn die Apps für Tests oder Auslieferung deployed werden sollen. Das fehlende iOS SDK von Apple für Windows Systeme verhindert, iPhone oder iPad Apps direkt auf dem Entwicklungssystem erstellen zu können. Doch es gibt Ausweichmöglichkeiten, die hier erläutert werden.

Lange hält der Ripple Emulator her, doch irgendwann ist es soweit – Die App muss auf dem echten Gerät, oder eben dem nativen Simulator des Ökosystems getestet werden. Im Falle von iOS ist dies auf einem Windows-System bisher nicht möglich, da Apple ein SDK für Microsoft-Systeme wacker vermeidet. Allerdings gibt es hier zwei Wege, um an nativen App-Code für iOS zu kommen:

a) Lokal über ein zusätzliches Mac-System
Mit einem zusätzlichen lokalen Mac-System ist es möglich, mittels der Apple-eigenen Entwicklungsumgebung „XCode“ den App-Code nativ zu kompilieren. Das Deployment auf die Geräte erfolgt über iTunes.

b) Einen Cloud-Build-Service nutzen
Crossplatform-Tools wie das XDK von Intel haben den Zugang zu einem Cloud-Build-Service bereits integriert. Wer keinen direkten Zugang zu so einem Service in seinem Tooling hat, kann hier einen eigenen PhoneGap Dienst nutzen, der über ein Browserinterface gesteuert wird.

Doch wie ist das praktikabel für den Visual Studio Entwickler, der mit Cordova arbeitet? Betrachten wir also die beiden unterschiedlichen Wege und schauen uns die einzelnen Schritte an.

 

Lokales Deployment über zusätzliches Mac-System

Die gute Nachricht vorne weg: Visual Studio unterstützt diesen Prozess sehr gut. So ist es für den Entwickler möglich, den Build-Prozess aus Visual Studio heraus wie gewohnt mit z.B. F5 anzustoßen. Den Austausch zwischen Sourcen des Windows-Rechners und dem nativen App Code als erfolgreiches Build-Ergebnis des Mac-Systems erfolgt über eine Netzwerkverbindung automatisch. Das ursprüngliche Entwicklungssystem ist dann in der Lage, den nativen App Code über iTunes auf die Testgeräte zu deployen. Soll ein Simulator des Apple SDKs mit der App bespielt werden, so kann der Simulator nur auf dem Mac-System gestartet und bereitgestellt werden. Hier erfolgt keine Rückgabe an das Windows-System.

Doch was wird für diesen Prozess benötigt?

– Generell wird ein Mac-System. Ob man sich hier für ein Macbook, MacPro oder MacMini entscheidet, sollte vom restlichen Einsatzszenario abhängen, in dem das System agieren soll/kann. Wer nur einen „Build-Server“ für seine Crossplattform Entwicklungen sucht, wird mit einem MacMini auskommen. Aber Achtung: Sollen die Simulatoren genutzt werden, muss Monitor, Maus, Tastatur vorhanden sein um diese zu betrachten und zu steuern.

– Es muss mindestens die Mac OS X Version „Mavericks“ verfügbar sein.

– XCode ab Version 5.1 und die XCode Command Line Tools

– iOS Developer Account

– Node.js auf dem Mac-System

– Die beiden Systeme müssen im selben Subnetz registriert sein.

Konfiguration des Mac-Systems

Sind die Voraussetzungen geschaffen, muss der Mac mit dem „Cordova Build Host for Visual Studio“ bestückt werden. Er nimmt die Build-Jobs des Entwicklungssystems über die Netzwerkverbindung an, und stoßt den Build-Prozess an. Dazu muss die Consolen-Anwendung auf dem Mac-System gestartet und der Build Host per CMD-Line Command installiert werden:

sudo npm install -g vs-mda-remote

Entwickler die den iOS Simulator verwenden möchten, müssen diesen noch extra dem System hinzufügen, da mit der Installation des Build Host nur das Geräte-Deployment bzw. die Rückgabe des nativen App Codes zum Windows-System unterstützt wird. Auch für die Installation der Simulatoren ist ein CMD-Line Command verantwortlich:

sudo npm install -g ios-sim

Beim Starten des Build Host muss ein Verzeichnis-Pfad für die temporären Dateien des Build Prozesses angegeben werden:

vs-mda-remote --buildDir TempBuildDir

Wer den Simulator verwenden möchte, muss dies beim Starten des Build Host mit einem zusätzlichen Parameter bekannt geben. Danach ist das Bauen und Zurückspielen zum Entwicklungssystem immer noch möglich. Es wird nur der Simulator als zusätzliches mögliches Target aktiviert:

vs-mda-remote --buildDir TempBuildDir --allowsEmulate=true

Konfiguration in Visual Studio

Damit Visual Studio und das Mac-System miteinander kommunizieren und die Bits austauschen können, muss die IP-Adresse des Build-Host-Systems in Visual Studio bekannt gegeben werden. In den „Options“ von Visual Studio gibt es einen Option-Point „Multi-Device Hybrid Apps“ der die Angaben verwaltet:

VSBuildHostSettings

Die richtige IP-Adresse lässt sich über einen Line Command auf dem Mac-System schnell herausfinden:
ifconfig

Im Ausgabe-Listing findet sich unter “inet” die gesuchte Information

BuildHostMacIP

Der Build Host wird per default auf dem Port 3000 gestartet. Sofern nichts anderes explizit gewünscht wird, kann der Wert 3000 in Visual Studio einfach bestehen bleiben.

Somit sind alle Einstellungen gesetzt, und der Build-Host von Visual Studio heraus ansprechbar.

 

Aber Achtung:

Damit das Mac-System auf die Anfrage reagieren und den nativen App Code wirklich bauen kann, muss in XCode der Apple Developer Account mit gültigem Provisioning-File hinterlegt sein. Es reicht NICHT nur, einen Developer Account zu hinterlegen. Der Account muss auch die Subscription für iOS-Development abonniert haben (aktueller Preis: 99 Dollar im Jahr).

Das Provisioning-File stellt quasi die Brücke zwischen dem gültigen (und bezahlten) Developer Account mit iOS Subscription (oder/und Mac Development… dies kann optional dazu erworben werden), und den registrierten Geräten auf, auf denen getestet bzw. deployed werden soll. Die Aufnahme und Pflege dieser Geräteverwaltung und Zuordnung erfolgt über das Apple Developer Portal im Browser.

Im fünften Teil der dieser Blogreihe betrachten wir die Möglichkeit, iOS-Apps in der Cloud zu bauen.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>