Two weeks ago, the Gleap mobile app was an empty git repository. Today it is a native app on the Apple App Store and Google Play, with passkey login, realtime sync, push notifications, and Liquid Glass tabs on iOS 26. It was built almost entirely by Claude Fable 5, Anthropic’s newest and most capable model. And since launch, it has been maintained the same way everything at Gleap is maintained now: bug reports go in, reviewed pull requests come out, and Kai Code does the work in between.
This post is the build log. What Fable 5 actually did, where it surprised us, and how we wired the finished app into the same self healing loop we sell.
Why we built a native app now
Gleap’s dashboard is where support teams work all day, but the moments that matter increasingly happen away from the desk. Kai answers customers and repairs bugs on its own, which means the human’s job has shifted from doing the work to supervising it: approving a plan, reviewing a pull request, unblocking a coding session that needs judgment. Those are interactions that take thirty seconds, and they should not require opening a laptop.
For years our answer was a web app pinned to the home screen. It worked, barely. No reliable push notifications on iOS for a long time, no native navigation, no system feel. When the supervision loop became the core workflow, barely stopped being acceptable. We needed a real native app, and we decided to find out how far the newest generation of AI models could take us in building one.
What is Claude Fable 5?
Claude Fable 5 is the first model in Anthropic’s Claude 5 family and their most capable generally available model, sitting in a new tier above Claude Opus. The headline capability is sustained agentic work: instead of answering a prompt and stopping, it carries an engineering session for hours, reading a codebase, forming a plan, building, testing, and correcting itself along the way.
That distinction matters for a project like this. Writing a toy app from a single prompt has been possible for two years. Building a production companion app against a real API surface that has grown for seven years, with authentication, realtime events, and a rich text message format shared by three existing clients, is a different category of problem. It is exactly the category Fable 5 was built for.
How Fable 5 built the app
The build did not start with code. It started with an audit.
Fable 5 read through our existing codebases, meaning the web dashboard, the API server, and the customer facing messenger, and grounded every decision in what it found there, with file references inline. Then it produced a written framework evaluation: Expo React Native versus Flutter versus Compose Multiplatform, scored on the things we actually cared about. The deciding argument was one we had not fully appreciated ourselves: Expo Router’s native tabs render a real UITabBarController, which means Liquid Glass on iOS 26 comes from the system for free, while Flutter had paused its Cupertino redesign work entirely. For a React and TypeScript team that wanted the app to feel genuinely native, the matrix pointed one way.
Then it planned, and then it built. The numbers from the git history:
- 177 commits from first scaffold to the builds we shipped, in under two weeks.
- Five native tabs (Home, Inbox, Boards, Kai Code, Alerts) on Expo SDK 56, React Native, and TypeScript.
- Passkey login via native WebAuthn, alongside email login, with tokens stored in the iOS Keychain.
- The same realtime layer as our web dashboard, reused as is, so a conversation updates on your phone the moment it updates anywhere else.
- TanStack Query with persistence on the device, so the app opens instantly on cached data and refreshes in place.
One detail we want to be honest about, because it is the most realistic part of the story: there was a failed first attempt. An earlier build effort produced twelve commits and got abandoned. Fable 5 did not throw that away. It read the surviving history, kept what had been proven (the API and realtime integration worked from Expo), and discarded what had not. Learning from a dead branch instead of repeating it is exactly what you would want from a senior engineer, and it is not something we had seen a model do unprompted before.
The hardest problem was a judgment call, not code
Every Gleap conversation is stored as rich structured content, a custom editor format with roughly thirty node types: help center articles, callouts, tables, embedded videos, interactive buttons. That schema already lives in three codebases. The obvious move for a mobile app is to write a fourth renderer, natively. The obvious move is wrong: copy number four would drift out of sync forever, and the composer (mentions, templates, attachments) is even harder than the renderer.
Fable 5 evaluated the options, including the community’s native editor wrappers, and recommended something more architectural: render each conversation in a single embedded web view, served by a new slim route in our existing dashboard codebase, connected to the native shell through a small versioned message bridge. One schema owner, full fidelity, and improvements to the message surface ship to the app without an App Store release. It even flagged the platform trap that a web view per message costs 100 to 200 milliseconds per bridge round trip, which is why it insisted on one web view per conversation thread.
That recommendation is the moment this stopped feeling like code generation and started feeling like working with an engineer. The model was not asked to be clever. It was asked to solve the problem, and the solution it defended was the one that minimizes maintenance over years, the kind of call that usually takes a painful rewrite to learn.
What we learned about building with Fable 5
A few practices made the difference between good output and great output:
- Spec first, then autonomy. Fable 5 does its best work when the full task is specified up front and it is left to run. Vague prompts refined over many turns produced weaker results than one well written brief.
- Plans are the review surface. We reviewed written plans before any code existed. Disagreements were cheap to resolve at the plan stage and expensive after.
- Verification is part of the task. The model ran the app, exercised the flows it had just built, and fixed what it found before reporting done. We stopped discovering its bugs for it.
- Judgment stays human. We made the calls on scope, design taste, and what ships. The model proposed; we decided. That division of labor never felt limiting. It felt like the point.
If that sounds familiar, it is because it is the same philosophy we built into Gleap’s own agents: agents propose, builders decide.
How Kai Code keeps the app healthy after launch
Shipping was the halfway point. The real question for any app is what happens in week three, when real users on real devices hit the bugs your simulator never showed you.
For us, that loop already existed, because it is our product. The mobile app now lives on the same self healing software loop as every other Gleap surface:
- A bug report arrives through in app bug reporting, carrying its evidence: screenshots, session replay, console logs, network requests, and device data.
- Kai Resolve investigates. It works through the technical evidence with access to source context and ticket history, then routes the next step: a fix, a product gap, or a task for a human.
- Confirmed bugs enter Kai Code plan mode. Kai reads the app’s codebase and writes a plan we can approve.
- Build mode implements the fix, and a pull request lands in the repository for review.
- When the fix ships, the customer who reported it gets notified automatically.
No triage meetings, no reproduction hunts, no copying stack traces between tools. Maintenance is not a sprint line item anymore; it is a background process with human checkpoints.
And there is a recursion here that we genuinely enjoy. One of the app’s five tabs is Kai Code itself. You open it to watch coding sessions plan, build, and open pull requests, and to step in when one needs your judgment. Which means the app you use to supervise Kai Code is an app that Kai Code maintains. The loop closed all the way around.
What this means if you build software
The economics of this project would not have made sense eighteen months ago. A native companion app was permanently third on our priority list: valuable, never urgent enough to pull two engineers off the core product for a quarter. With Claude Fable 5 doing the building and Kai Code carrying the maintenance, the cost side of that equation collapsed, and an item that sat in the backlog for years shipped in two weeks without slowing anything else down.
That is the actual promise of this generation of AI, and it is not software without engineers. It is that the gap between what your team wants to exist and what your team can afford to maintain gets dramatically smaller. Build the thing. Wire it into a loop that heals it. Move on to the next thing.
If you want the supervision side of that loop in your pocket, download the Gleap mobile app for iPhone, iPad, or Android. And if you want your own product to repair itself while you sleep, the full agent stack, Kai Resolve and Kai Code included, is part of every Gleap plan, with a 14 day free trial to run it on your real bug reports.