Was kann die App NavShip?

In der NavShip-App für Android und iOS wirst du beim Start aufgefordert, deinen Bootstyp anzugeben. Dies wirkt sich zum einen auf das Schiff-Symbol aus. Zum anderen erkennt NavShip, ob sich auf der Route Beschilderungen befinden, die das Passieren mit Motor- oder Segelboot untersagen und wird dich entsprechend informieren. Bei der Auswahl eines Kanus oder Ruderboots werden z.B. automatisch die Kleingewässer aktiviert. Du kannst deine Präferenzen jederzeit unter „Mein Boot“ ändern.

Der Beitrag Eine App für alle Bootstypen erschien zuerst auf NavShip Boot-Routenplaner.

Eine Frage, die öfter mal aufkommt. Und eigentlich lässt sie sich sehr leicht beantworten: Die Entwicklungen für Android und iOS laufen parallel. Wir verwenden kein Framework und auch keine Fertiglösungen, beide Apps laufen nativ auf den jeweiligen Plattformen.

Das bedeutet auch, dass der Entwicklungsaufwand doppelt so groß sein müsste. Dies ist aber gar nicht der Fall: Das komplexe ist nicht das Programmieren an sich, sondern das Entwickeln der Algorithmen und Erfinden neuer Ideen. Bevor eine Programmzeile geschrieben wird, gehen einige Berechnungen und Planungen voraus – und zwar nur einmal für beide Plattformen; zumindest in der Regel. Es gibt wenige Features, die nur auf Android oder nur auf iOS laufen und auf der jeweils anderen Plattform nicht.

Pauschal kann man also sagen, dass 50% der Zeit für diese Phase benötigt wird, 30% für die Umsetzung in Android und nochmal 20% für die Umsetzung in iOS, denn vieles aus dem Programmcode kann 1:1 entnommen werden. Das bedeutet nicht, dass iOS grundsätzlich einfacher zu programmieren wäre. Für die Technikaffinen: Wir verwenden für Android Java/Kotlin im Mix und für iOS Swift5, mit Objective-C-Libraries.

Warum Android zuerst?

Die Antwort liegt im Veröffentlichungsprozess. Eine Android-App kann um 16 Uhr fertig programmiert und um 18 Uhr bereits live im Play Store sein. Die Prüfungen gehen sehr viel schneller und es kann Stück für Stück, also Prozentual, ausgeliefert werden. Das hat den großen Vorteil, dass bei einem Fehler im Programmcode nicht gleich alle Geräte betroffen sind, sondern nur die voreingestellte Prozentzahl. Wir verteilen in der Regel am ersten Tag des Updates 10% und am zweiten Tag 30% auf alle Geräte. Sollte es dann immernoch zu keinen Fehlern kommen, wird am dritten Tag an alle Geräte ausgeliefert.

In der Vergangenheit kam es zwei mal vor, dass ein Update zurückgezogen werden musste, weil der Programmcode für Abstürze gesorgt hat. Da ist es gut, dass nur maximal 10% der Geräte betroffen sind und nicht alle.

Was ist das Problem mit iOS?

Bei Apple sieht die Sache etwas anders aus. Wir haben Testflight, aber das steht nur einer ganz kleinen Nutzerbasis zur Verfügung. Ein breites Testen ist dann ohne Voranmeldung nicht möglich. Das Hauptproblem aber, warum wir neue Features nicht zuerst mit iOS ausliefern, liegt am langen und strengen Veröffentlichungsprozess. Früher musste man bis zu einer Woche warten, bis das Update live gehen konnte. Heute sind es 24-48 Stunden. Aber immer noch weitaus länger als bei Google Play.

Die Kontrollen sind streng bei iOS und das ist auch gut so. Hin und wieder wird eine App abgelehnt, z.B. wenn Bedienelemente zu klein sind oder Farbkontraste nicht stimmig sind. Grundsätzlich ist das eine gute Sache – allerdings verlängert und erschwert es den Prozess, wenn man ein Feature nur mal testen möchte.

Daher wird es auch in Zukunft neue Features immer erst für Android geben. Für die iOS-User immerhin ein Trost: Wenn das Feature für eure Geräte kommt, ist es zumindest ausgereifter.

Der Beitrag Warum kommen Android-Updates immer vor den iOS-Updates? erschien zuerst auf NavShip Boot-Routenplaner.