Guide · for product people who want the craft layer

    Build an interactive mobile app with AI: the Duolingo-shaped ambition

    Have you ever looked at an app like Duolingo — the hopping characters, the streak flames, the progress path that feels like a board game — and thought: my product deserves that layer of craft? Then discovered that layer is why they employ game engineers? Here is the 2026 version of that story: the engine behind it is a 2D game engine, an AI agent can drive it, and the specification skills you already have are the input it runs on.

    Start with why this layer has been out of reach. A standard app — screens, lists, forms — is built with UI frameworks, and one team builds it. The interactive layer is different material: things that move with physics, react to touch mid-motion, animate characters, celebrate. That material is built with game technology, which is why gamified products traditionally need two kinds of engineers — and why most product teams, lacking the second kind, settle for a confetti library and call it gamification.

    The unlock is understanding what the layer actually is: gamification is a game engine wearing app clothes. The streak celebration, the hopping mascot, the level path — mechanically, those are 2D game scenes: sprites at coordinates, animated per frame, responding to touch. The same engine that powers full 2D games powers the interactive moments inside serious apps — and that engine on iOS is SpriteKit, Apple's own 2D framework, shipping inside every iPhone.

    Which reframes the question from "how do we hire game engineers?" to "how do we drive that engine?" — and driving engines is exactly what AI agents became good at this year.

    The architecture: an app with game-engine moments

    The pattern our docs recommend deserves to be stated plainly, because it is the whole trick: you do not build a game — you build a normal native app and add game-engine scenes where the craft belongs. The app's chrome — navigation, settings, lists, auth — stays regular SwiftUI, boring in the best way. The moments that should feel alive — the practice loop, the progress map, the celebration — are SpriteKit scenes embedded exactly there, and nowhere else.

    In Modaal this is a template decision with an escape hatch, per the docs: interaction-first products start from the "2D game / Interactive app" template, which scaffolds the machinery games need (an artwork pipeline that turns PNGs into game-ready graphics, pooled sound, layouts that survive rotation, tests passing from first build) — while a conventional app that might grow interactive moments starts from the Production template and adds SpriteKit later. Either way, interactive screens are built as reusable components alongside your regular ones — one codebase, one project, both materials.

    That composability is what kills the two-team problem: the agent writes both the SwiftUI and the SpriteKit, in one Swift project you own, and your job is what it always was — deciding what deserves the craft.

    What the layer is made of — a PM's parts list

    Concretely, the interactive layer decomposes into five mechanics, all buildable by description (the sample your project starts from — splash, menu, a tap-the-target game with scoring and sound, settings that remember volume — already contains most of them in miniature):

    Progress made physical. Not a percentage bar — a path, a map, a tower that grows. The user's history as a place they can see.

    Feedback with body. Taps that bounce, cards that snap, streaks that ignite — responses with weight and timing, which is precisely what a scene-graph engine does per-frame that a UI framework fights you on.

    Character moments. A mascot that reacts — the highest-craft, highest-affection mechanic, and the one that most obviously needs game technology.

    The practice loop. The Duolingo-shaped core: a repeatable, escalating exercise with lives, timing, and score. Our docs' own example prompt is exactly this shape: "Arithmetic practice game: character hops between numbered blocks to answer sums. Hearts for lives, timer, persistent star score." Swap arithmetic for your domain — vocabulary, compliance training, sales onboarding — and that sentence is your feature.

    Celebration. The earned moment — level complete, streak saved — where motion and sound spend the emotional budget the quiet screens saved up.

    How a PM specifies gamification — mechanics, not vibes

    Here is where your existing skills become the engine's steering wheel. "Make it more engaging" produces confetti; a specified mechanic produces Duolingo-class craft. In the spec-driven workflow, a gamified feature's mini-spec answers four questions a game designer would recognise and a PM can absolutely write:

    Trigger — what user action starts the moment? (Completes a lesson; logs a workout; hits day 7.) Feedback — what does the screen do, physically? ("The streak counter ignites and the mascot jumps" — write the verb, the agent writes the frames.) Progression — what accumulates, and where does the user see it as a place? (Stars fill the level path; the tower gains a floor.) Failure & mercy — what do lives/hearts cost, and what does mercy look like? (Three hearts, one restored daily — mercy rules are where gamification becomes kind instead of coercive.)

    Write those four for one feature and you have specified an interactive experience the way the plan-reviewed workflow can build it — reviewed before code, iterated with unlimited prompts, in native Swift you own.

    The honest gate, PM to PM: gamification amplifies a loop; it cannot create one. If the underlying action isn't worth repeating, streaks make that discovery faster, not slower — validate the core loop first. And know the boundary: this is 2D craft — physics-heavy 3D worlds are a different discipline entirely. Within the boundary sits basically every gamified product you admire.

    Frequently asked questions

    The interactive layer that defines apps like Duolingo — animated progress, character moments, practice loops with lives and streaks — is 2D game-engine material, and AI agents now drive that engine from plain-language specs. In Modaal, the "2D game / Interactive app" template scaffolds the machinery and the agent builds SwiftUI screens and SpriteKit scenes in one native project. You specify mechanics (trigger, feedback, progression, mercy); it builds the frames.

    A regular app is screens, lists, and forms — UI-framework material. An interactive app adds moments built with game technology: elements that move with physics, react mid-touch, animate characters, celebrate progress. The practical architecture is both at once — regular app chrome with game-engine scenes embedded exactly where the craft pays.

    Historically yes — that was the two-team problem, and why most products settled for confetti. In 2026 an AI agent writes both the app screens and the game-engine scenes in one Swift project; the scarce input is the specification (which moments deserve craft, what triggers them, what accumulates), which is product-manager work, not engineering.

    SpriteKit — Apple’s own 2D scene-graph framework, shipping inside every iPhone: artwork placed at coordinates, animated per frame, hit-tested where drawn. It powers full 2D games and the gamified moments inside serious apps alike. Modaal builds on it with an open-source foundation, so the output is inspectable native Swift you own.

    When the core loop isn’t worth repeating yet — gamification amplifies a loop, it cannot create one, and streak mechanics on a weak loop just accelerate churn. Validate the underlying action first, then spend craft on the moments that reward genuine progress. Also outside scope: 3D and physics-heavy game worlds, which are a different discipline from 2D interactive craft.

    Start free. Ship native.

    One project, unlimited prompts. No card.

    Download for Mac

    Keep reading