面向 Compose Multiplatform 的架构

The same Compose skills can target iOS, desktop, and web through Compose Multiplatform. Structuring code well today makes that leap far easier later.

The big idea is a clean line between your shared logic and platform-specific code. The more lives in shared modules, the more you reuse everywhere.

Write your ViewModel and UI state in pure Kotlin with no Android imports. State and logic that depend on nothing platform-specific travel anywhere.

When you truly need platform APIs, use Kotlin expect/actual. You declare an expectation in shared code and provide each platform real implementation.

References to Context, Activity, or android.* tie code to one platform. Push them behind interfaces so your shared module stays portable.

With Compose Multiplatform, even your Composable screens move into shared code. The same Column, Text, and Button render on iOS and desktop too.

The Android R class is platform-bound. The compose-resources library gives you shared images and strings that resolve correctly on every target.

Pass dependencies in rather than constructing platform objects inside shared code. Dependency injection keeps your modules decoupled and testable.

You want a ViewModel that could run on Android and iOS. What must you avoid in it?

A clear stack of data, domain, and presentation layers pays off. Each layer has one job, which makes swapping platform pieces painless.

You do not need every platform today. Build Android-first with clean boundaries, and going multiplatform later becomes a refactor, not a rewrite.

In a multiplatform project, common logic lives in commonMain. Whatever you put there compiles for every target, so it becomes the heart of your app.

You kept logic platform-free, used expect/actual for the gaps, and layered your modules. Your app is architected to grow beyond Android.