Case study · ReactView

The 8-Hour
Ship

A Lovable web app, fully rebuilt in Flutter → a real iOS app in TestFlight, submitted to App Store review — in a single working day.

reactview.com
ReactView — web / desktop view
ReactView — iPhone app

One product, two screens · drop your ReactView screenshots into the frames

The product

ReactView

This case study isn't hypothetical. The app we took from prototype to the App Store is ReactView — a real, live video-analysis platform for coaches and athletes.

ReactView turns raw game footage into clear, teachable insight. Coaches and athletes upload film, tag plays, draw directly on the screen, and share clips in seconds. Its AI-assisted analysis surfaces key moments, recurring patterns, and decision-making tendencies — so coaches spend more time teaching and less time hunting through footage.

Film upload

Get game footage into one place.

Play tagging

Mark plays and key moments for instant recall.

On-screen telestration

Draw directly on the frame to show, not tell.

Voice-over feedback

Attach spoken coaching to any clip.

Second-fast sharing

Send clips to a player or the whole team.

AI analysis

Surface patterns and decision-making tendencies automatically.

Telestration — ink over a frozen frame
Telestration
Play-tagging list
Play tagging
Shared clip with voice-over
Voice-over share

ReactView is exactly the kind of interaction-heavy product that earns a native mobile app. Video, on-frame drawing, gestures, quick capture, instant sharing — a responsive web page can only approximate those. On a phone, in a coach's hand at the rink, it needs to feel native.

The starting line

A browser tab is not an App Store listing

You built something great in Lovable. It's React, it's fast, and in a browser it feels like a product. Then reality lands.

Between your prototype and a native iOS app is a gauntlet most teams underestimate. Teams routinely lose weeks here. Some never make it out.

Signing & provisioning Native rebuild Deep-link auth Review guidelines Privacy labels A Mac you may not own

We treat that gauntlet as a solved, repeatable path — a Lovable React prototype taken from a clean GitHub checkout to the review queue in eight hours, by a small crew of senior engineers with AI under tight guardrails.

What “done” actually means

No demos that are secretly screenshots

Our definition of done for this build was concrete and testable:

A genuine Flutter rewrite — rebuilt in Dart and compiled to native code, not a WebView wrapper or the React bundle repackaged.

Installs on a real iPhone via TestFlight — not a simulator.

Boots & behaves native — real navigation, a real splash screen, a real app icon.

Authenticates against Supabase on-device, with sessions that persist and a deep-link redirect that returns into the app.

Submitted to App Store review — the real gate, not a private link.

Shipped through GitHub, PR-based — every change reviewed, attributable, and reproducible.

The deliverable isn't just an app — it's a path anyone can walk again.

Proof photo — app in-hand on a real iPhone
ReactView
TestFlight · Build 1 (1)
Ready to Test
TestFlight build listing screenshot

Proof it's real, not a render

The eight hours

Six phases, one working day

Everyone commits code; roles are hats, not silos, and they rotate at each phase boundary so no single person becomes the only one who understands the machine.

01
ORIGIN
Out of Lovable
02
SYNC
One GitHub repo
03
SHELL
Native project
04
BUILD
Cloud, no Mac
05
BETA
TestFlight, real devices
06
SHIP
Submitted to review
Hour allocation0 → 8 hrs
SYNC
SHELL
CORE + DATA
BUILD
BETA
SHIP
HOUR 0ORIGIN → SYNC

One source of truth

The first real move is getting your React app out of Lovable and into a single GitHub repository — the one source of truth for both apps: your existing web/desktop app and the new Flutter mobile app, under one roof, one history, one set of pull requests.

Owned by the Release Captain, crew committing in parallel.

Lovable · React prototype
one github repo
/web
desktop app
/mobile
Flutter app
one Supabase backend
HOURS 1–2SHELL

The native project — bake-off winner

We don't guess at the architecture; we run a quick bake-off on the Flutter setup — navigation and state management — and ship the winner. The Native Engineer scaffolds navigation, splash, app icon, and the native capabilities that clear Guideline 4.2 (Minimum Functionality).

Owned by the Native Engineer — app config, native shell.

bake-off → ship the winner
Navigation approachchosen
State managementchosen
Splash + app icon
Guideline 4.2 capability
Native ARM — not a wrapper
HOURS 2–4CORE + DATA · in parallel

Rebuild once, reuse the backend

Your Lovable prototype is React; Flutter runs on Dart — there's no copy-paste path, and we don't fake one. We rebuild from the ground up in Dart — every screen fresh as native Flutter, using your prototype as the reference. What we reuse is the only thing worth reusing: your Supabase backend — schema, auth, rules.

The payoff compounds: one Dart codebase compiles to iOS and Android natively. In parallel, Backend/Auth makes Supabase auth behave on a device — deep-link redirects, secure session persistence, and an RLS sanity pass.

Owned by the Shared-Core Dev and Backend/Auth.

Supabase backend
React
web client
Flutter · Dart
one codebase
↙  ↘
iOS
Android
HOURS 4–5BUILD

Cloud build, no Mac required

iOS builds need macOS — but nobody needs a Mac on their desk. A cloud macOS runner handles signing and produces the archive, so a developer on any OS can trigger a build from a clean checkout and get the same signed artifact. Signing credentials live with the Release Captain, never passed around in DMs.

Owned by the Release Captain — App Store Connect, the build pipeline.

Windows / Linux / Mac git push
Cloud macOS runner
signing + archive · no Mac on the desk
signed .ipa TestFlight
HOURS 5–6BETA

TestFlight on real devices

The signed build goes to TestFlight and onto physical iPhones. QA runs a device test matrix through the GitHub Actions gate, triages anything that surfaces, and distributes to testers. This is the moment the app stops being a plan and becomes a thing you can hold.

Owned by QA/DevOps — CI, TestFlight, issues.

device test matrix
iPhone SE
iPhone 13
iPhone 15 Pro
iOS 16
iOS 17
Dynamic Island
HOURS 6–8SHIP

App Store submission + the launch kit

Growth/Design closes it out: app icon, screenshots, store copy, and the App Store privacy labels, then packages the launch kit and writes up THE-PATH.md — the playbook so the next build starts from a known-good route. Submitted to review. Same day.

Owned by Growth/Design — launch kit, the recipe.

ReactView
Video analysis for coaches
GET
Screenshot 1
Screenshot 2
Screenshot 3

01 ORIGIN → 02 SYNC → 03 SHELL → 04 BUILD → 05 BETA → 06 SHIP

8hrs
start to submission
1
Dart codebase → 2 platforms
0
Macs required
100%
of changes PR-reviewed
The difference

Weeks, compressed into a day

Usual path to a native appseveral weeks
This buildone day

Same gate, same rigor — a fraction of the calendar.

Mobile-native UX

Not a shrunk-down desktop

A responsive layout asks: how do we make the desktop design fit a smaller screen? A native app asks a better question: what does this feature want to be on a phone, in one hand?

Before · responsive web, squeezedcramped
Web UI squeezed onto a phone
After · redesigned Flutter UInative
Redesigned native UI — bottom tabs, thumb-friendly
Navigation

Thumb-reachable bottom tabs and native gestures — swipe, pull-to-refresh, edge-swipe back.

Touch targets

Sized for fingers, not cursors — the primary action where your thumb rests.

Platform patterns

iOS sheets, native pickers, haptics, and safe-area handling around the notch.

Real-world states

Loading, offline, and error handling built for flaky mobile networks.

Motion

Native frame rates, not best-effort CSS transitions.

Your desktop app keeps its responsive web UI and its audience. The mobile app gets an interface designed for how people actually hold and tap a phone. Same product, two front doors — each one right for its screen.

How the crew works

Senior humans, AI under guardrails

A small crew of experienced engineers, each wearing a hat — and rotating those hats each round so knowledge never gets trapped in one head.

Release Captain

owns main, the pipeline, credentials

Native Engineer

owns app config, native shell

Shared-Core Dev

owns the shared Dart layer

Backend / Auth

owns auth, deep links, RLS

QA / DevOps

owns CI, TestFlight, issues

Growth / Design

owns launch kit, the recipe

AI is in the room the whole time, but on a leash. It accelerates the mechanical work — scaffolding, boilerplate, test matrices, first-draft store copy — while every consequential decision is made and reviewed by a person. Nothing reaches main without a human PR review. AI for velocity, humans for judgment.

The quality gate

Test, audit, review — then ship

Speed only counts if the thing that ships actually works. Nothing reaches main — and nothing reaches a tester — without clearing a layered gate built into the pipeline.

01
Pull request
required senior review
02
Automated checks
flutter analyze · lint · unit / widget / integration
03
Real-device matrix
physical iPhones
04
Audit pass
deps · secrets · perms · RLS
05
Go / no-go
green, or it doesn't ship

Security, by default

No secrets in the repo. Signing keys and Supabase creds live in encrypted secret stores — never in source, never in chat.

Least privilege. Store and signing credentials held by the Release Captain, granted deliberately, fully auditable.

Auth done right on-device. Tokens in the platform secure store, PKCE-style redirect flow, validated deep links.

Data boundaries enforced. Supabase RLS sanity-checked from the mobile client so users only reach their own data.

Compliance is the plan

App Store rejections are predictable — so we design for them up front. Cleared before submission:

4.2 Minimum Functionality
2.1 App Completeness
5.1.1 Privacy / data use
Sign in with Apple
Privacy nutrition labels
What you walk away with

Three things, not one

01

A real app in TestFlight

Installable on a physical iPhone and submitted to App Store review — booting, authenticating, behaving native.

02

An OS-neutral playbook

THE-PATH.md — clone → configure → cloud-build → ship. Your team can run this again without us.

03

A launch kit

Icon, device-framed screenshots, store listing copy and keywords, privacy labels, and a short demo — everything day one needs.

The offer

Have a Lovable app you want in the App Store?

From a React web app to a submitted, native iOS app built in Flutter, same-day — shipped through your GitHub, senior engineers on the keys, AI under guardrails. Because it's Flutter, Google Play is a short hop, not a second project.

Book a build slot See the playbook

Let's put it in the review queue this week.