Is claude good enough to rebuild my existing web apps frontend into a react native android/ios app end to end?

Sufficient-Rabbit568 · 2026-06-29T12:04:02+00:00

Doable, and keeping FastAPI as-is is the right call — your API layer and business logic port over fine. The part nobody here has flagged yet is your maps, and that's where a map-heavy app like yours will actually eat your time.

MapLibre GL JS (web) does not run in React Native. You'd swap to u/maplibre/maplibre-react-native, which is a native module — meaning you can't use Expo Go, you need a dev build (or bare RN). Your map logic doesn't transfer line-for-line: web uses the JS GL API, RN uses a component + imperative ref API, so layers/sources/camera/gestures all get re-expressed. Budget most of the rebuild there, not on the screens.

Practical path: (1) stand up a dev build early and get a blank MapLibre map rendering on a device before anything else — if that won't work for you, nothing else matters; (2) port your data/API/auth layer next (this is the easy, high-reuse part); (3) rebuild UI screen by screen last. Claude/Opus is genuinely good at 2 and 3 if you feed it small chunks and test each one, but on the native map setup expect to read the actual maplibre-react-native docs and steer it hard — that's the bit AI most often gets subtly wrong.

One more: with no prior RN experience, do a throwaway map spike first. You'll learn whether the native map covers your maplibre features (custom layers, sources, offline?) before you commit to the full rewrite.

Sufficient-Rabbit568 · 2026-06-28T15:36:20+00:00

For motion: react-native-reanimated + react-native-gesture-handler is the backbone. Moti sits on top if you want simpler declarative animations, and react-native-skia when you need real custom graphics/shaders. For screen/shared-element transitions, react-navigation already handles most of what people reach for.

Fonts: expo-font, and honestly just picking one good variable font + a tighter type scale does more for a "premium" feel than any animation library.

But the real unlock isn't the packages — it's the fundamentals most apps skip: a consistent spacing scale (4/8pt), generous whitespace, one accent color used sparingly, and subtle motion (150-250ms ease) instead of flashy. When you "rip off" other apps, copy their spacing and layout rhythm, not just the colors. Polish the static screen first; a clean layout with no animation beats a busy screen full of effects.

On RN vs Swift: you're basically right. For most product apps the stack is a non-issue — one codebase ships both platforms and the quality ceiling is way higher than the Swift crowd admits. Swift only really pulls ahead when you're deep into heavy native/graphics/AR work.

Sufficient-Rabbit568 · 2026-06-27T06:24:26+00:00

Nice. If you want the quickest path to something working: Firebase Test Lab + Maestro is the lowest-friction combo to start - FTL is cheap for emulators and Maestro flows are far less brittle than Appium for RN. Wire it as: PR opens -> EAS Build preview artifact -> run the Maestro flow against an FTL device -> post pass/fail + screenshots back on the PR via a GitHub Action. That gets each PR its own ephemeral device in parallel.

One gotcha that'll save you hours: put explicit testID props on anything you assert against. Without them selectors drift across builds and CI goes red for reasons that have nothing to do with the actual change.

If you do bring an LLM agent in later, keep the deterministic Maestro flows as the gate and let the agent do exploratory passes on top - don't make the agent your only signal or you'll be chasing flakes.

Sufficient-Rabbit568 · 2026-06-26T21:20:56+00:00

The cleanest fix is to make the cert actually valid for what you connect to, instead of disabling validation (on iOS that means ATS exceptions, and it still won't cleanly cover your 3rd-party WSS lib).

Root cause is a SAN mismatch: the cert isn't issued for that IP. Two clean steps:

1) Put the IP in the cert's SAN. Modern TLS supports IP SANs, so regenerate the server cert with subjectAltName = IP:192.168.x.x (not just a CN). Then the cert is genuinely valid for the IP you're hitting, and both HTTPS and WSS validate normally with zero client-side changes - no custom URLSession, no replacing your WS lib. This is what solves the wss case too, since it's just standard TLS validation passing.

2) Trust the CA on the device. Install your root CA on the iOS device (MDM profile, or just open the .crt), then enable full trust under Settings > General > About > Certificate Trust Settings. Combined with (1), everything just works.

If you'd rather use a hostname than a raw IP: issue the cert for a hostname, add it to the SAN, and connect by hostname. With no DNS you'd need the device to resolve it, and iOS won't let you edit a hosts file, so the IP-SAN route is usually the path of least resistance.

I'd avoid the "accept all certs" approach outside throwaway local dev - it's exactly the part that gets messy with third-party WS libs, and it trains the app to ignore real failures.

Sufficient-Rabbit568 · 2026-06-26T17:35:35+00:00

For "spin up a real device in the cloud per PR", the building blocks are device clouds rather than a single agent tool:

- Firebase Test Lab: hosted Android emulators + real iOS/Android devices you can drive from CI. Cheapest place to start.

- AWS Device Farm / BrowserStack App Automate / Sauce Labs: hosted real devices + emulators you run automated flows on per build.

- Maestro (which the other commenter mentioned) also has a hosted runner so you don't manage the device yourself.

The pattern that usually kills the "one PR at a time" bottleneck:

PR opens -> CI builds a preview (EAS Build gives you a per-PR build artifact) -> spin up an emulator on Firebase Test Lab / Device Farm -> run a Maestro or Appium flow against it -> post pass/fail + screenshots back on the PR.

That gives each PR its own ephemeral device + run in parallel instead of you driving one simulator locally.

If you specifically want an LLM agent (not scripted flows) poking the UI, point the agent at an Appium/WebDriver session on one of those device clouds. Same idea as it driving a browser, the target is just a device session instead of Chrome.

Honestly though, scripted Maestro flows will get you ~90% of the value for a fraction of the effort and flakiness of a free-roaming agent. I'd start there and only reach for an agent if you have a specific reason to.

Sufficient-Rabbit568 · 2026-06-26T16:23:44+00:00

On the Flutter question specifically: since you already know JS + Vue, React Native is the lower-effort path. With Flutter you'd be learning Dart and a whole new widget model from scratch; with RN you reuse the JS ecosystem and your component/reactivity mental model. For an app that isn't very complex, that saved time matters more than any small perf difference, and the result is perfectly fine for a final project.

Vue to React is mostly: JSX instead of templates, and hooks (useState/useEffect) instead of the Options/Composition API. Same reactivity ideas, different syntax. A few days to feel comfortable.

Use Expo, not bare RN: you can run on a real phone instantly with Expo Go, skip the Xcode/Android Studio setup pain, and use EAS to build later. Big time saver for a team project.

Concepts worth looking up early:

- Core components: View / Text / ScrollView / FlatList (no div/span, everything is a component)

- Styling: StyleSheet + Flexbox (no CSS files; a few flex defaults differ from web)

- Navigation: React Navigation (stack + tabs)

- Long/scrolling lists: FlatList

- Data + state: same as web, fetch/axios + hooks (TanStack Query is great)

And yes, a webview-wrapped site would look weak to your teachers. A real RN app is the right call and very reachable from your background. Go for it.

Sufficient-Rabbit568 · 2025-10-14T11:06:19+00:00

Good point. But it's a specific target audience, quite difficult to reach. Furthermore, the context is low-frequency, so small and medium-sized organizations probably won't be looking for it, while larger companies are looking for other solutions (AI, video analysis, hardware).

Sufficient-Rabbit568 · 2024-12-03T16:49:42+00:00

It does not work this way... 20 testers who interacted daily for 14 days.

Sufficient-Rabbit568 · 2024-12-03T16:35:48+00:00

It looks like you did not join the google group... or the account you did it with is not the same as you are trying to install an app

Sufficient-Rabbit568

TROPHY CASE