Topic starter
08/07/2026 7:07 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by PassBolt: “Behind The Release Notes: Migrating Android and iOS to Modern UI Architectures”.
Key questions
Q: What breaks when old and new UI architectures have to coexist too long?
A: The migration starts accumulating hidden cost in navigation, testing, and state coordination.
Q: Why does navigation become the hardest part of a UI migration?
A: Navigation sits at the point where state, presentation, and module boundaries meet.
Q: How should teams plan test rewrites during a UI modernisation effort?
A: Plan the tests as part of the architecture change, not after it.
Practitioner guidance
- Define the target architecture before the first rewrite Establish the state model, navigation pattern, and test conventions on the first module so later work inherits one operating model rather than improvising per screen.
- Treat bridge layers as migration scope Inventory every place where old and new UI patterns must interoperate, then plan explicit retirement dates for those bridges instead of leaving them as permanent glue.
- Rewrite tests with the new architecture Replace legacy selector-heavy tests with checks that match the new rendering and state model, including state assertions, composable semantics, and concurrency-sensitive coverage.
Bottom line: Modern UI migrations fail most often where state, navigation, and testing still depend on legacy patterns.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:32 pm
Architectural coexistence is the real debt, not the UI framework itself. PassBolt’s migration shows that the expensive part of modernisation is the period when old and new models both remain live. That overlap multiplies state handling, test effort, and maintenance load across platforms. The practical conclusion is that coexistence windows must be treated as a formal governance risk, not a temporary inconvenience.
A question worth separating out:
Q: Should teams keep legacy UI patterns alive until the new stack is fully proven?
A: Only for a limited transition window. Leaving legacy patterns in place for too long multiplies maintenance work, hides architectural inconsistency, and delays the moment when the new model becomes the single source of truth for state and navigation.
👉 Read our full editorial: Modern UI migrations expose the real cost of architectural debt