What we're adding to AppX in Q3 2026
Native iOS/Android builds via EAS, custom domains, multi-user collaboration, expanded template gallery, runtime-error-into-chat, voice input. Honest gates and confidence levels — no date promises.
AppX team ·
This is a roadmap post, not a release schedule. We are writing down what we want AppX to do by the end of Q3, with a clear note on what is gated, what is uncertain, and what we will quietly drop if the substrate fights us. Roadmaps that read like promises age badly. Roadmaps that read like intentions, with the gates named out loud, tend to survive contact with the actual quarter. Six items below, then a short section on what we are deliberately not doing.
1. Native iOS and Android builds via EAS
What. Take an AppX-generated project and turn it into a signed .ipa and .aab ready to upload to the App Store and Play Store. The plan is to ride on Expo's EAS Build pipeline rather than rebuild what they have already solved.
Why. Right now AppX takes a user from "I have an idea" to "QR code in Expo Go on my phone." That covers the demo and the iteration loop, but the user's actual destination is a store listing. Without a real ship path, AppX is a prototyping tool. With one, it is a product.
Gates. We need to wire app metadata into the AppX UI — icons, splash screens, bundle identifiers, store descriptions — and let users link their own EAS account so build minutes and signing identities belong to them, not us. The bigger gate is testing the EAS pipeline against the kind of code our generation actually produces, at the volume we would produce it. There is a non-trivial chance our pinned Expo SDK version does not line up with what EAS supports on the day we try to ship, and we will have to choose between bumping SDKs (risky for the live preview path) or waiting.
Confidence. Likely Q3 for the metadata UI and account linking. The end-to-end "press button, get an .ipa" experience is a stretch.
2. Custom domains for app previews
What. Today an AppX preview lives at ${slug}.preview.appx.uz. The intent is to let a user point app.theirdomain.com at their preview and have it Just Work — DNS verification, automatic TLS, and routing changes inside Forge so the right hostname lands on the right container.
Why. Founders demoing to investors do not want a third-party subdomain in the URL bar. Agencies showing client work want the client's domain. The friction is real and it is a feature gap, not a generation gap.
Gates. This is mostly a product-and-ops problem. DNS verification flows are well-trodden, TLS provisioning on demand is well-trodden, but doing both at the volume we would do them — with cert renewal handled silently and routing inside Forge updated as containers cycle — has edges. The bigger uncertainty is operational: a custom domain is a long-lived commitment, and our preview containers are not. We will probably want a "claim a preview" step that promotes a container from ephemeral to pinned before we attach a domain to it.
Confidence. Likely Q3 for verification and TLS. The pinning model is the unknown.
3. Multi-user collaboration on a project
What. Two people opening the same AppX project at the same time, seeing each other's cursors, sharing chat history, editing simultaneously without stepping on each other.
Why. Most AppX projects today are solo-built. The ones that matter most to us — agency work, small founding teams, design-and-dev pairs — are not. The Socket.io infrastructure for real-time chat already exists; this is mostly building on top of it.
Gates. Cursor presence and shared chat are tractable. Conflict resolution on simultaneous file writes is the hard part. We have a choice between optimistic concurrency with a merge-on-conflict UI, or a more pessimistic lock-the-screen-you-are-editing model. The first is nicer; the second is shippable in less time. We will probably do the pessimistic version first and see if anyone complains.
Confidence. Cursor presence and shared chat: likely Q3. Simultaneous edits: Q3 stretch.
4. Expanded template gallery
What. Our generation today seeds from a small set of golden templates — fitness, finance, social, ecommerce, task, food, education, travel. Eight categories. We want to roughly triple that, into the mid-twenties, by end of quarter.
Why. Templates are how cold-start prompts converge. If a user says "make me a meditation app" and the closest golden template is "fitness," the architect has to do more inference and the output drifts. More templates means tighter cold-start matching for the long tail of app ideas we currently approximate.
Gates. This is mostly a content problem, not an engineering problem. Each template needs to be hand-built, validated end-to-end through generation, and curated for code quality. The bottleneck is the team's time to author them well — a template that generates messy code makes every future app in that category worse, not better.
Confidence. Likely Q3 — the work is steady-state rather than blocked on anything.
5. Better runtime-error feedback into chat
What. When a generated app crashes on the user's phone, we want the runtime stack trace to land in the chat automatically, with enough context for the next edit to know what to fix. Today the user has to describe the crash in prose, which is a bad use of their time and a bad use of the model's context.
Why. The user's phone already knows what broke. The Forge side already has a retrieve_logs tool. The gap is purely the wiring — making the frontend listen for runtime errors, sending them up to the chat as context, and teaching the architect prompt how to weight them when planning a fix.
Gates. The wiring is straightforward. The architect prompt update is less so — we have to decide how aggressively to inject runtime errors into the conversation without drowning intentional user edits in noise.
Confidence. Likely Q3. This is one of the higher-confidence items on the list.
6. Voice input for chat
What. A microphone button on the chat input. Whisper-style transcription. Users describe an app, the words become a prompt.
Why. People describe apps faster than they type, and AppX is a product where the description is the input. Lowering the friction on the input lowers the friction on the whole loop.
Gates. Latency is the entire question. If the transcription round-trip feels real-time, this ships. If it stutters, it gets quietly shelved until it does not. We will not put a voice button in front of users that makes them wait a beat longer than typing.
Confidence. Q3 stretch — gated entirely on whether we can hit a latency budget that feels native.
What we are NOT building this quarter (and why)
A plugin system for third-party generators. Asked about often, the cost is high and the win is unclear until our own generation is uniformly excellent across all categories. Premature.
A self-hosted version of AppX. The economics of our compute layer assume density on shared infrastructure; a self-hosted version would either be slow or expensive, and probably both. We will revisit if a serious enterprise asks specifically.
A desktop app. The browser version does everything the desktop version would do, and the maintenance surface of a packaged Electron app is not a fight worth picking right now.
Backend-as-a-service generation. Generating a database schema and an API to go with the mobile app is the obvious extension and we think about it often. The reason it is not on the Q3 list is that we want to land native builds first — shipping to the store is more valuable to users than a backend they did not ask for.
Closing
The items above are intentions, not contracts. Some of them will move forward fast and ship cleanly. Some will hit a wall — a vendor change, an Expo SDK mismatch, a latency budget we cannot meet — and quietly slide to next quarter or get cut. We will write about what shipped, what slipped, and what we learned at the end of the quarter, with the same honesty we are trying to use here.
If you are an AppX user and one of these items would unblock something you are trying to build, tell us. Roadmap priorities respond to actual users much more than they respond to the order we wrote them down in.