I am Muhammad Adil. I live in Sydney and I build a React Native fitness app Sydney studios can actually run — iOS and Android, trainer publishing, and a payment that still works on Monday morning. People find me after they have already looked at a generic gym template, a no-code builder, or an agency slide that says “we do mobile”. None of those tell you how a trainer publishes a workout, how a member pays, or what happens when a class video fails to load at 6am. That is the work I take.
This is a first-person note on how I actually ship a React Native fitness app in Sydney — not a feature list. If you want the services menu, it lives under app development. If you want to see two products in this lane, read the Di Lorenzo fitness app and the Feels at Home fitness app case studies. If you are still deciding who should sit in the repository, I already wrote how to hire an AI or React Native developer in Sydney.
A fitness app is a product, not a React Native demo
Most briefs I see start with the stack. “We want React Native.” That is a reasonable choice for a studio that needs one codebase on iPhone and Android. It is not the product. The product is the two screens a member opens every week, and the admin surface a trainer can use without calling a developer.
For a diary-style health app those screens are usually today’s calories and today’s workout. For a branded studio they are usually “play this session” and “am I still subscribed”. Everything else — onboarding copy, badge screens, a dark mode toggle — can wait until those two paths work on a real device with a real Apple or Google account.
I will not invent a third app around a calorie widget. React Native is a good client for a boring, well-named API. It is a poor place to invent your entire business. If you do not yet know whether members book classes, log food, or stream trainer video, you do not have a mobile problem. You have a product problem. I would rather sort that in a short written scope than start a repo full of empty tabs.
The three shapes I keep seeing
Fitness products in this city are not one category. I keep seeing three shapes, and they want different first slices.
The first is a unified diary: workouts, nutrition, recipes and a subscription for Pro content. That is the Di Lorenzo shape. Trainers author workouts. Members log meals against a calorie target. Partners and staff need a CMS that publishes without an App Store round-trip.
The second is a branded studio product that has to live outside the room: trainer-led video, multi-week challenges, and a paywall that works on the phone and in the browser. That is the Feels at Home shape. The hard parts are video upload, entitlements, and an ops CMS a non-technical person can actually use.
The third is a class-booking and membership app. I still start with “book a class” and “pay for a membership”. I do not start with a social feed. If your studio lives and dies on the 6am spin list, the first vertical slice is that list, the waitlist, and the payment that keeps the member in it.
When someone asks me for “a React Native fitness app Sydney gyms use”, I ask which of those three they mean. The stack can look similar. The first eight weeks should not.
Di Lorenzo: one diary instead of two apps
Most fitness apps split workouts and nutrition. Di Lorenzo needed one experience: personalised calorie targets, trainer-authored workouts, and a recipe catalog that staff could update without waiting on a store release. I led that work as technical lead across mobile, API and dashboards over several years. I am not going to dress that up with vanity metrics. The useful facts are in the case study.
The mobile client is React Native with Expo. The API is a Node/Express service with domain modules for users, workouts, recipes, payments and blog, on MongoDB Atlas. Stripe covers web subscriptions; Apple and Google in-app purchase paths cover Pro content on the stores. A React admin CMS is the primary publishing surface. Trainers and partners can ship content without a mobile redeploy. Client insights sit in the same place: onboarding, calories, food log, workout adherence.
The lesson I still use on new work: do not make the home screen perform seven round-trips to paint a day. Aggregate on the server. Cache on the client with a stale-while-revalidate path so the diary feels instant when someone flicks between dates. That is unglamorous. It is also the difference between a demo and an app someone opens before breakfast.
If your brief is “workouts plus nutrition in one product, with a CMS”, read the Di Lorenzo case study before you send me a feature spreadsheet. The spreadsheet will be longer than the first slice you actually need.
Feels at Home: video, challenges and a paywall that works twice
Feels at Home needed a branded product beyond a generic studio template: trainer-led workout video and multi-week challenges, with subscriptions on phone and browser, plus an ops CMS for large video uploads. Expo on mobile, Next.js on the web, a React admin, and one Express API in front of Supabase. RevenueCat on native. Stripe on web. Cloudflare Stream for resumable video.
The store-compliance work is part of the product, not a launch-week surprise. Auth has to cover verify, reset, refresh rotation, and self-service deletion. I treat that as in-scope for a React Native fitness app, because Apple and Google will send you back if it is missing.
The other lesson: native entitlements and web checkout are not the same payment. Members will start on an iPhone and later open the site. If those two gates disagree, you will spend the month in support. RevenueCat on the device and Stripe on the web only work if the API is the source of “can this person see this challenge”. The clients should not invent their own truth.
Staff publish workouts and challenges with video without a developer release for every upload. That is the test I use when a founder says they want a CMS. If a trainer still needs me to cut a build to change a session, you do not have a CMS. You have a bottleneck with my name on it. The Feels at Home case study is the public write-up of that shape.
What I actually ship in React Native
I use React Native and Expo when both stores matter and the product is a client over an API. I use EAS for builds and over-the-air updates for the copy and the JS that should not wait on review. I do not treat OTA as a way to sneak past the stores. Native modules, permission prompts and payment SDKs still go through review. Anyone who tells you otherwise has not shipped a fitness paywall.
Push is a product decision. A class reminder is useful. A daily “come back and streak” blast is how you get deleted. I want the permission prompt next to a reason the member already understands, not on the first launch screen under a logo.
I work in the repository you will keep. I do not hide a fitness app in a private agency monorepo and hand over a zip at the end. You should be able to fire me and still ship a build. That is the same test I wrote about in the hiring guide, and I apply it to my own work.
I will quote a first slice with named screens, not “the app” as if the App Store were a PDF. For a diary product that slice is usually home, log, and one workout flow. For a video product it is login, paywall, and one playable session. For a studio booker it is the timetable and checkout. The rest of app development — store submission, a thin admin, the API — hangs off that slice, not the other way around.
Sydney hours, gym mornings, store weeks
I am based in Sydney. I will meet in person when a workshop actually shortens the project: first scope, a painful integration, or a store-release week. The rest is written updates and a shared board. Timezone still matters. A contractor in a distant timezone can be excellent. They cannot sit with a trainer at 7am in Marrickville when the check-in flow fails, and they cannot watch an Australian store review land at a civil hour.
Fitness traffic is not evenly spread across the day. Class peaks, Monday programs and January sign-ups all hit the API at once. I would rather load-test the booking or the diary aggregation before launch week than explain an outage to a studio owner who has a room full of people. That is not a metric. It is a calendar.
If you want one built
Write to me with the shape (diary, video studio, or class booker), the two screens that make it real, and who owns the Apple, Google, and payment accounts. I will tell you whether I am free, whether the first paid piece is a build or a review of something you already have, and what I will not do. I do not take Instagram retainers. I do not staff an offshore pod. I build and review software.
If you want a React Native fitness app Sydney can support in Australian hours, start with the hiring note, skim the two case studies, and then send the brief. I will answer in Australian time.
