How do you balance platform parity (iOS/Android feature consistency) against platform-specific excellence?

#Why "just make them identical" is the wrong instinct

This question tests whether you understand that iOS and Android aren't two skins on the same app — they're two platforms with different interaction conventions, different capabilities, and different user expectations, and treating parity as "pixel-for-pixel identical" produces an app that feels foreign on both of them. The senior answer isn't "we always keep them in sync" or "we always let each platform do its own thing" — it's a framework for deciding, feature by feature, which kind of consistency actually serves the user, because the honest answer is "it depends on the layer you're talking about."

#Separate what the product does from how it presents

I split the question into two very different questions that get conflated constantly: does the feature set match across platforms — pricing, entitlements, content, core business logic — and does the presentation match — navigation pattern, gesture, transition, which native affordances it uses. The first one should almost always be identical; a user who pays for premium on iOS and switches to Android expecting the same entitlements is not an edge case, it's the baseline expectation, and shipping a feature to one platform six months before the other because "iOS engineering was faster" is a business decision hiding inside what looks like a scheduling decision. The second one should almost never be identical, because iOS and Android disagree, on purpose, about what good navigation and good affordances look like.

#A three-tier way to make the call concrete

I've found it useful to sort any parity question into three tiers. Tier one is core user-facing flows and business logic — checkout, authentication, account state, entitlements — where divergence creates real user confusion and support burden, so I push hard for functional parity even when the underlying implementation differs. Tier two is platform-native affordances — back navigation, share sheets, notification actions, widgets — where I want the capability to be equivalent but I explicitly want each platform to express it in its own idiom, because fighting the OS's own conventions is what produces the "clearly a cross-platform port" feeling users notice immediately. Tier three is genuinely platform-exclusive capability — Live Activities and the Dynamic Island on iOS, the depth of the home-screen widget and App Shortcuts ecosystem on Android — where I think it's fine, even good, to ship unevenly, as long as the core experience doesn't strand users on the platform that lacks it.

#Biometric auth as the concrete example I reach for

The example I use most in interviews is biometric login. The underlying capability — letting the user unlock the app with their face or fingerprint instead of a password — has to reach full parity, because a user shouldn't lose a security feature by switching phones. But the implementation is necessarily platform-specific: LocalAuthentication/Face ID on iOS versus BiometricPrompt backed by the Android Keystore, and the UI each OS presents around that prompt is different by design and shouldn't be fought. That's tier one and tier two living in the same feature: identical capability, platform-idiomatic presentation.

#Making this a shared decision, not an engineering unilateral

Parity is fundamentally a product decision, and I try to make sure engineering's role is to surface the real cost of each option clearly, not to make the call alone or to quietly let it drift. In practice that means a living parity matrix — reviewed at each planning cycle, listing every meaningfully divergent feature and why — so "iOS has X and Android doesn't yet" is a documented, revisited decision instead of a fact nobody remembers agreeing to. A shared domain/business-logic layer, even when the UI layers are fully separate per platform, is the technical structure that makes tier-one parity cheap to maintain instead of something that has to be manually re-verified every release.

#Handling the pressure to just "make it the same"

The pushback I get most often is from a stakeholder who saw the other platform's screen and wants pixel parity on a feature that legitimately belongs in tier two or three. I don't argue this abstractly — I show the platform's own design guidance, and I ask what specific user problem the mismatch is actually causing versus what a forced match would cost in engineering time and in feeling wrong to that platform's users. Most of the time the real complaint is "these feel like different products," which is a tier-one problem — usually inconsistent terminology, information architecture, or feature availability — being misdiagnosed as a tier-two visual one.