네이티브 SDK 깔끔하게 감싸기

Some features only ship as an iOS-only SDK, like a payment or analytics kit. You still want one shared API your whole app can call. 🎁

Start in commonMain with a tiny interface describing what you need, in your own words, not the vendor SDK terms.

Declare an expect way to obtain that interface. commonMain promises an implementation exists without knowing how it is built per platform.

In iosMain provide the actual that forwards to the native SDK. This is the only place the vendor framework is ever imported.

Your iOS class is an adapter: it translates your clean calls into the SDK calls. The rest of the app never sees the vendor types.

If the SDK is iOS-only, androidMain still needs an actual. Provide a no-op or an Android equivalent so the app compiles everywhere.

Name methods after your app, not the SDK. track and identify read better than the vendor names, and they shield you from future renames.

Because callers depend on your interface, replacing the SDK means rewriting one adapter. Shared code does not change at all. ✨

A small interface is easy to fake. In tests you provide a fake Analytics and assert it was called, with no real SDK involved.

Hand the chosen actual to your code through Koin or a factory. Injection keeps construction in one spot and the rest decoupled.

Keep a single wrapper per native SDK. That boundary is where platform mess stays, leaving the rest of your shared code clean and portable.

You learned to define a clean shared interface, provide actuals per platform, and keep the vendor SDK behind one adapter you can swap or fake. 🎉