Skip to content
Creaitercreate your vision with ai
Sign inRegister
All example projects

iOS app

Vocabulary cards

Create your own cards and drill them offline

An iOS app for creating your own vocabulary cards and drilling them with no network — on the train, in a waiting room, on a plane.

Worked teaching examples: these three projects were written for the course along the documented seven-day rules. They are not real user projects, there is no running app, no live link and no store listing. The evidence here is the decisions, not a screenshot.

What it was built for

Existing vocabulary apps bring foreign word lists and require an account. Anyone studying for a specific exam or trip wants their own thirty words — and wants them where there is no network. The app does exactly that and nothing beyond it.

The core loop in four steps

  1. 1Open — the current deck is ready
  2. 2Drill a card — see the word, guess, flip
  3. 3Give the result — knew it or did not
  4. 4Carry on — the next card comes, the deck shrinks

Deliberately left out

Shrinking the scope is the real work of day 1. These points would have made the project bigger without making the core loop better.

  • No account and no sync between devices — that requires a server, a sign-in and an answer to what happens on conflicts.
  • No bundled word lists — they raise licensing and quality questions and do not solve the problem of your own thirty words.
  • No spaced-repetition algorithm — it is the actual appeal of such apps, but without a working basic flow it is worthless. It is on the V1.1 list.
  • No audio pronunciation — it needs either recordings or a paid service, and with it a cost limit.
  • No import from spreadsheets or other apps — convenient, but it does not make drilling better.

Release goal

Internal test channel with a signed build. A public store version was explicitly not the goal of these seven days.

The seven build days

For each day you see separately what was visible afterwards and what decision sat behind it. Where something did not work at first, that is here too.

  1. 1Day 1 — Your scope is set

    What was built
    A spec with the core loop, five non-goals and the explicit commitment to the internal test channel instead of the store.
    Why this way
    The release goal was deliberately pulled down to "internal test channel". Between a running device build and a public store version sit a developer account, signing and a review whose duration nobody controls. As a seven-day goal, the store version would have been a promise about someone else's queue.

  2. 2Day 2 — A real build runs

    What was built
    A project that starts on a real iPhone, with two screens and a local data model.
    Why this way
    The developer account and signing were handled on day 2, not on day 6. Both are waiting times you cannot shorten — pulling them to the front costs nothing and saves release day.
    What did not work at first
    The first build ran flawlessly in the simulator and would not install on the device. The cause was the provisioning profile that had not been set up — exactly the step that, without the day-2 decision, would have surfaced only on day 6.

  3. 3Day 3 — Your core loop works

    What was built
    The complete drill flow: see card, flip, rate, next card — and a visibly shrinking deck.
    Why this way
    The deck shows from the start how many cards are left. Without that number drilling feels endless and the user quits without anything actually being broken.

  4. 4Day 4 — Your app survives bad days too

    What was built
    Empty deck with a way to create cards, finished deck with a result, return mid-deck, and text scaling checked at the largest step.
    Why this way
    The offline case needed no work because the app never uses a network. It was still tested and noted — an assumption you do not test is not a property, it is a hope.

  5. 5Day 5 — Operations, legal and cost limits are set

    What was built
    Privacy policy, support route, app icon, launch image and the data-use declarations for the test channel.
    Why this way
    The privacy declaration says "no data collection", and that is demonstrably true because the app has no network access. This declaration was checked against the actual code rather than filled in from memory — a false statement here is a rejection reason.

  6. 6Day 6 — A real release candidate

    What was built
    A signed build in the internal test channel, tested on two devices with two operating system versions, plus notes for reviewers.
    Why this way
    Testing used a current and a four-year-old device. The distance is the point: two neighbouring versions behave almost identically and prove little.
    What did not work at first
    On the older device the flip animation was so slow it read as a hang. Rather than optimising it, it was shortened considerably — the card has to flip, it does not have to flip beautifully.

  7. 7Day 7 — Your decision is documented

    What was built
    A record with all release gates and a V1.1 list headed by the repetition algorithm.
    Why this way
    Not submitted — that was the goal from day 1. The test channel is reached, the core loop runs on real hardware, and the decision about the store falls deliberately after the first real feedback rather than out of a wish to be finished.

Take it and remix it

The remix takes the idea, core loop, non-goals and release goal as your starting point — not the solution. The seven build days stay identical; you skip no step and no check.

Prompt for your AI tool

If you would rather start right away instead of going through the path: this prompt describes the project completely enough for an AI tool to begin.

I am building a small iOS app: Vocabulary cards — create my own cards and drill them offline.

Core loop in four steps:
1. Open — the current deck is ready
2. Drill a card — see the word, guess, flip
3. Give the result — knew it or did not
4. Carry on — next card, the deck shrinks

Explicitly NOT in version 1: account and device sync, bundled word lists, spaced-repetition algorithm, audio pronunciation, import from spreadsheets.

Release goal: signed build in the internal test channel, not the public store version. The app works entirely offline.

Help me get started:
1. Ask me about anything you need to know for the first step.
2. Propose the smallest data structure that carries this core loop.
3. Name the developer-account and signing steps I should do right away instead of shortly before release.

Do not change the scope without asking me.