The Interface Update That Grows Your Ecosystem Also Grows Android's

Based on the research ofShiva Agarwal and Ram Ranganathan, "A Platform for Change? Core Component Innovations, Complementor Adaptation, and Multihoming in Platform-Based Ecosystems," Strategic Management Journal, 2026

That is the pattern at the center of a new study by Shiva Agarwal and Ram Ranganathan, forthcoming in Strategic Management Journal. Working through granular developer-response data spanning Apple's five major iOS releases, the authors document something that cuts against the usual story platform owners tell themselves about control. Conventional wisdom treats a platform's interface, the rules and APIs through which it coordinates what complementors build, as the lever a platform owner pulls to keep developers invested and close. Loosen the interface, make it easier to build on, and the assumption is that you only ever gain: more developers building more things, more often, for you. Agarwal and Ranganathan's data tell a messier story. In the periods right after Apple ships a core-component innovation, app developers simultaneously increase their co-innovation on iOS and become more likely to multihome, diversifying onto the competing platform. The interface update that deepens commitment is, in the same breath, the one that loosens exclusivity.

The Interface Is Not a Neutral Pipe

The reason this matters is that most platform owners treat the interface, the SDK, the API surface, the design language, as plumbing: a technical artifact whose job is to let complementors build efficiently, with the real strategy sitting elsewhere, in pricing or policy or marketing. Agarwal and Ranganathan's framing puts the interface itself in the strategy seat. An interface update is not one decision; it is two, bundled together. The platform owner decides what new capability to expose, and separately decides what shape that capability takes: a shape that borrows conventions other platforms also use, or a shape that only makes sense inside this one platform's walls. The paper calls the first path standardization and the second differentiation, and shows the two pull developer behavior in genuinely different directions.

Standardized interface changes, ones that align with cross-platform convention rather than inventing something iOS-only, spur more co-innovation on iOS and more diversification to the rival platform at the same time. Differentiated changes, ones that build in capability tied specifically to Apple's own hardware or software stack, do the opposite: they damp the diversification instinct, keeping developers more exclusively anchored to iOS, but at the cost of less of the adaptive, co-innovative response the platform owner was hoping the update would spark in the first place. Agarwal and Ranganathan frame the tension bluntly: governing through interfaces is what lets a platform scale its ecosystem at all, and the same mechanism is what limits how much control the platform keeps over that ecosystem as the interface evolves.

Picture the Two Releases Side by Side

Here is a way to hold the mechanism in your head without the paper's full dataset in front of you, a deliberately hypothetical pair of releases rather than a claim about any specific real feature Apple has shipped. Suppose Apple ships Release A, and the new capability is built around patterns a developer already uses when building for other platforms: a familiar data format, a familiar interaction model, nothing that only makes sense inside Apple's own stack. A developer who adopts it does more work on iOS, because the capability is genuinely useful, and that same developer's skills and even chunks of code now travel more easily to a second platform, because the pattern they just learned was never iOS-specific to begin with. Now suppose Apple ships Release B instead, and the new capability is wired tightly into hardware or software that exists only on Apple's own devices. A developer who adopts it also does more work on iOS, for the same reason, the capability is useful, but none of that investment transfers anywhere else. The two releases can look, on a roadmap slide, like the same kind of "big new API drop." Agarwal and Ranganathan's data say they are not the same kind of event at all, because the shape of the new capability, not just its existence, decides whether deepening investment and loosening exclusivity arrive together or separately.

This is the part most platform-governance thinking skips. The debate over how open an interface should be is usually framed as more openness equals more ecosystem growth, full stop, with the only cost a vague worry about losing control. What this paper adds is a specific channel for that loss: openness, in the standardization sense, buys you co-innovation and sells you exclusivity in the same transaction, because the thing that makes an interface easy to build deeply on and the thing that makes it easy to carry away from your platform are frequently the identical design choice.

The Governance Literature Already Half-Suspected This, From a Different Angle

Agarwal and Ranganathan are not the first to find that a platform's interface design shapes whether complementors multihome; they document, as far as this piece can confirm, a distinct channel running through the standardization-versus-differentiation split specifically. A 2022 study in the Journal of Management, by Liang Chen, Jingtao Yi, Sali Li, and Tony W. Tong, examined newly launched apps across Apple's iOS and Google's Android and found a related but separate lever: a more open governance design, one that gives the platform owner less centralized control over the ecosystem, also makes that ecosystem more complex for developers to navigate, and the added complexity raises the cost of porting an existing app into it, which lowers the odds a developer multihomes there at all. The negative effect on multihoming weakens when the developer already has experience in the destination ecosystem, or when the product itself is built in a more modular way that is cheaper to adapt.

Put the two findings side by side and a pattern about governance, not just interfaces, comes into view. Platform owners have more than one dial that moves multihoming, and the dials do not always point the same direction. Standardizing a specific interface, in Agarwal and Ranganathan's data, raises multihoming by lowering the cost of carrying skills elsewhere. Opening up governance more broadly, in Chen and colleagues' data, can lower multihoming by raising the cost of arriving somewhere new and more complex. A platform owner who reasons about "openness" as a single slider, more open is simply more open, is collapsing two mechanisms that can cancel each other out or compound, depending on which one is actually being turned.

The thing that makes an interface easy to build deeply on and the thing that makes it easy to carry away from your platform are frequently the identical design choice.

Your Release Calendar Is Already a Governance Choice

The scale at stake is not small. Apple's own transparency reporting for 2024 put registered developers across its platforms above 51.7 million, up more than 22 percent year over year, against nearly 2 million apps live on the App Store, an ecosystem large enough that a shift in multihoming behavior among even a thin slice of it reshapes how much of the next wave of innovation lands on iOS first, or at all. Every major interface decision a platform owner makes is implicitly a bet on where that release sits between standardization and differentiation, whether anyone on the roadmap review ever names it that way. Treat the decision as a pure engineering question, optimized for developer convenience or technical elegance, and a team will tend to drift toward standardization by default, because standardized patterns are better documented and more familiar to the engineers shipping the interface internally. That default quietly funds diversification nobody on the roadmap was trying to cause.

The fix is not to differentiate everything and accept a weaker co-innovation response across the board; Agarwal and Ranganathan frame the tension as a tradeoff a platform owner navigates release by release, not a problem with one correct answer. The fix is to ask, before a core-component interface ships, which regime this specific release sits in, and whether that is the regime actually wanted for this part of the roadmap. A platform's major releases have carried this kind of weight before: Apple's 2019 introduction of SwiftUI, a new way of building interfaces across its own device family, and its 2017 introduction of ARKit, a capability tied tightly to iPhone and iPad hardware, were, whatever their individual merits, very different kinds of bet about how much a new capability should travel versus how much it should stay put. The lesson from Agarwal and Ranganathan's data is that a platform owner should be asking which kind of bet it is making before the keynote, not reading the answer off a competitor's growth chart afterward.