Road4Trip

Luftlinie ist keine Distanz

Die erste Fassung rechnete den Abstand zwischen den Stopps einfach geometrisch – naheliegend und falsch. Bei der Sustenpass-Runde zeigte sie 55 Kilometer, tatsächlich sind es 113. Über alle Testrouten hinweg lag die Schätzung fast 60 Prozent zu tief, weil sich Bergstrassen nun einmal in Kurven den Hang hochziehen. Jetzt rechnet die App über Apples Routendienst die echte Fahrstrecke.

Zwei Bauteile, zwei Meinungen

Ein Fehler, der lange unbemerkt blieb, weil beide Seiten für sich genommen richtig aussahen: Die Streckenberechnung ging vom ersten Stopp aus, die Übergabe an die Karten-App liess die Startadresse jedoch weg – wodurch diese am aktuellen Standort begann. Wer nicht zufällig beim ersten Stopp stand, fuhr eine andere Strecke, als die App auswies. Sichtbar wurde es erst, als jemand fragte, wo man denn den Startort eingebe. Die Lehre: Eine Annahme, die zwei Komponenten unabhängig voneinander treffen, gehört ausgeschrieben – heute steht in der Liste ausdrücklich «Start» und «Ziel».

Eine Berechtigung, die mehr einschaltet als gedacht

Für die Sicherung in iCloud Drive braucht die App die iCloud-Berechtigung. Sobald sie im Programm steht, versucht das Datenbank-Framework von sich aus, eine Synchronisierung über CloudKit aufzusetzen – ungefragt. Deren Bedingungen erfüllte das Datenmodell nicht, die Datenbank liess sich nicht mehr öffnen, und die App startete nicht. Der Build war schon bei den Testern, bevor es auffiel.

Die Ursache stand im Klartext in der Konsole des Simulators; gefunden war sie in Minuten, vermutet hatte ich sie an ganz anderer Stelle. Beim Suchen kam ein zweiter Fehler zum Vorschein, der noch nicht zugeschlagen hatte: Die Fotos wären beim Verschieben der Datenbank verloren gegangen, weil sie in einem versteckten Ordner daneben liegen. Zwei Fehler, ein Nachmittag – und seither zwei Absätze mehr in der Projektdokumentation.

Der Prüfbericht kennt kein «Apple»

Ein Build wurde automatisch abgewiesen, weil in der Beschreibung des Sprachbefehls das Wort «Apple» vorkam – in App-Intent-Texten sind Markennamen nicht erlaubt. Eine Zeile Text, ein neuer Build. Solche Regeln stehen selten dort, wo man sie sucht.

Ein undokumentiertes Detail, am Gerät geprüft

Ob Apple Maps beim Übergeben einer Route wirklich alle Zwischenstopps übernimmt, ist von Apple nicht dokumentiert und liess sich im Simulator nicht abschliessend prüfen. Statt es einfach zu behaupten, blieb es ein offener Punkt – bis der Test auf echter Hardware über TestFlight ihn bestätigte: Eine Route über drei Orte kommt vollständig und in der richtigen Reihenfolge in Apple Maps an.

Das Icon ist Code

Statt einer Bilddatei erzeugt ein kleines Swift-Programm mit CoreGraphics die kurvige Strasse vor dem Abendhimmel – die Strassenbreite verjüngt sich perspektivisch entlang einer Bézier-Kurve. Farben und Form ändert man an einer Stelle und rendert neu.

Ausgeliefert ohne angeschlossenes Gerät

Entwickelt und veröffentlicht wurde remote, ohne iPhone am Mac. Weil Apples automatische Signierung ohne registriertes Gerät kein Profil ausstellt, läuft die Auslieferung über manuelle Signierung und die App-Store-Connect-API – vom Zertifikat über den Upload bis zur Freigabe.

Teilen war als Kleinigkeit geplant

Für Version 2.0 sollten sich Touren mit anderen teilen lassen. Apple bringt dafür etwas Fertiges mit, also stand es als kleiner Punkt auf der Liste. Beim Nachlesen kam heraus: Das Datenbank-Framework, auf dem die App aufbaut, spiegelt ausschliesslich den privaten Bereich der iCloud und kennt Freigaben schlicht nicht.

Damit standen zwei Wege offen – die gesamte Speicherung auf ein älteres Framework umbauen, oder eine eigene Schicht fürs Teilen daneben legen. Es wurde die zweite: Die App behält ihre Speicherung, das Teilen bekommt eigene Datensätze in einem eigenen Bereich. Der Aufwand lag um ein Vielfaches über meiner Schätzung. Immerhin ist es vor der ersten Zeile Code aufgefallen und nicht mittendrin.

Ein Framework, das rät statt zuzuordnen

Fotos sollten sich getrennt von den Routen synchronisieren lassen – ein eigener Schalter, weil Bilder gegen den iCloud-Speicher zählen. Das Framework schaltet die Synchronisierung aber pro Speicher, also bekamen die Bilder einen eigenen: zwei Konfigurationen in einem Behälter, eigentlich ein Lehrbuchfall.

Beim Nachmessen zeigte sich, dass ein solcher Behälter neue Objekte gar nicht nach ihrem Typ zuordnet, sondern einfach in der zuletzt genannten Konfiguration ablegt. Weil der Bilder-Speicher hinten stand, landete dort jede neue Route – und das Programm brach ab. Die App wäre beim Anlegen der allerersten Route abgestürzt, und dieser Build lag zu dem Zeitpunkt bereits bei Apple.

Zwei Dinge daran fand ich lehrreicher als den Fehler selbst. Erstens war er in meinen Tests unsichtbar: Die legten alle Typen in eine Konfiguration im Arbeitsspeicher, und dort kann die Zuordnung gar nicht danebengehen – geprüft wurde also die bequeme Fassung, nicht die echte. Zweitens liess sich die Ursache erst in einem kleinen Beispielprojekt ausserhalb der App festnageln; darin kam auch heraus, dass Umsortieren nichts bringt, sondern den Absturz bloss auf die Fotos verschiebt. Der Ausweg sind zwei getrennte Behälter. Die Einreichung habe ich zurückgezogen, bevor die Prüfung anlief – der neue Build ging am selben Tag hinaus.

Ein Netz, das man nicht misst, ist keines

Bevor 2.0 die Daten auf die neue Struktur umzieht, legt die App ungefragt eine vollständige Sicherung an – das Netz für den Fall, dass beim Umzug etwas schiefgeht. Beim Nachmessen war diese Sicherung 1,5 Kilobyte gross statt der erwarteten 6 Megabyte: Sie las bereits den neuen Ablageort, an dem noch gar nichts lag. Ausgerechnet die Fotos, für die es das Netz gibt, wären nicht drin gewesen. Seither wird die Grösse bei jeder Sicherung mitgeprüft.

Das Schema, das niemand geschrieben hatte

Nach der Freigabe von 2.0 zeigte sich, dass die Synchronisierung bei niemandem lief – lautlos, ohne eine einzige Fehlermeldung. Der Code war vollständig. Aber die iCloud trennt eine Entwicklungs- von einer Produktionsumgebung, und in der Produktion muss die Struktur der Daten vorher stehen; anlegen darf sie sich dort nicht selbst. Entstanden wäre sie beim Lauf eines Entwicklungs-Builds – wozu ein registriertes Gerät gehört, und dieses Projekt habe ich bewusst ohne eines gebaut.

Gelöst über ein Kommandozeilenwerkzeug von Apple. Dabei kam heraus, dass die Entwicklungsumgebung die Struktur längst trug, nur veraltet: Ein Datensatztyp fehlte ganz, ein Feld fehlte, weil die zugehörige Eigenschaft nie einen Wert bekommen hatte, als die Struktur entstand. Dass sich die Zuordnung am vorhandenen Stand ablesen liess statt raten zu müssen, machte den Unterschied zwischen einer sicheren Ergänzung und einem Ratespiel.

Eine App, die schweigt, wenn sie scheitert

In den Einstellungen stand «Aktiv», sobald sich der Speicher mit der iCloud öffnen liess. Ob je ein Datensatz ankommt, wusste die App nicht – und konnte es so auch gar nicht wissen. Dreimal ging deshalb dasselbe schief: Ein Feld oder ein Datensatztyp fehlte in der Produktion, der Abgleich stand still, und die Anzeige behauptete unbeirrt, alles laufe. Beim ersten Mal drei Tage, beim zweiten zehn – beim dritten Mal war eine ganze Funktion drei Wochen lang bei allen Nutzern tot, ohne dass es irgendwo auffiel.

Bemerkenswert daran finde ich nicht den Fehler, sondern warum er unsichtbar blieb. Ein fehlendes Zertifikat bricht den Export, eine fehlende Berechtigung bricht den Build – beides merkt man sofort. Eine fehlende Datenstruktur bricht gar nichts: In der Entwicklung funktioniert alles, denn dort legt die iCloud neue Typen beim ersten Schreiben selbst an. In der Produktion nie. Der Unterschied zeigt sich erst bei Leuten, die einem nichts davon erzählen.

Zwei Dinge kamen als Antwort dazu. Die App zeigt jetzt einen Zeitstempel statt eines Zustands: «Zuletzt abgeglichen vor fünf Minuten» lässt sich nachprüfen, «Aktiv» ist bloss eine Behauptung. Und vor jedem Upload vergleicht ein kleines Skript beide Umgebungen – dieselbe Prüfung, die an jedem einzelnen dieser Tage zwei Sekunden gebraucht hätte.

Ein Rädchen, das sich für immer dreht

Beim Wetter entlang der Route lief die erste Fassung genau in die Falle, die zwei Versionen zuvor beseitigt worden war. Sie fragte bis zu fünf Orte nacheinander ab, ohne Zeitlimit, und die Ansicht kannte nur zwei Zustände: «lädt» und «fertig». Hing ein Aufruf, stand «Wetter wird geholt …» notfalls für immer da. Ein Ladebalken ohne Ende ist schlimmer als eine Fehlermeldung – er behauptet, es ginge gleich weiter. Behoben mit gleichzeitigen Abrufen, einem Zeitlimit und einem dritten Zustand: gescheitert, mit Begründung.