Entwicklungstagebuch, Teil 19 · 24. August 2026
Gestern um 13:39 habe ich mich beim Apple Developer Program angemeldet. Heute um 11:54 ist der Antrag draußen, der über eine der wichtigsten Funktionen der geplanten iPhone-Fassung entscheidet.
Dazwischen liegen zweiundzwanzig Stunden und vier Stellen, an denen der Bildschirm etwas anderes sagte als meine eigene Anleitung.
Dieser Beitrag holt etwas nach. Die Anmeldung fiel mitten in den Nachmittag, über den Teil 18 berichtet — und kommt dort nicht vor. Ich habe gestern Abend über das geschrieben, woran ich gearbeitet hatte, nicht über das, was der Tag enthielt. Das ist ein Unterschied, und er gehört bemerkt.
Der Ausweis, den es nicht gab
Zur Anmeldung braucht Apple einen Lichtbildausweis. Ich hatte mir vorher eine Anleitung geschrieben und darin den Reisepass empfohlen — gestützt auf Apples allgemeine Seite, die von „passports in most regions“ spricht. Maschinenlesbar, international, eindeutig.
Die App bot in Deutschland keinen Reisepass an. Nur den Kartenführerschein.
Nicht falsch recherchiert. An der falschen Stelle recherchiert. Die allgemeine Seite beschreibt, was Apple weltweit anbietet. Der Bildschirm zeigt, was hier gilt.
Gekostet hat es eine Minute Verwirrung. Es ist trotzdem dieselbe Sorte Fehler, die mich in diesem Projekt schon mehrfach eingeholt hat: eine Quelle lesen, die allgemein richtig ist, und sie für die Antwort auf die konkrete Frage halten.
Drei Zahlen für denselben Betrag
Die Mitgliedschaft kostet 99 US-Dollar im Jahr. So steht es auf Apples Seite.
Die App zeigte beim Kauf $98.99.
Abgebucht wurden 98,99 Euro.
Drei Angaben, ein Vorgang. Keine davon ist gelogen, und keine zwei stimmen überein. Es gilt, was auf der Rechnung steht — und das ist nicht die Seite, auf der man vorher nachgesehen hat.
Nebenbei, klein gedruckt und wichtig: Die Anmeldung über die App ist ein Abonnement. Sie verlängert sich am 23. August 2027 automatisch. Kündigung spätestens einen Tag vorher.
Eine Tür, die zufällt
Bei der Anmeldung fällt eine Entscheidung mit, die man leicht übersieht: Einzelperson oder Organisation.
Als Einzelperson erscheint im App Store der Rechtsname als Anbieter — mein Name, nicht „PELARON“. Der Name der App bleibt davon unberührt. Für „PELARON“ als Anbieter bräuchte es eine Kapitalgesellschaft mit eigener Kennnummer.
Ein Einzelunternehmen lässt sich später nicht umstellen. Das ist keine Einstellung, die man ändert, sondern ein anderes Konto. Ich habe es trotzdem so gemacht, weil die Alternative eine Frage an den Steuerberater ist und den Antrag um Wochen verzögert hätte.
Aber es ist eine Tür, die zufällt, und ich schreibe sie deshalb auf.
Vierzehn Stunden, siebenundvierzig Minuten
Apple sagt zur Prüfung des Ausweises: Freischaltung binnen 24 Stunden.
Die beiden Bestätigungen kamen heute um 04:26 und 04:27. Vierzehn Stunden und siebenundvierzig Minuten nach der Anmeldung.
Eine Zusage, die eingehalten wurde, ist keine Nachricht wert. Ich schreibe sie trotzdem auf, weil ich sonst nur die Fälle notiere, in denen etwas schiefgeht.
Eine Kennung, die für immer bleibt
Der erste Schritt danach war kein Programmieren, sondern ein Formular: die Bundle-Kennung. Der eindeutige Name der App bei Apple, weltweit einmalig, nach der ersten Einreichung nie wieder änderbar.
de.pelaron.app. Passt zu beiden Adressen, pelaron.de und pelaron.app, und bleibt gültig, egal welchen technischen Weg die native Fassung später nimmt.
Registriert um 11:36. Der billigste Schritt des ganzen Vorgangs und einer der wenigen, die man nicht nachholen kann, wenn jemand anders schneller war.
Warum es überhaupt eilte
Die Ankerwache braucht ein besonderes Recht, das Apple einzeln vergibt: kritische Hinweise. Der Unterschied zur nächstschwächeren Stufe ist genau ein Satz aus Apples eigener Beschreibung.
Eine zeitkritische Mitteilung „breaks through system notification controls“. Nur eine kritische Mitteilung „bypasses the mute switch to play a sound“.
Nur die kritische Stufe durchbricht den Stummschalter. Und der ist nachts an Bord gesetzt.
Ein Schiff liegt vor Anker. Die Crew schläft unter Deck, das Gerät ist gesperrt, stumm und am Ladekabel. Wenn der Anker bei auflandigem Wind slippt, sitzt das Boot in Minuten fest. Eine Meldung, die auf einem stummen Gerät keinen Ton machen kann, ist dasselbe wie keine Meldung.
Das ist kein Bequemlichkeitsargument und keine Frage von Sekunden. Es ist der Unterschied zwischen einer Crew, die aufwacht, und einer, die es nicht tut.
Fünf Felder, wo drei stehen sollten
Ich hatte den Antrag vorbereitet: App-Name, Bundle-Kennung, Begründung. So stand es in meinem eigenen Entscheidungspapier, gestern nachgeschlagen.
Das Formular verlangt zwei Auswahlfelder und drei Textfelder.
Beim App Type stehen vier Möglichkeiten: Gesundheit, öffentliche Sicherheit, Personen- und Objektsicherheit, Sonstiges. Gesundheit wäre falsch, öffentliche Sicherheit meint Behörden und Rettungsdienste, Sonstiges hieße, Apple sortiert selbst ein. Es bleibt eine.
Bei der Häufigkeit drei: selten, häufig, regelmäßig geplant. Ein Sicherheitsalarm, der regelmäßig kommt, ist kein Alarm mehr, sondern ein Kanal. Es bleibt eine.
Und dann drei getrennte Textfelder: was die App ist, welche Mitteilungen kritisch verschickt werden, und warum das Recht nötig ist. Hätte ich meine vorbereitete Begründung als Block eingefügt, stünde alles in einem Feld und zwei wären leer geblieben. Das sieht ein Prüfer sofort.
Der häufigste Ablehnungsgrund bei diesem Antrag ist eine allgemein gehaltene Begründung. Ein Formular, das dreimal nachfragt, will genau das verhindern — und bestraft den, der es nicht vorher aufmacht.
Um 11:54 war er raus. Bestätigung, Vorgangsnummer, und der Satz: wir melden uns.
Was ich mitnehme
Viermal an einem Tag wich das, was auf dem Bildschirm stand, von dem ab, was ich vorbereitet hatte. Der Ausweis, der nicht angeboten wurde. Der Preis in drei Währungen. Das Formular mit fünf Feldern statt drei. Und der Weg zum Antrag selbst, der nicht über das Kontaktformular führte, sondern über einen Reiter an der App-Kennung, den ich nicht kannte.
Keine dieser Abweichungen war ein Fehler von Apple. Alle vier waren Abweichungen zwischen einer allgemeinen Beschreibung und dem konkreten Fall.
Was auf dem Bildschirm steht, gilt. Nicht, was die allgemeine Seite sagt, nicht, was in der eigenen Anleitung steht, und schon gar nicht, was man vorgestern darüber notiert hat.
Das ist derselbe Satz, der in diesem Projekt seit Wochen für Prüfsummen gilt: zuerst messen, dann behaupten. Er gilt offenbar auch für Formulare.
Nachtrag vom 28. August: Auf den Antrag ist bis heute keine Antwort gekommen. Fünf Tage, keine Mail, kein Zwischenstand. Er steht als eigener Punkt im Register und ist der einzige, an dem ich nichts tun kann außer warten.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.