Ist Xamarin die Zukunft der Crossplatform-Entwicklung?

Zum Thema Crossplatform-Entwicklung von mobile Apps gibt es verschiedene Lösungen. Neben Web-basierten Ansätzen, die hauptsächlich im Browser leben, hat sich mittlerweile auch Xamarin verbreitet.

Es unterscheidet sich von Web-Apps in erster Linie darin, dass es die Möglichkeit bietet nativ zu programmieren und verspricht damit gute Performance und Zugriff auf die neuesten Features der jeweiligen Plattform. Wir haben ein halbes Jahr damit gearbeitet und waren zunächst sehr begeistert. Technisch gesehen funktioniert Xamarin. Noch dazu ist es seit Kurzem kostenlos. Wir hatten noch dafür bezahlt, da wir an das Konzept glaubten. Wir haben uns dann aber letzten Endes entschieden, das entsprechende Projekt doch prototypisch nativ in Android neu aufzusetzen, weil Xamarin zu viele Nachteile mit sich bringt. Wie kam es zu der Entscheidung? Die fünf wichtigsten Punkte, die uns aus Entwicklersicht gestört haben, werde ich an dieser Stelle ansprechen.

1. Die Arbeitsersparnis ist marginal.

Xamarin ermöglicht es, Business-Logik nur einmal zu entwickeln und auf allen Plattformen zu nutzen. Die UI-Logik kann und sollte nativ für jede Plattform entwickelt werden. Das Framework jeder Plattform wurde dafür vom Xamarin-Team nach C# übersetzt. Das Problem hierbei: Business-Logik macht einen sehr geringen Teil der Arbeit an mobile Apps aus. Diese besteht in der Regel aus Anfragen an einen REST-Service. Diese REST-Anfragen können auch plattformübergreifend entwickelt werden. Das funktioniert grundsätzlich gut, aber auch hier müssen an manchen Stellen noch Eigenheiten der jeweiligen Plattformen beachtet werden, was zum Beispiel durch Compiler-Direktiven erfolgt. Besonders Windows Phone war dabei ein Problem. Die resultierenden Daten müssen in der UI dargestellt werden. Diese wiederum muss für jede Plattform separat entwickelt werden. Es gibt zwar für Standardfälle die sogenannten Xamarin-Forms. Die UI wird dann nur einmal programmiert und vom Xamarin-Framework automatisch gemäß den Designrichtlinien der jeweiligen Plattform zu nativer UI umgewandelt. Dies funktioniert aber nur für strikte Standardfälle, beispielsweise für die Listendarstellung von einfachen Texten mit einem einfachen Master-Detail-Flow. Erfordert eine Darstellung aber eine präzise oder kreative Anordnung der UI-Elemente kann man diese Möglichkeit nicht nutzen. Leider trifft das so gut wie immer zu. Ich hatte daher solch einen Standardfall nie gehabt und bin deshalb zugegebenermaßen gar nicht erst dazu gekommen die Xamarin Forms zu benutzen. Grob geschätzt macht der Anteil an Business-Logik, für die man sich die Mehrarbeit spart, in mobile Apps nur ca. 20-30% aus. Diesen Anteil hält man durch eine klug strukturiere REST-API ohnehin möglichst gering. Meiner Meinung nach lohnt sich da der Mehraufwand nicht, der aus den noch folgenden Punkten entsteht.

2. Übersetzter Code.

Das Xamarin-Team übersetzt den Code des Android- und iOS-Frameworks nach C#. Das heißt also, dass es deren Updates nachprogrammieren muss, um das Framework up to date zu halten. Sicherlich werden hierfür auch Automatismen verwendet und bisher scheint das gut zu funktionieren. Aber es entsteht dadurch eine weitere Fehlerquelle, was im Endeffekt Mehraufwand bedeutet.

3. Kleinere Community.

Ein signifikantes Problem: Genau wie beim vorigen Punkt muss das Xamarin-Team nicht nur den Framework-Code übersetzen, sondern auch die gesamten Bibliotheken, die die Communitys so produzieren. Natürlich ist das ein gigantischer Aufwand für Xamarin, deshalb sind auch nur die wichtigen Bibliotheken da. Sehr viele sogar. Aber es fehlen auch welche, die man gebrauchen könnte. Die Xamarin-Community zieht hier aber auch einiges nach. Wenn eine Bibliothek in Java existiert, gibt es noch Möglichkeiten, das Ganze halbautomatisch zu übersetzen und einzubinden. Das bedeutet aber wieder Mehraufwand.

4. Die IDE lässt sehr zu wünschen übrig.

Wir hatten das Xamarin Plugin für Visual Studio verwendet. Visual Studio ist gut. Wenn man für Windows entwickelt. Aber das Plugin ist leider nicht sehr stabil und besonders beim Vergleich mit Android Studio ist der Unterschied gewaltig. Völlig klar: Android Studio wird von Google speziell für Android entwickelt. Das Tooling ist exzellent und beschleunigt die Arbeit ungemein. Da kann das Xamarin Plugin nicht mithalten. Am meisten hat uns der Layout-Designer gestört. Ich kann es nicht anders beschreiben: Der ist einfach schlecht. Wir haben im Endeffekt die Layouts im Android Studio designt und das Resultat nach Xamarin kopiert. Das kann nicht im Sinne des Erfinders sein und erst recht nicht im Sinne des Nutzers. Das war alles andere als zufriedenstellend und bedeutete wiederum Mehraufwand (und Ärger).

5. Windows Phone ist tot.

Microsoft hat offiziell angekündigt, sich mit Windows Phone nur noch auf Enterprise-Kunden zu konzentrieren. Daher lohnt es sich fast nie dafür zu entwickeln. Man entwickelt also nur noch für zwei Plattformen statt für drei. Wäre Windows Phone ein Faktor, wäre Xamarin auch noch immer eine Überlegung wert. Ansonsten sinkt aber noch mehr der Nutzen, den man daraus ziehen kann.

https://www.thurrott.com/mobile/windows-phone/67400/microsoft-streamline-windows-phone-business

https://www.windowscentral.com/microsoft-memo-reveals-shifting-mobile-strategy

https://www.neowin.net/news/windows-phones-microsoft-to-aim-its-devices-at-just-18-core-markets-focus-on-businesses

 

Für eine Crossplatform-Lösung würde ich zurzeit nicht zu Xamarin greifen. Vielleicht wird sich das Zukunft nochmal ändern. Momentan sieht es mir aber nicht danach aus. Ich würde dann eher in Richtung Web Apps gehen. Die sind einmal entwickelt und sehen überall gleich aus. Natürlich gibt es auch hier Nachteile, aber die Aufwandsersparnis steht in einem günstigeren Verhältnis. Die beste Alternative bleiben daher aus meiner Sicht nach wie vor von Grund auf native Apps.

 


 

Samsung Galaxy S7 Daten-Roaming einschalten