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. Η βασική διαφορά από άλλες λύσεις cross-platform — το πλαίσιο δεν προσπαθεί να ενοποιήσει το UI, αλλά επικεντρώνεται στην κοινή χρήση ακριβώς εκείνου του κώδικα που είναι πραγματικά ίδιος και για τις δύο πλατφόρμες: αιτήματα δικτύου, μοντέλα δεδομένων, επικύρωση φορμών, επιχειρηματικούς κανόνες και εργασία με βάσεις δεδομένων.

Σύμφωνα με το JetBrains Developer Survey (2025), το KMM χρησιμοποιείται από το 14% των προγραμματιστών κινητών και αυτό το ποσοστό αυξάνεται κατά 5% ετησίως. Η τεχνολογία επιλέγεται από εταιρείες με υψηλές απαιτήσεις απόδοσης και εγγενούς εμπειρίας χρήστη, για τις οποίες οι υβριδικές λύσεις είναι απαράδεκτες.

Αρχιτεκτονική KMM: shared module και υλοποιήσεις πλατφόρμας

Η αρχιτεκτονική του KMM αποτελείται από τρία modules: shared (κοινός κώδικας σε Kotlin), iosApp (εγγενής εφαρμογή iOS σε Swift) και androidApp (εγγενής εφαρμογή Android σε Kotlin). Το shared module μεταγλωττίζεται σε JAR για Android και σε ένα καθολικό πλαίσιο (Apple Framework) για iOS.

Shared module: τι μεταφέρεται στον κοινό κώδικα

Στο shared module εισέρχονται όλα τα επίπεδα ανεξάρτητα από την πλατφόρμα: επίπεδο δικτύου σε Ktor Client, μοντέλα δεδομένων με σειριοποίηση μέσω kotlinx.serialization, αποθετήρια για διαχείριση δεδομένων, επικύρωση φορμών και επιχειρηματικοί κανόνες (για παράδειγμα, υπολογισμός κόστους αποστολής ή έλεγχος δικαιωμάτων πρόσβασης).

Το shared module χρησιμοποιεί το Gradle Multiplatform Plugin και περιέχει τρία σύνολα πηγαίου κώδικα: commonMain (κοινός κώδικας), androidMain (υλοποιήσεις ειδικές για Android) και iosMain (υλοποιήσεις ειδικές για iOS). Ο μεταγλωττιστής Kotlin/Native μετατρέπει τον κοινό κώδικα σε εγγενή βιβλιοθήκη για iOS, η οποία συνδέεται με το έργο Swift μέσω XCFramework.

Modules πλατφόρμας

Το module Android — είναι μια τυπική εφαρμογή Android σε Kotlin με Jetpack Compose ή ViewBinding. Το shared module συνδέεται ως μια συνηθισμένη εξάρτηση Gradle και όλες οι κλάσεις από το commonMain είναι άμεσα προσβάσιμες.

Το module iOS — είναι ένα έργο Xcode σε Swift ή Objective-C. Το shared module συνδέεται μέσω 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 module, αυτή η συνάρτηση καλείται χωρίς να λαμβάνεται υπόψη η πλατφόρμα.

Παράδειγμα αιτήματος δικτύου με χρήση 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 είναι επίσης cross-platform.

Σύγκριση KMM με Flutter και React Native

Το KMM κατέχει μοναδική θέση μεταξύ των τεχνολογιών cross-platform, επειδή δεν προσπαθεί να αντικαταστήσει το εγγενές UI σε αντίθεση με τα Flutter και React Native. KMM — είναι μια λύση για κοινή χρήση λογικής, όχι για ενοποίηση διεπαφής.

Το κύριο πλεονέκτημα του KMM — πλήρης έλεγχος του UI. Εάν η εφαρμογή πρέπει να φαίνεται και να συμπεριφέρεται ως εγγενής σε κάθε πλατφόρμα (για παράδειγμα, να χρησιμοποιεί iOS TabBar και Android BottomNavigation με κινούμενα σχέδια πλατφόρμας), το KMM είναι η μόνη λύση cross-platform που το εξασφαλίζει χωρίς προσωρινές λύσεις.

Μειονέκτημα — η ομάδα πρέπει να γνωρίζει ταυτόχρονα 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 module), καθώς και Swift και Jetpack Compose (για το UI). Η εύρεση ενός καθολικού ειδικού είναι δύσκολη, γι' αυτό συνήθως σχηματίζεται ομάδα από προγραμματιστές Android και iOS που διαχειρίζονται από κοινού το shared module.

Η δεύτερη πρόκληση — τα εργαλεία. Το KMM απαιτεί διαμόρφωση των Gradle, CocoaPods ή Swift Package Manager, καθώς και ενσωμάτωση με το Xcode. Στα πρώτα στάδια του έργου, είναι συχνά προβλήματα με τη διαμόρφωση μεταγλώττισης, ειδικά κατά την εργασία με βιβλιοθήκες C.

Η τρίτη πρόκληση — ο εντοπισμός σφαλμάτων. Όταν ένα σφάλμα εμφανίζεται στη διεπαφή Kotlin/Native και Swift, ο προσδιορισμός της αιτίας του είναι δυσκολότερος από ό,τι σε μια μονολιθική εφαρμογή. Η JetBrains βελτιώνει συνεχώς τα εργαλεία εντοπισμού σφαλμάτων, αλλά στην πράξη οι ομάδες πρέπει να αφιερώνουν έως και 20% του χρόνου σε υποδομές.