# Compose Multiplatform: Why You Should Not Build Entire iOS Apps in Compose

Maintain native iOS navigation and system controls while sharing core product UI screens.

- **Source:** [ProAndroidDev - Medium](https://brifing.si/source/d9553fa9-7b72-4b9b-bc73-c6bf9a40dd5f)
- **Published:** 2026-11-09
- **Topic:** [technology](https://brifing.si/c/technology)
- **Original article:** <https://proandroiddev.com/compose-multiplatform-why-you-shouldnt-build-your-whole-ios-app-in-compose-9e1e8c978a5b?source=rss----c72404660798---4>
- **On Brifing:** https://brifing.si/s/2c757eb7-e75d-47d4-b933-b6823d18ee4b

## The Hybrid UI Strategy

Compose Multiplatform allows developers to reuse Kotlin and Compose code on iOS, but fully replicating system controls like tab bars often leads to maintenance issues. Instead of building the entire app in Compose, developers should leverage native UIKit components for navigation and system interactions to ensure a consistent platform experience.

## System Controls vs Product Content

System elements like tab bars and navigation headers evolve with every iOS update, making them difficult to mimic perfectly in Compose. By using native UIKit for these containers, the app automatically adopts Apple's design changes. Meanwhile, core product screens like calorie trackers remain shared, keeping business logic and UI implementation unified.

## Implementing Native Tab Bars

In the ClariMeal app, the developer uses UIKit to manage the tab bar, allowing the system to handle standard behaviors. For specific actions like an 'Add' button, the app intercepts taps via the tab bar delegate. This approach ensures that the interface feels native while still utilizing shared Kotlin logic for functionality.

## Navigation Stack Ownership

Native navigation controllers should own the stack, while Compose renders the content within each view. By implementing a shared AppNavigator interface, the app pushes and pops screens using native iOS navigation controllers. This prevents conflicts between the two layers and ensures that the back gesture and transitions behave exactly as expected.

## Handling System Updates

When Apple updates the iOS SDK, native controls automatically adopt new appearances, reducing the need for manual code adjustments. If a developer copies system details like corner radii or blur effects into Compose, they become responsible for updating those tokens manually. Relying on native components eliminates this repetitive maintenance burden entirely.

## Defining the Boundary

The boundary between shared and native code is determined by what the operating system should own. Navigation, swipe gestures, and system-level sheets belong to the platform. Product-specific content, such as charts, macro rows, and data insights, remains in Compose. This separation keeps the codebase efficient without sacrificing the platform-specific user experience.

## Avoiding SwiftUI Rewrites

Rewriting entire screens in SwiftUI would require maintaining two separate implementations for every product update. By keeping screen content in Compose and using native containers, the developer avoids this duplication. The business logic remains in Kotlin, ensuring that changes to the insight engine or database are reflected across both platforms simultaneously.

## Integration Technical Details

Each screen is hosted through ComposeUIViewController, allowing UIKit to manage the container while Compose handles the internal rendering. This method supports complex native controls like UIDatePicker or UISearchController seamlessly. By treating Compose as a content renderer rather than the entire application framework, developers maintain full control over the native iOS environment.

## Strategic Development Conclusion

The most effective cross-platform strategy is to share the product logic and UI components while respecting the host operating system's native controls. By letting UIKit manage navigation and system interactions, developers create more stable, maintainable applications. This hybrid approach balances the efficiency of code sharing with the necessity of native platform behavior.

## Sources covering this story

- https://proandroiddev.com/compose-multiplatform-why-you-shouldnt-build-your-whole-ios-app-in-compose-9e1e8c978a5b?source=rss----c72404660798---4 — 

---

_Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._
