xDay
Eine Todo-App, die nicht fragt, was zu tun ist, sondern ob es in den Tag hineinpasst.
Herunterladen geht noch nicht — Version 1.0 ist eingereicht und wartet auf die Prüfung. Sobald sie freigegeben ist, steht der Link hier.
Warum es die App gibt
Jede Aufgabenliste kann eine Sache nicht: rechnen. Sie nimmt zehn Einträge genauso bereitwillig an wie drei und sagt kein Wort dazu, dass der Tag nur acht Stunden hat — davon fünf mit Terminen belegt. Am Abend ist die Hälfte offen, und weil das jeden Abend so ist, wird aus der Liste ein Vorwurf.
xDay schliesst diese Lücke mit einer einzigen zusätzlichen Angabe: wie lange etwas dauert. Daraus wird eine Zahl, die keine andere Liste nennt — wie viel vom Tag noch übrig ist. Und ein Strich in der Liste, ab dem der Tag nicht mehr aufgeht.
Vorbild — und wo es aufhört
Als Massstab diente Microsoft To Do, ausdrücklich als Haltung und nicht als Vorlage: eine ruhige Oberfläche, eine Handlung pro Bildschirm, die Erfassung immer unten und mit dem Daumen erreichbar.
Zwei Dinge sind bewusst Gegenposition. Den Kontozwang gibt es hier nicht — ohne Microsoft-Konto läuft dort nichts, hier gibt es überhaupt keines. Und den Umgang mit Zeit: Dort gibt es Fälligkeiten, aber keine Dauer und kein Budget. Genau diese Lücke ist der Grund für diese App. Wer sie nachbaut, baut die tausendste Liste.
So sieht sie aus
Fünf Ansichten aus Version 1.0.
Was die App kann
Wenig Funktionen, aber die eine, die sonst fehlt.
Ein Feld, das mitdenkt
«Zahnarzt morgen 14:00 45min» wird zu einer Aufgabe mit Datum, Uhrzeit und Dauer. Kein Formular, keine Auswahlräder — und alles daran ist freiwillig. Wer nur «Milch kaufen» tippt, bekommt genau das.
Das Tagesbudget
Hinterlegte Zeitfenster pro Wochentag, davon abgezogen die Kalendertermine — gerechnet ab jetzt und nicht ab Mitternacht. Übrig bleibt die Zeit, die der Tag noch hergibt.
Der Strich, ab dem es nicht mehr aufgeht
In der Liste läuft eine Linie zwischen der letzten Aufgabe, die noch hineinpasst, und der ersten, die nicht mehr passt. Keine Warnung, keine Farbe — eine Grenze, die man sieht, bevor der Tag sie einem beweist.
Reihenfolge ist Priorität
Kein Prioritätsfeld mit drei Stufen, das ohnehin jeder auf «hoch» stellt. Was oben steht, ist wichtiger. Ziehen genügt.
Zwei Bereiche, eine Regel
«Heute» rechnet, «Ohne Datum» rechnet nicht. Wer keine Zeit angeben will, arbeitet dort wie in jeder gewöhnlichen Todo-App; eine Wischgeste holt einen Eintrag ins Heute. Die einzige Regel, die man verstehen muss: Was ohne Datum liegt, zählt in keine Rechnung.
Erinnerungen, auch dringliche
Aufgaben mit Uhrzeit melden sich. Auf Wunsch als zeitkritische Mitteilung, die auch durch einen Fokus hindurchkommt — eine Berechtigung, die Apple einzeln freigibt.
Die Morgenfrage
Was gestern liegengeblieben ist, wird beim ersten Öffnen gefragt: heute einplanen, später, oder streichen. Nichts wandert von selbst weiter.
Kalender nur lesen
Die App liest Termine, um zu rechnen. Sie legt keine an und ändert keine — im Code steht keine einzige schreibende Zeile.
Alles bleibt auf dem Gerät
Kein Konto, keine Anmeldung, kein Server. Export als JSON in die Dateien-App, Zurücksetzen mit doppelter Rückfrage.
Was dabei interessant war
Ein paar Sachen, die ich beim Bauen gelernt habe.
Ein Name ist schwerer zu finden als eine Funktion
Zweimal danebengegriffen: xTask war in App Store Connect reserviert, obwohl keine App dieses Namens existiert. xDo liess sich reservieren — bis auffiel, dass es in derselben Kategorie bereits «Xdo – die Todo App» gibt.
Die Lehre steht seither in der Projektdokumentation: Namen auf enthaltene Treffer prüfen, nicht auf exakte, und in mehreren Ländern. Und: Die öffentliche Suche findet nur veröffentlichte Apps — reservierte Namen sieht man erst beim Anlegen. Sie ist ein Indiz, kein Beweis. Die Kennung der App ist nach der ersten Einreichung für immer festgelegt; diesen Fehler macht man genau einmal.
Eine Textersetzung, die Code getroffen hat
Sichtbare Texte tragen Umlaute und nie ein ss-Zeichen. Beim Nachrüsten per Suchen-und-Ersetzen wurde aus dem Suchmuster uebermorgen ein übermorgen — womit die App «uebermorgen» nicht mehr verstand — und aus einem Startargument --ueberhang ein --überhang. Aufgefallen ist es nur, weil ein Test darauf bestand. Seither gilt: nur innerhalb von Textbausteinen ersetzen, Code ausnehmen.
Die Testzahl des Werkzeugs stimmte nicht
Das Bauwerkzeug meldete 29 bestandene Tests, wo 33 vorhanden waren. Der fehlende war nicht durchgefallen, sondern abgestürzt — und der Absturz versteckte sich hinter der falschen Zahl. Verlässlich ist nur, die bestandenen Fälle aus dem Protokoll auszuzählen.
Eine Prüfung zur falschen Zeit findet nichts
Die Morgenfrage nach dem Liegengebliebenen prüfte beim Erscheinen der Ansicht — da ist die Datenbankabfrage aber oft noch leer. Am Gerät wäre die Frage gelegentlich einfach ausgeblieben, ohne dass irgendetwas nach einem Fehler ausgesehen hätte. Die Prüfung hängt jetzt am Datenbestand statt am Zeitpunkt.
Eine App darf sich nicht selbst beenden
Gewünscht war: zurücksetzen, App schliesst, beim Öffnen ist alles neu. Apple rät ausdrücklich davon ab — für den Nutzer ist ein Programm, das sich schliesst, nicht von einem Absturz zu unterscheiden, und in der Prüfung ist es ein Ablehnungsgrund. Stattdessen steht nach dem Bestätigen wieder die Einführung da: dasselbe Ergebnis, ohne den faulen Trick.
Der Datenschutz-Fragebogen ist die einzige Handarbeit
Beschreibung, Suchbegriffe, Kategorien, Preis, Altersfreigabe, Screenshots, TestFlight — alles läuft über die App-Store-Connect-Schnittstelle. Nur der Fragebogen zur Datenerfassung hat keinen Endpunkt; die zuständigen Adressen antworten mit «nicht gefunden». Ausgefüllt wurde er am Ende über einen ferngesteuerten Browser.
Technisch
Das Rechnen ist von der App getrennt. Der Teil, der das Tagesbudget ausrechnet, kennt weder Datenbank noch Kalender noch Oberfläche — er bekommt Zeitspannen und Dauern und gibt eine Zahl zurück. Deshalb lässt sich der Kern der App beweisen, statt ihn auszuprobieren: 33 Tests, der grösste Teil davon auf dieser Rechnung.
- Oberfläche
- SwiftUI, durchgehend deklarativ
- Speicherung
- SwiftData, rein lokal, kein Konto
- Kalender
- EventKit, ausschliesslich lesend
- Mitteilungen
- UserNotifications mit
interruptionLevel: .timeSensitive - Eingabe
- eigener Parser für Datum, Uhrzeit und Dauer im Fliesstext
- Tests
- 33 Tests, Schwerpunkt auf der Budgetrechnung
- Projektdatei
- aus YAML erzeugt (XcodeGen)
- Auslieferung
- App Store Connect API, Signierung und Upload skriptgesteuert
- Plattform
- iOS 18 und neuer
Zeitspannen zusammenlegen, bevor man abzieht. Kalendertermine dürfen sich überschneiden. Wer sie einzeln abzieht, zieht eine doppelt belegte Stunde zweimal ab — und der Tag sieht voller aus, als er ist. Überlappende und aneinandergrenzende Spannen werden deshalb erst verschmolzen, dann subtrahiert.
Aufgaben ohne Dauer werden ausgewiesen, nicht verschwiegen. Sie können nicht ins Budget einfliessen; sind es viele, wäre jede Zahl zu optimistisch. Also steht daneben, wie viele es sind: «noch 3 Stunden frei · 4 Aufgaben ohne Dauer». Eine ehrliche Lücke schlägt eine falsche Gewissheit.
Ein Testmodus, den niemand versehentlich findet. Hinter einer bewusst unauffälligen Geste und einem Passwort lässt sich mit Beispieldaten arbeiten, ohne den echten Bestand anzufassen.
Die App ist die Quelle der Texte. Hilfe und Datenschutzerklärung stehen einmal im Code; ein Skript erzeugt daraus die öffentlichen Webseiten, die Apple als Support- und Datenschutz-Adresse verlangt. So können App und Webseite nicht auseinanderlaufen.
Stand
Version 1.0 ist eingereicht und wartet auf die Prüfung — Build 4, die Freigabe läuft automatisch. Vorher lag Build 2 auf TestFlight.
Von der ersten Idee bis zur Einreichung vergingen zwei Tage: Konzept, Namenssuche, Symbol, App, Tests, Webseiten, Store-Eintrag, TestFlight. Was zwischen den beiden Tagen lag, war kein Code, sondern die erste Rückmeldung — das Erfassen war zu umständlich, die Auswahlfelder passten nicht in ihre Zeilen, und es fehlte die Möglichkeit, eine Aufgabe ohne Zeitangabe zu notieren. Alle drei Punkte sind in 1.0 behoben.
Unabhängig von Road4Trip
Kein gemeinsamer Code, keine gemeinsamen Kennungen, keine Abhängigkeit in eine der beiden Richtungen. Übernommen wurde ausschliesslich Erfahrung — die Arbeitsweise mit XcodeGen, die Auslieferung ohne angeschlossenes Gerät, Texte als Quelle im Code. Zur Road4Trip-Seite →