Zum Inhalt springen
Creaitercreate your vision with ai
EinloggenRegistrieren
Alle Beispielprojekte

iOS-App

Vokabelkarten

Eigene Karten anlegen und offline abfragen

Eine iOS-App, mit der man eigene Vokabelkarten anlegt und sie ohne Netz abfragt — im Zug, im Wartezimmer, im Flugzeug.

Konstruierte Lehrbeispiele: Diese drei Projekte wurden für den Kurs entlang der belegten Sieben-Tage-Regeln geschrieben. Es sind keine echten Nutzerprojekte, es gibt keine laufende App, keinen Live-Link und keinen Store-Eintrag. Der Beleg sind die Entscheidungen, nicht ein Bildschirmfoto.

Wofür es gebaut wurde

Vorhandene Vokabel-Apps bringen fremde Wortlisten mit und verlangen ein Konto. Wer für eine bestimmte Prüfung oder eine Reise lernt, will die eigenen dreißig Wörter — und zwar dort, wo kein Netz ist. Die App macht genau das und nichts darüber hinaus.

Der Kernloop in vier Schritten

  1. 1Öffnen — der aktuelle Stapel steht bereit
  2. 2Eine Karte abfragen — Wort sehen, raten, umdrehen
  3. 3Ergebnis geben — gewusst oder nicht gewusst
  4. 4Weitermachen — die nächste Karte kommt, der Stapel schrumpft

Bewusst weggelassen

Das Verkleinern des Scopes ist die eigentliche Arbeit von Tag 1. Diese Punkte hätten das Projekt größer gemacht, ohne den Kernloop besser zu machen.

  • Kein Konto und keine Synchronisierung zwischen Geräten — das verlangt einen Server, eine Anmeldung und eine Antwort darauf, was bei Konflikten passiert.
  • Keine mitgelieferten Wortlisten — sie werfen Lizenz- und Qualitätsfragen auf und lösen das Problem der eigenen dreißig Wörter nicht.
  • Kein Lernalgorithmus mit Wiederholungsintervallen — er ist der eigentliche Reiz solcher Apps, aber ohne funktionierenden Grundablauf ist er wertlos. Er steht auf der V1.1-Liste.
  • Keine Audioaussprache — sie braucht entweder Aufnahmen oder einen kostenpflichtigen Dienst und damit eine Kostengrenze.
  • Kein Import aus Tabellen oder anderen Apps — bequem, aber es macht das Abfragen nicht besser.

Release-Ziel

Interner Testkanal mit signiertem Build. Eine öffentliche Store-Version war ausdrücklich nicht das Ziel dieser sieben Tage.

Die sieben Bautage

Für jeden Tag steht getrennt, was danach sichtbar war und welche Entscheidung dahinterstand. Wo etwas zuerst nicht funktionierte, steht auch das.

  1. 1Tag 1 — Dein Scope steht

    Was entstand
    Eine Spec mit dem Kernloop, fünf Nicht-Zielen und der ausdrücklichen Festlegung auf den internen Testkanal statt auf den Store.
    Warum so
    Das Release-Ziel wurde bewusst auf „interner Testkanal“ heruntergezogen. Zwischen einem laufenden Gerätebuild und einer öffentlichen Store-Version liegen Entwicklerkonto, Signierung und ein Review, dessen Dauer niemand steuert. Als Sieben-Tage-Ziel wäre die Store-Version ein Versprechen über eine fremde Warteschlange gewesen.

  2. 2Tag 2 — Ein echter Build läuft

    Was entstand
    Ein Projekt, das auf einem echten iPhone startet, mit zwei Bildschirmen und lokalem Datenmodell.
    Warum so
    Das Entwicklerkonto und die Signierung wurden an Tag 2 erledigt, nicht an Tag 6. Beides sind Wartezeiten, die man nicht abkürzen kann — sie an den Anfang zu ziehen kostet nichts und rettet den Release-Tag.
    Was zuerst nicht klappte
    Der erste Build lief im Simulator einwandfrei und ließ sich auf dem Gerät nicht installieren. Ursache war das noch nicht eingerichtete Bereitstellungsprofil — genau der Schritt, der ohne Tag-2-Entscheidung erst am Tag 6 aufgefallen wäre.

  3. 3Tag 3 — Dein Kernloop funktioniert

    Was entstand
    Der vollständige Abfrageablauf: Karte sehen, umdrehen, bewerten, nächste Karte — und ein sichtbar schrumpfender Stapel.
    Warum so
    Der Stapel zeigt von Anfang an, wie viele Karten noch kommen. Ohne diese Zahl fühlt sich das Abfragen endlos an, und der Nutzer bricht ab, ohne dass irgendetwas kaputt wäre.

  4. 4Tag 4 — Deine App hält auch schlechte Tage aus

    Was entstand
    Leerer Stapel mit Einstieg zum Anlegen, durchgearbeiteter Stapel mit Ergebnis, Wiedereinstieg mitten im Stapel und geprüfte Textskalierung auf der größten Stufe.
    Warum so
    Der Offline-Fall brauchte keine eigene Arbeit, weil die App nie ein Netz benutzt. Das wurde trotzdem geprüft und notiert — eine Annahme, die man nicht testet, ist keine Eigenschaft, sondern eine Hoffnung.

  5. 5Tag 5 — Betrieb, Recht und Kosten stehen

    Was entstand
    Datenschutzerklärung, Support-Weg, App-Icon, Startbild und die Angaben zur Datenverwendung für den Testkanal.
    Warum so
    Die Datenschutzangabe lautet „keine Datenerhebung“, und das stimmt nachweislich, weil die App keinen Netzwerkzugriff hat. Diese Angabe wurde gegen den tatsächlichen Code geprüft und nicht aus dem Gedächtnis ausgefüllt — eine falsche Angabe an dieser Stelle ist ein Ablehnungsgrund.

  6. 6Tag 6 — Ein echter Release-Kandidat

    Was entstand
    Ein signierter Build im internen Testkanal, getestet auf zwei Geräten mit zwei Betriebssystemversionen, dazu Notizen für Prüfende.
    Warum so
    Getestet wurde auf einem aktuellen und einem vier Jahre alten Gerät. Der Abstand ist der Punkt: Zwei benachbarte Versionen verhalten sich fast gleich und beweisen wenig.
    Was zuerst nicht klappte
    Auf dem älteren Gerät war die Umdrehen-Animation so langsam, dass sie wie ein Hänger wirkte. Statt sie zu optimieren wurde sie deutlich verkürzt — die Karte muss sich umdrehen, sie muss nicht schön umdrehen.

  7. 7Tag 7 — Deine Entscheidung ist belegt

    Was entstand
    Ein Protokoll mit allen Release-Gates und eine V1.1-Liste, angeführt vom Wiederholungsalgorithmus.
    Warum so
    Nicht eingereicht — das war von Tag 1 an das Ziel. Der Testkanal ist erreicht, der Kernloop läuft auf echter Hardware, und die Entscheidung über den Store fällt bewusst nach den ersten echten Rückmeldungen statt aus dem Wunsch heraus, fertig zu sein.

Mitnehmen und remixen

Der Remix übernimmt Idee, Kernloop, Nicht-Ziele und Release-Ziel als deinen Ausgangspunkt — nicht die Lösung. Die sieben Bautage bleiben identisch, du überspringst keinen Schritt und kein Prüfkriterium.

Auftrag für dein KI-Werkzeug

Wenn du lieber sofort loslegst, statt über den Pfad zu gehen: Dieser Auftrag beschreibt das Projekt vollständig genug, dass ein KI-Werkzeug damit anfangen kann.

Ich baue eine kleine iOS-App: Vokabelkarten — eigene Karten anlegen und offline abfragen.

Kernloop in vier Schritten:
1. Öffnen — der aktuelle Stapel steht bereit
2. Eine Karte abfragen — Wort sehen, raten, umdrehen
3. Ergebnis geben — gewusst oder nicht gewusst
4. Weitermachen — nächste Karte, der Stapel schrumpft

Ausdrücklich NICHT in Version 1: Konto und Geräte-Synchronisierung, mitgelieferte Wortlisten, Lernalgorithmus mit Wiederholungsintervallen, Audioaussprache, Import aus Tabellen.

Release-Ziel: signierter Build im internen Testkanal, nicht die öffentliche Store-Version. Die App arbeitet vollständig offline.

Hilf mir, damit anzufangen:
1. Stelle mir Rückfragen zu allem, was du für den ersten Schritt wissen musst.
2. Schlage die kleinste Datenstruktur vor, die diesen Kernloop trägt.
3. Nenne mir die Schritte für Entwicklerkonto und Signierung, die ich am besten sofort erledige statt kurz vor dem Release.

Ändere den Scope nicht, ohne mich zu fragen.