I've spoken with dozens of founders who burned six figures on the wrong mobile development approach. Not because their idea was bad — because nobody gave them a straight technical answer before they signed a contract.
This guide fixes that.
The First Decision: Android, iOS, or Both?
Most "go build both" advice is lazy. Here's the engineering reality:
| Factor | Android | iOS |
|---|---|---|
| Market Share | ~71% globally | ~28% globally |
| Dev Program Fee | $25 one-time | $99/year |
| Review Process | Faster, flexible | Strict, higher bar |
| User Retention | Lower (region-dependent) | Consistently higher |
| Primary Language | Kotlin / Java | Swift / Objective-C |
| Best For | Global reach, emerging markets | Enterprise, North America |
Rule of thumb: If your B2B buyers are enterprise decision-makers in North America or Europe, ship iOS first. If you're targeting SMBs in Southeast Asia, LATAM, or Africa, Android first.
Shipping both simultaneously stretches your QA surface, doubles your App Store maintenance burden, and splits your developer's focus. One polished app beats two mediocre ones every time.
Native vs. Cross-Platform: The Technical Trade-off Nobody Explains Clearly
Native (Swift / Kotlin)
Built separately per platform. Direct access to platform APIs — Face ID, Apple Pay, Android Widgets, background services, push notification handling at the OS level.
Choose native when:
- You need real-time data sync (WebSockets, live queries)
- App relies on hardware: camera pipelines, GPS, biometrics
- You're building for enterprise users with high UX expectations
- Heavy API traffic is core to the product
Cross-Platform (React Native / Flutter)
Single codebase compiled or bridged to both platforms. React Native uses a JavaScript bridge to native modules. Flutter compiles to native ARM via Dart — generally better performance than RN for animations and graphics.
Choose cross-platform when:
- You're shipping an MVP to validate PMF
- App is content-driven: dashboards, portals, data display
- Feature set is stable and unlikely to need deep native hooks
- Budget is a real constraint (expect ~30–40% cost reduction vs. two native builds)
The Trap Founders Fall Into
They pick React Native to save money in sprint 1, hit framework limitations in sprint 8, and spend more on native module bridging than they saved upfront.
Choose your stack based on your 18-month product roadmap — not your current sprint.
The Dev Stack Reference: What to Expect From a Serious Developer
📱 iOS Native
Language: Swift 5.x
UI Framework: SwiftUI / UIKit
Async: Combine / async-await
Dependency: Swift Package Manager
🤖 Android Native
Language: Kotlin
UI Framework: Jetpack Compose / XML Views
Async: Coroutines + Flow
Dependency: Gradle
⚛️ Cross-Platform: React Native
Language: TypeScript
Navigation: React Navigation
State: Redux Toolkit / Zustand
Native Bridge: Expo Modules / bare workflow
🐦 Cross-Platform: Flutter
Language: Dart
State: Riverpod / Bloc
Platform: iOS, Android, Web, Desktop
If a developer can't speak fluently about at least one column here, keep looking.
API Architecture: Where Most B2B Apps Break
B2B apps are integration-heavy by nature — CRMs, ERPs, payment gateways, internal tooling. This is where mobile development gets genuinely complex.
What your developer needs to handle:
- RESTful API consumption with proper error handling, retry logic, and auth token refresh (OAuth 2.0 / JWT)
- Offline-first architecture — what happens when a field sales rep loses signal mid-demo? Your app needs local caching with conflict resolution on sync.
- Push notification pipelines — APNs (Apple) and FCM (Firebase/Google) have different payload structures and delivery guarantees. A developer who conflates them will cost you support tickets.
- Background sync — iOS App Refresh and Android WorkManager behave very differently. Background tasks that work on Android often get silently killed on iOS due to battery management policies.
5 Technical Red Flags in a Developer Interview
- They can't explain what a retain cycle is (iOS) or a memory leak is (Android). Memory management is day-one knowledge.
- Their portfolio only has Expo apps. Expo is a valid starting point, but a developer who has never ejected or built a bare RN workflow hasn't solved real problems.
- They quote a fixed price before scoping. Legitimate engineers scope before pricing. A fixed quote before a PRD exists is a guess dressed up as a number.
- No mention of testing. Ask about their unit testing approach (XCTest, JUnit, Jest). If they look blank, their codebase is a liability.
- They've never handled an App Store rejection. Both stores reject apps. A developer who hasn't navigated a rejection hasn't shipped enough.
App Store Submission: What Developers Often Skip
App Store review isn't just a formality — it's a technical gate that catches real issues.
Apple App Store checklist:
- [ ] Privacy manifest files for all third-party SDKs (required since iOS 17)
- [ ] App Tracking Transparency prompt if using IDFA
- [ ] No use of private APIs (automated scan catches this)
- [ ] Screenshots for all required device sizes
- [ ] Correct entitlements in the provisioning profile
Google Play checklist:
- [ ] Target API level meets current Play policy (usually n-1 of latest Android)
- [ ] 64-bit compliance for all native libraries
- [ ] Declared permissions match actual usage
- [ ] Data safety section completed accurately
Your developer should own this end-to-end — including handling rejections with written responses to reviewers.
Cloud Integration: Extending App Capability Without Rebuilding
For B2B apps, the mobile client is often the thin end of a much heavier backend. Get this architecture right and you can ship features faster without app updates:
- Firebase — Auth, Firestore for real-time sync, Cloud Messaging for push, Crashlytics for crash reporting. Best for fast iteration.
- AWS Amplify — Better for teams already in the AWS ecosystem. More control over infrastructure.
- Custom REST/GraphQL backend — Necessary when you need complex business logic, fine-grained access control, or enterprise SSO (SAML, OIDC).
The key insight: push business logic to the backend. The more logic lives server-side, the faster you can iterate without waiting on app store review cycles (which can take 24 hours to 7 days).
TL;DR
- Start with one platform based on your buyer geography
- Choose native for performance-critical B2B apps; cross-platform for MVPs
- Vet developers on their live shipped apps, API experience, and testing discipline
- You must own your IP — get this in the contract before anything else
- Push logic server-side to reduce dependency on app store review cycles
Building something and hit a wall deciding between native and cross-platform? Drop your use case in the comments — happy to give a direct take.
Top comments (0)