Entwicklungstagebuch · Teil 26

Svenner ist mein iPhone

Entwicklungstagebuch, Teil 26 · 28. und 29. August 2026

Entwicklungstagebuch, Teil 26 · 28. und 29. August 2026

Am Freitagabend um 19:38 lief zum ersten Mal Programmcode für die native App durch, und vierunddreißig Prüfungen meldeten null Fehler. Auf Anhieb.

Ich habe darauf nicht mit Erleichterung reagiert. Ich habe gedacht: na endlich, jetzt beginnt der Bau der nativen App.

Das ist die ehrliche Reaktion nach einem Tag, an dem es von morgens bis abends um Fehler ging. Die grünen Prüfungen waren nicht das Ereignis. Der Anfang war es.

Was die Maschine nicht kann, und was daraus folgt

Vor der ersten Zeile stand eine Messung, an die ich selbst nicht gedacht hätte. Der Rechner, auf dem die Maschine arbeitet, hat kein Swift — und kann sich auch keines holen. Zwei Adressen, beide abgewiesen, gemessen um 17:31.

Für die Webseiten war es dieses Jahr die tragende Regel: erst am Server messen, dann behaupten. Neun Funde in einer einzigen Woche verdanken sich dieser Schleife. Bei einer nativen App gibt es keinen Server. Es gibt Xcode auf meinem MacBook und ein iPad in meiner Hand.

Die Antwort darauf war ein Schnitt, den ich für den wichtigsten dieser Woche halte:

Alles, was eine Entscheidung trägt — die Geometrie des Schwojkreises, wann ein Alarm gilt, welche Position zählt — kommt in einen Teil, der ohne Gerät und ohne Simulator prüfbar ist. Die Oberfläche und alles, was das System anfasst, bleibt außen vor.

Der eine Teil lässt sich in Sekunden messen. Der andere nur, indem ich draufdrücke. Wie richtig dieser Schnitt war, hat sich schneller gezeigt, als mir lieb ist.

Zwei Fehler, die der Übersetzer gefunden hat

Der erste Bauversuch brachte zehn Fehler, alle mit derselben Ursache: eine fehlende Zeile in zwei Dateien. Beim Umbau war sie herausgefallen. Kein Denkfehler, ein Abschreibfehler.

Der zweite war interessanter. Eine gelbe Warnung, die man leicht wegklickt: „Result of 'try?' is unused.“

Dahinter steckte etwas Echtes. Die Zeile springt ans Ende der Protokolldatei, bevor eine neue Zeile angehängt wird. Mit dem Fragezeichen wird ein Scheitern verschluckt — und dann schreibt der nächste Befehl da weiter, wo der Griff gerade steht: am Dateianfang. Die neue Ortsmeldung hätte den Anfang der Nacht überschrieben.

Ausgerechnet in der Datei, die beweisen soll, dass die Wache durchgelaufen ist.

Beide Fehler standen in dem Teil, für den es keine Prüfungen gibt. Der geprüfte Teil war größer und hatte keinen.

Und dann Samstagmorgen

Ich hatte Freitagabend abgebrochen, weil ich zu müde war. Das lag nicht an der Arbeit. Es lag daran, dass ich in der letzten Stunde einen Fehler gejagt habe, den es nicht gab.

Xcode meldete immer wieder: „Developer Mode disabled“ — der Entwicklermodus sei auf dem Gerät nicht eingeschaltet. Ich habe ihn eingeschaltet. Am iPad, in den Einstellungen, ganz unten. Neustart. Bestätigt. Der Schalter stand auf Ein.

Die Meldung kam wieder.

Kabel ab, Kabel dran. Xcode beendet, Xcode gestartet. iPad neu gestartet. Entwicklermodus aus, Neustart, wieder ein, Neustart. Die Meldung kam wieder.

Am Samstagmorgen habe ich dann das Fenster geöffnet, in dem Xcode auflistet, welche Geräte es sieht. Da standen zwei.

SvenneriPhone 17 Pro — mit dem roten Fehler
iPad Pro12,9 Zoll — ohne jeden Fehler

„Svenner“ ist mein iPhone.

Die ganze Zeit war eingestellt, dass die App auf das iPhone soll. Dort war der Entwicklermodus aus. Am iPad war alles in Ordnung, von Anfang an. Es war nur nie gemeint.

Und die Maschine hatte mir am Abend geschrieben: „Svenner ist dein iPad.“ Angenommen, weil der Name auftauchte, als ich das iPad anschloss. Nachgesehen hat sie nie — obwohl in genau dem Fenster, das die Antwort enthielt, beide Geräte untereinander standen.

Das ist derselbe Fehler, gegen den dieses Heft seit vier Wochen anschreibt, nur diesmal von der anderen Seite: eine Behauptung ohne Messung. Sie hat mich einen Feierabend und einen Vormittag gekostet.

Die Katze und ihr Schwanz

Als die App dann endlich auf dem iPad lag, stand oben brav das Recht auf Ortung — und darunter „Noch keine Position.“ Der Knopf „Anker gefallen“ war grau.

Der Grund war wieder logisch, nicht technisch: Das Einschalten der Ortung steckte im Ankersetzen. Also keine Position, weil nicht geortet wird; nicht geortet, weil kein Anker gesetzt ist; kein Anker möglich, weil keine Position da ist.

An Bord ist die Reihenfolge umgekehrt und jeder weiß das: Erst weiß man, wo man ist, dann fällt der Anker.

Eine Zeile, und die Position stand da. Auf fünf Meter genau.

Die Zahl, die sich von selbst geändert hat

Und dann kam der Moment, an dem ich gesehen habe, dass das Ding wirklich rechnet und nicht nur anzeigt.

Vor der Ortung stand der Alarmradius bei 50 Metern. Nachdem die Position da war, standen dort 55.

Der Unterschied sind die fünf Meter, auf die das iPad seine eigene Position genau kennt. Die gehen in den Kreis ein, weil die Unschärfe zweimal wirkt: beim Setzen des Ankerpunkts und beim Vergleich. Niemand hat das eingetippt. Die Rechnung hat sich genommen, was sie brauchte, sobald es da war.

29 Meter waagerecht, 11 Meter Boot, 5 Meter Ortung, 10 Meter Reserve.

Was ich mitnehme

Ich habe von Xcode keinerlei Ahnung. Ich bin da absoluter Laie, und ich habe ein Werkzeug bedient nach einer Anleitung von jemandem, der es selbst noch nie gesehen hat — das stand ehrlich oben drüber.

Es war die einzige Möglichkeit, außer mit anderen Werkzeugen von vorn anzufangen. Am Ende hat es geklappt, und das freut mich.

Aber der Preis stand in derselben Anleitung, in einem Satz, den ich schon im August aufgeschrieben hatte:

Was auf dem Bildschirm steht, gilt. Nicht, was die allgemeine Seite sagt, nicht, was in der eigenen Anleitung steht.

Am Freitagabend stand auf dem Bildschirm eine Liste mit zwei Geräten. Wir haben beide nicht hingesehen — sie nicht, weil sie es für erledigt hielt, ich nicht, weil ich es ihr geglaubt habe.

Am Donnerstag fahre ich aufs Boot. Dann wird sich zeigen, ob die App mit dem Bordnetz redet — und das kann sie im Browser nicht, aus einem Grund, den wir im August gemessen haben. Deshalb der ganze Umbau.

Fünf Tage.

Nachtrag vom selben Vormittag, 08:21. Die Frage, wegen der das alles gebaut wurde, ist beantwortet. Ich habe den Anker gesetzt, das iPad gesperrt und achtzehn Minuten liegen lassen.

1245 Meldungen. 97 Prozent davon aus dem Hintergrund. Größte Lücke: null Minuten.

Die Ortung läuft also weiter, während das Gerät zu ist. Das konnte die Webfassung nie, und deshalb der ganze Umbau.

Die interessanteste Zahl ist aber eine andere: vier Meter Drift. Das iPad lag still auf dem Schreibtisch, und trotzdem ist die gemeldete Position um bis zu vier Meter gewandert. Das ist keine Bewegung, das ist die Ortung selbst.

Damit weiß ich seit heute etwas, das ich vorher nur vermutet hatte: Ein Ankeralarm mit zehn Metern Radius geht an einem Boot los, das gar nicht geankert hat, sondern nur daliegt. Die zehn Meter Reserve in der Rechnung sind keine Vorsicht. Sie sind das Mindeste.

← Zurück zum Entwicklungstagebuch

PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.