Can we ship an update to our existing iOS app without adopting Liquid Glass?

Not really, because the choice is not yours to opt out of. Since 28 April 2026 every upload to App Store Connect must be built with Xcode 26 or later against the iOS 26 SDK, and building against that SDK applies Liquid Glass to system-provided controls automatically. You can keep the scope small, adopting the material and fixing contrast and layout collisions without a redesign, but doing nothing produces a half-converted interface where system sheets and navigation look one way and your custom components look another.

What happens if we miss the Google Play API 36 deadline on 31 August 2026?

You can no longer publish new apps or updates. Existing installs keep working, and an extension to 1 November 2026 is available, but until you target API 36 you cannot ship a fix. Separately, existing apps must target at least API 35 to stay available to new users on newer devices. Wear OS and Android Automotive need API 35 or higher, Android TV and Android XR need API 34 or higher. Google raises the required target level by one each year, so plan for the next bump rather than treating this as a one-off.

Should we use Kotlin Multiplatform, Flutter or React Native?

It depends on where the product's value sits. If it depends on platform capability such as Liquid Glass fidelity, widgets, Live Activities, watch and wear surfaces, CarPlay or Android Auto, or on-device AI through each platform's own model API, share the logic in Kotlin Multiplatform and keep the UI native. If the product owns its own visual language and the platform integration is modest, Flutter or React Native will genuinely halve the UI work. Both frameworks are in a stable phase now, with Flutter 3.47 in August 2026 and React Native having shipped two releases, 0.83 and 0.86, with no user-facing breaking changes at all.

Is on-device AI good enough, or will we end up paying for cloud inference anyway?

Both, usually. Apple's on-device AFM 3 Core is a 3B model tuned for summarisation, extraction, classification and structured output, and Gemini Nano 4 is Google's current on-device model, reachable through ML Kit's Prompt API and already supported across more than 140 million devices. Those tasks run free, private and offline. World knowledge and long-context reasoning still need a cloud model with a per-call bill. Device eligibility also limits reach, since Apple Intelligence requires recent hardware, so we check what share of your install base can run the feature before committing to it.

Which age-verification rules apply to us, and who is responsible for compliance?

The store verifies age, but the developer must consume and act on the signal, which is where the engineering sits. The Texas App Store Accountability Act (SB 2420) took effect on 1 January 2026, and Apple published dedicated guidance for apps distributed in Texas on 3 June 2026. In practice that means integrating Apple's Declared Age Range API, including parental-consent re-validation and revocation, and Google Play's Age Signals API, already live in Brazil and arriving in Australia and Canada from mid-August 2026. Apple's new social-media capability questions in the age-rating questionnaire become required in September 2026.

Mobile App Development Services for iOS 26 and Android 17

Mobile app development is the work of designing, building and shipping applications that run on iOS and Android, and of keeping them publishable on the App Store and Google Play afterwards. The second half of that sentence carries far more weight in 2026 than it did when this page was first written.

Two hard gates now sit between a finished build and a released update. Since 28 April 2026, every upload to App Store Connect must be built with Xcode 26 or later against the iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK. From 31 August 2026, new apps and updates on Google Play must target API level 36, with an extension available to 1 November 2026, while existing apps need API 35 to remain available to new users on newer devices (Google Play Console Help, target API level requirements). Neither is a recommendation. An app that misses them cannot ship a bug fix, let alone a feature.

Mixcore Studio has been building software for 8+ years with a team of about 20, across 320+ delivered projects. What follows is how we build and maintain mobile apps as of August 2026, including the parts of the older approach that no longer hold.

One thing worth saying before the rest. A mobile app is not always the right deliverable. Shipping to a store now commits you to an annual toolchain and target-SDK bump, an age-signal integration in several markets, a privacy manifest, an age-rating questionnaire and a review process that can block a hotfix. If your product needs no camera, no background location, no push-driven retention loop and no offline state, a responsive web application will reach the same users with none of that overhead. We would rather tell you that at the quoting stage than after the first rejection.

The 2026 deadlines that decide whether your app can ship

Most of the mobile work we were asked about this year started as a compliance problem rather than a feature request. These are the dates that matter, in the order they arrive.

Xcode 26 and the iOS 26 SDK, already in force — the App Store Connect gate closed on 28 April 2026. Building against that SDK also applies Liquid Glass to system controls automatically, so this is not only a toolchain bump.
Google Play API 36 by 31 August 2026 — new apps and updates must target Android 16, with an extension to 1 November 2026. Wear OS and Android Automotive need API 35 or higher, Android TV and Android XR need API 34 or higher. Google raises the required target level by one each year, so the cycle repeats.
Apple's social-media age-rating questions, September 2026 — new capability questions become required, with a Social Media content descriptor attached to the product page. Updated questionnaire responses were already due on 31 January 2026.
Android developer verification, 30 September 2026 — enforcement begins in Brazil, Indonesia, Singapore and Thailand across Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps, for certified devices on Android 7 and above, with global rollout from 2027 (Android Developers, developer verification documentation). If you distribute internally or outside Play in those markets, this is a now problem.
Android 17 adaptive layouts, live since 16 June 2026 — API level 37 removes the developer opt-out from resizability and orientation restrictions on any display above 600dp. Letterboxing a phone-shaped layout on a tablet or foldable is no longer a supported shipping state.
Device floors for the next OS wave — iOS 27, iPadOS 27, macOS 27, watchOS 27, visionOS 27 and tvOS 27 were announced at WWDC26, held 8 to 12 June 2026, for a late-2026 release. Every wave drops older devices, and Apple Intelligence features remain limited to recent hardware, so check the supported-device list against your install base before promising either.

The practical consequence is that maintenance stopped being optional. We now quote mobile work as a build plus a named maintenance retainer, because a fixed-price build with no retainer produces an app that becomes unpublishable within about twelve months.

Liquid Glass, and what adopting it actually costs

Apple's Liquid Glass redesign is no longer an opt-in visual refresh. Recompiling against the iOS 26 SDK applies the new material to system-provided controls whether or not anyone asked for it, which means an app with a heavily customised UI ships a visibly mixed-era interface unless its own components are reworked. Apple published updated Liquid Glass design kits for Figma and Sketch covering iOS, iPadOS and macOS 27 on 23 June 2026.

The honest version of the estimate splits into three cases. An app built mainly from standard SwiftUI and UIKit controls mostly gets the redesign for free and needs a review pass for contrast, legibility over the new translucency and a handful of layout collisions. An app with a bespoke design system pays for a component-level rebuild, because custom chrome that ignores the material sits badly next to system sheets and navigation bars that adopted it. An app built in a cross-platform framework that draws its own widgets is the difficult case, since matching the material convincingly means either accepting an approximation or dropping to native views for the surfaces where the difference is visible.

There is no version of this where the answer is to do nothing, but there is a version where the answer is to do less. If your app is mostly forms, lists and system navigation, adopt the material and stop there. A full redesign hung off a compliance deadline is how mobile budgets get spent on work nobody asked for.

Native, Kotlin Multiplatform, or a cross-platform framework

The cross-platform question changed shape. The old framing was whether one framework could draw every screen on both platforms. The 2026 framing is how much logic you can share while keeping genuinely native UI, and Kotlin Multiplatform is the mainstream expression of that. KMP is in production at Google Workspace, Duolingo, Forbes and Philips. JetBrains reports that Duolingo saved an estimated 6 to 12 engineer-months with KMP, spending five months on iOS and 1.5 months on web against nine months for the initial Android build, that Bitkey shares 95% of its mobile codebase, and that Forbes consolidated over 80% of its logic across platforms (JetBrains Blog, Helping Decision-Makers Say Yes to KMP, April 2026).

Native Android is Compose-first — Google declared Compose the default UI approach at I/O 2026, and 68% of the top 1,000 Android apps now use Jetpack Compose in production (Android Developers Blog, Celebrating 5 years of Jetpack Compose, 28 July 2026). Compose 1.12 and BOM 2026.08.00 shipped on 12 August 2026 with hardware-accelerated mesh gradients, wide-colour gamut support including Display P3, and downloadable variable fonts, and require compileSdk 37 with AGP 9.2.0 or newer.
Native iOS is Swift and SwiftUI — Swift 6.3 arrived on 24 March 2026 with the @c attribute, module-name selectors and the first official Swift SDK for Android. Apple's own migration of its TrueType hinting interpreter to Swift produced an implementation 13% faster than the C code it replaced (Swift.org, 12 June 2026), which is a useful signal about where Apple is investing.
Kotlin Multiplatform for shared logic — Kotlin 2.4.10 is current as of 14 July 2026. Compose Multiplatform 1.11.0 in May 2026 added native UIView-backed iOS text input with system context menus, Autofill and Translate, and turned on concurrent iOS rendering by default.
Flutter, for UI-heavy products that own their visual language — Flutter 3.47 landed on 12 August 2026, splitting Material and Cupertino into standalone material_ui and cupertino_ui packages, making Impeller the default renderer on macOS, Windows and Linux, raising the minimum to iOS 15 and macOS 12 for Xcode 27, and adding UIScene lifecycle handling ahead of iOS 27.
React Native, now in a stability phase — 0.87 shipped on 11 August 2026 with strict TypeScript as the default JS API, Metro 0.87, experimental Swift Package Manager support, Android Gradle Plugin 9 and a Node.js 22 minimum. Both 0.83 and 0.86 shipped with zero user-facing breaking changes, which is a genuine change in cadence from the churn of previous years. Expo SDK 57 followed on 30 June 2026 on React Native 0.86.
Capacitor, where an existing web app is the product — 8.5.0 arrived on 31 July 2026 with iOS UIScene support and a migrator, with Capacitor 9 in alpha.

Where cross-platform is the wrong choice. If the app's value sits in platform-specific capability, such as tight Liquid Glass fidelity, Live Activities, widgets, Wear OS and watchOS complications, CarPlay or Android Auto, deep camera or sensor pipelines, or on-device AI running through each platform's own model API, the shared-UI approach spends more on bridging than it saves on duplication. In those cases we recommend native UI on both sides with shared business logic in KMP, and we will say so even when the brief arrives with a framework already chosen. The reverse also holds. For a content, commerce or workflow app with modest platform integration, insisting on two native codebases is an expensive way to look thorough.

Adaptive layout is now part of this decision rather than an afterthought. Android 17 removed the opt-out above 600dp, and Google reports that foldable users spend approximately 14 times more than standard phone users (Android Developers Blog, Enhance your app for the new Pixel lineup, 12 August 2026). Flo Health reduced state-preservation code by roughly 30% using Compose state primitives with ViewModel and Window Size Classes, which is the kind of saving that only appears once layouts are genuinely adaptive.

On-device AI, cloud AI, and an honest split between them

On-device AI became a callable, shipping API on both platforms rather than a conference demo. On iOS, Apple's third-generation foundation models are reachable through the Swift Foundation Models framework, which now supports multimodal prompts that reason about images alongside text, execution either on device or in Private Cloud Compute, and any model provider that ships a Swift package conforming to the Language Model protocol. On Android, Gemini Nano 4 is reachable through the ML Kit GenAI Prompt API and AICore.

What runs locally — AFM 3 Core is a 3B dense on-device model, with AFM 3 Core Advanced a 20B sparse model activating 1 to 4B parameters. Apple reports AFM 3 Core was preferred on 45.6% of text prompts against 23.3% for the baseline, and AFM 3 Cloud on 64.7% against 8.7% for its predecessor (Apple Machine Learning Research, 8 June 2026). Gemini Nano is supported on more than 140 million devices, and Google describes Gemini Nano 4 as further optimised for battery and performance efficiency (Android Developers Blog, Build intelligent Android apps: On-device inference, 21 July 2026).
What local models are good at — summarisation, extraction, classification, rewriting and structured output over content the app already holds. These run offline, cost nothing per call and keep data on the device.
What still needs the cloud — world knowledge, long-context reasoning, anything requiring current information. That means a per-call bill, a latency budget and a degraded path for users with no connectivity.
Who will actually see the feature — Apple Intelligence requires recent iPhone, iPad and Mac hardware, and Gemini Nano 4 ships on newer Android flagships. Before committing to an on-device feature we check what share of your install base can run it, because the answer sometimes makes the cloud path the only viable one.
The consent work that comes with it — App Review Guideline 5.1.2(i) requires explicit user permission and clear disclosure before sharing personal data with third parties, including with third-party AI. Adding an LLM feature is therefore a privacy-policy, consent-flow and vendor-review project, not only an integration.
Regional feature parity — platform AI features do not reach every market at the same time, and the EU and China have repeatedly lagged the initial launch set. If an assistant-style feature assumes a system capability, confirm its availability storefront by storefront first, because the EU build can genuinely differ and should be costed separately.

Our default is to start with the on-device model for the tasks it handles well, route only what it cannot handle to a cloud model, and instrument the split so the inference bill is attributable per feature. If a proposed AI feature only works with a frontier cloud model on every keystroke, we would rather show you that number early than discover it in month three.

Distribution, store fees and age signals

Four distribution regimes changed at once, and the practical answer differs by market rather than by principle.

European Union — a single 5% Core Technology Commission on digital goods and services revenue replaced the €0.50-per-install Core Technology Fee from 1 January 2026, applying across the App Store, web distribution and alternative marketplaces (Apple Developer, DMA and apps in the EU). Notarization is still required on every path.
United States — App Review Guideline 3.1.1(a) states that the external-purchase-link entitlements are not required for apps on the United States storefront to include buttons, external links or other calls to action pointing at purchase mechanisms other than in-app purchase. In other storefronts this still needs the StoreKit External Purchase Link Entitlement.
Japan — the Mobile Software Competition Act is in force, and from iOS 26.2 Apple's Japan terms let developers distribute on alternative app marketplaces, operate a marketplace, process payments for digital goods outside In-App Purchase and use alternative browser engines. Web Distribution is not among the options, so apps go through the App Store or an authorised marketplace.
Brazil — following an agreement with the competition regulator CADE, Apple announced on 18 June 2026 that alternative marketplaces and payment processing outside In-App Purchase become available beginning with iOS 26.5.
Android — Google Play split its fees on 24 June 2026 into a service fee starting at 10% on the first $1M of annual earnings and a separate 5% billing fee charged only when Google Play's billing system is used. Developers may instead offer an alternative billing system or link users to their own site, in which case no billing fee applies. Rollout began in the United States, EEA and United Kingdom on 30 June 2026, with reduced rate cards for the Games Level Up and Apps Experience programmes from 30 September 2026.

Our advice on external purchase flows is usually to wait. The engineering, payment processing, tax handling, refunds and support cost is real and recurring, and the fee stack differs per storefront, so the only number that matters is net revenue after all of it. Below a certain transaction volume the store commission is still the cheaper option, and we will model that with your actual figures rather than the headline percentages.

Age verification is the other change with genuine engineering cost. The Texas App Store Accountability Act (SB 2420) took effect on 1 January 2026, and Apple published dedicated guidance for apps distributed in Texas on 3 June 2026. Both platforms now ship surfaces you are expected to consume rather than self-attest against, namely Apple's Declared Age Range API with parental-consent re-validation and revocation, and Google Play's Age Signals API, live in Brazil and arriving in Australia and Canada from mid-August 2026 with global availability later in 2026. Australia retired the 15+ rating in favour of 16+ on 18 June 2026, Vietnam requires four region-specific ratings, and from 26 March 2026 regulated medical device status must appear on App Store product pages in the EEA, UK and US. The store verifies, but the developer has to act on the signal, and putting a verification wall in front of onboarding has a measurable conversion cost that belongs in the plan.

Migration work off foundations that no longer hold

Several things this page or a 2023 proposal might have recommended are now gone or superseded rather than merely deprecated. If your app depends on any of them, that is scheduled work, not an optional cleanup.

Skia is no longer Flutter's default renderer — Impeller is the default on Android API 29 and above, and on iOS it is the only renderer. As of 3.47 it is also the default on macOS, Windows and Linux. Older or non-Vulkan Android devices still fall back to the legacy OpenGL renderer and Android retains an opt-out, but new work should assume Impeller.
React Native's legacy architecture and the Bridge — removed in stages: 0.84 deleted the legacy architecture components on both platforms, and 0.87 removed the remaining iOS bridge code guarded by RCT_REMOVE_LEGACY_ARCH, making the New Architecture mandatory. JSC is no longer the default engine either, having been replaced by Hermes V1 in 0.84. Legacy native modules need rewriting against the New Architecture.
CocoaPods for Flutter iOS plugins — Swift Package Manager is the direction of travel, and Flutter 3.47 continued to improve SwiftPM support for iOS builds. React Native 0.87 added experimental SwiftPM support on the same trajectory.
Xamarin.Forms-era .NET MAUI code — the Microsoft.Maui.Controls.Compatibility package is no longer built or shipped in .NET MAUI 11, CoreCLR replaces Mono as the default runtime on all platforms, and the minimum Android API rose from 21 to 24, so apps now require Android 7.0 or higher. The non-async animation methods such as FadeTo and RotateTo are marked obsolete in favour of their Async equivalents.
ExoPlayer 2 and Wear OS Tiles — the standalone com.google.android.exoplayer2 library is discontinued and apps should migrate to androidx.media3, and Wear OS 7 replaced the Tiles framework with Wear Widgets built on Jetpack Glance and RemoteCompose. Wear OS 7 also delivers up to 10% better battery life than Wear OS 6 (Android Developers Blog, 12 August 2026).
Permission and reflection patterns on Android — for apps targeting Android 17, the Contacts Provider withholds personally identifiable columns from the data view, local network access is gated behind the new ACCESS_LOCAL_NETWORK runtime permission, and modifying a static final field by reflection now throws IllegalAccessException.
Privacy manifests for common SDKs — Apple requires manifests and signatures for a published list of widely used SDKs, explicitly including Flutter, Capacitor, Cordova, Hermes, the Firebase family, Lottie, OneSignal, RxSwift, SDWebImage, UnityFramework and many Flutter plugins.

We usually scope this as a separate remediation pass ahead of feature work, because mixing the two makes it impossible to tell which change caused a regression, and because the deadline for the remediation is fixed while the feature work rarely is.

What our mobile practice covers

Native iOS With Swift And SwiftUI
Native Android With Jetpack Compose
Kotlin Multiplatform Shared Logic
Cross Platform With Flutter And React Native
On Device And Cloud AI Features
Store Compliance And Release Engineering

How we run a mobile engagement

Four stages, in order. The first produces a list of dates and blockers rather than code, and the last one is a standing commitment rather than a launch party.

01

Audit against the shipping gates first

We check the current Xcode and SDK versions against the App Store Connect requirement, the target API level against the Google Play deadline, adaptive-layout behaviour above 600dp on Android 17, age-rating and age-signal exposure by market, privacy manifests for every embedded SDK, and any dependency on a superseded foundation such as Flutter's Skia renderer, the React Native Bridge or ExoPlayer 2. The output is a dated list, because the deadlines are dated.
02

Decide the architecture per surface, not per fashion

Shared logic in Kotlin Multiplatform with native UI where platform integration or Liquid Glass fidelity matters, a single cross-platform framework where the product owns its own visual language and integration is modest. We state which surfaces are native and why, so the decision can be argued with before it is built rather than discovered afterwards.
03

Build with store constraints in the definition of done

A feature is not finished when it works on a simulator. It is finished when it passes review considerations, has its consent and disclosure flow for any third-party AI, degrades properly on devices without on-device model support, behaves on a foldable and a tablet, and ships through a reproducible signed pipeline for both stores.
04

Keep it publishable with a named retainer

One toolchain bump and one target-SDK bump per platform per year is now contractual rather than optional, because Google raises the required target API level annually. We agree the retainer that covers those, plus OS-release regression passes, dependency and privacy-manifest updates, and the store-policy changes that arrive without notice.

Frequently asked questions

Can we ship an update to our existing iOS app without adopting Liquid Glass?

Not really, because the choice is not yours to opt out of. Since 28 April 2026 every upload to App Store Connect must be built with Xcode 26 or later against the iOS 26 SDK, and building against that SDK applies Liquid Glass to system-provided controls automatically. You can keep the scope small, adopting the material and fixing contrast and layout collisions without a redesign, but doing nothing produces a half-converted interface where system sheets and navigation look one way and your custom components look another.
What happens if we miss the Google Play API 36 deadline on 31 August 2026?

You can no longer publish new apps or updates. Existing installs keep working, and an extension to 1 November 2026 is available, but until you target API 36 you cannot ship a fix. Separately, existing apps must target at least API 35 to stay available to new users on newer devices. Wear OS and Android Automotive need API 35 or higher, Android TV and Android XR need API 34 or higher. Google raises the required target level by one each year, so plan for the next bump rather than treating this as a one-off.
Should we use Kotlin Multiplatform, Flutter or React Native?

It depends on where the product's value sits. If it depends on platform capability such as Liquid Glass fidelity, widgets, Live Activities, watch and wear surfaces, CarPlay or Android Auto, or on-device AI through each platform's own model API, share the logic in Kotlin Multiplatform and keep the UI native. If the product owns its own visual language and the platform integration is modest, Flutter or React Native will genuinely halve the UI work. Both frameworks are in a stable phase now, with Flutter 3.47 in August 2026 and React Native having shipped two releases, 0.83 and 0.86, with no user-facing breaking changes at all.
Is on-device AI good enough, or will we end up paying for cloud inference anyway?

Both, usually. Apple's on-device AFM 3 Core is a 3B model tuned for summarisation, extraction, classification and structured output, and Gemini Nano 4 is Google's current on-device model, reachable through ML Kit's Prompt API and already supported across more than 140 million devices. Those tasks run free, private and offline. World knowledge and long-context reasoning still need a cloud model with a per-call bill. Device eligibility also limits reach, since Apple Intelligence requires recent hardware, so we check what share of your install base can run the feature before committing to it.
Which age-verification rules apply to us, and who is responsible for compliance?

The store verifies age, but the developer must consume and act on the signal, which is where the engineering sits. The Texas App Store Accountability Act (SB 2420) took effect on 1 January 2026, and Apple published dedicated guidance for apps distributed in Texas on 3 June 2026. In practice that means integrating Apple's Declared Age Range API, including parental-consent re-validation and revocation, and Google Play's Age Signals API, already live in Brazil and arriving in Australia and Canada from mid-August 2026. Apple's new social-media capability questions in the age-rating questionnaire become required in September 2026.