TL;DR: Moving Android from XML plus MVP to Compose plus MVI and consolidating iOS onto modern SwiftUI was really an architecture and testing reset, with navigation and concurrency debt shaping the hardest work, according to Passbolt. The lesson for identity teams is that legacy coexistence patterns always raise operational cost until the old model is fully removed.
NHIMG editorial — based on content published by Passbolt: Behind the Release Notes: Migrating Android and iOS to Modern UI Architectures
By the numbers:
- A 2025 IJARSCT paper reports 30 to 40% less UI code and up to 50% faster implementation for complex UI components with Jetpack Compose compared to View-based UI.
- Compiler warnings dropped from about 1500 to about 8 during Passbolt's Swift 6 migration.
Questions worth separating out
Q: How should teams plan a UI architecture migration without creating more legacy debt?
A: Start by identifying the state, routing, and test boundaries that the old architecture depends on, then redesign those boundaries before converting screens.
Q: Why do mixed UI stacks become harder to govern over time?
A: Mixed UI stacks create duplicate patterns, inconsistent navigation, and multiple testing strategies, which increases operational load each time a new screen is added.
Q: How can teams tell whether a migration has actually improved maintainability?
A: Look for fewer glue layers, a single dominant state model, and tests that no longer depend on legacy framework behaviour.
Practitioner guidance
- Map the migration as a control-plane change Document where routing, state ownership, and auth handoffs cross old and new stacks before converting additional modules.
- Rewrite tests alongside presentation logic Replace framework-specific UI tests with tests that follow the new state model and selectors.
- Limit the lifespan of dual architectures Keep legacy and modern stacks modular and time-boxed, then remove the remaining dependencies that keep the old model alive.
What's in the full article
Passbolt's full article covers the operational detail this post intentionally leaves for the source:
- The module-by-module migration sequence for Android and iOS, including how the team staged the transition.
- The specific navigation and authentication friction that made the coexistence period more expensive.
- The concrete testing rewrite from view-based selectors to Compose semantics and test tags.
- The Swift 6 concurrency cleanup experience, including the warning reduction and harder modules still in progress.
👉 Read Passbolt's migration story on modern Android and iOS UI architecture →
UI architecture migration: what identity and platform teams should notice?
Explore further
Legacy coexistence is the real migration debt. The article shows that the hardest work was not rewriting screens but removing the cost of having two architectures active at once. MVP and MVI on Android, and multiple UI generations on iOS, created bridge logic, testing drift, and longer decision paths. For identity teams, this is the same pattern that appears when old and new control models are allowed to coexist too long. Practitioner conclusion: the migration cost is driven by overlap, not by the destination architecture alone.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: What should engineering leaders do when compiler warnings surface during a platform migration?
A: Treat warning cleanup as part of the migration, not as polish. Compiler warnings often reveal hidden assumptions about threading, lifecycle, or dependency ordering, so the work needs time and ownership. If you delay the cleanup, the migration becomes slower later because unresolved debt keeps reappearing in harder modules.
👉 Read our full editorial: Modern UI migrations expose the real cost of architectural debt