The subscription model’s dominance of mobile app monetization was, until recently, treated as a settled question. One-time purchases were dead. Advertising was privacy-constrained and algorithmically contested. Subscriptions provided predictable revenue, lower upfront friction, and the renewal economics that made customer lifetime value calculations favorable. Every growth deck from 2018 to 2022 told the same story about subscriptions being the obvious answer.

The reckoning that followed was predictable to anyone paying attention to the demand side of that story. Users had subscribed to enough things. The subscription fatigue that entertainment services experienced — as the number of streaming subscriptions a household maintained reached and exceeded what they were willing to pay — extended to software. Productivity apps, fitness apps, photo editors, and note-taking tools all compete for a monthly budget that users have become conscious of in ways they were not during the subscription model’s initial adoption phase.

Push notifications were introduced as a mechanism for delivering timely, relevant information to mobile users. They have become, in the hands of most apps, a mechanism for re-engaging users who have stopped using an app — delivered at volumes and frequencies that have trained users to disable notifications as a reflex rather than a deliberate choice.

The data on notification effectiveness tells a story that most growth teams choose not to hear. Opt-in rates for push notifications have declined steadily as users have learned from experience what push permission grants apps permission to do. iOS’s explicit permission prompt — which apps must request before sending any notification — shows opt-in rates below 50 percent for most app categories. Users who do opt in disable notifications at rates that correlate directly with how many notifications an app sends, not with how relevant those notifications are.

Performance optimization is the area of mobile development most susceptible to the wrong kind of effort. Teams spend significant engineering time improving benchmark numbers that have no correlation with user experience while ignoring the specific failure modes that cause users to uninstall apps and leave negative reviews. The gap between what is easy to measure and what actually matters to users is wide, and navigating it requires a more careful choice of metrics than most teams make.

Every mobile app that does anything interesting eventually needs a backend. Authentication, data storage, push notifications, file uploads, real-time updates — the list of backend requirements grows quickly once an app moves beyond a local-only experience. The decision of how to provide that backend is one of the most consequential architectural choices a mobile development team makes, and it is one that becomes substantially harder to reverse after significant user data has accumulated.

Google’s transition of Android UI development from the XML layout system to Jetpack Compose has been, by the standards of platform UI framework migrations, unusually smooth. Compose became stable in August 2021. By 2024, it was the recommended approach for new Android development. In 2026, the question for Android teams is no longer whether to adopt Compose but how to manage the migration of existing View-based codebases.

The comparison with SwiftUI is instructive. Both frameworks launched within two years of each other, both represent declarative replacements for older imperative UI systems, and both have faced criticism for gaps between their initial capabilities and the full feature set of what they replaced. Compose has navigated this transition with fewer of the minimum-API-level constraints that limit SwiftUI’s adoption curve, because Android’s broader device compatibility requirements have historically pushed Google toward more conservative backward compatibility policies.

SwiftUI launched in 2019 with a demonstration that made experienced iOS developers simultaneously excited and nervous. Excited because the declarative paradigm promised to eliminate the impedance mismatch between interface builder storyboards and code. Nervous because Apple’s track record with new frameworks included several that were replaced, deprecated, or quietly ignored within a few development cycles.

Five years later, SwiftUI is neither the complete replacement for UIKit that Apple’s marketing implied nor the abandoned experiment that skeptics predicted. It is a mature but still-evolving framework that handles a large majority of common iOS UI requirements elegantly, struggles with a specific set of advanced requirements, and has permanently changed how iOS UI code is written even when developers reach for UIKit to solve problems SwiftUI cannot.

Apple’s App Store commission structure has been the subject of regulatory scrutiny, antitrust litigation, developer revolt, and congressional testimony for five years. The outcome of all this attention is a commission structure that has changed at the margins while remaining fundamentally intact at its core. The 30 percent standard rate — reduced to 15 percent for developers earning under a million dollars annually and for certain subscription renewals — continues to apply to the overwhelming majority of App Store revenue.

Google’s decision to build Flutter on top of Dart — a language that had minimal developer mindshare and an uncertain future when Flutter launched — was a risk that the broader developer community viewed with skepticism. Dart was not JavaScript. It was not Kotlin. It was not a language that developers had strong feelings about because most developers had never used it. Building a cross-platform UI framework on an obscure language was, on its face, an unusual strategic choice.

React Native was announced by Facebook in 2015 with a promise that rewrote the calculus of mobile development: learn once, write anywhere. The promise was qualified from the start — React Native was never write once, run anywhere in the way that early web-based mobile frameworks had claimed to be — but it was credible enough to reshape how a generation of mobile teams made technology decisions.

Eleven years later, React Native is used in production by Microsoft, Shopify, Coinbase, and thousands of smaller organizations. It has survived the emergence of Flutter, the maturation of Kotlin Multiplatform, and a period of internal uncertainty at Meta when the framework’s future was genuinely in question. Its survival reflects something real about the problem it solves and the ecosystem it has built.

The question of whether to build natively for iOS and Android or to abstract across both platforms with a cross-platform framework has occupied mobile development teams for more than a decade. The answer has not settled. What has settled is the character of native development itself — and in 2026, Swift and Kotlin have each reached a maturity that makes the native argument significantly stronger than it was five years ago.