Deterministic by Design: Building an Offline-First Verb Practice Engine in SwiftUI

North Growth Lab — Tue, 25 Aug 2026 10:05:06 +0000

Language-learning apps look simple from the outside: a search field, a conjugation table, a speaker button and a quiz. The difficult part is keeping those surfaces consistent when every supported language has different grammar, data quality and release constraints.

We ran into that problem while building NGL Verb Lab, a native SwiftUI product for verb lookup and active practice. The current release core covers English, French, Spanish and German. It contains 1,150 reviewed verbs across the four languages, while larger dictionaries remain build-time inputs rather than automatically becoming user-facing content.

This article focuses on the architecture choices behind that boundary: a reusable core package, deterministic practice sessions, local-first product state and fail-closed translation packs.

1. Keep the learning engine outside the app shell

The first decision was to separate reusable language behavior from SwiftUI screens. VerbLabCore owns verb records, catalog lookup, search and practice-question generation. The app target owns navigation, views, speech, purchases and local preferences.

That split matters for three reasons:

Core behavior can be tested without launching a simulator.
UI experiments cannot silently change grammar or answer generation.
Build-time content tools can use the same models as the application.

The package currently targets iOS 17+ and macOS 14+, which lets core tests run quickly on macOS while the product remains a native iPhone application.

2. Treat source dictionaries as inputs, not as the product

A large dictionary is not automatically a trustworthy learning catalog. Source datasets can contain duplicate lemmas, fragments, uncommon long-tail entries, inconsistent glosses and forms that are technically valid but wrong for a first release.

Our runtime boundary is therefore smaller than the authoring boundary:

French: 300 reviewed release-core verbs
English: 250 reviewed release-core verbs
Spanish: 300 reviewed release-core verbs
German: 300 reviewed release-core verbs

The order is frequency-informed, with explicit safeguards for essential everyday vocabulary. Automated audits check for duplicate lemmas, invalid language identifiers, missing definitions, empty examples, malformed forms and accidental leakage from authoring-only data.

This is intentionally conservative. Expanding a catalog is easy; defending every row presented to a learner is harder.

3. Search the form a learner actually saw

Learners frequently encounter a conjugated form before they know its infinitive. Searching only by lemma would make the product fail at the exact moment it should be useful.

The search layer therefore normalizes accents and searches both infinitives and known forms. Results are then ranked by a combination of signals:

exact conjugated-form match;
infinitive prefix match;
frequency rank.

Pronominal forms need additional handling. A query such as a French reflexive form should not be reduced to a naïve substring match; reflexive markers and the base lemma have to be considered together. The product also represents dual-auxiliary cases where meaning or transitivity changes the correct compound form.

The useful design principle is broader than language apps: normalize input aggressively, but rank results using domain knowledge.

4. Generate daily practice deterministically

The app creates a ten-question daily session from the same conjugation records used by search and reference screens. We wanted the session to be stable during a day, change on the next day and remain fully testable.

Instead of relying on global randomness, the engine derives a seed from the start of the current day. A round number changes the sequence for an additional session. Position-specific offsets select the verb, tense and form.

let startOfDay = calendar.startOfDay(for: date)
let daySeed = calendar.dateComponents(
    [.day],
    from: Date(timeIntervalSince1970: 0),
    to: startOfDay
).day ?? 0

let verbIndex = positiveModulo(
    daySeed + roundSeed + position * 7,
    verbs.count
)

Each language supplies its own preferred learning tenses. If the preferred set is unavailable for a particular record, the engine falls back to non-empty conjugations rather than manufacturing an answer.

Distractors first come from other persons in the same tense. If that does not produce three unique choices, the engine looks for the same mood, tense and subject in other verbs. The correct answer is inserted at a deterministic position.

This gives us repeatable tests without making the learner see the same static quiz forever.

5. Keep core use available offline

Verb lookup, conjugation data, favorites, pronunciation controls and daily progress should not require an account or a network round trip.

The product therefore bundles the release catalogs and stores lightweight state locally. Favorites, language choice, practice accuracy and streak data remain available without authentication. Apple’s AVSpeechSynthesizer provides language-specific system voices for infinitives, examples and displayed forms, with slow and natural playback speeds.

Offline-first does not mean “no services will ever exist.” It means the core learning job still works when the network, an API or a subscription backend does not.

6. Make paid translation content fail closed

Cross-language explanation packs add a different risk: a pack can exist as a file while still being incomplete or unreviewed.

For release builds, the translation store accepts only packs marked as reviewed. It validates key coverage and checks a SHA-256 digest against the bundled content. Packs are cached in memory after validation. Debug builds may expose machine-generated material for QA, but that state cannot silently qualify as paid release content.

That distinction is important. Automated checks can detect missing keys, wrong scripts and placeholders. They cannot certify that grammar guidance is pedagogically correct.

7. Test invariants, not screenshots

The highest-value tests protect rules that should remain true as UI changes:

every release-core lemma is unique inside its language;
search returns infinitive and conjugated-form matches in a useful order;
practice questions have one correct answer and unique distractors;
forms and language identifiers are valid;
authoring-only entries cannot leak into the runtime catalog;
release translation packs satisfy their review and digest contract.

UI tests still matter, but they are not the right first defense for data integrity.

What we would preserve in the next product

The most reusable lesson is not a particular SwiftUI view or data format. It is the set of boundaries:

authoring data versus reviewed runtime data;
pure learning logic versus the app shell;
deterministic generation versus global randomness;
offline core behavior versus optional services;
automated validation versus human language review.

Those boundaries make the product easier to test today and safer to expand later with recorded audio, cloud sync or additional reviewed language packs.

NGL Verb Lab is still in development, so we are not claiming App Store adoption or learning outcomes. We are using the build as first-party evidence of how we approach native iOS architecture, content QA and product constraints.

If you are planning a native iPhone product, North Growth Lab documents its iOS app development approach.

DEV Community: North Growth Lab