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 vs 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 की आवश्यकता होती है। सस्पेंड फ़ंक्शन के लिए, @ObjCName और Kotlin 2.0+ से async/await समर्थन के साथ callback-आधारित विधियाँ जनरेट की जाती हैं।

// 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 vs Flutter vs 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 लक्ष्य beta में है। नेटिव UI वाले प्रोडक्शन प्रोजेक्ट के लिए, KMP का लाभ Flutter से मुख्य अंतर बना हुआ है।