Kotlin Multiplatform Mobile — ما هو، المفاهيم الأساسية وهندسة KMM

ما هو Kotlin Multiplatform Mobile؟

Kotlin Multiplatform Mobile (KMM) هي تقنية تسمح بكتابة منطق الأعمال المشترك لتطبيق محمول بلغة Kotlin واستخدامه على iOS و Android بدون تكرار الكود. على عكس Ionic أو Cordova، لا تعرض KMM الواجهة في WebView — تبقى واجهة المستخدم أصلية بالكامل وتُكتب في SwiftUI (iOS) و Jetpack Compose (Android).

أعلنت JetBrains عن KMM في عام 2019 كجزء من استراتيجية Kotlin Multiplatform. الفرق الرئيسي عن الحلول الأخرى عبر المنصات هو أن الإطار لا يحاول توحيد واجهة المستخدم، بل يركز على مشاركة الكود المتطابق حقًا لكلا المنصتين: طلبات الشبكة، نماذج البيانات، التحقق من صحة النماذج، قواعد العمل والتعامل مع قواعد البيانات.

وفقًا لاستطلاع مطوري JetBrains (2025)، يُستخدم KMM من قبل 14% من مطوري التطبيقات المحمولة، وهذه النسبة تنمو بنسبة 5% سنويًا. يتم اختيار هذه التقنية من قبل الشركات ذات المتطلبات العالية للأداء وتجربة المستخدم الأصلية، حيث الحلول الهجينة غير مقبولة.

هندسة KMM: الوحدة المشتركة وتنفيذات المنصة

تتكون هندسة KMM من ثلاث وحدات: shared (كود Kotlin المشترك)، iosApp (تطبيق iOS الأصلي بلغة Swift)، و androidApp (تطبيق Android الأصلي بلغة Kotlin). يتم تجميع الوحدة المشتركة في JAR لنظام Android وإطار عام (Apple Framework) لنظام iOS.

الوحدة المشتركة: ما يُدرج في الكود المشترك

تحتوي الوحدة المشتركة على جميع الطبقات المستقلة عن المنصة: طبقة الشبكة باستخدام Ktor Client، نماذج البيانات مع التسلسل عبر kotlinx.serialization، مستودعات إدارة البيانات، التحقق من صحة النماذج وقواعد العمل (مثل حساب تكلفة التوصيل أو التحقق من صلاحيات الوصول).

تستخدم الوحدة المشتركة إضافة Gradle Multiplatform وتحتوي على ثلاث مجموعات من المصادر: commonMain (الكود المشترك)، androidMain (تطبيقات خاصة بنظام Android)، و iosMain (تطبيقات خاصة بنظام iOS). يحول مترجم Kotlin/Native الكود المشترك إلى مكتبة أصلية لنظام iOS، والتي تُربط بمشروع Swift عبر XCFramework.

الوحدات الخاصة بالمنصة

وحدة Android — هي تطبيق Android قياسي بلغة Kotlin مع Jetpack Compose أو ViewBinding. تُربط الوحدة المشتركة كاعتماد Gradle عادي، وكل الفئات من commonMain متاحة مباشرة.

وحدة iOS هي مشروع Xcode بلغة Swift أو Objective-C. تُربط الوحدة المشتركة عبر CocoaPods أو Swift Package Manager أو XCFramework. يُنشئ Kotlin/Native رؤوس Objective-C لتصدير أنواع Kotlin، مما يجعلها متاحة من Swift.

آلية expect/actual في KMM

expect/actual هي آلية في Kotlin Multiplatform تسمح بتعريف واجهة برمجة تطبيقات في الكود المشترك (تعريف expect) وتوفير تطبيقها بشكل منفصل لكل منصة (تعريف actual). يضمن المترجم وجود تطبيق actual لكل منصة مستهدفة.

حالات الاستخدام النموذجية لـ expect/actual: الحصول على الوقت الحالي مع المنطقة الزمنية، العمل مع SharedPreferences (Android) / UserDefaults (iOS)، وظائف التشفير وتوليد UUID. كل منصة تستخدم واجهة برمجة التطبيقات الخاصة بها.

بدون expect/actual، سيكون من المستحيل الحصول على كود موحد لمنطق الأعمال، لأن واجهات برمجة التطبيقات للعمل مع نظام الملفات والشبكة والتخزين تختلف بين 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. في بقية كود الوحدة المشتركة، يتم استدعاء هذه الدالة بغض النظر عن المنصة.

مثال لطلب شبكة باستخدام 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. KMM هي حل لمشاركة المنطق، وليس لتوحيد الواجهة.

الميزة الرئيسية لـ KMM هي التحكم الكامل في واجهة المستخدم. إذا كان التطبيق يجب أن يبدو ويتصرف بشكل أصلي على كل منصة (على سبيل المثال، استخدام TabBar في iOS و BottomNavigation في Android مع رسوم متحركة خاصة بالمنصة)، فإن KMM هي الحل الوحيد عبر المنصات الذي يوفر ذلك بدون حلول مؤقتة.

العيب هو أن الفريق يجب أن يعرف Kotlin و Swift و Jetpack Compose و SwiftUI في نفس الوقت، مما يعقد التوظيف. يتطلب Flutter و React Native معرفة لغة واحدة وإطار واحد.

مزايا وتحديات اعتماد KMM

Kotlin Multiplatform Mobile هي تقنية قوية، لكن اعتمادها يتطلب نهجًا متوازنًا. دعنا نستعرض المزايا الرئيسية والتحديات النموذجية التي تواجه الفرق.

مزايا KMM

الميزة الأولى والأهم هي تقليل تكرار الكود. وفقًا لدراسات الحالة من JetBrains (2024)، الفرق التي اعتمدت KMM تقلل الكود المكرر بنسبة 60–80% لطبقة الشبكة وبنسبة 40–50% لمنطق الأعمال بشكل عام. هذا يؤثر مباشرة على سرعة التطوير وعدد الأخطاء.

الميزة الثانية هي الأداء بمستوى التطبيقات الأصلية. على عكس الأطر الهجينة، لا تضيف KMM طبقات تجريد بين واجهة المستخدم والنظام. يتم تنفيذ كود منطق الأعمال بنفس سرعة كتابته بلغة Swift أو Kotlin لكل منصة على حدة.

تحديات الاعتماد

التحدي الرئيسي هو مؤهلات الفريق. يجب على المطورين معرفة Kotlin (للوحدة المشتركة)، بالإضافة إلى Swift و Jetpack Compose (للواجهة). من الصعب العثور على متخصص شامل، لذلك تتكون الفرق عادة من مطوري Android و iOS الذين يديرون الوحدة المشتركة بشكل مشترك.

التحدي الثاني هو الأدوات. يتطلب KMM تكوين Gradle و CocoaPods أو Swift Package Manager، بالإضافة إلى التكامل مع Xcode. في المراحل المبكرة من المشروع، تكون مشكلات تكوين البناء شائعة، خاصة عند العمل مع مكتبات C.

التحدي الثالث هو تصحيح الأخطاء. عندما يحدث خطأ عند تقاطع Kotlin/Native و Swift، يكون تحديد سببه أكثر صعوبة مما هو عليه في تطبيق متكامل. تعمل JetBrains باستمرار على تحسين أدوات تصحيح الأخطاء، لكن عمليًا، تقضي الفرق ما يصل إلى 20% من وقتها في مهام البنية التحتية.