Most cross-platform projects don't fail because the framework couldn't do the job. They fail because the codebase grew without an architecture that anticipated three platforms pulling in three directions at once. Over several years of building web, mobile, and desktop apps from shared codebases, five patterns have consistently made the difference between a codebase that stays maintainable and one that becomes a minefield.
1. The Shared Core, Thin Shell pattern
Put as much business logic, validation, and state management as possible into a platform-agnostic core library that has zero knowledge of UI. Each platform then wraps that core in the thinnest possible shell - just enough to render UI and handle platform-specific concerns like navigation gestures or file system access.
The test for whether you've done this correctly: could you swap out your entire UI framework without touching the core? If the answer is no, logic has leaked into the UI layer somewhere, and that's usually where the hardest bugs come from.
2. Platform capability interfaces, not platform checks
It's tempting to sprinkle if (platform == iOS) checks through shared code whenever you need something platform-specific. This works until it doesn't - usually around the fortieth check, when nobody can confidently say what happens on Windows anymore.
The more durable pattern is to define an interface for the capability you need - INotificationService, IFilePicker, IBiometricAuth - in the shared layer, then provide a concrete implementation per platform through dependency injection. Shared code calls the interface and never needs to know which platform it's running on.
If you can't describe your platform-specific code without saying the word "if," you probably have a capability that wants to be an interface.
3. Adaptive layout, not duplicated layout
Duplicating your UI per platform - one layout for mobile, a completely separate one for desktop - doubles your maintenance burden and guarantees the two will drift apart over time. The more resilient approach is a single component tree with layout primitives that adapt based on available space and input method, rather than hard platform checks: a list that becomes a grid on wider screens, a bottom sheet that becomes a side panel, a swipe gesture that becomes a hover state.
This takes more thought upfront than just building two versions, but it means a bug fix or a design change only has to happen once.
4. Feature modules with explicit boundaries
As a cross-platform app grows, features start depending on each other in ways nobody intended - a settings screen quietly importing something from the checkout flow, a notification handler reaching into user profile internals. Structuring the codebase into feature modules with explicit public interfaces, and treating cross-module imports as something that needs a reason, keeps the dependency graph legible as the team and codebase grow.
This matters more in cross-platform projects than single-platform ones, because you already have three build targets adding complexity. Uncontrolled internal coupling is complexity you can actually remove.
5. A deliberate testing pyramid across platforms
Shared logic should carry the bulk of your test coverage, since a bug there affects every platform at once - that's where unit tests earn their keep. Platform shells need a thinner layer of integration tests focused specifically on the platform-specific glue code: permission handling, native navigation, platform APIs. And a small number of end-to-end tests per platform catch the things that only show up when everything runs together on real hardware.
Teams that skip straight to end-to-end tests on every platform end up with slow, flaky suites that don't actually tell you where the bug is. Teams that only unit test the shared core miss the platform-specific failures that are, in practice, where most cross-platform bugs actually live.
Putting it together
None of these patterns are exotic, and none of them are unique to any one framework - I've applied all five in .NET MAUI Hybrid Blazor projects, and the same thinking transfers cleanly to React Native, Flutter, or Kotlin Multiplatform codebases. What they have in common is a refusal to let "cross-platform" become an excuse for architectural shortcuts. The apps that stay maintainable for years are the ones where these decisions were made deliberately, early, before the codebase got too large to easily change course.
