Performance work in mobile development wastes more effort than almost any other kind of engineering. Teams burn sprints shaving milliseconds off benchmarks that no user will ever feel. Meanwhile the problems that actually make people uninstall, the freezes, the janky feeds, the phone that’s dead by 4pm, sit in the backlog because nobody put a number on them.

The gap between what’s easy to measure and what users care about is wide. Closing it starts with picking the right metrics.

Apple’s App Tracking Transparency framework, which required explicit user permission for cross-app tracking, reduced mobile advertising effectiveness in ways the industry understood theoretically in 2021 and has spent the subsequent years quantifying empirically. The quantification has not been favorable. CPMs for iOS advertising inventory dropped significantly in the period following ATT’s rollout. Attribution accuracy — the ability to connect an ad impression to a downstream app install or purchase — declined materially. The precision-targeted mobile advertising ecosystem that had been the dominant growth channel for consumer apps was not destroyed, but it was substantially impaired.

The default architecture for most mobile applications treats network connectivity as a reliable precondition. API calls are made on demand. Failures produce error states. The user waits for responses. This architecture produces apps that work acceptably on fast, reliable connections and badly on slow, intermittent, or absent connections — which describes the conditions under which many mobile users actually use apps.

Offline-first architecture inverts this assumption. The app reads from and writes to local storage first. Network synchronization happens in the background, opportunistically, whenever connectivity permits. The user experience is fast and available regardless of network state. The complexity is in the synchronization layer, which most teams underestimate significantly before they build it.

The accessibility argument is made with sufficient frequency in developer conferences and engineering blog posts that it has acquired the character of something everyone agrees with and nobody acts on. Apps ship with missing accessibility labels, unlabeled buttons, broken VoiceOver navigation, and dynamic type support that was added for text elements but forgotten for layout constraints. The gap between the accessibility investment that development teams describe as important and the accessibility state of their shipped applications is among the widest in software development.

Mobile testing is harder than web testing for reasons that are partly technical and partly organizational. The technical reasons: the diversity of physical devices, OS versions, screen sizes, and hardware configurations that a production mobile app must run on is several orders of magnitude larger than the browser matrix that web applications face. The organizational reasons: mobile development cycles historically moved faster than testing infrastructure could keep pace with, producing teams that ship without adequate test coverage and accumulate testing debt that compounds with each release.

App Store Optimization was, in its early form, a relatively straightforward keyword game. Include the right terms in your app title and description, achieve a certain volume of downloads and ratings, and the app store algorithm would surface your app to relevant searches. The practitioners who figured this out first made significant money. The techniques spread, the competition intensified, and the algorithm changed — as algorithms always do when they are being gamed at scale.

The cross-platform vs native debate has a quality problem: the people most qualified to give objective assessments have financial or professional stakes in one answer. Agency developers who charge by the hour prefer native because it doubles the billable work. Cross-platform framework vendors publish benchmark comparisons designed to minimize the gaps between their output and native. Native platform advocates at Apple and Google have obvious incentives to characterize cross-platform output as inferior.

The integration of AI capabilities into mobile applications has followed the familiar hype cycle pattern: an initial period of breathless coverage about what AI would do for apps, followed by a quieter period of teams discovering which AI features users actually value and which are dismissed as gimmicks within the first week of use. The dust has not fully settled, but the outline of what works is becoming clear.

The AI features that have demonstrated durable user value are mostly not the ones that received the most attention during the hype phase. Large language model chatbots embedded in apps — the most visible AI feature of the 2023-2024 period — have retention profiles that most teams find disappointing. Users try them, find them useful or impressive in isolated interactions, and then forget to use them because the chat interface requires more effort than the specific task typically warrants.

Mobile security vulnerabilities cluster in a predictable set of categories. The same mistakes appear in security audits of consumer apps, enterprise apps, and fintech apps with equal regularity. The recurrence of the same errors across different teams and different organizations suggests that the failures are not primarily due to ignorance — most mobile developers are aware that security matters — but to a gap between security knowledge and the specific engineering practices that translate that knowledge into secure code.

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.

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.

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.