Kotlin Multiplatform Mobile — این چیست، مفاهیم کلیدی و معماری KMM

Kotlin Multiplatform Mobile چیست؟

Kotlin Multiplatform Mobile (KMM) — فناوری است که به شما امکان می‌دهد منطق تجاری مشترک یک برنامه موبایل را در Kotlin بنویسید و بدون تکرار کد از آن در iOS و Android استفاده کنید. برخلاف Ionic یا Cordova، KMM رابط را در WebView رندر نمی‌کند — UI کاملاً بومی باقی می‌ماند و در SwiftUI (iOS) و Jetpack Compose (Android) نوشته می‌شود.

KMM توسط JetBrains در سال 2019 به عنوان بخشی از استراتژی Kotlin Multiplatform اعلام شد. تفاوت کلیدی با سایر راه‌حل‌های چندپلتفرمی — فریم‌ورک سعی در یکپارچه‌سازی UI ندارد، بلکه بر اشتراک‌گذاری دقیقاً همان کدی تمرکز می‌کند که واقعاً برای هر دو پلتفرم یکسان است: درخواست‌های شبکه، مدل‌های داده، اعتبارسنجی فرم‌ها، قوانین تجاری و کار با پایگاه‌های داده.

طبق JetBrains Developer Survey (2025)، KMM توسط 14% از توسعه‌دهندگان موبایل استفاده می‌شود و این شاخص سالانه 5% رشد می‌کند. این فناوری توسط شرکت‌هایی با نیازهای بالا به عملکرد و تجربه کاربری بومی انتخاب می‌شود که راه‌حل‌های ترکیبی برای آنها غیرقابل قبول است.

معماری KMM: ماژول shared و پیاده‌سازی‌های پلتفرمی

معماری KMM از سه ماژول تشکیل شده است: shared (کد مشترک در Kotlin)، iosApp (برنامه بومی iOS در Swift) و androidApp (برنامه بومی Android در Kotlin). ماژول shared برای Android به JAR و برای iOS به یک فریم‌ورک جهانی (Apple Framework) کامپایل می‌شود.

ماژول Shared: چه چیزی به کد مشترک منتقل می‌شود

تمام لایه‌های مستقل از پلتفرم به ماژول shared منتقل می‌شوند: لایه شبکه بر روی Ktor Client، مدل‌های داده با سریال‌سازی از طریق kotlinx.serialization، مخازن برای مدیریت داده‌ها، اعتبارسنجی فرم‌ها و قوانین تجاری (به عنوان مثال، محاسبه هزینه تحویل یا بررسی مجوزهای دسترسی).

ماژول shared از Gradle Multiplatform Plugin استفاده می‌کند و شامل سه مجموعه منبع است: commonMain (کد مشترک)، androidMain (پیاده‌سازی‌های خاص Android) و iosMain (پیاده‌سازی‌های خاص iOS). کامپایلر Kotlin/Native کد مشترک را به یک کتابخانه بومی برای iOS تبدیل می‌کند که از طریق XCFramework به پروژه Swift متصل می‌شود.

ماژول‌های پلتفرمی

ماژول Android — یک برنامه استاندارد Android در Kotlin با Jetpack Compose یا ViewBinding است. ماژول shared به عنوان یک وابستگی معمولی Gradle متصل می‌شود و تمام کلاس‌های commonMain مستقیماً در دسترس هستند.

ماژول iOS — یک پروژه Xcode در Swift یا Objective-C است. ماژول shared از طریق CocoaPods، Swift Package Manager یا XCFramework متصل می‌شود. Kotlin/Native هدرهای Objective-C را برای صادرات انواع Kotlin تولید می‌کند و آنها را از Swift قابل دسترسی می‌سازد.

مکانیزم expect/actual در KMM

expect/actual — مکانیزم Kotlin Multiplatform است که امکان اعلام API در کد مشترک (expect declaration) و ارائه پیاده‌سازی آن را به طور جداگانه برای هر پلتفرم (actual declaration) فراهم می‌کند. کامپایلر نظارت می‌کند که actual برای هر پلتفرم هدف وجود داشته باشد.

سناریوهای معمول استفاده از expect/actual: دریافت زمان فعلی با در نظر گرفتن منطقه زمانی، کار با SharedPreferences (Android) / UserDefaults (iOS)، توابع رمزنگاری و تولید UUID. در هر پلتفرم از API سیستم خود استفاده می‌شود.

بدون expect/actual داشتن کد یکپارچه منطق تجاری غیرممکن بود، زیرا APIهای کار با سیستم فایل، شبکه و ذخیره‌سازی بین iOS و Android در سطح فراخوانی‌های سیستم متفاوت هستند. این مکانیزم تضمین می‌کند که توسعه‌دهنده پیاده‌سازی بخش پلتفرمی را فراموش نکند.

برای فراخوانی‌های پلتفرمی مانند کار با دوربین یا بیومتریک، KMM کتابخانه expect/actual را همراه با افزونه‌های مشابه Cordova ارائه می‌دهد، اما در Kotlin/Native. JetBrains همچنین کتابخانه kotlinx-datetime را منتشر کرده است که کار با تاریخ‌ها را انتزاعی می‌کند.

نمونه کد در KMM

ساختار پایه یک پروژه KMM با اعلام تابع expect برای تولید UUID و پیاده‌سازی آن برای iOS و Android را بررسی می‌کنیم.

// commonMain — اعلام مشترک
expect fun generateUUID(): String

// androidMain — پیاده‌سازی برای Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — پیاده‌سازی برای iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

در کد مشترک expect fun generateUUID() اعلام می‌شود. برای Android از java.util.UUID و برای iOS از NSUUID از فریم‌ورک Foundation استفاده می‌شود. در بقیه کد ماژول shared این تابع بدون در نظر گرفتن پلتفرم فراخوانی می‌شود.

نمونه درخواست شبکه با استفاده از Ktor Client در کد مشترک:

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

این کد در هر دو پلتفرم بدون تغییر کار می‌کند. Ktor Client به طور خودکار از OkHttp در Android و NSURLSession در iOS بدون پیکربندی اضافی استفاده می‌کند. سریال‌سازی JSON از طریق kotlinx.serialization نیز چندپلتفرمی است.

مقایسه KMM با Flutter و React Native

KMM موقعیت منحصر به فردی در میان فناوری‌های چندپلتفرمی دارد، زیرا برخلاف Flutter و React Native سعی در جایگزینی UI بومی ندارد. KMM — راه‌حلی برای اشتراک‌گذاری منطق است، نه برای یکپارچه‌سازی رابط.

مزیت اصلی KMM — کنترل کامل بر UI است. اگر برنامه باید در هر پلتفرمی ظاهر و رفتاری بومی داشته باشد (به عنوان مثال، استفاده از iOS TabBar و Android BottomNavigation با انیمیشن‌های پلتفرمی)، KMM تنها راه‌حل چندپلتفرمی است که این را بدون راه‌حل‌های موقت تضمین می‌کند.

نقطه ضعف — تیم باید همزمان Kotlin، Swift، Jetpack Compose و SwiftUI را بداند که استخدام را پیچیده می‌کند. Flutter و React Native نیاز به دانش یک زبان و یک فریم‌ورک دارند.

مزایا و چالش‌های پیاده‌سازی KMM

Kotlin Multiplatform Mobile — فناوری قدرتمندی است، اما پیاده‌سازی آن نیاز به رویکرد سنجیده‌ای دارد. مزایای کلیدی و چالش‌های معمول که تیم‌ها با آن مواجه می‌شوند را بررسی می‌کنیم.

مزایای KMM

اولین و مهمترین مزیت — کاهش تکرار کد. طبق JetBrains Case Studies (2024)، تیم‌هایی که KMM را پیاده‌سازی کرده‌اند، حجم کد تکراری را برای لایه شبکه 60–80% و برای منطق تجاری به طور کلی 40–50% کاهش می‌دهند. این به طور مستقیم بر سرعت توسعه و تعداد باگ‌ها تأثیر می‌گذارد.

دومین مزیت — عملکرد در سطح برنامه‌های بومی. برخلاف فریم‌ورک‌های ترکیبی، KMM لایه‌های انتزاعی بین UI و سیستم اضافه نمی‌کند. کد منطق تجاری به همان سرعتی اجرا می‌شود که اگر به صورت جداگانه برای هر پلتفرم در Swift یا Kotlin نوشته شده بود.

چالش‌های پیاده‌سازی

چالش اصلی — صلاحیت تیم. توسعه‌دهندگان باید Kotlin (برای ماژول shared) و همچنین Swift و Jetpack Compose (برای UI) را بدانند. پیدا کردن یک متخصص همه‌کاره دشوار است، بنابراین معمولاً تیمی از توسعه‌دهندگان Android و iOS تشکیل می‌شود که به طور مشترک ماژول shared را مدیریت می‌کنند.

چالش دوم — ابزارها. KMM نیاز به پیکربندی Gradle، CocoaPods یا Swift Package Manager و همچنین ادغام با Xcode دارد. در مراحل اولیه پروژه، مشکلات مربوط به پیکربندی ساخت، به ویژه هنگام کار با کتابخانه‌های C، رایج است.

چالش سوم — اشکال‌زدایی. هنگامی که باگ در محل اتصال Kotlin/Native و Swift رخ می‌دهد، تعیین علت آن دشوارتر از یک برنامه یکپارچه است. JetBrains به طور مداوم ابزارهای اشکال‌زدایی را بهبود می‌بخشد، اما در عمل تیم‌ها مجبورند تا 20% از زمان خود را صرف وظایف زیرساختی کنند.