Technology · 04 Mobile Platforms
Native iOS in Swift and SwiftUI, native Android in Kotlin and Jetpack Compose, or cross-platform with React Native, Flutter and Kotlin Multiplatform. Here is what each asks of you after launch, and how we decide which fits your app, team and budget.
Updated September 2026 You own everything Reply within one business day
Good morning
Your account at a glance
Balance
12,480
OlDevs, a full-stack technology studio in Vancouver, defaults to native Swift and Kotlin when an app depends on device hardware, on-device AI or the platform's own design language, and to React Native with Expo or Kotlin Multiplatform when one team must ship to both stores with shared logic.The choice is made per project against who will maintain the code, which devices matter and how much change the budget can absorb.
Key facts
04 · Mobile Platforms
Each card below says when the option is the right call and what it will ask of you after launch.
Right when the app leans on iPhone hardware, Apple Intelligence or the iOS 26 design language, and iPhone users are the ones who pay. Later cost: a second codebase if Android follows, and a yearly pass through Apple's SDK deadline to stay accepted by review.
Best when your audience skews Android, you need NFC, Bluetooth or background location, or tablets and foldables with Android 16 adaptive layouts matter. Later cost: keeping pace with Play's target API deadlines and testing across a wide range of devices.
Our default when one team must ship to both stores, the interface is mostly screens, forms and lists, and you already have TypeScript developers. Later cost: native modules for anything unusual, an Expo SDK upgrade about once a year, and a larger app binary.
A strong fit for custom, animation-heavy interfaces that must look identical on iOS, Android, web and desktop, or for teams that already write Dart. Later cost: a smaller hiring pool, widgets that lag new platform design changes, and platform channels for native features.
Right when the hard part is business logic, networking or sync, and you still want native SwiftUI and Compose screens. Later cost: two UI codebases, iOS developers who must read Kotlin, and build tooling that needs an owner as the shared module grows.
Choose this when a feature must work offline, keep personal data on the phone or respond instantly: summarising, classifying, extracting text from photos. Later cost: device and OS gates for the newest models, a fallback for older phones, and re-testing at each OS release.
Stack
Concrete tools, current at the time of writing; confirmed for your project at scoping.
iOS
Android
Cross-platform
Services behind the app
Testing, release and monitoring
What changed
What moved in this area and what it means for your build.
Sep 2025
Apple's yearly release restyled every stock control and added the Foundation Models framework for on-device generative features. Native SwiftUI apps picked up the new look almost for free; older custom UI kits needed a review to avoid looking dated.
Jun 2025
Apps targeting Android 16 can no longer lock orientation or size on large screens, so tablet and foldable layouts became a requirement. Google also opened Gemini Nano to third-party apps through ML Kit GenAI APIs, a supported path for on-device summaries and rewriting.
2025
With the legacy architecture frozen, libraries that had not migrated fell behind. For clients with an existing React Native app the upgrade became a planned project rather than a routine bump; new builds avoid a whole class of bridge-related performance problems.
2025
Kotlin Multiplatform gained a supported way to share UI as well as logic. We still favour native SwiftUI screens on iOS for most clients, but for internal tools a single Compose codebase is now a credible option rather than an experiment.
Nov 2025
New apps and updates targeting recent Android versions must support 16 KB memory pages, which exposed old native libraries buried in dependencies. Clients with long-lived Android apps should plan a dependency audit before their next major release.
2026
Apple expects submissions built with the current Xcode each spring, and Google Play raises its target API level every summer. In practice a mobile app needs at least one maintenance release a year even when nothing about the product changes.
How we choose
If your in-house developers write TypeScript, a React Native app stays alive after handover. If you employ Kotlin or Swift engineers, native or Kotlin Multiplatform serves them better. We match the codebase to the team that will own it.
Camera pipelines, NFC, Bluetooth peripherals, background GPS and health sensors all work best in native code. When more than a few screens depend on hardware, we go native from the start rather than wrapping native modules one at a time.
Banking, health and government apps are judged against the stock apps beside them, so we use SwiftUI and Compose to inherit each platform's design language. Brand-led consumer apps with fully custom interfaces are where Flutter or React Native earn their place.
Every platform needs a yearly maintenance release for store compliance. We estimate that recurring effort honestly for each option, including OS betas and dependency upgrades, and pick the one whose upkeep your organisation can actually fund.
Field apps for crews with poor signal need local-first storage and conflict-tolerant sync; a content app can stay online-only. We settle the offline model before the framework, because it shapes the data layer and the back-end more than the UI does.
App Store review, Google Play policy, privacy manifests, data safety forms and WCAG 2.2 AA accessibility all have to pass before anyone downloads the app. We check each candidate platform against those requirements early, not after a rejection.
Who it's for
Whether the audience is a customer, a member, a citizen, or your own team, the choice has to hold up under real use.
Employee and customer apps that must pass security review, work with single sign-on and ship to managed devices. We typically go native or Kotlin Multiplatform, integrate with your identity provider and support enterprise distribution alongside the public stores.
Member and citizen apps with accessibility, bilingual EN/FR and privacy obligations. We favour native SwiftUI and Compose so the app inherits platform accessibility features, host data in Canadian regions, and document everything for procurement and audit.
One app, many locations: loyalty, ordering, bookings and location-aware offers across a network. React Native with Expo lets a single team ship both stores quickly, while a shared back-end keeps every franchisee's data and branding consistent.
A first release that proves the idea without forcing a rewrite later. We usually start with React Native or Flutter to reach both stores with one team, keep hardware and AI features behind clean interfaces, and plan the path to native modules if traction demands them.
Related technology
Modular monolith or microservices, queues or direct calls, one tenant or many: the shape of a system decides…
Explore03Seven runtimes, three API styles and the plumbing around them: sign-in, queues, caching, file storage, email…
Explore07Most AI projects never need a training cluster. We match each workload to the right silicon, rent before we…
ExploreFAQ
Go native when the app depends on device hardware, on-device AI or the platform's own design language, or when you will only ever ship to one store. Go cross-platform when one team must reach both iOS and Android and the interface is mostly screens and forms. We make the call per project and put the trade-off in writing before any code exists.
Yes, and that is the main reason to pick React Native, Flutter or Kotlin Multiplatform. With React Native and Expo a TypeScript team ships both stores from one codebase; with Kotlin Multiplatform shared logic sits under native screens. Either way there is one build pipeline, one test suite and one release checklist.
Most submissions are reviewed within a few days, though first releases and apps handling payments, health or children's data can take longer. Common rejection causes are missing privacy disclosures, sign-in without an account deletion path, incomplete metadata and crashes on the reviewer's device. We run a pre-submission checklist against both stores' current guidelines.
Automated unit and UI tests run on every commit, then each build goes to TestFlight on iOS and the internal or closed testing track on Google Play, where your team and a small group of real users try it on their own phones. You see a working demo every week during the build, so a release candidate holds no surprises.
Yes. We design a local-first data layer with SQLite or Room, queue changes made without signal, and reconcile them with the server when the connection returns, with clear rules for conflicts. This matters for field crews, inspectors, drivers and anyone working in buildings or rural areas.
Increasingly, yes. Apple's Foundation Models framework and Core ML run on the phone, and Gemini Nano is available to Android apps through ML Kit on supported devices. We use them for summaries, classification and text extraction where privacy or offline use matters, with a graceful fallback for older devices.
You do. Both store accounts are opened in your organisation's name, we work as a team member inside them, and every repository, design file, certificate and third-party account is yours from day one. If you ever move to another team, they inherit a documented codebase with a working build pipeline.
Let’s connect
Tell us what you’re building. We’ll reply within one business day with recommended platforms, structure and a tailored quote — no obligation.