Choosing between native, hybrid, and cross-platform development is one of the first real technical decisions a mobile project forces you to make. It shapes your team structure, your timeline, and what your app can and can’t do. Native apps run closer to the metal, integrate more deeply with device hardware, and perform better, but they’re slower and more expensive to build than cross-platform alternatives.
This article covers 10 real-world native apps, explains specifically why each chose native, and gives you a practical framework for making that call on your own project.
What is a native app?
A native app is a mobile application built for one operating system, iOS or Android, using platform-native languages: Swift or Objective-C for iOS, Kotlin or Java for Android. Native apps compile directly to the device’s OS with no intermediate layer, so they have full access to device hardware (camera, GPS, sensors, background audio) and run faster than hybrid or web alternatives.
What is native app development?
Native development means building separate codebases for iOS and Android, each optimized for its target platform. iOS developers use Xcode and follow Apple’s Human Interface Guidelines. Android developers use Android Studio and Google’s Material Design 3. Fireup’s mobile app development team works with both.
Languages used in native development:
- iOS: Swift (current standard), Objective-C (legacy)
- Android: Kotlin (current standard), Java (legacy)
Building natively requires two engineering tracks — one per platform. That increases cost and development time compared to cross-platform alternatives. But it gives you the highest possible performance and the deepest OS integration available.
Pros and cons of native app development
Advantages
Performance. Native apps run compiled code directly on the device’s OS without any abstraction layer. Load times are faster, animations smoother.
Full device hardware access. Camera, GPS, accelerometer, microphone, background audio, push notifications – all available without the latency a JavaScript bridge introduces.
Platform-native UX. Apps follow each OS’s design language, which means they feel familiar. Users don’t have to learn your interface; it already behaves the way they expect.
Security. Native development gives access to platform-level security: Secure Enclave on iOS, Android Keystore on Android, OS-enforced sandboxing, and mandatory app store vetting.
Offline functionality. Native apps can store data and function without a connection by default.
Early access to new OS features. When Apple or Google ships new APIs – ARKit updates, Dynamic Island on iOS, Predictive Back on Android — native developers can use them on day one. Cross-platform frameworks often lag 3–12 months behind.
Disadvantages
Higher cost. Two codebases mean two teams and roughly 1.5–2× the development budget compared to a cross-platform approach.
Longer time to market. Building for both platforms takes more time, whether you do it sequentially or in parallel.
More maintenance. Bug fixes, feature updates, and OS compatibility patches all have to be applied to each codebase separately.
Platform lock-in. A native iOS app won’t run on Android. If you change platforms, you start over.
10 native app examples and why they went native
1. Spotify
Why native: Spotify depends on uninterrupted background audio playback the kind that keeps working when the screen is off, the phone is locked, and the user is doing something else. That requires direct access to the platform’s audio framework. It also needs OS-level media controls on the lock screen, Bluetooth device integration, and crossfade between tracks.
None of that is impossible in React Native, but it requires custom native modules and introduces enough edge cases that Spotify chose to handle the audio pipeline natively from the start. When they migrated critical audio modules to native code in 2018, background playback reliability improved noticeably on lower-end Android devices.
Native APIs: AVFoundation (iOS), ExoPlayer (Android), MediaSession API, BLE audio profiles.
2. WhatsApp
Why native: WhatsApp’s push notification architecture is worth understanding. On iOS, notification delivery goes through Apple’s APNs infrastructure and requires a specific background entitlement to wake the app for incoming calls. On Android, it uses FCM with a persistent background service. Both need platform-native implementation to work reliably in low-connectivity environments.
End-to-end encryption runs on platform-level cryptographic libraries Secure Enclave on iOS, Android Keystore on Android, not accessible from a WebView layer. Calls also rely on native audio processing APIs to maintain quality under variable network conditions.
Native APIs: CallKit (iOS), Connection Service API (Android), platform cryptography APIs, push notification entitlements.
3. Instagram
Why native: The Instagram camera is not a simple camera integration. Stories, Reels, and live video use real-time AR processing, custom shader effects, and 60fps rendering — all running on the device’s GPU. On iOS that means Metal; on Android, Vulkan. A JavaScript bridge between the app and the graphics layer would introduce visible frame drops.
Instagram uses native code for its entire media pipeline. For less performance-sensitive screens: settings, notifications, some profile pages – they use React Native. It’s a practical split, not a philosophical commitment to one approach.
Native APIs: AVCaptureSession (iOS), Camera2 API (Android), Metal / Vulkan for GPU rendering, ARKit (iOS) for AR effects.
4. Google Maps
Why native: Map rendering is computationally expensive. Google Maps renders vector tiles at 60fps while simultaneously processing GPS input, handling turn-by-turn audio, and recalculating routes in the background. That combination requires direct access to the device’s GPU via OpenGL ES, and background location modes that are tightly controlled by both iOS and Android.
Offline maps add another constraint: downloading and storing several gigabytes of tile data requires direct access to the device file system and a reliable background download manager – both platform-native APIs.
Native APIs: Core Location (iOS), Fused Location Provider (Android), OpenGL ES for tile rendering, SQLite for offline storage.
5. Uber
Why native: Every second of GPS latency in the Uber driver app is a real problem. The app tracks location continuously in the background, updates the map in real time, and receives push notifications instantly for ride matching. Uber also integrates with CarPlay (iOS) and Android Auto, both require native app entitlements and platform-specific APIs that cross-platform frameworks can’t access without custom native modules.
Accurate GPS in dense urban environments also requires sensor fusion (GPS + accelerometer + gyroscope), which native code handles more reliably than a JavaScript abstraction.
Native APIs: Core Location background modes (iOS), FusedLocationProviderClient (Android), CarPlay API, push notification priority APIs.
6. Airbnb
Why native: Airbnb’s story here is worth reading carefully, because it runs counter to the assumption that cross-platform always saves money.
After three years using React Native, Airbnb’s engineering team publicly documented their decision to move away from it in 2018. Their conclusion: the JavaScript bridge introduced performance overhead they couldn’t engineer around for complex UI transitions. Maintaining two codebases, native and React Native, turned out to require more work than maintaining two fully native codebases, because every platform-specific feature still required native code anyway.
Today Airbnb uses SwiftUI (with UIKit for legacy views) on iOS and Jetpack Compose on Android, sharing business logic between platforms via Kotlin Multiplatform. Their investment in UI/UX design work also benefits from tight platform integration — native gesture handling and transition animations are noticeably smoother than what React Native delivered.
Native APIs: SwiftUI / UIKit (iOS), Jetpack Compose (Android), Kotlin Multiplatform for shared business logic.
7. Tesla
Why native: The Tesla app controls physical systems, charging schedules, climate, door locks, remote start. The app stores vehicle authentication credentials in the Secure Enclave (iOS) and Android Keystore, hardware-backed secure storage unavailable to WebView-based or JavaScript-bridged code.
The phone-as-key feature communicates with the car over Bluetooth Low Energy in the background. On iOS, background BLE requires specific entitlements and careful use of Core Bluetooth’s background modes to maintain the connection without excessive battery drain.
Native APIs: CoreBluetooth (iOS), Android Bluetooth Low Energy API, Secure Enclave / Android Keystore, background execution entitlements.
8. Duolingo
Why native: Duolingo’s retention mechanics depend on push notifications delivered at exactly the right time, and on satisfying haptic and audio feedback during exercises. The animated characters that appear during lessons require GPU-accelerated rendering – full frame-by-frame animations, not SVGs.
Streak reminder notifications use platform-native scheduling APIs (UNUserNotificationCenter on iOS, WorkManager on Android) rather than server-sent pushes, so they fire reliably even when the user’s device has poor connectivity.
Native APIs: Core Animation (iOS), Jetpack Compose animations (Android), AVAudioEngine for audio timing, UNUserNotificationCenter / WorkManager for notification scheduling.
9. Pokémon GO
Why native: Pokémon GO combines GPS, AR, gyroscope input, and 3D rendering simultaneously in real time. It’s built on Unity, which compiles to native binaries on both platforms, so it’s native in the sense that matters most: compiled code with direct access to platform APIs.
ARKit (iOS) and ARCore (Android) handle the AR overlay. GPS and gyroscope data feed the map and encounter mechanics. All rendering runs at the graphics layer via Metal (iOS) and Vulkan (Android). A WebView or JavaScript bridge couldn’t sustain that combination at a playable frame rate.
Native APIs: ARKit (iOS), ARCore (Android), Core Location, Metal / Vulkan for 3D rendering, Unity native build pipeline.
10. Revolut
Why native: Revolut handles real-time transactions, and users notice immediately when a financial app feels slow or unreliable. Face ID and Touch ID on iOS, Android Biometric API on Android, all backed by hardware secure elements are the authentication methods users expect, and they require native integration.
Transaction push notifications on iOS are set to critical priority (APNs critical alerts), which bypass Do Not Disturb. On Android, they use high-priority notification channels. That distinction matters when someone’s card is used unexpectedly.
Native APIs: Local Authentication / Secure Enclave (iOS), Android Biometric API / Keystore, APNs critical alerts, Android high-priority notification channels.
Native vs. hybrid vs. cross-platform
| Native | Hybrid (Ionic/Capacitor) | Cross-platform (React Native / Flutter) | |
|---|---|---|---|
| Performance | Highest – compiled OS code | Lowest – WebView overhead | Near-native for most use cases |
| Device hardware access | Full, direct | Limited via bridge | Full via native modules |
| UI fidelity | Fully platform-native | Web-based, non-native | Near-native (Flutter renders its own UI) |
| Offline capability | Yes, by default | Limited | Yes, by default |
| Development cost | Highest (two teams) | Lowest (single web team) | Moderate (single team, platform tuning) |
| Time to market | Slowest | Fastest | Moderate |
| Maintenance | Per platform | Single codebase | Single codebase |
| Best for | Performance-critical, hardware-intensive apps | Simple MVPs, content apps | Consumer apps needing both platforms |
🚀 A practical rule: choose native when your app’s core features depend on real-time graphics, continuous background hardware access, platform security APIs, or need to match the OS’s exact behavior. React Native or Flutter make more sense when you need both iOS and Android at lower cost and the app doesn’t require deep hardware integration.
When to choose native app development
Performance is the product. Streaming apps, navigation tools, games, and real-time communication apps need frame-level rendering performance. Spotify, Google Maps, and Pokémon GO are all cases where any performance degradation would directly damage the user experience.
Your core features depend on hardware. If the app needs continuous background location, Bluetooth peripherals, camera processing, or biometric authentication, native is the most reliable path. Workarounds exist in cross-platform frameworks, but they add complexity and failure modes.
Security requirements are strict. Financial apps, healthcare tools, and enterprise software that stores sensitive data need hardware-backed cryptographic storage – Secure Enclave on iOS, Android Keystore on Android. These aren’t accessible from a JavaScript layer.
You need new OS APIs immediately. Apple and Google release new capabilities every autumn. Native developers get them on day one.
The UX has to feel first-party. In categories where users compare you directly to Apple’s or Google’s own apps messaging, maps, music following each platform’s design conventions precisely makes a difference.
If none of those apply to your project, React Native or Flutter will get you to market faster and at lower cost. The right choice depends on your specific requirements. Our custom software development team regularly works through this decision with clients at the start of a project.
Summary
The apps in this article — Spotify, WhatsApp, Instagram, Google Maps, Uber, Airbnb, Tesla, Duolingo, Pokémon GO, and Revolut chose native because their core features require capabilities that only platform-native code reliably delivers: real-time audio, continuous GPS, AR processing, biometric authentication, and hardware-backed security.
If your product needs any of those things, native is worth the added cost and time. If it doesn’t, cross-platform will get you there faster. The decision usually comes down to a handful of specific technical requirements.
If you’re working through that decision now, contact our team at Fireup — we’ll help you map out the options for your specific project.
