لماذا نحتاج إلى تجريد الإعدادات

Android and iOS each ship their own way to save small values. Without a shared layer, you would write that code twice. Let's fix that. 🔑

Android stores small key-value data in SharedPreferences, while iOS uses NSUserDefaults. Same idea, two very different APIs.

A Settings abstraction wraps both native stores behind a single Kotlin interface, so your shared code calls one method everywhere.

The community library multiplatform-settings gives you exactly that: one Settings type backed by the right native store on each platform.

You add the multiplatform-settings artifact to your shared module's commonMain so every target can use it.

At its core sits the Settings interface. Your shared code depends on this type, never on the platform store directly.

Abstraction keeps your shared logic portable. Swap the backing store or add a platform later, and the calling code never changes.

Settings is built for small values: flags, a username, a theme choice. For big or relational data, reach for SQLDelight instead.

Each platform builds its own Settings instance and passes it into shared code, so commonMain stays free of platform dependencies.

Once injected, your shared code just calls Settings methods. The same line runs on Android and iOS without a single change.

Because it's an interface, you can drop in a fake in-memory Settings during tests, no device or emulator needed. 🧪

You learned why KMP wraps native key-value stores behind one Settings interface: portable, testable, and written once. Next, real reads and writes. 🎉