The implementation becomes much less simple when the same product must handle irregular forms, different grammatical systems, offline use, deterministic practice, source attribution, and a UI that remains fast as the catalog grows.

We encountered those constraints while building Verb Lab, a native iOS product at North Growth Lab. This article is not a launch announcement or a claim about learning outcomes. It is a practical account of the architecture decisions that made the current prototype testable and maintainable.

1. Treat linguistic content as product data, not view copy

Our first useful boundary was between authoring data and runtime data.

Large dictionaries, frequency sources, generated inflections, and translation candidates belong in the build pipeline. They are useful inputs, but they should not automatically become user-facing content. The app bundles only reviewed release-core records with the fields the runtime actually needs: lemma, language, definition, examples, moods, tenses, subjects, forms, and spoken text.

That decision creates two different systems:

• an authoring pipeline that imports, normalizes, audits, and exports content;
• a runtime catalog that is small enough to load predictably and strict enough to test exhaustively.

This is more work than dropping a large JSON file into the application bundle. It also prevents a common failure mode: the interface quietly becoming the quality-control layer for unreviewed data.

2. Keep the learning engine independent of SwiftUI

The domain model and practice generator live in a separate Swift package. SwiftUI views consume the results, but they do not decide which tense to test, how distractors are selected, or how a language record is interpreted.

Conceptually, the dependency direction is:

versioned content -> domain model -> practice/search services -> SwiftUI views

The UI never needs to know where a conjugation record came from. The practice engine never needs to know whether the answer will be displayed in a list, a card, or a future widget.

This boundary gave us three immediate benefits:

1. Core behavior can be tested with swift test without launching a simulator.
2. Content-validation tools can reuse the same domain assumptions as the app.
3. UI redesigns do not require a rewrite of the learning logic.

For a content-heavy product, this separation is not academic architecture. It is what makes iteration affordable.

3. Make daily practice deterministic

Random quizzes are easy to generate and surprisingly difficult to debug. If a question is malformed only for one combination of verb, tense, and subject, a fully random session may be impossible to reproduce.

Verb Lab derives a daily seed from the calendar day. The engine then uses stable offsets to choose a verb, a preferred conjugation, a form, and distractors. A new practice round adds another deterministic offset.

The simplified pattern looks like this:

let daySeed = daysSinceEpoch(startOfDay)
let verbIndex = positiveModulo(daySeed + position * 7, verbs.count)
let tenseIndex = positiveModulo(daySeed + position * 3, tenses.count)
let formIndex = positiveModulo(daySeed + position * 5, forms.count)

The exact multipliers are less important than the property they create: the same date, catalog, and round produce the same session.

That makes a bug report reproducible. It also gives a learner a coherent daily set without requiring an account, remote scheduler, or server-generated session.

4. Preserve language differences inside a shared model

English, French, German, and Spanish do not fit one universal tense list. A shared interface should not erase those differences.

We use one general verb model, but the practice engine selects preferred mood-and-tense pairs by language. If a preferred group is unavailable, it falls back to valid conjugations already present in that verb record.

This is a useful middle ground:

• the application does not duplicate its entire architecture for every language;
• the domain layer still represents language-specific moods, auxiliaries, subjects, and compound forms;
• the view renders the data it receives instead of pretending every grammar system has the same shape.

Shared code is valuable only when it preserves the distinctions the product exists to teach.

5. Build an offline-first core before adding accounts

Search, favorites, practice, progress, and pronunciation do not require a network request in the current core experience.

The reviewed catalogs ship with the application. Favorites and practice statistics use local storage. Progress is small and explicit: total answers, correct answers, completed sessions, the last completion date, and current and best streaks.

This reduced the first-release surface area significantly. We did not need to introduce authentication, synchronization conflicts, an availability dependency, or a privacy-sensitive analytics identity just to prove the core interaction.

Offline-first does not mean cloud features are forbidden. It means the product remains useful when the cloud is absent. Sync can be added later if it solves a demonstrated cross-device problem.

6. Isolate native speech behind a service

Pronunciation is part of the learning loop, so the app uses Apple's AVSpeechSynthesizer with language-specific voices.

Speech has its own state and lifecycle: the current phrase, selected rate, playback status, cancellation, and delegate callbacks. Keeping that behavior in a service prevents each view from becoming a collection of audio edge cases.

The views ask for an utterance. The service decides how to stop the previous phrase, select the voice, configure the rate, and publish playback state.

This also leaves a clean upgrade path. Recorded native-speaker audio or speech scoring could be introduced behind the same product boundary without rewriting every conjugation row.

7. Test the content as aggressively as the code

In a language product, a valid build can still ship broken content.

Our checks cover both software behavior and release data. The current active release cores contain 1,150 reviewed verb records, and tests audit properties such as duplicate lemmas, invalid language identifiers, empty or malformed forms, translation-key coverage, and accidental exposure of authoring-only entries.

The build pipeline also keeps source attribution and linguistic-resource licences with the project. Content provenance is an architectural requirement, not a paragraph to reconstruct immediately before release.

A practical release gate for this kind of product should answer four questions:

1. Can the parser load every bundled record?
2. Can search and practice use every released record safely?
3. Can we explain where the underlying data came from and how it may be used?
4. Has reviewed content remained separate from generated or experimental material?

8. Keep commercial state outside the learning engine

The prototype includes a StoreKit 2 subscription flow for testing entitlement, restoration, and localized pricing behavior. The learning engine does not depend directly on StoreKit.

Instead, entitlement controls which reviewed content or explanation paths may be requested. That prevents transaction logic from leaking into verb models and practice questions.

It also makes local testing safer: a bundled StoreKit configuration can exercise monthly, annual, restore, and management flows without charging a real account.

What we would measure after launch

Architecture can prove that a product is testable. It cannot prove that the product is valuable.

The next evidence should come from actual use:

• how quickly learners find the form they searched for;
• whether a lookup becomes a completed practice session;
• which language pairs fail because content is incomplete or unclear;
• whether people return for repeated practice;
• which speech and explanation controls are used at the moment of confusion.

Until those signals exist, we avoid claiming retention, adoption, or learning improvement.

A reusable checklist for content-heavy mobile apps

If you are designing a similar product, ask:

• Is authoring data separated from reviewed runtime data?
• Can the domain and business logic run without the UI framework?
• Can a reported session or generated result be reproduced?
• Does shared code preserve real domain differences?
• Which workflows genuinely need an account or network request?
• Are device capabilities isolated behind services?
• Are content quality, provenance, and licences part of the release gate?
• Can payment and entitlement change without contaminating the core model?

Those boundaries matter more than the number of screens in the first prototype.

You can explore the interactive product preview and the evidence behind the build in the North Growth Lab portfolio.

Disclosure: Verb Lab is a North Growth Lab product in development. The architecture and capabilities described here are implemented in the current prototype. This article does not claim App Store availability, adoption, retention, or learning outcomes.