Uplift Funnel is an autopilot for the screens between install and paid. It reads your store listing and screenshots, works out which activation flows your app is missing, writes them in your own theme, and shows you the whole set once. After you approve it, it publishes, measures, experiments and rewrites — and tells you which of its claims it can actually prove.
Snap a photo of any meal and get instant calories and macros.
runs native inside your app, not a webview
One
approval, before anything reaches a user
5%
held back permanently, to audit our own claims
Zero
of your own screens it is allowed to touch
Plugs into the stack you already run
Why it matters
Editors solved the release cycle years ago, and the screens are still the ones you wrote at launch. Optimizing a funnel is a standing job, and on a small team there is no week in which it becomes the priority.
~0%
The first open decides most of it. For most apps that session was written once, the week before launch, by someone who was busy.
0–0%
It is the store, and it is the part of the product nobody owns. Not because it is hard to change — because changing it well is a weekly job.
+0%
Ask, personalize, then offer. Building that sequence is an afternoon; keeping it right as the app changes is the part that never happens.
Industry data, not our own numbers: RevenueCat State of Subscription Apps · Superwall · Adapty, 2025–2026
How it works
01 · Connect
Your App Store link, the SDK, your revenue provider, and five sentences about your app that the system has already drafted from your listing and screenshots — you correct them rather than write them. The SDK step is verified by measurement, not a checkbox: the server watches for the key being used, the presenter registering, and your products arriving.
02 · It writes
It builds a profile of what your app does, who for, its aha moment and the words it uses, then works out which activation flows you are missing — a permission primer before the notification prompt, a first-value setup, an empty state. It writes them in your theme, renders every screen headlessly across devices and languages, and fixes what overflows, clips or goes off-vocabulary before you ever see it.
03 · You approve
Everything it wrote, with a phone preview per flow and the trigger in one sentence. Next to it: what it will do — autonomy level, holdout, guardrails, weekly experiment budget — and what it will never touch, including your own app's screens and anything you lock. Approve and it publishes on a ramp, not to everyone at once.
04 · It keeps going
It watches where people drop, forms a hypothesis, checks the change is legal against your constraints, runs the experiment, promotes what wins, and rewrites a flow that has stopped earning its place. Once a week it writes you a memo saying what it did, what it learned, and which numbers it is not entitled to claim.
Setup
Nothing publishes until the profile is complete — and the screen says which sentence is missing.
The obvious worry
Correct, eventually — that is what autopilot means. It is also the reason most of this product is machinery for making that survivable. Here is all of it, in order.
Every generated screen is drawn headlessly across devices and languages before it is shown to you — the same layout engine that runs on the phone. Overflow, clipping, contrast and off-vocabulary wording are caught there. The device × language matrix is on the approval screen; if a run could not render, it says so instead of showing a green tick.
Nothing reaches a user before you approve. That screen shows what it wrote, what it intends to do, and — in its own panel — what it is never allowed to change. Locks you set there are enforced by the schema, not by asking a model nicely.
Approved flows roll out on a canary. Guardrail metrics are watched throughout, and a breach rolls the change back on its own — no ticket, no waiting for you to notice.
Autopilot only ever changes Uplift flows. Your own screens, your purchase code, your sign-in and your permission prompts are yours; the flow asks, your handlers answer.
A per-account kill switch halts every autopilot publish. Flows already live keep being served — we will not break something in your revenue path to make a point about billing or safety.
Every autonomous action lands in an audit log with its reason, and shows up in the weekly memo. Nothing happens that you cannot find afterwards.
Prefer to drive? The editor is still there, and so is the MCP server. Autopilot is the road; neither one is a dead end.
How the guardrails workHonesty, mechanically
Growth tools are graded on the size of the number they show you. This one carries a label saying how it knows — and presenting one level in another's language is blocked in the product, not just discouraged in the copy.
An experiment in your own traffic, read against a control arm. Available once your volume can carry the metric being decided on.
“38% drop at step 3 · shown to 120 people · 43 completed.” True, useful, readable within weeks at small volumes — and not a claim that anything caused anything.
What usually works for this kind of app and this kind of screen. It is how day one starts, and it stays labelled as an assumption until something measures it here.
The same change run in many small apps at once and combined at the archetype level, so a decision exists where a single account could never read one. You would get the decision, never another app's numbers.
The holdout
Held back from day one, permanently, so there is always a group to compare against. It exists to check us, not you.
If your app is small
A revenue-metric experiment needs roughly 56,000 users per arm to detect a 14% difference — about four months, even at the top of the small band. So it decides on the highest metric your traffic can actually read in four weeks, starts from pattern-library priors rather than from nothing, and reports the rest descriptively. What it will not do is hand you a revenue number it did not earn.
How decisions are made at low trafficWhat it writes
Not a blank canvas and not a template pack. On day one it picks from three activation archetypes, based on what your app does and what your users already do — and it writes each one with the trigger that fires it.
a later session, permission not yet granted
Explain what notifications are for, and ask only from someone who has seen the reason. A denied permission is permanent until the user goes to Settings — every other mistake here is recoverable next session.
aha moment not reached, N days after install
Carry a new user to the moment the product makes sense, before they leave. Needs your aha moment, which is one of the five questions.
a later session, still nothing created
Give somebody staring at an empty screen a first thing to do. Only planned when your screen inventory actually contains one.
Not on day one
The paywall and the trial-lifecycle flow are the two screens where a wrong guess costs real money, so they stay out of scope until there is data about your app rather than assumptions about apps like it. Your existing paywall — in RevenueCat, Adapty, Superwall or your own code — keeps doing its job in the meantime.
The step nobody else has
A flow can run inference mid-way — a photo analysed, a quiz turned into a personal plan, a recording levelled — on your own provider key. The result is written back as a typed profile variable, so your copy, your branching and your app can all read it afterwards.
Also in the box
In your app
Two calls are the whole integration. Setup does not take your word for it either — the server watches for the key being used, the presenter registering and your products arriving before it will let anything publish.
await UpliftFunnel.configure(apiKey: 'fnl_pk_...');
// The server decides which flow, and when. Your app decides how —
// and can always say "not now" by returning false.
UpliftFunnel.registerPresenter((request) async {
if (!mounted) return false;
await showModalBottomSheet<void>(
context: context,
builder: (_) => UpliftFunnelFlow(request.flowKey),
);
return true;
});await UpliftFunnel.configure(apiKey: "fnl_pk_...")
UpliftFunnel.registerPresenter(self)
// Same server, same decision, native SwiftUI.
func presentSheet(flowKey: String, dismissible: Bool) async -> Bool {
guard canInterrupt else { return false }
sheetFlowKey = flowKey // drives a .sheet in your view
return true
}Register a presenter and the server answers the question of what to show and when — on cold launch, on events you track, and when a flow ends. You keep the veto: return false and nothing is shown, the frequency cap is not spent, and it can be offered again later.
Screens are drawn with the platform's own components, in your fonts and colors. There is no browser anywhere in the stack to give it away.
Purchases, sign-in, permission prompts and photo pickers are handlers you register once. The flow decides when to ask; your app decides how, and nothing about a purchase is ours to run.
One engine, written once in Swift. The Flutter package hosts it rather than reimplementing it, so a flow cannot render differently in a Flutter app than in a native one. Android and React Native cannot render at all — every call throws off iOS instead of failing quietly.
When you want to drive
Everything autopilot writes is an ordinary flow you can open, edit and publish yourself — the visual editor did not go anywhere. And for the times you would rather type than click, there is a hosted MCP server: point Claude Code or Cursor at it and your agent reads your live flows, authors screens, and checks its work against the schema before anything is written.
One line, in any MCP-capable agent — Claude Code, Cursor, Codex. There is no key in the command, so nothing secret is written to disk.
The dashboard mints a code that is valid for ten minutes. Your agent exchanges it for scoped access to that one app, and you can end the session from the dashboard whenever you like.
“Outline the onboarding flow.” “Rewrite the paywall headline to lead with the annual saving, show me.” The agent reads the real flow, edits it, and looks at a rendered screenshot of its own work.
Agents write to a draft. People deploy. There is no deploy tool and the pairing carries no scope for one. You open the flow, see the draft your agent restored, and press the button yourself.
$ claude mcp add --transport http uplift https://api.upliftfunnel.com/mcp Added HTTP MCP server uplift
Six tools
list_flowsEvery flow in the appget_flowA flow's outline — a tenth the size of the documentget_screenOne screen's tree, ids, variables and themeedit_screenValidate, render, and write one screen to the draftcreate_flowA new flow from a full documentcheck_flowWhole-flow check, including App Store paywall policyThe difference
A funnel builder
An autopilot
A canvas, and your Tuesday evening
The first set is written before you ask
You decide what to test next
It finds the drop-off and proposes the change
You read the dashboard
It reads the dashboard and writes you a memo
A number is just a number
Every number carries how it was measured
Too small to A/B test anything
Pooled decisions across similar apps, labelled as such
Onboarding quietly ages
A flow that stops earning gets rewritten
Who it's for
You are the growth team, and the growth team is busy shipping. Set it up once and the install-to-paid corridor gets worked on every week without appearing on your list.
Twenty apps, none of which will ever get a bespoke funnel. One account covers all of them, and what the system learns on one app makes the next one start further along.
Two calls and you are done being the bottleneck. Purchases, sign-in and permissions stay in your code; nothing generated reaches a user unrendered, and every change is in the audit log.
Pricing
Autopilot is in beta and costs nothing. When we do price it, it will be a flat monthly tier read from your app's own subscription revenue — not a share of everything you earn, and not a number we made up about lift.
We will publish the numbers before anyone is charged, and nobody moves from free to paid without agreeing to a price they have already seen.
Every account, every app, today.
Published flows are never switched off over an invoice — before or after we start charging.
FAQ
Uplift Funnel is an autopilot for the screens between install and paid in an iOS subscription app. You connect your App Store listing, add the SDK, connect your revenue provider and correct five sentences about your app. From there it builds a profile of what your app does and how it talks, works out which activation flows are missing — a permission primer, a first-value setup, an empty state — writes them in your app's own theme, and shows you the whole set once for approval. After that single approval it publishes them, measures drop-off, runs its own experiments, promotes what wins and rewrites what stops working. It is in beta and free.
Eventually yes, and that is what autopilot means — so most of the product is machinery for making that survivable. You approve the first set before anything reaches a user, and that gate is a hard stop. Every generated screen is rendered headlessly across devices and languages before you see it, so overflow, clipping, contrast and off-vocabulary wording are caught first. Approved flows roll out on a canary ramp rather than to everyone, guardrail metrics roll a change back automatically if they degrade, every autonomous action is written to an audit log, and a per-account kill switch stops all autopilot publishing at once. Autopilot only ever changes Uplift flows — never your own app's screens, purchase code, sign-in or permission prompts.
It writes activation flows: permission primers, first-value setup, empty states, feature discovery, return flows and surveys, each with the trigger that fires it. On day one it deliberately will not write your paywall or your trial-lifecycle flow. Those are the two places where a wrong guess costs real money, so they stay out of scope until there is data about your app rather than assumptions about apps like it. Your existing paywall — in RevenueCat, Adapty, Superwall or your own code — keeps doing its job.
Yes, but it decides differently and says so. A revenue-metric experiment needs roughly 56,000 users per arm to detect a 14% difference, which is about four months even at the top of the small band — so on a small app Uplift Funnel picks the highest metric your traffic can actually read within four weeks, such as step completion rather than revenue, starts from pattern-library priors instead of from nothing, and reports the rest descriptively: "38% drop at step 3, shown to 120 people, 43 completed." Every number is labelled with how it was reached, and it will not report a revenue improvement it did not measure. Your own 5% holdout accumulates in the background from day one, so the reads become yours as the app grows. Pooling decisions across many small apps at the archetype level is designed and specified but not shipped yet; until it is, a small account gets descriptive reads and labelled priors rather than a pooled measurement.
Every number Uplift Funnel shows carries an evidence level: measured_here (an experiment in your own traffic, read against a control arm), descriptive (a real observation that is not a causal claim, like "38% drop at step 3, shown to 120 people"), assumed_prior (what usually works for this kind of app, until something measures it here) and measured_pooled (combined across similar apps at the archetype level — specified, not yet shipped). Presenting one level in another's language is blocked in the product rather than discouraged in the copy, and a decision taken on an activation metric is never reported as a revenue result. Separately, 5% of your users are permanently held back from everything autopilot does, and a reconciliation panel shows claimed cumulative lift next to holdout-measured lift. When the two disagree, the panel says so.
iOS only, through two SDKs: a native Swift package, and a Flutter package that hosts the same Swift engine rather than reimplementing it — which is why the two cannot draw a flow differently. A Flutter app therefore gets Uplift Funnel flows on iOS and not on Android. Android, React Native and web are not supported and are not on the roadmap; every SDK call throws UpliftFunnelUnsupportedPlatform off iOS rather than failing quietly, so you can guard for it in one place.
Yes. Everything autopilot writes is an ordinary flow you can open, edit and publish in the visual editor, and you can author flows from scratch there too. Uplift Funnel also ships a hosted MCP server at api.upliftfunnel.com/mcp: add it to Claude Code, Cursor or any MCP-capable agent, pair it with a ten-minute code from the dashboard, and the agent can list flows, read a screen, author or edit screens and validate a whole flow against the schema. Agent writes land in a draft — there is no deploy tool, so publishing to live traffic stays a human action. Autopilot is the primary path; the editor is the escape hatch, not a dead end.
Two calls. UpliftFunnel.configure with your public key, then registerPresenter, which is how your app hands the question of what to show and when back to the server — your app never names a flow. When a trigger fires, the SDK asks you to present it and you can always return false, in which case nothing is shown, the frequency cap is not spent and it can be offered again later. Purchases, sign-in, permission prompts and photo pickers stay in your code as handlers you register once. Setup does not take your word for the integration either: the server verifies it by watching for the key being used, the presenter registering and your products arriving.
Nothing today — autopilot is in beta and free on every account. The model that will replace that is a flat monthly tier read from your app's own subscription revenue, priced per account with a quota of apps, with a free tier that generates and previews flows but does not publish them. The numbers are not set and are not published, because a price built on nothing is exactly the kind of confident-but-unfounded number this product refuses to produce. We will publish them before anyone is charged, nobody moves from free to paid without agreeing to a price they have seen, and published flows are never switched off over an invoice.
No. Uplift Funnel can run in-flow inference — a photo analysed, a quiz turned into a personal plan — on your own provider key, and that step is off if you do not supply one. The same is true of App Store Connect and fal.ai: without those keys the related capability is disabled and everything else works normally.
Yes. What changes is flow content — copy, screen order, which offer is shown, quiz branching — not native binary behavior, which is the line Apple's rules draw. Uplift Funnel also refuses to publish a paywall without Terms and Privacy links attached and generates the required legal caption at serve time, so the screen a reviewer sees is compliant by construction. Flows are cached on the device, so a user with no network sees the last known-good version rather than a blank screen.
Connect the app, drop in the SDK, answer five questions. Then look at the flows it made, in your own theme, and decide whether any of it goes live.
No credit card · Free during beta · iOS, Swift & Flutter