Frequently Asked Questions
Should we build native iOS/Android or use React Native?
React Native is the right default for most products. A shared JavaScript/TypeScript codebase reduces development and maintenance cost significantly, and performance is near-native for standard UI interactions. Choose native when: you need complex animations at 120fps, you require deep integration with platform-specific APIs unavailable in React Native (e.g., specific ARKit features, HealthKit granular access), or your product has extreme performance requirements (real-time video processing, game rendering). The productivity advantage of React Native outweighs native performance for 80%+ of mobile products.
Do we need offline support?
Ask: what happens when a user opens the app with no internet connection? If the answer is 'the app shows an error' — do you accept that for your use case? Consumer apps where users expect to view their data (banking app showing balance, food app showing order history) need at minimum read-offline with cached data. Apps used in the field (logistics, healthcare, field service) need full offline read/write with sync. Offline-first is an architectural commitment — it cannot be added as a feature later without a significant rebuild.
How long does an App Store review take?
Apple App Store reviews typically take 24-48 hours for new apps and updates, with expedited review (1-2 days) available for critical bugs affecting users. Rejected submissions require a resubmission cycle that adds 2-5 days. Google Play reviews typically take 1-3 days. Both stores have extended review times around holidays and for apps in sensitive categories (financial, health, kids). Build App Store review time into your launch planning — do not plan a same-day release after submission.
How do we ensure a high crash-free rate?
Crash-free rate above 99.5% requires: crash monitoring from day one (Firebase Crashlytics or Sentry with symbolication), automated regression testing for core user flows, device fragmentation testing on physical devices or a device farm, memory pressure testing to catch low-memory crashes, and a triage process for crash reports within 24 hours of detection. The goal is never to ship a regression that causes visible crashes — automated testing and crash monitoring together prevent the majority of preventable crashes.
What are App Store privacy requirements we need to prepare for?
Apple requires a Privacy Manifest (PrivacyInfo.xcprivacy) declaring all data collected and its purpose, an App Privacy label in App Store Connect accurately reflecting all tracking and data collection, permission usage strings for every sensitive API (camera, location, contacts, etc.) and App Tracking Transparency framework for any advertising tracking. Google Play requires a data safety section in the Play Console. Both stores actively reject submissions with inaccurate privacy declarations. We build privacy compliance into the architecture, not as a last-minute checklist.
How do we handle push notifications reliably?
Push notification reliability requires: APNs and FCM direct integration with your backend, notification payload design that works with background processing (content-available for silent pushes, alert notifications for visible ones), retry logic for failed deliveries, delivery receipt tracking, notification permission request timing (never on first launch — request after demonstrating value), and separate notification types for engagement vs transactional. Notification open rate and delivery rate should be monitored as product metrics.
How do we support multiple languages and regions?
Internationalisation (i18n) requires: all user-facing strings extracted to localisation files (NSLocalizedString on iOS, strings.xml on Android), layout testing for languages with longer strings (German, Finnish) and RTL support for Arabic and Hebrew markets. Localisation should be set up from the first sprint — retrofitting i18n onto a product with hundreds of hardcoded strings is a week-long task per language. If international markets are in scope, we design for localisation from day one.
What is the difference between TestFlight and App Store distribution?
TestFlight is Apple's beta testing platform — you upload a build to App Store Connect, add testers by email or public link, and they install via the TestFlight app. TestFlight builds expire after 90 days and require a build review that is lighter than full App Store review but still takes 24-48 hours. App Store distribution is for production release — requires full App Store review and full privacy metadata. Google Play has equivalent Internal Testing, Closed Testing and Open Testing tracks with different review requirements and user access controls.
How do we implement in-app purchases correctly?
In-app purchases (StoreKit 2 on iOS, Play Billing Library on Android) require: product configuration in App Store Connect/Play Console, receipt validation on your backend against Apple/Google servers to prevent fake purchase claims, subscription state management for renewals and cancellations, handling of family sharing and promotional offers, and server-to-server notifications for subscription lifecycle events. Apple takes 15-30% of in-app purchase revenue and enforces its in-app purchase requirement strictly for digital goods.
How long does a mobile app take to build?
A production mobile app with authentication, core features, API integration, offline support, push notifications and App Store submission takes 14-22 weeks from architecture to launch. Simple utility apps with 3-5 screens take 8-12 weeks. Complex apps (real-time features, custom hardware integration, extensive offline) take 20-32 weeks. React Native apps sharing 70%+ code across iOS and Android save 30-40% vs native dual builds. We deliver in two-week sprint cycles with TestFlight/beta releases at each milestone.
