Shipping LiftCrew AI: Our Journey Building an AI-Powered iOS Fitness App

The brief: group gym training, AI-personalized

Most fitness apps optimize for a single user. LiftCrew started with a different premise: people train better in groups, but a group of friends rarely shares the same strength baseline. Our co-founder pictured a crew of four hitting the same exercise, on the same set, at the same moment — each with the right weight on the bar for their own body. That deceptively simple idea became the product's core primitive: same exercise, individualized weight.

Building it required a tight loop between an AI model that understands programming, a realtime layer that keeps a distributed crew in lockstep, and an iOS experience that feels native enough to disappear during a heavy set.

Why React Native + Expo for iOS (and why it's still native enough)

We chose React Native 0.81 on the New Architecture (Fabric + TurboModules) and Expo SDK 54 with expo-router 6 for file-based navigation. That stack let us share a single codebase across iOS and Android while still reaching for native iOS modules where the experience matters: native expo-apple-authentication for Sign in with Apple, native StoreKit 2 via react-native-purchases (RevenueCat), the iOS camera roll via expo-image-picker, and Reanimated 4.3 for 60fps animations on the UI thread.

The result is an app that submits cleanly through Apple review (App Store Connect ID 6762237223, Team C23ARGS845), respects Apple Human Interface Guidelines, and gets JavaScript-bundle OTA updates via EAS — without giving up the things iOS users actually feel.

The AI: Claude as the workout coach

The AI Coach generates a per-session plan when a crew starts a workout. The model receives crew composition, each member's 1RM baselines, recent session history, equipment at their gym, and the day's training intent. It returns a structured JSON plan with exercises, set/rep schemes, and a per-member weight prescription.

We default to Claude Haiku 4.5 for speed and cost, with a cascade up to Claude Sonnet 4 for harder programming and for vision (meal photo analysis). Critically, the API key never leaves the server: every AI call goes through a Vercel serverless proxy at /api/generate-workout, authenticated with the user's Supabase JWT. The app bundle contains zero secrets — the only Anthropic key lives in Vercel environment variables.

On top of that we layered a 1-hour client-side response cache (so re-opening the same plan doesn't cost tokens), exercise-substitution mid-session (the model recalculates the swap weight based on the relative intensity), and a deliberately short retry budget so a flaky network never blocks the user from training.

Realtime crew sync without a custom backend

Crew sessions are the social heart of the app. Four people in three different gyms have to feel like they're training together: when someone completes a set, everyone sees it; when the rest timer ends, everyone advances; when someone hits a PR, the whole crew gets the confetti.

Rather than build a bespoke realtime service, we leaned on Supabase Realtime WebSocket broadcasts. Every set completion, exercise advance, and member state change pushes a small event into a session-scoped channel. The local Zustand store applies it optimistically and falls back to AsyncStorage if the network drops mid-set — the lift is sacred, the sync is best-effort.

PR detection runs client-side using the Epley formula against each user's stored 1RM. When a session ends, the highest estimated 1RM per lift is committed back to the profile and broadcast to the crew feed. Tied PRs surface all co-winners, because the social loop matters more than the leaderboard.

Photo meal logging with Claude vision

Nutrition was originally going to be a manual food-search screen. We threw it out after the first prototype — nobody wants to type "chicken breast, 142g" after a leg day. Instead, the user takes a photo of their plate and Claude Sonnet's vision capability returns calories and macros in a structured JSON shape that drops straight into the daily totals.

Behind that is a Mifflin-St Jeor BMR/TDEE calculator that sets the user's targets, daily progress rings that animate as meals come in, and a 5-day rolling history persisted as a JSONB column on the user's Supabase profile. Sign-out and reinstall don't lose the data — that turned out to be one of the highest-impact decisions we made.

Crew challenges: turning workouts into a season

Crew challenges are how friends keep showing up. The app supports four scoring modes — volume (total kg lifted), sessions (count of workouts completed), PRs (number of personal records), and streaks (consecutive training days). When a session closes, participating challenges automatically tally and the standings update for the whole crew.

The scoring engine lives entirely in Supabase functions and Postgres — there is no separate challenge service. RLS policies make sure a user only ever sees challenges scoped to a crew they actually belong to. It's an old-fashioned lesson: when your data layer is good, you don't need many services.

The hard parts: payments, trials, and Apple review

We used RevenueCat with native StoreKit 2 on iOS and Google Play Billing on Android. The entitlement is a single pro flag, products are liftcrew_pro_monthly_v2 (CA$4.99/mo) and liftcrew_pro_yearly_v4 (CA$39.99/yr). The 15-day free trial is server-enforced in a subscriptions table anchored to auth.users.created_at — because client-side trial clocks are an open invitation to date-spoofing and reinstall abuse.

A RevenueCat webhook at /api/revenuecat-webhook mirrors every subscription event back to Supabase, so a lapsed user is gated on the next launch even if their receipt cache is stale. The paywall itself dismisses automatically the moment the entitlement flips.

Apple review surfaced one big requirement we hadn't planned for: Guideline 1.2 compliance — user-generated content needs a way to report and block other users. We added a user_reports table, a block list on connection requests, and an delete_own_account RPC so users can purge their account end-to-end. The app cleared review on the next submission.

The architecture, in one paragraph

React Native 0.81 + Expo 54 on the client. Zustand for state, persisted to AsyncStorage and synced to Supabase JSONB columns so the app survives reinstall. Supabase Postgres with RLS across nine tables for users, sessions, exercises, crew connections, gyms, challenges, push tokens, subscriptions and reports. Supabase Realtime for live crew sessions. Vercel serverless functions for the AI proxy, RevenueCat webhook, push sender and a Gmail-to-Linear support agent. Claude for AI. RevenueCat for payments. EAS Build for cloud iOS/Android compilation. Bebas Neue and DM Sans for type, lime #d4ff5a on #0d0d0f for the look.

What we'd do again — and what we wouldn't

• Do again: server-side AI keys behind a JWT-authenticated proxy. Non-negotiable.
• Do again: JSONB columns for evolving user-state shapes (settings, meals, plans). They moved faster than schema migrations would have.
• Do again: RevenueCat. The webhook + StoreKit 2 combination paid for itself the first time we needed to reconcile a refund.
• Wouldn't again:launching without Apple 1.2 compliance scoped from day one. We knew intellectually we'd need report/block; we should have shipped it in the first build.
• Wouldn't again: a client-side trial clock — even as a placeholder. Move it server-side first.

Want this for your iOS app?

LiftCrew AI is one of several iOS apps SEYSO SERVICES INC has designed and shipped. If you have an idea — AI-powered, fitness, productivity, B2B — and you want a partner who can take it from a sketch to a live App Store listing, we'd love to talk. Native Swift, SwiftUI, React Native, Expo, AI integration, App Store Optimization, the long tail of Apple compliance: it's what we do.