Kotlin Multiplatform Mobile — یہ کیا ہے، کلیدی تصورات اور KMM آرکیٹیکچر

Kotlin Multiplatform Mobile کیا ہے؟

Kotlin Multiplatform Mobile (KMM) ایک ٹیکنالوجی ہے جو موبائل ایپلیکیشن کے مشترکہ کاروباری منطق کو Kotlin میں لکھنے اور کوڈ کی نقل کے بغیر iOS اور Android پر استعمال کرنے کی اجازت دیتی ہے۔ Ionic یا Cordova کے برعکس، KMM WebView میں انٹرفیس پیش نہیں کرتی — صارف انٹرفیس مکمل طور پر مقامی رہتا ہے اور SwiftUI (iOS) اور Jetpack Compose (Android) میں لکھا جاتا ہے۔

KMM کا اعلان JetBrains نے 2019 میں Kotlin Multiplatform حکمت عملی کے حصے کے طور پر کیا تھا۔ دوسرے کراس پلیٹ فارم حلوں سے بنیادی فرق یہ ہے کہ فریم ورک صارف انٹرفیس کو متحد کرنے کی کوشش نہیں کرتا، بلکہ اس کوڈ کو بانٹنے پر توجہ دیتا ہے جو واقعی دونوں پلیٹ فارمز کے لیے یکساں ہے: نیٹ ورک درخواستیں، ڈیٹا ماڈلز، فارم کی توثیق، کاروباری قواعد اور ڈیٹابیس آپریشنز۔

JetBrains ڈویلپر سروے (2025) کے مطابق، KMM 14% موبائل ڈویلپرز استعمال کرتے ہیں، اور یہ شرح سالانہ 5% بڑھ رہی ہے۔ یہ ٹیکنالوجی اعلی کارکردگی اور مقامی صارف تجربے کی ضروریات والی کمپنیاں منتخب کرتی ہیں، جہاں ہائبرڈ حل قابل قبول نہیں ہیں۔

KMM آرکیٹیکچر: مشترکہ ماڈیول اور پلیٹ فارم کے نفاذ

KMM آرکیٹیکچر تین ماڈیولز پر مشتمل ہے: shared (Kotlin میں مشترکہ کوڈ)، iosApp (Swift میں مقامی iOS ایپلیکیشن)، اور androidApp (Kotlin میں مقامی Android ایپلیکیشن)۔ مشترکہ ماڈیول Android کے لیے JAR اور iOS کے لیے یونیورسل فریم ورک (Apple Framework) میں کمپائل ہوتا ہے۔

مشترکہ ماڈیول: مشترکہ کوڈ میں کیا شامل کیا جاتا ہے

مشترکہ ماڈیول میں تمام پلیٹ فارم سے آزاد پرتیں شامل ہوتی ہیں: Ktor Client استعمال کرنے والی نیٹ ورک پرت، kotlinx.serialization کے ذریعے سیریلائزیشن والے ڈیٹا ماڈلز، ڈیٹا مینجمنٹ کے لیے ذخیرے، فارم کی توثیق اور کاروباری قواعد (مثلاً ترسیل کی لاگت کا حساب یا رسائی کی اجازتوں کی جانچ)۔

مشترکہ ماڈیول Gradle Multiplatform Plugin استعمال کرتا ہے اور اس میں تین سورس سیٹ ہوتے ہیں: commonMain (مشترکہ کوڈ)، androidMain (Android کے مخصوص نفاذ)، اور iosMain (iOS کے مخصوص نفاذ)۔ Kotlin/Native کمپائلر مشترکہ کوڈ کو iOS کے لیے مقامی لائبریری میں تبدیل کرتا ہے، جو XCFramework کے ذریعے Swift پروجیکٹ سے منسلک ہوتی ہے۔

پلیٹ فارم ماڈیولز

Android ماڈیول — Jetpack Compose یا ViewBinding کے ساتھ Kotlin میں ایک معیاری Android ایپلیکیشن ہے۔ مشترکہ ماڈیول ایک عام Gradle انحصار کے طور پر منسلک ہوتا ہے، اور commonMain کی تمام کلاسیں براہ راست قابل رسائی ہیں۔

iOS ماڈیول Swift یا Objective-C میں ایک Xcode پروجیکٹ ہے۔ مشترکہ ماڈیول CocoaPods، Swift Package Manager یا XCFramework کے ذریعے منسلک ہوتا ہے۔ Kotlin/Native Kotlin اقسام کو برآمد کرنے کے لیے Objective-C ہیڈرز تیار کرتا ہے، انہیں Swift سے قابل رسائی بناتا ہے۔

KMM میں expect/actual طریقہ کار

expect/actual Kotlin Multiplatform کا ایک طریقہ کار ہے جو مشترکہ کوڈ میں API اعلان کرنے (expect اعلان) اور ہر پلیٹ فارم کے لیے الگ سے اس کا نفاذ فراہم کرنے (actual اعلان) کی اجازت دیتا ہے۔ کمپائلر اس بات کو یقینی بناتا ہے کہ ہر ہدف پلیٹ فارم کے لیے actual موجود ہو۔

expect/actual کے عام استعمال کے معاملات: ٹائم زون کے ساتھ موجودہ وقت حاصل کرنا، SharedPreferences (Android) / UserDefaults (iOS) کے ساتھ کام کرنا، خفیہ نگاری کے افعال اور UUID کی تخلیق۔ ہر پلیٹ فارم اپنا سسٹم API استعمال کرتا ہے۔

expect/actual کے بغیر، متحد کاروباری منطق کوڈ کا ہونا ناممکن ہوگا، کیونکہ فائل سسٹم، نیٹ ورک اور اسٹوریج کے ساتھ کام کرنے کے APIs سسٹم کال کی سطح پر iOS اور Android کے درمیان مختلف ہوتے ہیں۔ طریقہ کار اس بات کی ضمانت دیتا ہے کہ ڈویلپر پلیٹ فارم کے مخصوص حصے کو نافذ کرنا نہیں بھولے گا۔

کیمرہ یا بایومیٹرکس کے ساتھ کام کرنے جیسی پلیٹ فارم کالز کے لیے، KMM expect/actual طریقہ کار کو Cordova جیسے پلگ انز کے ساتھ پیش کرتی ہے، لیکن Kotlin/Native پر۔ JetBrains نے kotlinx-datetime لائبریری بھی جاری کی ہے، جو تاریخ اور وقت کے انتظام کو تجریدی بناتی ہے۔

KMM کوڈ کی مثالیں

آئیے UUID کی تخلیق کے لیے expect فنکشن کے اعلان اور iOS اور Android کے لیے اس کے نفاذ کے ساتھ KMM پروجیکٹ کی بنیادی ساخت دیکھتے ہیں۔

// 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 Foundation فریم ورک سے NSUUID استعمال کرتا ہے۔ مشترکہ ماڈیول کے باقی کوڈ میں، یہ فنکشن پلیٹ فارم سے قطع نظر بلایا جاتا ہے۔

مشترکہ کوڈ میں 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 بغیر اضافی ترتیب کے Android پر OkHttp اور iOS پر NSURLSession خودکار طور پر استعمال کرتا ہے۔ kotlinx.serialization کے ذریعے JSON سیریلائزیشن بھی کراس پلیٹ فارم ہے۔

KMM کا Flutter اور React Native سے موازنہ

KMM کراس پلیٹ فارم ٹیکنالوجیز کے درمیان ایک منفرد مقام رکھتی ہے، کیونکہ یہ Flutter اور React Native کے برعکس مقامی UI کو تبدیل کرنے کی کوشش نہیں کرتی۔ KMM منطق کو بانٹنے کا حل ہے، انٹرفیس کو متحد کرنے کا نہیں۔

KMM کا بنیادی فائدہ صارف انٹرفیس پر مکمل کنٹرول ہے۔ اگر ایپلیکیشن کو ہر پلیٹ فارم پر مقامی نظر آنے اور برتاؤ کرنے کی ضرورت ہے (مثال کے طور پر، پلیٹ فارم اینیمیشنز کے ساتھ iOS TabBar اور Android BottomNavigation استعمال کرنا)، تو 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 (UI کے لیے) کا علم ہونا چاہیے۔ ایک عالمگیر ماہر تلاش کرنا مشکل ہے، لہذا ٹیمیں عام طور پر Android اور iOS ڈویلپرز پر مشتمل ہوتی ہیں جو مشترکہ طور پر مشترکہ ماڈیول کو برقرار رکھتی ہیں۔

دوسرا چیلنج اوزار ہیں۔ KMM کو Gradle، CocoaPods یا Swift Package Manager کی تشکیل کے ساتھ ساتھ Xcode کے ساتھ انضمام کی ضرورت ہوتی ہے۔ پروجیکٹ کے ابتدائی مراحل میں، بلڈ کنفیگریشن کے مسائل عام ہیں، خاص طور پر C لائبریریوں کے ساتھ کام کرتے وقت۔

تیسرا چیلنج ڈیبگنگ ہے۔ جب Kotlin/Native اور Swift کے سنگم پر کوئی بگی پیدا ہوتی ہے، تو اس کی وجہ تعین کرنا یک سنگی ایپلیکیشن کے مقابلے میں زیادہ مشکل ہوتا ہے۔ JetBrains ڈیبگنگ ٹولز کو مسلسل بہتر بنا رہا ہے، لیکن عملی طور پر، ٹیمیں اپنا 20% وقت بنیادی ڈھانچے کے کاموں پر خرچ کرتی ہیں۔