Apple Keeps Upgrading iOS. Developers Keep Hedging Toward Android.

Based on the research ofAgarwal and Ranganathan, "A platform for change? Core component innovations, complementor adaptation, and multihoming in platform-based ecosystems," Strategic Management Journal, 2026

The Upgrade That Was Supposed to Deepen Lock-In

Every time Apple ships a new core component, a rewritten rendering path, a new machine learning layer, a new privacy architecture, it typically also changes the interfaces that third-party developers use to plug into that component. That coupling is not an accident. Interfaces are how a platform coordinates thousands of outside developers without negotiating with each one, and Apple has spent two decades perfecting the art of telling developers exactly how to adapt: new APIs at WWDC, deprecation notices in release notes, migration guides on developer.apple.com. The standard story is that this coordination deepens the relationship. A developer who rebuilds a feature to the new interface has sunk more time into the platform, not less, and should be harder, not easier, to poach.

Shiva Agarwal and Ram Ranganathan tested that story against granular data from five major iOS releases and found something closer to the opposite. In the periods right after Apple's core component innovations, App Store developers did increase their co-innovation on iOS, building more features that used the new components. But they simultaneously became more likely to multihome, diversifying effort to the competing platform, Android. The two behaviors were not substitutes. They rose together. An interface event that was supposed to be a lock-in moment was, for a meaningful share of developers, also a hedging moment.

The explanation the authors land on is architectural, not psychological. It is not that developers panic indiscriminately whenever Apple changes something. It depends on what kind of change it is.

Two Kinds of Change, Two Very Different Developer Responses

The paper splits interface evolution into two flavors. Some changes push the platform toward cross-platform standardization: the new interface looks and behaves more like what developers already use elsewhere, lowering the specific knowledge that is locked up inside Apple's walls. Other changes push toward platform-specific differentiation: the new interface is distinctly Apple's own, tightly bound to its particular hardware, design philosophy, or regulatory posture, and harder to repurpose anywhere else.

Standardizing moves spurred both outcomes at once, more co-innovation on iOS and more multihoming to Android. Differentiating moves still allowed co-innovation to continue, but they reduced the tendency to diversify. The mechanism is intuitive once stated plainly: when Apple makes its own interface resemble a broader industry pattern, the skills a developer builds while adapting to it transfer more easily to a rival platform. When Apple instead builds something idiosyncratic, the adaptation effort is harder to carry anywhere else, so developers keep investing in iOS without the same pull toward Android.

Apple's own description of SwiftUI, introduced at WWDC 2019, is a useful illustration of a standardizing move, even though the paper's own classification of any specific release is more rigorous than any single example can capture. Apple's developer documentation states plainly that "SwiftUI is designed to integrate with your existing code base on any of Apple's platforms," a declarative UI paradigm that deliberately mirrors design patterns already common across the broader software industry rather than something exclusive to one device. A framework built to be portable and familiar is, by the paper's logic, exactly the kind of interface evolution that makes a developer's newly built skill set easier to carry elsewhere too.

Contrast that with Apple's App Tracking Transparency framework, rolled out in iOS 14.5. ATT is distinctly Apple's own regulatory architecture: a system prompt, a purpose string, and a hard requirement that any app wanting the device's advertising identifier must ask the user directly, as Apple's developer documentation spells out in detail. It is not a pattern borrowed from elsewhere in the industry. It is Apple differentiating its privacy posture in a way no other major platform had matched at the time. If the paper's logic holds, a change like that should dampen the pull toward diversification even as developers keep adapting their iOS code around it, rather than functioning as an open door to Android.

The ATT Episode Shows Dependence Still Pushes Developers Elsewhere

Even a differentiating change can still move money and attention if it hits a complementor's revenue hard enough, and the real-world record around ATT shows exactly that kind of pressure, through a different channel than app porting. Academic researchers Guy Aridor, Yeon-Koo Che, Brett Hollenbeck, Maximilian Kaiser, and Daniel McCarthy studied advertiser behavior after the ATT rollout and found that conversion-optimized Meta ad campaigns, which depend heavily on third-party tracking data, suffered a 37 percent reduction in click-through rates relative to click-optimized campaigns. Firms with a higher baseline dependence on Meta advertising saw a 37 percent reduction in firm-wide revenue. Crucially, the same study documents that advertisers responded by substituting spend toward the Google ecosystem, even though that substitution was not enough to fully offset the losses for the most Meta-dependent firms. Google itself prepared its advertiser and developer base for exactly this disruption, publishing guidance in early 2021 warning that ATT would "reduce visibility into key metrics that show how ads drive conversions" and would affect how iOS inventory was valued and bid on.

That is not the same population the anchor paper studies, advertisers rather than app developers, and ATT is best read as a differentiation-style change in the paper's own framework. But it shows the same underlying force at a different point in the ecosystem: when an Apple interface change threatens a complementor's position badly enough, dependent businesses look for a way to rebalance toward the rival platform regardless of how the change is classified. It is a reminder that the standardization-versus-differentiation split predicts the strength of the multihoming pull, not whether any pull exists at all.

Governing through interfaces is what lets a platform scale to millions of outside developers without negotiating with each one. The same interfaces are what give those developers a map for leaving.

The Scalability Trap Every Growing Platform Eventually Hits

The tension Agarwal and Ranganathan describe is structural, not a failure of any single Apple release. A platform that wants to coordinate a large complementor base has to standardize enough that developers can reasonably predict how to build for it, and that same predictability is what makes a developer's investment portable to a competitor. A platform that instead keeps its interfaces idiosyncratic retains more control over where developer effort lands, but it also slows the broad adoption and the ease of building that made the platform attractive to begin with. There is no interface design that maximizes both control and scale at once.

For any platform owner watching its own complementors after a major update, the practical signal is which kind of change just shipped. If the new interface looks like an industry pattern rather than something proprietary, expect deeper engagement on the platform and more hedging toward rivals in the same breath, and plan retention efforts accordingly rather than assuming the extra engagement means the relationship is safe. If the change is genuinely idiosyncratic, the diversification pressure eases, but so does some of the broader ecosystem efficiency that standardization would have delivered. Apple's own release history, the ATT disruption among them, shows there is no version of platform evolution that avoids that trade. There is only a choice about which side of it to accept.