Kotlin Multiplatform: یہ کیا ہے، shared module اور expect/actual

Kotlin Multiplatform کیا ہے؟

Kotlin Multiplatform ایک کراس کمپائلیشن ٹیکنالوجی ہے جو Kotlin میں مشترکہ کوڈ لکھنے اور اسے مختلف پلیٹ فارمز کے لیے کمپائل کرنے کی اجازت دیتی ہے: JVM (Android)، LLVM (iOS، macOS، watchOS)، JavaScript (Web) اور مقامی بائنری (Linux، Windows)۔ KMP UI فریم ورک نہیں ہے — یہ انٹرفیس نہیں، بلکہ کاروباری منطق کو دوبارہ استعمال کرنے کا مسئلہ حل کرتا ہے۔

KMP فن تعمیر ایک shared module کے گرد بنایا گیا ہے — ایک Gradle ماڈیول جس میں پلیٹ فارم سے آزاد کوڈ کے ساتھ commonMain اور ہر ہدف (androidMain، iosMain، desktopMain) کے لیے source sets شامل ہیں۔ 2025 کے JetBrains اعداد و شمار کے مطابق، 40% سے زیادہ نئے Kotlin پروجیکٹ پلیٹ فارمز کے درمیان کوڈ شیئر کرنے کے لیے KMP استعمال کرتے ہیں۔

Kotlin Multiplatform Mobile (KMM) — iOS+Android موبائل منظرنامے کا پچھلا نام ہے۔ Kotlin 2.1+ سے، KMM کی اصطلاح کو Kotlin Multiplatform سے تبدیل کر دیا گیا ہے، کیونکہ ٹیکنالوجی موبائل ڈیویلپمنٹ سے آگے بڑھ گئی ہے۔ Netflix، McDonald's اور VMware موبائل ایپلیکیشنز کے درمیان کوڈ شیئر کرنے کے لیے پروڈکشن میں KMP استعمال کرتے ہیں۔

Expect/actual میکانزم: فن تعمیر

Expect/actual — پلیٹ فارم کے مخصوص کوڈ کے ساتھ کام کرنے کے لیے KMP کا کلیدی میکانزم ہے۔ commonMain میں ایک expect اعلان (فنکشن، کلاس، پراپرٹی) اعلان کیا جاتا ہے، اور ہر پلیٹ فارم کے مخصوص source set (androidMain، iosMain) میں ایک actual نفاذ فراہم کیا جاتا ہے۔ کمپائلر چیک کرتا ہے کہ ہر expect کے لیے ہر ہدف پلیٹ فارم پر actual موجود ہے۔

// commonMain — پلیٹ فارم API اعلان
expect fun getPlatformName(): String

expect class PlatformContext(val appVersion: String)

// androidMain — Android کے لیے actual
actual fun getPlatformName(): String = "Android \${Build.VERSION.SDK_INT}"

// iosMain — iOS کے لیے actual
actual fun getPlatformName(): String =
    UIDevice.currentDevice.systemName

KMP میں source sets کا درجہ بندی درمیانی سطحیں بنانے کی اجازت دیتی ہے: مثال کے طور پر، iosArm64Main (جسمانی iOS آلات) اور iosSimulatorArm64Main (سیمولیٹر) مشترکہ iosMain کے ساتھ۔ commonMain کا کوڈ تمام پلیٹ فارمز کے لیے دستیاب ہے، جبکہ iosMain کا کوڈ صرف iOS ہدفوں کے لیے دستیاب ہے۔ یہ تکرار کو کم کرتا ہے جب نفاذ ہر پلیٹ فارم کے لیے نہیں بلکہ پلیٹ فارمز کے گروپ کے لیے مختلف ہوتا ہے۔

عملی طور پر، expect/actual اس کے لیے استعمال ہوتا ہے: مقامی اسٹوریج تک رسائی (SharedPreferences بمقابلہ NSUserDefaults)، نیٹ ورکنگ (فی پلیٹ فارم HttpEngine)، فائل سسٹم تک رسائی، کرپٹوگرافی اور تجزیات۔ JetBrains expect/actual اعلانات کی تعداد کو کم سے کم کرنے اور جتنا ممکن ہو سکے commonMain میں کوڈ منتقل کرنے کی سفارش کرتا ہے۔

Shared module: ساخت اور Gradle

Shared module — org.jetbrains.kotlin.multiplatform پلگ ان کے ساتھ ایک معیاری Gradle ماڈیول ہے۔ اس میں src/commonMain/kotlin/ میں مشترکہ کوڈ اور src/androidMain/kotlin/ اور src/iosMain/kotlin/ میں پلیٹ فارم کے مخصوص نفاذ شامل ہیں۔ ایک KMP پروجیکٹ میں androidApp اور iosApp بھی شامل ہوتے ہیں، جو shared module پر منحصر ہوتے ہیں۔

// build.gradle.kts — shared module
plugins {
    kotlin("multiplatform")
    id("com.android.library")
}

kotlin {
    androidTarget()
    
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach {
        it.binaries.framework {
            baseName = "shared"
            isStatic = true
        }
    }

    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("io.ktor:ktor-client-core:3.1.0")
                implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.3")
            }
        }
        val androidMain by getting {
            dependencies {
                implementation("io.ktor:ktor-client-okhttp:3.1.0")
            }
        }
        val iosMain by creating {
            dependencies {
                implementation("io.ktor:ktor-client-darwin:3.1.0")
            }
        }
    }
}

KMP کے لیے Gradle تشکیل میں iOS ہدفوں کا واضح اعلان درکار ہے — x64 (Intel سیمولیٹر)، arm64 (جسمانی آلات) اور simulatorArm64 (Apple Silicon سیمولیٹر)۔ ہر ہدف کے لیے ایک علیحدہ Apple فریم ورک تیار کیا جاتا ہے۔ kotlin("multiplatform") پلگ ان اعلان کردہ ہدفوں کے مطابق JVM اور LLVM کے لیے خود بخود کمپائلیشن ترتیب دیتا ہے۔

Ktor اور kotlinx.serialization — معیاری KMP لائبریریاں جو مشترکہ کوڈ کو سپورٹ کرتی ہیں۔ Ktor ہر پلیٹ فارم کے لیے انجنوں کے ساتھ HTTP کلائنٹ فراہم کرتا ہے (Android کے لیے OkHttp، iOS کے لیے Darwin)۔ kotlinx.serialization commonMain میں اپنے ملٹی پلیٹ فارم نفاذ کی وجہ سے expect/actual کے بغیر تمام پلیٹ فارمز پر کام کرتا ہے۔

Kotlin/Native کے ذریعے iOS انضمام

Kotlin/Native — LLVM کے ذریعے مقامی کوڈ کے لیے Kotlin کمپائلر ہے۔ iOS کے لیے، shared module ایک Apple فریم ورک (.framework) میں کمپائل ہوتا ہے جو Xcode کے ذریعے منسلک ہوتا ہے۔ Swift/Objective-C سے مشترکہ کوڈ کال پیدا کردہ Objective-C ہیڈرز کے ذریعے ہوتی ہے، لہذا shared module API کو Objective-C کے ساتھ مطابقت رکھنا چاہیے۔

iOS انضمام کی حدود: Kotlin کلیکشنز (List, Map) NSArray/NSDictionary میں تبدیل ہو جاتے ہیں۔ ڈیفالٹ پیرامیٹر والے فنکشنز ایکسپورٹ نہیں ہوتے — overloads کی ضرورت ہے۔ suspend فنکشنز کے لیے، @ObjCName اور Kotlin 2.0+ سے async/await سپورٹ کے ساتھ کال بیک پر مبنی طریقے تیار کیے جاتے ہیں۔

// iOS ایپ: Swift سے shared module کال کرنا
import shared

class ViewModel: ObservableObject {
    let repository = UserRepository()
    
    func loadUsers() {
        repository.fetchUsers(completionHandler: { result, error in
            if let users = result as? [User] {
                print("Users: \(users.count)")
            }
        })
    }
}

Xcode میں shared module کا انضمام embed-and-framework کے ذریعے ہوتا ہے — تیار کردہ .xcframework Xcode پروجیکٹ میں شامل کیا جاتا ہے۔ Gradle پلگ ان embedAndSignAppleFrameworkForXcode کے ذریعے بلڈ کے دوران فریم ورک کو خود بخود اپ ڈیٹ کر سکتا ہے۔ سیمولیٹر پر جانچ کے لیے، iosSimulatorArm64 یا iosX64 بائنری کافی ہے۔

KMP بمقابلہ Flutter بمقابلہ React Native

KMP، Flutter اور React Native کے درمیان انتخاب ترجیح پر منحصر ہے: کوڈ دوبارہ استعمال یا مکمل کراس پلیٹ فارم۔ KMP ہر پلیٹ فارم پر مقامی UI فراہم کرتا ہے لیکن انٹرفیس کے لیے دو کوڈ بیسز کی ضرورت ہوتی ہے۔ Flutter اور React Native ایک واحد UI استعمال کرتے ہیں لیکن مقامیت کو قربان کرتے ہیں۔

KMP کب منتخب کریں: پروجیکٹ کو اعلی کارکردگی والے UI (گیمز، نقشے، اینیمیشنز) کی ضرورت ہے، موجودہ مقامی کوڈ کو دوبارہ استعمال کرنا ہے، ٹیم پہلے سے Kotlin اور مقامی پلیٹ فارمز جانتی ہے۔ Flutter/RN کب منتخب کریں: محدود بجٹ والا MVP یا سٹارٹ اپ، ایک پروفائل والی ٹیم، UI کو گہری مقامی تخصیص کی ضرورت نہیں ہے۔

KMP ٹولز اور لائبریریاں

KMP ٹولز ایکو سسٹم میں ایپلیکیشن کی تمام تہوں کے لیے لائبریریاں شامل ہیں: نیٹ ورکنگ (Ktor)، سیریلائزیشن (kotlinx.serialization)، ڈیٹا بیس (SQLDelight)، نیویگیشن (Decompose)، DI (Koin) اور ڈیٹا اسٹوریج (multiplatform-settings)۔ JetBrains Compose Multiplatform کو سپورٹ کرتا ہے — ایک Kotlin UI فریم ورک جو تمام پلیٹ فارمز پر چلتا ہے۔

// SQLDelight + Ktor کے ساتھ KMP ریپوزٹری
class UserRepository(
    private val httpClient: HttpClient,
    private val db: AppDatabase
) {
    suspend fun syncUsers(): List<User> {
        val remote = httpClient.get("https://api.example.com/users")
            .body<List<UserDto>>()
        
        db.userQueries.replaceAll(remote.map { it.toDomain() })
        
        return db.userQueries.selectAll().executeAsList()
    }
}

Compose Multiplatform — Jetpack Compose پر مبنی KMP کے لیے ایک UI فریم ورک ہے۔ یہ Android، iOS، Desktop اور Web کے لیے Kotlin میں انٹرفیس لکھنے کی اجازت دیتا ہے۔ 2025 میں، Compose Multiplatform Android اور Desktop کے لیے مستحکم حالت تک پہنچ گیا؛ iOS ہدف بیٹا میں ہے۔ مقامی UI والے پروڈکشن پروجیکٹس کے لیے، KMP کا فائدہ Flutter سے بنیادی فرق بنا ہوا ہے۔