Native Mobile and AI - Kevin Galligan, Filip Dolník | next app devCon 2026

Chapter markers and summaries on this page were generated by AI from the video transcript.

The Berlin version of my native mobile and AI talk, this time shared with Filip Dolník. The first half is mine: mobile is a special case because two apps do the same thing, so the first platform is the spec for the second. Shopify’s move from React Native back to native gets a section of its own. In the second half, Filip explains why analyzing two entire apps reliably is not something you can just ask a coding agent to do, and how our analysis engine uses code to orchestrate agents instead.

Chapter links jump into the video.

Intro

0:00 — Who we are — I’m co-founder and CTO of Ntive Labs, previously Touchlab, doing native mobile since forever and deep in Kotlin Multiplatform until the end of 2024. Filip is a founding engineer at Ntive Labs; at Touchlab he was a staff Kotlin developer on KMP developer experience and co-author of SKIE.
0:39 — Back in Berlin — My first Droidcon was Droidcon Berlin 2013. AI is going to dramatically impact development, and nowhere more so than mobile.
1:04 — Not everyone is on the same page — Some devs use AI a lot, most are in the middle, some say they never will. I’m not selling you on it, just describing where it is and how it’s going to affect mobile.
1:40 — Why mobile is unique — Two apps doing essentially the same thing with entirely different implementations. What that enables is the rest of the talk.

Where agentic coding actually is

1:57 — A narrow slice — This is about using AI to write code. Following the entire AI space would be a full-time job.
2:16 — AI has arrived on mobile — A year ago, agents had pretty much skipped mobile: we have our own IDEs, languages and culture. Now you can do things you couldn’t think about six to nine months ago. I barely touch code, and someone still needs to know what’s going on.
3:13 — How far has it come? — The start was Sonnet 3.5, about two years ago. The benchmarks moved to SWE-bench Pro because the old one stopped meaning anything. More important to me is how long agents can run without falling over. I run them overnight now.
4:22 — Benchmarks, with salt — Open models claim to be competitive and then fall over in an agent. Some open models are pretty good now, but the frontier models are still ahead.
4:42 — Bun to Rust — Anthropic taking Bun from Zig to Rust looks like hype if you haven’t translated code with AI. I’ve spent the last year and a half doing it. With full test coverage, it’s totally doable. It burns a lot of tokens.
5:16 — The industry is maturing — Token maxing turned into “we blew through our annual budget in Q1.” The extremes are still arguing, but institutional use of AI is maturing and growing.

General vs. mobile

5:48 — English to code — General AI coding turns English into code. How well that works depends on your project context and how well the model guesses at what you didn’t say.
6:11 — Spec-driven development — Everything I do with AI still starts with a design spec. But spec-driven development got to the point of describing everything in YAML, at which point you might as well write the code.
6:52 — The first platform is the spec — An iOS implementation gives you a complete, presumably correct view of what the Android version needs to do, edge cases and architecture included. Code is precise and complete. That’s the point of code.
7:27 — LLMs are excellent translators — They can translate between platforms and follow each platform’s best practice. To the “it’ll be slop” pushback: if your project is set up well, AI produces non-slop. You have to experiment to see it.
7:51 — Six weeks, then one week — Our first big port, over a year ago with Sonnet 3.7 and general tools, took six weeks of handholding and wrong turns, but it worked. A recent job of similar size, with our own tool, more experience and more review, took about a week.
8:40 — Not outlandish — Google I/O announced an Android migration assistant. The concept is gaining traction.
8:58 — Shopify and Coinbase — Shopify, all in on React Native since 2020, is moving everything to native and handing off its React Native open source projects. Coinbase said “us too,” with no details yet.

What it implies

9:26 — AI reduces the need for specialists — Most of my code is TypeScript, and I’d fail a TypeScript whiteboard test. That doesn’t mean I’m shipping bad code. You may not write Swift to your iOS team’s standard, but you can read what comes out, and AI writes good Swift.
10:10 — Breaking down the silos — Eighteen years of calls to break the silos, and most teams still have them. Native devs are specialists for the same reason as in any other field: staying proficient on both platforms takes more focus than most people can give.
10:43 — Then who picks cross-platform? — If you can build native apps for an effort close to React Native or Flutter, who chooses not to, and why? Shopify suggests it’s happening sooner than I expected.
11:20 — “React Native is an elegant solution to an old problem” — One of our design partners’ summary of my much longer explanation.
11:35 — Is it actually going to happen? — My tech predictions have a mixed record. Not everyone is going to drop React Native, but the tech is there now and the tooling is being built as we speak. The market will decide.

Practical tips

12:29 — General AI tips — A real how-to would be a whole class. These are the critical things if you’re running into problems.
12:46 — Context is critical — Wasted tokens, explaining things over and over, dumb work: that’s almost always your context. A single agent file is probably not enough.
13:04 — The consultant you have for an hour — Every team has an incomplete, stale wiki and someone who tells you not to use the architecture library a dev left behind three years ago. Whatever you don’t tell the model, it guesses at, and that’s where the weird stuff comes from. It reads well, so tell it once.
13:46 — Don’t trust context management plugins — If it were easy to manage automatically, it already would be. On the plane I told an agent not to run tests; it saved that to memory, and back at the hotel it still wouldn’t run them.
14:09 — Agent fundamentals — Every message and tool call lives in the context window. Most models have a million tokens; don’t get anywhere near it, or you get rot. Compacting is a short summary that doesn’t remember what you think it does. Use phased plans and subagents.
14:31 — It’s a new skill — It’s simple for a prototype and much less so after that. “If I have to, I’ll learn it in a week.” You will not.
14:54 — The workflow — Triage, design, adversarial review, implementation and tests, review, commit, with each step able to kick work back. That’s becoming standard.
15:23 — PR review will change too — The complaint that AI leaves humans reviewing everything is valid for now. But with UI validation and automated testing, you won’t need to look at every button radius change, just the parts that matter, like your transaction handling.

Shopify goes native

16:19 — Shopify — I’ve focused on AI for cross-platform native since early last year and seen almost nobody else talk about it. Then this dropped: native is now the future of mobile at Shopify, from Mustafa, their head of mobile. As a KMP person, I remember their 2020 React Native announcement as an oddly sad day.
17:25 — What the post says — Implement features on one platform using the other as a reference, which sounds a lot like the first platform is the spec. Help developers contribute outside their primary platform. Dramatically reduce the cost of maintaining parity.
18:00 — Parity with AI — Shopify talks about process to maintain parity. Our tool, Parive, uses AI to analyze, monitor and plan fixes so the two apps actually do the same thing. If you use AI for everything else, using it to check that is a no-brainer.
18:40 — Helix — The tempting approach is to point Claude Code at the codebase, have it write spec docs, and implement everything. Shopify’s tool breaks the work into small checkpoints, verifies each one, and feeds the feedback back in so the loop improves.
19:13 — How Helix works — A screen, roughly a feature, is broken into tasks. Each is built and tested, the screens are shown side by side, AI runs adversarial review, and a human approves at the end. Any stage can kick work back.
19:39 — What’s standard, and what’s new — Breaking down work, design, test and review have become standard practice. The mobile-specific tasks (structure first, then UI) and the side-by-side visual review are new. We’ve been experimenting with multimodal comparison, but having a developer check visually is practical.
20:33 — Testing from underneath — UI testing became the bottleneck for agents, so Shopify built their app so a CLI drives the UI directly, without simulated clicks. I can’t tell you to rearchitect your app, but I expect this to become common.
21:29 — The payoff — Twelve weeks, six devs. Cold start times way down, ten times fewer crashes, a smaller Android release, and great build times. Go read the post.

What we’re building

21:56 — The port tool — Our first, unnamed tool ports large production apps, and it is surprisingly effective and efficient. But then you have two apps, and the big problem is keeping them in parity going forward.
22:35 — Parive — It analyzes and normalizes screens, features, terminology and user stories, and compares them between the apps.
22:46 — Analysis has to be repeatable — You need apples-to-apples comparisons to find the edge cases and error states that differ even when the screens look the same. The analysis updates as commits land.
23:21 — History, notes and plans — Trace history to find out why something differs and whether it’s intentional, with notes and eventually issues and Slack. Then generate a plan to close the gap and run it in Claude Code or in our agent, which opens a PR.
23:50 — Public preview — A full analysis of the Wikipedia iOS and Android apps, from June, with a new engine landing soon. Accurate analysis is critical, which is Filip’s part.

Filip: Building the analysis engine

24:18 — Why a specialized tool? — The analysis has to cover the entire project at once, and scale is the primary problem; most of this doesn’t apply to projects under about 10,000 lines. The output also has to be a source of truth you can build on.
25:06 — Cost, time and quality — LLMs aren’t cheap, so the cost has to make sense against the value. Projects change fast; if the analysis takes days, it will always be stale. And the output has to be trustworthy.
25:49 — Soundness and completeness — Terms from static analysis. Sound: everything it reports about an item, like a screen, is correct. Complete: it finds every such item. Both, every run.
26:33 — Why not just ask Claude? — Coding agents aren’t designed for this. AI makes mistakes, more of them as tasks get harder, so mistakes grow quickly with project size.
27:07 — Agents are lazy — On open-ended tasks they don’t know when they’re done; nobody knows up front how many screens there are. Push harder and you get the inverse: ask an agent to fix a hundred bugs, and it will, even if it has to disagree with you about what a bug is.
28:23 — Variance between runs — Run the same thing twice and you get very different results, assuming you’ve isolated the agents so they can’t copy each other’s answers. Switch models or providers for funnier results. “What are all the screens” should always have the same answer.
29:24 — Bring back code — The fundamental problem is using LLMs for what they aren’t good at. Code orchestrates the agents instead: a dedicated session per file, so every run is guaranteed to look at every file.
30:32 — Many small problems — Splitting the work means sessions run in parallel; the engine can run thousands at once, so hours with a coding agent become minutes. Simpler tasks leave less room for mistakes.
31:18 — A model 100 times cheaper — Coding agents often need something like GPT-Sol or Astra. Simple tasks get away with something like Luna, which is 100 times cheaper than Astra, without using noticeably more tokens. That saving carries straight through to the cost of the analysis.
31:58 — Code for everything else — The LLM should be the last resort. Structured data instead of text, and custom tools so each agent can only do the operations its task needs.
32:53 — Exit gates — Be mean to your agents: they can’t call a task done until code checks the output. If an agent makes a claim about a file its tool calls show it never read, send it back to read it.
33:43 — A second agent judges — Where code can’t check the result, a separate session reviews the output or the log and sends feedback to the original. Agents, like people, are better at judging an answer than producing it.
34:30 — Split the review too — Dedicated agents look for mistakes in individual items, others for missing items, others for duplicates.
35:06 — Come find us — For more on how the analysis works or building custom agents, visit the booth.