Building an App: Lessons Learned

Expo is the best cross-platform framework right now. It handles native modules, OTA updates, build tooling (EAS), and has a massive ecosystem of pre-built packages. You write once and deploy to both platforms without touching Xcode or Android Studio for most things.

Other solid options: React Native (bare workflow if you need full native control), Flutter (Dart-based, great UI toolkit from Google), and .NET MAUI (if you're in the Microsoft/C# ecosystem). Each has trade-offs, but for most indie builders, Expo is the fastest path to both stores.

If you're only targeting iOS, skip the cross-platform overhead entirely. Go straight Swift with SwiftUI — it's Apple's native framework and gives you the best performance, tightest OS integration, and access to every new API on day one.

Both Apple and Google require a privacy policy URL and terms of service before you can submit your app. This isn't optional — your app will get rejected without them. Apple checks these during review, and Google requires them in the Play Console before you can even publish.

You can host them as simple pages on your website, or use a free generator to get started. Just make sure they're accessible via a public URL and actually describe what your app does with user data.

Don't leave this for the last minute. Set them up early, link them in your app's settings screen, and make sure they're referenced in your store listing.

Apple Developer Program costs $99/year. You need it to distribute on the App Store, test on physical devices via Xcode, and access APIs like push notifications, Sign in with Apple, and CloudKit. No license = no App Store.

Google Play Developer registration is a one-time $25 fee. That's it. You pay once and you're in forever. The barrier to entry is much lower, which is why the Play Store has more apps (and more junk).

If you're bootstrapping, factor these into your costs from day one. The Apple fee renews annually — if it lapses, your apps get pulled from the store.

If your app uses AI (OpenAI, Claude, Gemini, etc.), both stores now require you to disclose what user data is sent to third-party AI services. Apple updated their guidelines to specifically address this — you need to explain what data leaves the device, which APIs receive it, and how it's processed.

Google has its own AI-generated content policy. If your app generates content using AI, you need to be transparent about it. This includes labeling AI-generated content and disclosing third-party AI service usage in your data safety section.

Be specific in your privacy policy: 'We send your workout data to the OpenAI API for coaching recommendations' is better than 'We use AI features.' Reviewers read these now.

Apple and Google both require that your paywall screen includes links to your Terms of Service and Privacy Policy. If you have a free trial, you must clearly state how long it lasts, what happens when it ends, and how much the user will be charged. This is a top rejection reason.

Add these links at the bottom of your paywall. Make the trial terms impossible to miss — not buried in fine print. 'Start your 7-day free trial. $9.99/month after.' That's it. Clear, honest, visible.

If your app uses AI features behind the paywall, add a disclosure about what data the AI processes. RevenueCat's paywall components have built-in support for terms/privacy links — use them.

If your app uses location services, you don't need to run around outside to test it. Xcode's iOS Simulator lets you set custom GPS coordinates, simulate routes (like a freeway drive), and load GPX files with custom paths. Android Studio's emulator has the same — Extended Controls lets you set lat/long or simulate GPS routes.

For more realistic testing, build a development version and install it on your actual phone. This is especially important for background location, geofencing, and GPS accuracy testing — simulators don't perfectly replicate real-world GPS behavior.

Either way, test GPS early. Location permissions, background tracking, and battery impact are all things that behave differently on real devices vs simulators.

To build and run a dev version of your app on a physical iPhone, you need an active Apple Developer license ($99/year) and Developer Mode enabled on your device. Without both, Xcode won't let you install your app.

Enable Developer Mode in Settings > Privacy & Security > Developer Mode (iOS 16+). Then in Xcode, select your iPhone as the build target and hit Run. Xcode handles provisioning profiles and signing automatically if you're signed into your developer account.

First-time setup takes a few minutes — Xcode needs to register your device and create certificates. After that, building to your phone is one click.

Android builds are faster and simpler. You can build an APK or AAB from the terminal with a single Gradle command (./gradlew assembleDebug or bundleRelease), transfer it to your phone, and you're testing. No IDE required for the build step.

iOS? You need Xcode. Period. Even if you use Expo and EAS Build for production builds, local dev builds still need Xcode for the simulator and device deployment. Xcode is slow, takes up 15+ GB of disk space, and the build process is noticeably longer than Android.

This isn't a deal breaker — it's just reality. Budget more time for iOS builds and testing. If you're on a tight timeline, get your Android version stable first, then tackle iOS-specific issues.

Permissions work differently on each platform. On iOS, you add purpose strings (NSLocationWhenInUseUsageDescription, etc.) to your Info.plist explaining why you need the permission. The system shows these when requesting access. That's it — Apple doesn't require a separate disclosure screen.

Android is stricter for background permissions. Google Play requires a 'prominent disclosure' — an in-app screen that clearly explains why you need background location (or other sensitive permissions) before you request them. If you skip this, your app gets rejected.

Build a permissions flow that handles both: on Android, show the disclosure screen first, then request the permission. On iOS, just request it with a clear purpose string. Use Platform.OS checks to handle the difference.

If you want to build for Apple Watch, you need a separate Swift/SwiftUI target that builds alongside your iOS app. The Watch app lives in its own directory within the Xcode project and communicates with your iOS app via WatchConnectivity.

If you're using Expo, you can't build a Watch app purely in JavaScript. You need the @bacons/apple-targets config plugin (from Evan Bacon) which lets you add a native watchOS target to your Expo project. It generates the required Xcode project structure and lets your Watch app build alongside the Expo iOS app.

The Watch app itself is written in Swift/SwiftUI — there's no way around that. But the plugin handles the build configuration so you don't have to manually manage the Xcode workspace. It's the bridge between Expo's managed workflow and Apple's native watchOS tooling.