Cross-Platform Mobile App Development in Flutter, Capacitor, KMP and React Native
Cross-platform mobile development means shipping one codebase to iOS and Android, and the 2026 version of it shares business logic while keeping the user interface native. Mixcore Studio builds and maintains cross-platform apps in Flutter, Capacitor, Kotlin Multiplatform and React Native, and chooses between them per product rather than defending a house framework.
We have delivered software for more than 8 years, with a team of around 20 and over 320 projects behind us. On mobile in 2026, that experience matters less for the code than for the calendar. Both platforms have turned toolchain and target-SDK upgrades into hard annual cut-offs, and an app that misses one cannot ship an update at all until it catches up.
The 2026 release gates every mobile app has to clear
These are not recommendations. Each one stops a build from being accepted.
- Xcode 26 and the iOS 26 SDK — since 28 April 2026, every upload to App Store Connect must be built with Xcode 26 or later against the iOS, iPadOS, tvOS, visionOS and watchOS 26 SDKs. Recompiling against that SDK also applies Apple's Liquid Glass material to system controls automatically, so the visual change arrives whether or not it was planned.
- Google Play target API 36 — Google Play Console Help states that new apps and updates must target API 36 (Android 16) by 31 August 2026, with an extension available to 1 November 2026, and that existing apps must target at least API 35 to remain available to new users on newer devices.
- Adaptive layouts on Android 17 — API 37 went stable on 16 June 2026 and removed the developer opt-out from resizability and orientation restrictions on any display above 600dp. Letterboxed phone layouts on tablets and foldables are no longer a supported shipping state. Google's Android 17 release post puts the installed base at over 580 million large screen devices, so this is rarely wasted work.
- Age signals — the Texas App Store Accountability Act (SB2420) has been in force since 1 January 2026. Apple now requires new Apple Accounts created in Texas to confirm whether the user is 18 or older, with under-18 accounts joining a Family Sharing group so a parent can consent to downloads and purchases. Apple's Declared Age Range API and Google Play's Age Signals API are integration work with real effects on onboarding conversion, not a policy checkbox.
- Android developer verification — Android's developer documentation sets enforcement from 30 September 2026 in Brazil, Indonesia, Singapore and Thailand, covering Google Play, Galaxy Store, HONOR, OPPO, Palm Store, V-Appstore and GetApps, with global rollout from 2027. Anyone doing enterprise or non-Play distribution in those markets needs a plan now.
Choosing between Flutter, React Native, Kotlin Multiplatform and Capacitor
The useful question is no longer which framework wins, but how much of the product genuinely benefits from being shared.
- Flutter — draws its own UI, so the two platforms look identical by construction. Flutter 3.47 (12 August 2026) split Material and Cupertino out of the SDK into standalone material_ui and cupertino_ui v1.0 packages, made Impeller the default renderer on macOS, Windows and Linux, raised the minimum to iOS 15 and macOS 12 for Xcode 27, and made UIScene lifecycle adoption mandatory for iOS 27. Good for design-led products where brand consistency outranks platform convention.
- React Native — the right choice when you already have React engineers. 0.87 (11 August 2026) made the strict TypeScript API the default, shipped Metro 0.87, experimental Swift Package Manager support for iOS and Android Gradle Plugin 9, and requires Node.js 22 and Kotlin 2.0 or newer. Expo SDK 57 (30 June 2026) sits on React Native 0.86 with Reanimated 4.5 and Gesture Handler 2.32.
- Kotlin Multiplatform — shares the logic layer and leaves SwiftUI and Compose to draw each platform natively. It is production-standard at Google Workspace, Duolingo, Forbes and Philips. The JetBrains blog "Helping Decision-Makers Say Yes to KMP" (April 2026) reports Duolingo saving an estimated 6 to 12 engineer-months, Bitkey sharing 95% of its mobile codebase, and Forbes consolidating over 80% of logic across platforms. Compose Multiplatform 1.11.0 (May 2026) added UIView-backed native iOS text input with system context menus, Autofill and Translate, and turned on concurrent iOS rendering by default.
- Capacitor — the shortest path when a working web application already exists and the native shell mainly needs device APIs, push and store presence. Capacitor 8.5.0 (31 July 2026) added iOS UIScene support with a migrator plus TypeScript 7 support for capacitor.config.ts, and Capacitor 9 is in alpha.
- .NET MAUI — sensible only where a .NET backend team and existing C# domain code dominate. MAUI 11 has been in preview through August 2026, replacing Mono with CoreCLR as the default runtime on all platforms, raising the minimum Android API from 21 to 24, and exposing Apple Intelligence APIs from Preview 5.
What died this year, and what replaced it
A large share of cross-platform work in 2026 is migration off foundations that have been removed outright, or are far enough into deprecation that the removal date is the only open question. If any of the following is in your codebase, plan the migration now.
- Skia, everywhere Impeller has reached — Flutter's own documentation now states that Impeller is the only supported renderer on iOS, with no ability to switch back to Skia. On Android it is enabled by default from API 29 up, falling back to the legacy OpenGL renderer only on older releases and on devices without Vulkan. Flutter 3.47 made it the default on macOS, Windows and Linux as well, and the docs say the ability to opt out will be removed in a future release. Custom shaders and platform view code written against Skia need rework.
- React Native's legacy architecture and the Bridge — being removed release by release. The RCT_REMOVE_LEGACY_ARCH flag arrived as experimental in 0.83 and became the default on iOS in 0.84, which also made Hermes V1 the default JavaScript engine on both platforms. Old native modules must be rewritten as TurboModules and Fabric components. The upside is that 0.83 and 0.86 both shipped with zero user-facing breaking changes, so the churn era is genuinely over.
- CocoaPods for Flutter iOS plugins — the Flutter 3.47 announcement of 12 August 2026 reports that 92 of the top 100 iOS plugins have migrated to Swift Package Manager, with CocoaPods moving to maintenance mode. React Native 0.87 added experimental SwiftPM support on the same trajectory.
- Xamarin.Forms-era MAUI code — the Microsoft.Maui.Controls.Compatibility package is no longer built or shipped as of .NET 11 Preview 6, and MessagingCenter was made internal in .NET 10. ListView, TableView, the cell types, FontImageExtension, DisplayAlert and DisplayActionSheet are all deprecated in favour of CollectionView, FontImageSource and the Async pop-up methods, so they are on the same path.
- Background audio, Wear OS Tiles and broad contacts access — apps targeting Android 17 must play background audio from a foreground service with while-in-use capability or the playback, focus and volume APIs fail silently; Wear widgets, powered by Jetpack Glance and the Remote Compose framework, are the new Wear OS surface, with a documented migration path off Tiles; and Contacts Provider 2 strips account-identifying columns from the data view and enforces strict SQL validation when READ_CONTACTS has not been granted.
On-device AI, scoped honestly
On-device AI became a callable shipping API on both platforms in 2026 rather than a demo. Apple's Swift Foundation Models framework gives an app direct access to Apple's foundation models both on device and in Private Cloud Compute, and to any model provider that ships a Swift package conforming to the Language Model protocol, so the same session API can be pointed at a different vendor's model. It also takes multimodal prompts, letting an app reason about images alongside text. On Android, Gemini Nano is reachable through the ML Kit GenAI APIs — Prompt, Summarization, Proofreading, Rewriting, Image Description and Speech Recognition — which sit on top of the AICore system service.
Two caveats decide whether this is worth building. First, small on-device models are tuned for summarisation, extraction, classification and rewriting, not world knowledge or hard reasoning, so most products need an explicit local-versus-cloud split and a cloud inference budget. Second, eligibility is narrow: on iPhone, Apple Intelligence starts at iPhone 15 Pro and iPhone 15 Pro Max (A17 Pro) and iPhone 16 or later, and Gemini Nano availability depends on the device, so we size the addressable fraction of your actual install base before any of it is scoped. App Review Guideline 5.1.2(i) also now requires explicit user permission and clear disclosure before personal data is shared with third-party AI, which turns an AI feature into a consent-flow and privacy-policy workstream as well as a code one.
Where cross-platform is the wrong answer
We turn down cross-platform work regularly, because for some products it costs more than it saves.
- When the app must feel unmistakably native on iOS — Liquid Glass is a material system, not a colour scheme. Frameworks that draw their own widgets approximate it rather than inherit it, and the approximation drifts with every OS release. If your differentiator is iOS interface craft, build the UI natively.
- When platform-exclusive capability is the product — new Apple and Google APIs land in Swift and Kotlin first and reach cross-platform through community plugins months later, if at all. Widgets, Live Activities, App Intents, AppFunctions, Wear OS 7 and visionOS all fall in this category.
- When you already have two native teams — the saving comes from having one team instead of two. Consolidating existing native teams onto a shared framework usually spends more on migration than it recovers.
- When graphics, camera or real-time processing dominate — the bridge or shared layer becomes the bottleneck, and you end up writing platform code anyway with an extra abstraction on top.
The honest trade-off in Kotlin Multiplatform, which we recommend often, is that it is not a single-UI framework. You still write and maintain SwiftUI and Compose separately. What it removes is duplicated networking, persistence, validation and business rules, which is where the divergent-bug class actually lives.
How we run a cross-platform engagement
We start by auditing the app against the gates above and reporting what blocks the next release, with dates. That audit stands alone and is useful even if we build nothing further. Build work then proceeds framework-first only after the shared-versus-native boundary is agreed in writing, because that boundary, not the framework logo, is what determines cost over five years.
Distribution and fee strategy is part of the scope, not an afterthought. Several regimes changed at once: Apple's Core Technology Commission of 5% of digital goods revenue replaced the €0.50-per-install Core Technology Fee as a single unified EU model from 1 January 2026 (Apple Developer, "DMA and apps in the EU"); Apple opened alternative app marketplaces and non-IAP payment processing in Japan from iOS 26.2 to comply with the Mobile Software Competition Act, announced in December 2025; it did the same in Brazil from iOS 26.5, announced on 18 June 2026 under its agreement with CADE; and the Epic v. Google settlement has reopened US Play billing to alternative payment options. We work the net-revenue arithmetic after engineering, payment processing, tax and support, and give a recommendation rather than a legal survey.
Because both platforms now force an annual toolchain and target-SDK bump, we quote maintenance as a named retainer covering SDK upgrades, deprecation migrations, store-policy changes and release management, rather than pretending a fixed-price build stays shippable on its own.
Our expertise
- Shared logic, native UI
- Flutter and Impeller
- Kotlin Multiplatform
- React Native and Expo
- Adaptive and foldable layouts
- Store compliance and release
Frequently asked questions
Which cross-platform framework should we choose in 2026?
It depends on where your existing engineering strength is and how native the interface has to feel. React Native suits teams that already write React; Capacitor is the shortest route when a web app exists; Flutter fits design-led products where both platforms should look identical; and Kotlin Multiplatform fits products that need genuinely native UI on each platform while sharing networking, persistence and business rules. We make the recommendation after a short audit rather than before it.
Can a Flutter or React Native app adopt Apple's Liquid Glass design?
Partly, and the distinction matters. Since 28 April 2026 every App Store upload must be built against the iOS 26 SDK, which applies Liquid Glass to system controls automatically. Frameworks that render their own widgets do not inherit that material, so an app can end up visually half-converted. React Native and Capacitor, which use platform views more heavily, pick up more of it for free than Flutter does. Where iOS interface fidelity is the differentiator, we recommend a native UI layer over a shared one.
What happens if we do not update our app this year?
You lose the ability to ship updates. Uploads to App Store Connect have required Xcode 26 and the iOS 26 SDK since 28 April 2026, and Google Play Console Help requires new apps and updates to target API 36 by 31 August 2026, with an extension available to 1 November 2026. Existing apps that fall behind API 35 stop being available to new users on newer devices. The app already installed on a phone keeps working; the pipeline to improve it does not.
Can cross-platform apps use on-device AI such as Apple Foundation Models or Gemini Nano?
Yes, through platform channels or plugins, but with a lag. Apple's Foundation Models framework and Google's ML Kit GenAI Prompt API are Swift and Kotlin APIs first, and cross-platform bindings usually arrive later. Eligibility is the bigger constraint: Apple Intelligence requires A17 Pro or newer, so we measure what share of your install base can actually run the feature before scoping it, and design a cloud fallback for the rest.
Does Android developer verification affect us if we distribute outside Google Play?
Very likely, yes. Android's developer documentation puts enforcement from 30 September 2026 in Brazil, Indonesia, Singapore and Thailand, spanning Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps on certified Android 7+ devices, with global rollout from 2027. Enterprise and internal distribution in those markets needs verified developer identity in place before the date, and we handle that registration as part of release setup.
Contacts
We are always happy to talk with you.
Feel free to contact us in any suitable way
Request a quote
Let's discuss your project!
Please, provide us with a brief description of what you
already have and what you are going to achieve.
Mail us contact@brainiacminds.com