Generated Mobile Clients Join the Backend
Historical note: This article documents an earlier TeaQL generation target. Early versions emitted backend templates, UI pages, mobile clients, and service scaffolding directly into application workspaces. Modern TeaQL has moved to a clearer boundary: generation produces versioned libraries, deterministic business APIs, query DSLs, and runtime capabilities that applications consume as artifacts. This is more friendly to AI-assisted coding and DevOps because AI agents can focus on business workflows, integrations, tests, and product behavior, while generated capabilities are reviewed, tested, published, upgraded, and rolled back through normal dependency and release pipelines.
After the Java backend templates stabilized, the generator began producing client-side code.
The code diff shows new Android framework templates, Swift POJO templates, SwiftyJSON mapping helpers, remote manager templates, and sample HTTP request generation. This was not just adding another output language. It changed the generator from a backend scaffold into a multi-target system.
Android Application Skeleton
The Android templates introduced generated application structure:
- activity framework files
- entry page fragments
- manifest templates
- generated string resources
- menu and naming convention helpers
The generated Android app did not need every screen to be handwritten. The same domain model could drive initial navigation, labels, and object entry pages.
Swift Object Generation
Swift support added another important boundary: generated domain objects could exist outside Java.
The Swift templates produced:
- struct-based model objects
- custom string conversion
- JSON object mapping
- reference-list handling
- nil-safe member access
That forced the metadata layer to become less Java-specific. Field names, reference names, and type mapping had to work across languages.
Remote Manager Pattern
The remote manager templates connected mobile clients back to generated backend services.
Instead of treating the mobile app as a separate hand-coded consumer, the generator began producing both sides of the contract: server manager methods and client access code. That reduced drift between API shape and client expectations.
Why This Stage Mattered
The practical feature was mobile scaffolding. The architectural feature was bigger: one domain model could emit multiple runtime surfaces.
That idea later became essential for generating backend APIs, admin UI, mini-program code, search DSLs, and typed query APIs from the same model vocabulary.