Native Mobile and AI - droidcon USA 2026

AI is doing a lot to software development generally, but mobile is a special case for one reason: two apps do the same thing. The whole talk works out from there — what that means for silos, for cross-platform, for KMP, and for what my team is building.

Chapter links jump into the video.

Where agentic coding actually is

• 0:00 — Intro — Who I am and what Ntive Labs is, announced the day before this talk. Previously Touchlab, doing native mobile since 2011 and deep in Kotlin Multiplatform through late 2024.
• 0:56 — Not everyone is on the same page — Some devs use AI constantly, some are in the middle, some refuse. I’m not selling you on it, just pointing out that it’s here.
• 1:19 — Why mobile is unique — Two apps do the same thing. That’s the conceit the rest of the talk hangs on.
• 1:43 — The last year — Coding agents largely ignored mobile a year ago; we have our own IDEs and fairly bespoke languages, so we weren’t first. They’ve arrived, and they do things that weren’t straightforward even six months ago. I barely touch code now, and someone still has to know what they’re doing.
• 2:51 — How far has it come? — I asked Claude to chart this, and left the slides unedited. The starting gun was Sonnet 3.5 in October 2024 — less than two years ago.
• 4:09 — Benchmarks, with salt — Matching benchmark numbers doesn’t mean matching behavior. Drop a model into a real harness and it can fall over immediately. Public benchmarks also get trained on.
• 4:39 — The metric that matters — How long can an agent run and still do good work? With Sonnet 3.7, “let me take an alternative approach” was your cue to kill it, because it was about to delete what it couldn’t figure out and solve something simpler. That mostly doesn’t happen now.
• 6:37 — Bun to Rust — Anthropic converting Bun’s Zig to Rust, automated. That sounds wild until you’ve done a large port yourself: it’s logic, with a big test suite.
• 7:12 — From hype machines to work machines — Claude volunteered all the caveats about its own numbers without being asked. The models got much less breathless.
• 7:30 — Peak hype — Token maxing, agent-count maxing, vibe coding as a side hustle, Slack-only workflows, the one-person billion-dollar company. Tech always has hype; this is something else.
• 9:00 — Meanwhile, the quiet work — The people getting real work done are quietly figuring out the tools. I use a terminal — IDE integration is still a chat window bolted on. The integrations built for developers are still coming.

General vs. mobile

• 9:46 — English to code — General AI coding is making code from natural language. How well it works depends on how well your project is configured and how well the model can guess at what you didn’t specify.
• 10:16 — Spec-driven development — Some of the specs I saw were so detailed you should have just written the code. Code is a precise, complete spec for a machine. That approach has softened as models stabilized and teams got better at verifying AI output.
• 12:14 — The first platform is the spec — This is the critical concept. However you build the feature the first time, that code is the spec for the second platform.
• 12:49 — LLMs are excellent translators — The pushback is that it’ll all be slop. I can’t settle that with a code slide — you can only see it through experimentation on a project that’s set up well.
• 13:24 — Six weeks, then one week — Early last year: 100k lines of not-well-structured iOS code, off-the-shelf Sonnet 3.7-era tools, about six weeks of handholding against a six-month estimate. Recently: a similar-sized app, about a week, just me, no hand-written code until some UI tweaks at the end, using multimodal image comparison to close the gaps.
• 14:53 — Not just me — Google I/O announced an Android migration assistant. Different function, but the concept is clearly gaining traction.

What it implies

• 15:26 — AI reduces the need for specialists — Almost all my code right now is TypeScript, a language I still don’t like and would fail a whiteboard test on. You may not write Swift to an iOS team’s standard, but you can read it — and reading and reviewing is a different job than writing.
• 16:35 — Breaking the silos — Eighteen years of calls to break the silos, and most teams above a certain size still have them. The people calling for it misunderstood why they existed: specialists exist in every field for a reason.
• 17:12 — Then who picks cross-platform? — If you can build native apps for a similar effort to React Native or Flutter, who chooses not to? Most users and product people would prefer native.
• 17:52 — “React Native is an elegant solution to an old problem” — A design partner’s line, from a team moving off React Native to native. Anecdotally, though, the traffic runs in both directions.
• 18:34 — Am I sure? No. — I thought KMP was going to be huge almost immediately, so my track record on predictions is what it is. Investors who expect AI to upend society within months often can’t picture anyone choosing native over React Native.

What about KMP?

Thoughts, not predictions — and the first time I’d said any of this publicly.

• 19:35 — Setting up the KMP question — This section also frames the broader point about specialists, so it runs longer than I planned.
• 20:23 — The bad news — KMP was a tough sell before AI. It wasn’t scaling past a shared library for big teams or a screen for small ones. Teams chose to duplicate code by hand before AI; if AI can just translate it, that doesn’t make the pitch easier.
• 21:17 — The good news — KMP struggled for people reasons, not just Swift interop. The community focused on “if we had X, iOS devs would love this.” Then X shipped, and the situation didn’t change.
• 22:14 — Ten and ten — A manager hired ten Android and ten iOS devs for a greenfield KMP app, planning for the specialists to become generalists. The iOS devs struggled with Kotlin. The Android devs’ Swift PRs drew so many comments that they quietly went back to writing Kotlin.
• 23:45 — Why this is the KMP question — KMP to the screen needs generalists, or a serious change to how the team collaborates. Most teams won’t do either. If AI dissolves the specialist problem, that’s a huge obstacle gone.
• 24:08 — Swift-friendly wrappers — SKIE is great and you should use it, and Swift export is in progress. But Kotlin isn’t Swift, and no deterministic tool gets you all the way there. If agentic coding were where it is today back in 2022, I doubt we’d have built SKIE.
• 25:06 — Translating is cheap, not free — Not tokens — weight. Two sets of code is still two sets of code and more risk, and code you didn’t translate needs no verification of the translation. That’s a real argument in KMP’s favor.
• 25:42 — So what do I think? — I like KMP and I hope it takes off. But “why use KMP if I can just port Kotlin to Swift” is an easy throwaway line, and I haven’t seen much of the counter-pitch. All great ideas need to be sold.
• 26:44 — Or why not just Rust? — If AI writes good wrappers and lets you work in languages you don’t know well, the shared-library argument gets asked in the other direction too.

Practical tips

• 27:01 — General AI tips — A real getting-started guide would be a class series, so these are the principles I give devs who aren’t getting on with it.
• 27:20 — Context is critical — It’s the wiki for your AI. Wasted tokens, repeated explanations, dumb work — that’s your context. A single agent file is almost certainly not enough for a real codebase.
• 27:46 — The consultant you have for an hour — Every team wiki I’ve been onboarded with was incomplete and stale. Do you want the model spending its first half hour reverse-engineering your mess, or do you just tell it?
• 28:34 — Don’t trust context management plugins — If it were easy, it would already be built in. Automate what you can, but treat this as chores. Worse than no context is wrong context — then you’re lying to the model.
• 29:02 — Agent fundamentals — Every message and tool call lives in the context window. Most models advertise 1M; I don’t go past 300–400k, whatever the model or the marketing says. Compacting is a nice name for forgetting — use phased plans and subagents instead.
• 29:50 — Mobile-specific translation context — Don’t spend context telling a model what it already knows, but do explain how your DI, concurrency, and specific libraries should map across platforms.
• 30:43 — It’s a new skill — It feels like something you learn in an afternoon, until you point it at your real project. After my first month I thought I was great at it. I wasn’t.

What we’re building

• 31:06 — The port tool, and the real problem — We built something that ports a large production app in one long run. Then we realized the harder, more valuable problem is keeping the two apps in sync afterward. That became Parive, announced the day before this talk.
• 31:54 — Why not just ask Claude? — Because you need precise, repeatable analysis that approaches deterministic, normalized across both apps. To a user it’s screens and features; in code it’s a pile of views that differ per platform.
• 32:28 — What you actually get — An army of agents questioning each other produces a feature list, what differs between platforms and how badly, git history explaining how you got there, then an editable plan you can hand to a coding agent and ship as a PR.
• 33:16 — No assumptions about your workflow — Run it in our agent or assign it to a dev and open Claude Code. Manage your work wherever you already manage it. Nobody wants lock-in.
• 33:47 — Public preview — Run against the open-source Wikipedia apps, with a public preview on the site.
• 34:16 — Live demo — Feature comparisons, significance, git investigation, the plan view with its edit history, and execution. Also some advice: check what’s on your screen before you plug in your laptop.
• 38:11 — Looking for design partners — If you have a pair of apps you’d like this analysis run on, we’d like to talk. We’re not selling it yet — we’re finding out whether there’s a product here.