Mobile App
React Native Mobile App Development
Cross-platform iOS and Android apps built with Expo — one codebase, both stores, shipped through App Store review with real rejection experience.
Building a mobile app is not the hard part. Shipping it — through Apple's review process, with the right auth setup, without triggering IAP policy violations — is where most first-time app projects stall. MassageGo iOS was my first App Store submission. It got rejected on three counts and approved on the second build. That experience is now part of every mobile project I take on.
Start a project →What makes this niche different
The real challenges of building for mobile app
App Store compliance from day one
Apple's review guidelines are long, inconsistently applied, and occasionally updated without notice. The most common first-time rejections — missing privacy manifest entries, incorrect Apple Sign-In button appearance, missing account deletion flow — are all avoidable if you know to look for them before submitting, not after.
In-app payment restrictions
Using Stripe or any third-party processor for digital goods or subscription services sold within an iOS app will get the app removed from the App Store. Apple requires IAP for in-app transactions and takes 15–30% commission. Most service platforms are better served by handling payment on the web and using the app as a companion — a decision that has to be made in the architecture phase, not after launch.
Cross-platform parity without doubling the work
React Native shares 90%+ of code between iOS and Android, but the platforms diverge on permissions, navigation gestures, font rendering, and keyboard behaviour. Designing for parity from the start — rather than building for iOS and retrofitting Android — avoids a full second QA cycle before Play Store submission.
Push notifications end-to-end
Push notifications in a React Native app involve APNs certificates, device token management, a server-side delivery queue, permission request timing, and deep link routing from the notification to the right screen. Each of these can fail silently. Getting the full stack right — from server event to user tap — requires testing on a real device, not just the simulator.
Offline behaviour and sync
Users expect apps to work when their connection drops. Deciding which data to cache, how long to keep it, and how to queue and replay actions taken offline is an architectural decision that cannot be retrofitted cheaply. For service apps — booking, ordering, messaging — offline handling is the difference between a usable product and one that shows a spinner and times out.
OTA updates vs full releases
Expo's EAS Update lets you push JS and asset changes without App Store review — useful for bug fixes and UI tweaks. But updates that touch native code still require a full build and submission. Knowing which changes require a full release and which can be pushed OTA is essential for maintaining a fast post-launch iteration cycle.
Live examples
What I've built in this space
On-demand massage booking app for iOS. Built with Expo SDK 54 and React Native, featuring Apple Sign-In, real-time booking notifications via Supabase Realtime, and a provider dashboard. Submitted and approved through the App Store review process — including resolving a three-count rejection covering privacy manifest compliance, Apple Sign-In button requirements, and account deletion functionality.
FAQ
Common questions about mobile app platforms
- Why Expo and React Native instead of native Swift?
- Swift gives you the deepest iOS integration and best performance, but you end up maintaining two separate codebases for iOS and Android. React Native shares 90%+ of the code between platforms. For product apps — booking flows, directories, dashboards, marketplaces — the performance difference is imperceptible to users. The cost and time difference is very real. Expo adds a managed build and submission pipeline on top, removing most of the Xcode pain.
- What are the most common reasons an app gets rejected by Apple?
- From direct experience: missing privacy manifest entries (required for any app using certain APIs or third-party SDKs), non-compliant Apple Sign-In button (must use the official ASAuthorizationAppleIDButton component, not a custom-styled button), and missing account deletion functionality (required if the app has user accounts). All three are avoidable if you check for them before first submission.
- Can I update my app without going through App Store review?
- Yes — Expo's EAS Update lets you push JavaScript and asset changes directly to users' devices without a review cycle. This covers UI changes, bug fixes, and content updates. Changes that touch native code — new permissions, new native modules, binary changes — still require a full build and App Store submission.
- How do I handle payments in an iOS app without violating Apple's policies?
- For digital goods and subscription services sold within the app, Apple requires IAP (In-App Purchase) and takes 15–30% commission. For physical goods and services fulfilled outside the app (a massage booking, a restaurant reservation, a physical product shipped to you), third-party payment processors like Stripe are permitted. Most service platforms handle payment on the web and use the app as a companion — avoiding the IAP commission entirely.
- How long does it take to build and ship a React Native app?
- A focused iOS app with auth, core feature set, and push notifications typically takes 6–10 weeks from kickoff to App Store approval. Apple's review process adds 2–5 days on top of build completion. Adding Android extends the project by 1–2 weeks. Complex apps with real-time features, maps, or intricate booking flows take longer — typically 10–14 weeks total.
Building in mobile app?
Tell me what you're building. I'll reply within 48 hours with an honest assessment and estimate.
Get in touch →