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.