Ship UI/UX fast
with AI powered plug-and-play Server-Driven UI
Install one SDK in a day. Ship paywalls, banners, and full screens to Flutter, React Native, iOS, and Android with crash isolation and 1-click rollback.
Supported Production SDKs • Built for Mobile Speed
Good morning, Emma
Brew & Co.
Limited time
Halloween Sale: 30% off
Shop nowBestsellers
See all
Cold Brew
$4.50
Croissant
$3.25
PromoBanner · Content
No issues · works on app v4.2+
Reaches ~182,000 users (14% of MAU)
Every team ships its own screens
Developers set up FlashUI once. After that, anyone on your team can change a live screen from the dashboard, and every change goes through review and a staged rollout before users see it.
- Product & growth teams change banners, offers and onboarding, and run A/B tests themselves
- Designers build with the app's own components, fonts and brand colors
- Developers set up the SDK once, choose what others can edit, and keep the kill switch
- Release managers approve changes, roll out by percentage, and roll back in one click
When something goes wrong
A bad change should never become a bad day
Someone will publish a typo, a broken link or the wrong discount. Networks drop. Our servers could go down too. Here is what your users see when that happens.
- 1
The new version you published Didn't load
Shown when it loads and renders correctly.
- 2
The last version that worked on this phone Your users see this
Saved on the device, so it works offline too.
- 3
The version shipped inside your app
Bundled with every build you release.
- 4
Your own native screen
The one your developers already built. Always there.
- 0
crashes caused by FlashUI
Errors inside FlashUI are caught before they reach your app. The worst case is your own native screen.
- 60s
to undo any change
One click sends every online phone back to the previous version. No new build, no store review.
- <500KB
added to your app
No extra permissions, and less than 20 ms added to startup.
- 6–18mo
of engineering you skip
That's how long teams spend building server-driven UI in-house. FlashUI installs in a day.
Your code stays yours
You own the codebase. FlashUI handles the server-driven UI.
FlashUI isn't an app builder and never takes over your app. Your developers keep full control of the code and can change anything by hand, any time. FlashUI only runs the parts you choose to make server-driven.
You keep
- Navigation and state
- Business logic and checkout
- Analytics and tracking
- Every native screen
FlashUI runs
- The slots you place
- Rollouts, targeting and rollback
- The editor and AI Harness
- Delivery to every phone
1export function HomeScreen() {2 return (3 <Screen>4 <Header />your code5 <FlashSlotFlashUI6 id="home_banner"7 fallback={<PromoBanner />}8 />9 <ProductGrid />your code10 <CheckoutButton />your code11 </Screen>12 );13}
React Native shown. Flutter works the same way: one slot, with your own screen as the fallback.
How it works
From install to your first live screen in an afternoon
- HomeScreen.tsx
$ npm i @flashui/react-native <FlashSlot id="home_banner" fallback={<PromoBanner />} />
SDK connected · 440 KB01
Add the SDK
Install it once and place a slot wherever screens should change. Your own view stays as the fallback.
Brew & Co.
Tonight only
Halloween Sale: 40% off
Shop the sale🎃AI HarnessMake a Halloween version, 40% off02
Design the change
Edit on a real phone canvas, or describe it to the AI. Both use only your components and brand colors.
Halloween banner
Live1%10%50%100%Roll backCrash-free sessions 99.96%
Next step 50% in 2h
03
Roll it out safely
Send it to 1% of users, watch crash rates, then go wider. One click rolls it back.
Built Specifically for Solo Founders, Startups & Agile Mobile Teams
See how FlashUI solves the exact headaches of your role.
Ship Mobile Growth Experiments in Minutes, Not 2-Week Sprints
When you're building solo or with a 2-person team, waiting 4 to 7 days for App Store review kills your growth momentum. FlashUI gives you the unfair advantage of pushing paywalls, onboarding tests, and seasonal sales immediately.
Before you install the SDK
What engineering teams ask us first
Mobile leads, founders and security reviewers tend to raise the same five concerns. Here's how FlashUI handles each one.
- Will it break my app?
- A screen that fails to load or doesn't match the schema never reaches the user. The SDK falls back to the last version that worked, then to the native view your developers shipped. Every screen also has its own kill switch.
- Teams that build server-driven UI in-house usually find schema mismatches the hard way, as crashes in production.
- Will Apple or Google reject it?
- FlashUI only sends layout data for components already compiled into your app. No code or JavaScript is downloaded at runtime, which keeps you within App Store Guideline 2.5.2.
- Code push tools such as Expo EAS Update and Shorebird ship new code, which gets more attention in store review.
- Are we locked in?
- FlashUI isn't an app builder. It runs only the slots you place on your screens, and everything else stays in your repo. To remove it, delete the init line and your native screens keep working as before.
- App builders like FlutterFlow generate the whole app, so leaving means rewriting it.
- What if someone non-technical breaks production?
- Engineers decide which components and brand colors can be edited. Marketing and design work inside those limits, every publish needs approval, and a rollout pauses itself if crash or conversion numbers drop.
- Open-source server-driven UI frameworks don't come with a dashboard, approvals or roles.
- Will it hold up at our scale?
- Screens are served from edge CDNs and cached on the phone. They render from cache in under 100 ms at p95, and still open when the user is offline.
- A self-hosted setup needs someone on call for traffic spikes, like the minute a sale goes live.
How FlashUI compares
| FlashUI | Build it in-house | App builders | Code push | |
|---|---|---|---|---|
| Time to first live screen | Under an hour | 6–18 months | Weeks, after a rebuild | Days |
| Visual editor | Yes, on a real device frame | No, developers only | Yes | No |
| You own the code | Yes | Yes | No | Yes |
| Store review risk | Low, layout data only | Low | Low | Higher |
| Staged rollout and rollback | Rollback in under 60 s | You build it | No | 5–15 minutes |
FAQ
Questions, answered
What teams usually ask before adding FlashUI to their app.
Still have a question?
Get a 20-minute walkthrough with the team, on your own app.
The basics
Instead of hard-coding a screen into your app build, the app asks a server what to show and renders it with components that are already in the app. Change the layout on the server and every user sees it, with no new build or store review. FlashUI gives you that, plus the dashboard, rollouts and safety, without building it yourself.
Consumer apps that change their UI often: e-commerce, food delivery, fintech, travel and media. Developers set it up once, then product, growth and design teams make the day-to-day changes themselves.
Flutter comes first, followed by React Native (new and old architecture, Expo included). Native iOS (SwiftUI and UIKit) and Android (Jetpack Compose and Views) SDKs are on the roadmap. Apps that mix native and cross-platform screens use a single app key.
Most teams get a first live screen in under an hour: install the SDK, add your app key, place one FlashSlot and run the app. The dashboard walks you through each step.
Your code
Yes. Your app stays your app. FlashUI only controls the slots you place, and everything else (navigation, business logic, checkout, analytics) stays in your code, where your developers can change anything by hand at any time. FlashUI takes care of the server-driven UI.
No. You add FlashUI one screen or section at a time, starting with something small like a home banner. Each slot uses your own components and keeps your native screen as its fallback.
Delete the init line and the slots. Your native fallback screens are still there, so the app keeps working. There is nothing to migrate out.
Safety
It's built not to. Errors inside FlashUI are caught before they reach your app. A screen that fails to load falls back to the last version that worked on that phone, then to the version bundled with your build, then to your own native screen. Every screen also has a kill switch.
FlashUI sends UI data for components that are already compiled into your app, never executable code. That is the line both stores draw. We include a compliance guide you can share with app reviewers.
They can only use the components and actions your developers approve. Changes go through test mode, review and approvals, then roll out in stages. If a health check fails, the rollout pauses on its own.
One click. It reaches 95% of online phones in under 60 seconds, with no app release.
Yes. Screens are saved on the device, so the app shows the last version with no connection, and keeps working if our servers are down.
AI Harness
It turns a prompt, a screenshot or a Figma frame into an editable screen that uses only your components and brand colors. Tag a component on the canvas and describe the change, like "make a Halloween version with a new image". Every result is a draft that goes through the same review as human work, and AI never publishes on its own.
No. Your data and designs are never used to train shared models, and that is written into the contract.
Stop waiting 7 days for app store approvals.
Book a demo and our team will walk you through FlashUI on your own app, then help you ship your first live screen.