In der modernen Softwareentwicklung ist die Wiederverwendung von Code über Plattformen hinweg ein wesentlicher Schlüssel, um Effizienz und Qualität zu gewährleisten. Besonders im Bereich der mobilen App-Entwicklung stehen Entwickler häufig vor der Herausforderung, SDKs zu erstellen, die sowohl für Android als auch für iOS verfügbar sind, ohne dabei Projekte zweimal von Grund auf neu schreiben zu müssen. Ein solcher Ansatz ist die Nutzung von Kotlin Multiplatform, die es erlaubt, eine gemeinsame Codebasis für mehrere Plattformen zu verwenden. Allerdings stellt die Einbindung dieser gemeinsamen Module in eine native Swift-Umgebung eine besondere Herausforderung dar. Genau an dieser Stelle kommt SKIE ins Spiel.
Dabei handelt es sich um ein Tool, das den Brückenschlag zwischen Kotlin und Swift vereinfacht und beschleunigt. Das Portfolio von PowerSync zeigt eindrucksvoll, wie sich eine solche Idee in der Praxis umsetzen lässt und welche Lehren Entwickler dabei ziehen können. PowerSync verfolgt das Ziel, die Datenprovisionierung und Zustandsverwaltung in Anwendungen radikal zu vereinfachen. Es bietet einen automatisch synchronisierten lokalen Datenspeicher auf Basis von SQLite, der sicherstellt, dass relevante und autorisierte Daten stets auf den Clients verfügbar sind. Um diese Vorteile möglichst vielen Entwicklern zugänglich zu machen, bietet PowerSync plattformübergreifende SDKs, unter anderem für Kotlin und Swift.
Die Reise zur Entwicklung des Swift SDKs verdeutlicht, wie wichtig eine klare Architektur ist und wie man pragmatisch sowohl native als auch geteilte Komponenten optimal nutzt. Zu Beginn stand die Erkenntnis, dass ein eigenständiges Swift SDK auf Basis der bisherigen Kotlin Kernimplementation sinnvoll sein kann, um Kosten und Entwicklungszeit zu sparen. Die erste Alpha-Version basierte auf Objective-C-Code, der aus dem kompilierten Kotlin SDK generiert wurde, anschließend wurde SKIE eingesetzt, um Swift-Interfaces daraus zu erstellen. SKIE, entwickelt von Touchlab, erwies sich als besonders wirkungsvoll, weil es eine beinahe automatische Brücke von Kotlin zu Swift bildet. Dadurch konnte der Großteil des bereits vorhandenen Kotlin Codes wiederverwendet werden, ohne ihn komplett neu schreiben zu müssen.
Trotzdem zeigte sich, dass dieses rohe SKIE-Ergebnis noch einige Schwächen hatte. Beispielsweise waren die Funktionsnamen verschachtelt und schwer lesbar, viele Kotlin-typische Wrapper mussten in Swift manuell übersetzt werden, und Entwickler mussten selbst zahlreiche Brücken zwischen Kotlin und Swift schlagen, was den Aufwand erhöhte und die Entwicklererfahrung einschränkte. Daher musste eine Verbesserung her, die im Rahmen der Beta-Version realisiert wurde. Das Ziel war klar: das SDK sollte ein natives, idiomatisches Swift-Erlebnis bieten, ohne auf die gemeinsame Kotlin-Kernlogik zu verzichten. Deshalb wurden Swift-Protokolle für die öffentlichen APIs eingeführt, die als saubere Schnittstellen agieren.
Dies ermöglichte es, die internen Kotlin-Implementierungen mit leichten Adaptern zu verbinden und dabei Swift-eigene Foundation-APIs zu nutzen. Das Ergebnis war deutlich besser lesbarer, wartungsfreundlicher und intuitiver zu programmierender Code. Die Entwickler mussten sich nicht mehr mit Kotlin-Wrappern herumschlagen, sie bekamen eine API, die sich wie ein echtes Swift SDK anfühlte. Ein weiterer entscheidender Fortschritt dieses Designs war die Stabilität und Zuverlässigkeit. Die Entwickler von PowerSync legten besonderen Wert darauf, dass alle asynchronen Operationen und Datenbankzugriffe thread-sicher ablaufen.
Gerade bei Apps mit hoher Parallelität und konkurrierenden Datenbankoperationen ist korrekte Synchronisation essentiell, um Datenkorruption und Abstürze zu vermeiden. Im stabilen SDK wurde deshalb ein ausgeklügeltes System zur Synchronisation implementiert, welches verhindert, dass mehrere Tasks die interne State-Maschine gleichzeitig in Konflikt bringen. Die Konsistenz wird durch koordinierte Abläufe sichergestellt, selbst wenn mehrere Tasks gleichzeitig Verbindungs-Aufrufe oder Abfragen durchführen. Zusätzlich wurde im stabilen Release das Konzept des Connection Poolings eingeführt. Im Gegensatz zum Beta-SDK, das noch mit jeweils einer einzelnen Schreib- und Leseverbindung arbeitete, erlaubt das stabile SDK mehrere gleichzeitige Lesezugriffe auf eine Pool-Liste von Lese-SQLite-Verbindungen.
Die Schreibverbindung bleibt zwar sequenziell, um atomare Operationen sicherzustellen, kann aber durch die parallele Lesepool-Architektur deutlich mehr Performance bei datenintensiven Anwendungen liefern. Gerade bei moderneren Swift-Apps, die zahlreiche Datenquellen parallel aus einer lokalen Synchronisationsdatenbank abfragen, zahlt sich dies mit flüssigen und schnellen UI-Erlebnissen aus. Ein weiterer Anwendungsfall, der enorm von dieser verbesserten Architektur profitiert, ist das Watch-Query-System, das reaktive Datenänderungen in Echtzeit an die Anwendung weiterleitet. Angefangen bei der Alpha- und Beta-Version traten dort noch Probleme wie verpasste Updates oder veraltete Zwischenergebnisse auf. Mit der stabilen Version wurden Mechanismen für thread-sichere Benachrichtigungen und effizientes Zusammenfassen von Updates eingeführt.
So arbeitet nun jede überwachte Abfrage unabhängig und synchronisiert Änderungen zuverlässig an die jeweiligen UI-Komponenten oder Prozesse weiter. Das verbessert nicht nur die Performance, sondern auch die Entwicklererfahrung erheblich. Neben der technischen Stabilität war der Fokus auch auf einer übersichtlichen und nativen Swift API. Im stabilen SDK wurde konsequent darauf geachtet, alle Kotlin-Datentypen, die für Swift unnatürlich waren, durch native Swift-Typen zu ersetzen. Das betrifft beispielsweise Datumswerte, die nicht mehr als Kotlin-eigene Wrapper, sondern als Swift-Date-Objekte zurückgegeben werden.
So entfällt der lästige Boilerplate-Code zur Umwandlung, was die Lesbarkeit und Handhabung des Codes deutlich verbessert. Auch der Umgang mit Transaktionen wurde überarbeitet. Während die erste Version noch mit eingeschränkter Generik-Unterstützung aus Kotlin kämpfte und oft unsichere Casts erforderte, ermöglichte die Umwandlung der Transaktions-API in native Swift-Funktionalitäten eine saubere Handhabung inklusiver typsicherer Rückgabewerte. Dies erhöht die Wartbarkeit, verringert Fehlerquellen und sorgt dafür, dass Entwickler sicherer und flüssiger mit Datenbanktransaktionen umgehen können. Darüber hinaus vereinfachte das Team die CRUD-Operationen erheblich.
Dort, wo vorher noch die SKIE-generierten Kotlin-Methoden mühsam und wenig intuitiv aufgerufen werden mussten, ermöglicht das stabile SDK einfache Swift-Methodenaufrufe, welche sich nahtlos in native Codebasen einfügen. Man könnte sagen, die API fühlt sich endlich „Swift-like“ an – schlanke Methoden, keine unnötigen Parameter und klarer Fokus auf Produktivität. Ein komplexes Feature bei SQLite-Integration sind die Cursor APIs, mit denen Datenbankergebnisse zeilenweise ausgewertet werden. Während Beta-Varianten hier oft durch Kotlin-spezifische Typeninseln glänzten, ist das stabile SDK darauf ausgerichtet, komplett native Swift-Werte zurückzugeben. Das vermeidet Umwandlung und Casting, was gerade bei der Verarbeitung großer Datenmengen für Stabilität und Performance wichtig ist.
Außerdem wurden Komfortfunktionen wie das Unterdrücken unnötiger Compiler-Warnungen, Unterstützung von nil-Parametern in SQL-Statements sowie spezialisierte Fehlerklassen für SQL-Cursor-Fehler ergänzt. All diese Details zeigen, dass das Team nicht nur an die Architektur, sondern auch an die Komfortabilität der SDK-Nutzung dachte. Was macht diese Architektur so besonders wertvoll? Sie verbindet auf clevere Weise die Stärken einer geteilten, in Kotlin geschriebenen Kernlogik mit einer schlanken, nativen Swift-Schicht obendrauf. Das bedeutet für Entwickler von Swift-Apps: Sie profitieren von der Stabilität, der getesteten Business-Logik und den kontinuierlichen Updates des Kotlin-Moduls, ohne sich mit Kotlin-spezifischen Details belasten zu müssen. Gleichzeitig erlaubt die Swift-Oberfläche eine idiomatische, komfortable Nutzung der APIs mit nativen Typen und Protokollen.
Diese Herangehensweise führt auch zu einer ganz klaren Win-Win-Situation für das SDK-Team. Statt Fehler und Features in zwei völlig getrennten Codebasen pflegen zu müssen, kann die Kernfunktionalität einmal aufwendig getestet, optimiert und verlässlicher gemacht werden. Alle Plattformen profitieren unmittelbar von Verbesserungen, während das Swift-Frontend flexibel auf Neuerungen reagieren kann, etwa wenn Apple neue Sprachfeatures veröffentlicht oder Designrichtlinien anpasst. Was können Entwickler und Teams, die mit Kotlin Multiplatform und Swift arbeiten, von PowerSyncs Vorgehen lernen? Wichtig ist es, von Anfang an mit modularen, klar definierten Schnittstellen zu arbeiten, damit der Austausch zwischen den Welten so sauber und wartbar wie möglich bleibt. Die Nutzung von Tools wie SKIE kann die Startphase deutlich verkürzen, sollte aber nicht als Endlösung gesehen werden.
Eine native Adaptierung der APIs in der Zielplattform steigert die Akzeptanz und Entwicklerzufriedenheit deutlich. Darüber hinaus ist die Konzentration auf asynchrone Programmierung und Thread-Sicherheit essenziell, um bei komplexen Anwendungen Stabilität zu gewährleisten. Die Verbindung von Shared Code mit nativen Patterns ist dabei ein Schlüssel, um die Vorteile beider Welten zu vereinen und somit langfristig den größten Nutzen aus Investitionen in einmaligen Code zu ziehen. Die Zukunft der Swift SDKs auf Kotlin-Basis sieht vielversprechend aus. PowerSyncs stable Versionen signalisieren, dass ein solches hybrides Konzept produktiv und wartbar umgesetzt werden kann.
Mit der offenen Architekturoffenheit bleibt Raum für Verbesserungen, alternative SQLite-Engines und native Spezialfeatures – genau das, was eine lebendige SDK-Ecosystem braucht. Insgesamt zeigt das Projekt, dass das Zusammenspiel von Kotlin Multiplatform, SKIE und nativen Swift-Praktiken keine pure Theorie ist, sondern echte und substanzielle Mehrwerte für Entwickler und Anwender liefert. Die dabei gewonnene Flexibilität, Performance und Usability sind entscheidende Faktoren, um SDKs erfolgreich über Plattformgrenzen hinweg anzubieten. Für alle, die sich mit Multiplattform-Entwicklung auseinandersetzen wollen, bietet dieser Erfahrungsbericht wertvolle Einsichten in technische Chancen und Herausforderungen beim Brückenbauen zwischen Kotlin und Swift.
![Create a Product People Will Buy [video]](/images/4977E4E7-1D4B-48A2-9726-DEADC3B12E4D)
