Teil 2 – Nativ oder stirb? Swift & Kotlin im Fokus

Es gibt Entwickler, die bei dem Wort „nativ“ sofort nicken – und solche, die die Augen verdrehen. Beide Reaktionen sind nachvollziehbar. Denn native Entwicklung bedeutet: Für iOS schreibst du Swift, für Android Kotlin, und die beiden Codebasen haben miteinander so viel gemeinsam wie ein Lötkolben mit einem Touchscreen. Nichts. Trotzdem – oder gerade deshalb – lohnt sich ein genauer Blick.

Was „nativ“ eigentlich bedeutet

Nativ heißt: Du redest direkt mit dem Betriebssystem. Keine Abstraktionsschicht dazwischen, kein Framework, das übersetzt, vermittelt oder puffert. Deine App nutzt die Plattform-APIs so, wie Apple und Google sie vorgesehen haben – und das merkt man. Animationen laufen flüssig, die Integration ins System sitzt perfekt, und neue Betriebssystem-Features stehen dir zur Verfügung, sobald das Update draußen ist. Cross-Platform-Frameworks hinken hier oft Monate hinterher.

Aus der Perspektive eines Elektronikers lässt sich das gut einordnen: Es ist der Unterschied zwischen einem Treiber, der direkt auf der Hardware aufsetzt, und einer Middleware, die erst noch interpretiert werden muss. Beides funktioniert – aber eben nicht gleich.

Swift: Apples Antwort auf Objective-C

Swift erschien 2014 und hat Objective-C innerhalb weniger Jahre fast vollständig verdrängt. Das sagt einiges. Die Sprache ist modern, ausdrucksstark und deutlich weniger fehleranfällig als ihr Vorgänger – allein schon durch das Typsystem und die klare Handhabung von optionalen Werten. Wer einmal in einem Objective-C-Projekt in einem Nil-Pointer-Chaos versunken ist, weiß, wovon ich spreche.

SwiftUI hat die UI-Entwicklung auf Apple-Plattformen nochmal grundlegend verändert. Deklarativ, reaktiv, eng verzahnt mit dem Apple-Ökosystem. Der Einstieg fühlt sich für jemanden mit modernem Entwicklungshintergrund deutlich natürlicher an als die alte UIKit-Welt. Allerdings: SwiftUI hat noch Ecken und Kanten, besonders wenn komplexere Layouts oder ältere iOS-Versionen ins Spiel kommen. Da greift man dann doch wieder zu UIKit – und plötzlich vermischt sich das Neue mit dem Alten auf eine Art, die den Code schnell unübersichtlich macht.

Die Bindung an Apples Ökosystem ist Stärke und Schwäche zugleich. Xcode als Entwicklungsumgebung ist mächtig, aber auch eigensinnig. Wer nicht auf einem Mac sitzt, entwickelt schlicht nicht für iOS – das ist eine harte Einschränkung, die sich nicht wegdiskutieren lässt.

Kotlin: Der Erwachsenenweg auf Android

Kotlin hat Java auf Android in einer Geschwindigkeit abgelöst, die die gesamte Community überrascht hat. Google erklärte Kotlin 2017 zur offiziellen Sprache, und seitdem ist Java in neuen Android-Projekten eigentlich kein ernstes Thema mehr. Die Sprache ist prägnant, typsicher, und Coroutines haben asynchrone Programmierung auf Android von einem Albtraum in etwas Beherrschbares verwandelt.

Jetpack Compose – Googles Antwort auf SwiftUI – denkt UI-Entwicklung auf Android komplett neu. Statt XML-Layouts schreibt man UI direkt in Kotlin-Code, deklarativ und reaktiv. Das ist ein Paradigmenwechsel, den man erst mal verinnerlichen muss. Aber wenn er sitzt, will man nicht zurück.

Was Kotlin gegenüber Swift noch interessanter macht: Es läuft nicht nur auf Android. Kotlin Multiplatform öffnet die Tür zu geteilter Geschäftslogik auf iOS, Desktop und Web – dazu mehr in Teil 4 dieser Serie. Das hebt Kotlin aus der reinen Android-Ecke heraus und gibt der Sprache eine strategische Dimension, die Swift schlicht fehlt.

Wann lohnt sich der doppelte Aufwand?

Zwei Codebasen bedeuten zwei Teams, zwei Entwicklungszyklen, doppelter Wartungsaufwand. Das klingt erst mal nach einem Argument gegen nativ – ist es aber nicht automatisch. Wenn Performance entscheidend ist, wenn die App tief ins System eingreift, wenn plattformspezifische Features keine Kompromisse erlauben, dann ist nativ die richtige Wahl. Spiele, AR-Anwendungen, systemnahe Tools: hier spielt nativ seine Stärken voll aus.

Für eine Business-App, die hauptsächlich Daten anzeigt und ein Formular absenden lässt? Da muss man die doppelte Codebasis wirklich rechtfertigen können. Das ist keine Schwäche nativer Entwicklung – es ist einfach eine ehrliche Einschätzung der Kosten.

Fazit für Teil 2

Swift und Kotlin sind beides ausgereifte, moderne Sprachen, die Spaß machen – wenn man sich auf ihre jeweilige Plattform einlässt. Die Stärke nativer Entwicklung liegt nicht im Prestige, sondern in der Tiefe der Plattformintegration und der Verlässlichkeit. Wer die Ressourcen hat und Kompromisse bei Performance oder User Experience scheut, fährt damit richtig. Allen anderen empfehle ich, erst Teil 3 zu lesen.