- Ein plattformübergreifendes natives Framework, mit dem sich auf Basis von Swift und SwiftUI iOS- und Android-Apps mit einer einzigen Codebasis entwickeln lassen
- Ab Skip Version 1.7 entfallen alle Lizenzbeschränkungen, womit es zu einem vollständig Open-Source-Tool wird, das jeder kostenlos nutzen kann
- Die Kern-Engine „skipstone“ wurde auf GitHub veröffentlicht und stellt wichtige Build-Funktionen wie Projekterstellung, Konvertierung und Packaging als Open Source bereit
- Bestehende zahlende Abonnenten werden automatisch in ein Sponsoring-Programm überführt; Unterstützung des Projekts ist durch Einzelpersonen und Unternehmen möglich
- Diese Veröffentlichung ist ein Wendepunkt für den Aufbau eines langfristigen, communitygetriebenen Ökosystems und die Bereitstellung eines echten nativen Erlebnisses
Überblick
- Seit der Einführung im Jahr 2023 wurde Skip mit dem Ziel weiterentwickelt, die gleichzeitige Entwicklung von iOS- und Android-Apps mit Swift- und SwiftUI-Code zu ermöglichen
- Anfangs begann es mit einem Swift-to-Kotlin-Transpiler und grundlegender Unterstützung für die SwiftUI-API
- Später wurde durch die Gründung der Swift Android Workgroup und die Veröffentlichung des Swift Android SDK die native Kompilierung für Android unterstützt
- Heute ist es mit Dutzenden integrierten Frameworks und Tausenden Swift-Paketen kompatibel und bietet die vollständigste eigenständige SwiftUI-Implementierung
Grenzen kostenpflichtiger Entwicklungstools
- Bisher waren für Skip kostenpflichtige Abonnements und Lizenzschlüssel erforderlich; nur einzelne Entwickler mit Einnahmen unterhalb einer bestimmten Schwelle konnten es kostenlos nutzen
- Die meisten Entwickler erwarten jedoch kostenlose Tools, und auch wichtige IDEs wie Xcode und Android Studio werden kostenlos angeboten
- Zudem gibt es Bedenken hinsichtlich der Nachhaltigkeit kostenpflichtiger und geschlossener Tools
- Falls ein Unternehmen eingestellt oder übernommen wird, besteht das Risiko, dass die Wartung von Entwickler-Apps erschwert wird
- Um dieses Problem zu lösen, stellt Skip vollständig auf eine freie Open-Source-Basis um, sodass die Community die Technologie unabhängig weiter pflegen kann
Änderungen
- Ab Skip 1.7 werden Lizenzschlüssel, Testversionen und EULA vollständig abgeschafft
- Bestehende Nutzer: Nach dem Upgrade ist kein Lizenzschlüssel mehr erforderlich
- Neue Nutzer: Builds sind sofort möglich
- Die Skip-Engine „skipstone“ wird Open Source
- Enthält zentrale Build-Funktionen wie Projekterstellung und -verwaltung, Xcode- und SwiftPM-Plugins, iOS→Android-Konvertierung, Resource-Bundling, JNI-Brücke, Source-Transpilation, App-Packaging und Projektexport
- Öffentliches GitHub-Repository: https://github.com/skiptools
- Umzug der offiziellen Website
- Wechsel von skip.tools zu skip.dev
- Umfasst Dokumentation, Blog und Fallstudien; auch die Website selbst wird als Open Source veröffentlicht
Zukünftige Unterstützung für Skip
- Skip wurde unabhängig und ohne externe Investitionen betrieben und bleibt ohne Kontrolle großer Tech-Unternehmen auf Entwickler ausgerichtet
- Um diese Unabhängigkeit zu bewahren, ist Unterstützung durch die Community nötig
- Bestehende Abonnenten werden automatisch in die Tiers Individual oder Supporter überführt
- Einzelne Entwickler können Skip monatlich über GitHub Sponsors unterstützen
- Unternehmen können über ein Sponsoring-Programm direkt die Entwicklung, Wartung und Infrastruktur des Frameworks fördern
- Diese Unterstützung sichert die kontinuierliche Entwicklung und den langfristigen Erfolg von Skip und stärkt die Wettbewerbsfähigkeit des Entwicklungsteams
Weitere Pläne
- Die App-Entwicklung steht derzeit vor den Grenzen bestehender plattformübergreifender Frameworks
- Auf Änderungen moderner UI-Systeme wie iOS Liquid Glass oder Android Material Expressive lässt sich nur schwer reagieren
- Kompromisse in einer einheitlichen Codebasis führen zu veralteten Oberflächen und geringerer Wettbewerbsfähigkeit
- Skip entwickelt sich in Richtung eines vollständig nativen Erlebnisses auf beiden Plattformen weiter
- Die Open-Source-Umstellung ist der nächste Schritt, um verschiedene Ökosysteme wie Swift·Kotlin, SwiftPM·Gradle, Xcode·Android Studio zusammenzuführen
- Die weitere Entwicklung hängt von Beteiligung und Unterstützung der Entwickler-Community ab
und wird auf Skips Vision einer „plattformübergreifenden Grundlage ohne Kompromisse“ hinarbeiten
3 Kommentare
Cross-Plattform ist eine (scheinbar greifbare, aber doch unerreichbare) Fata Morgana.
Skip – Entwicklung nativer iOS- und Android-Apps mit einer einzigen Swift-Codebasis
Hacker-News-Kommentare
Es ist bedauerlich, dass Entwickler selbstverständlich kostenlose Tools erwarten.
Dass ein so gut bezahlter Berufsstand wie unserer kein Geld für Tools ausgeben will, ist selbst im Vergleich zu anderen Fachberufen ungewöhnlich.
Wenn möglich, sollte man nicht von FAANG oder VC-Geldern abhängig sein, sondern für gute Software direkt bezahlen.
Wir gehören zu einem Berufsfeld, das seine Tools selbst bauen kann, und die Vertriebskosten liegen bei null.
Weil man denkt „Das kann ich auch selbst bauen“, ist der Markt für bezahlte Entwicklertools begrenzt.
Open Source verringert diesen Frust, und Nutzer müssen letztlich nur ihre eigene Trägheit überwinden.
Wichtiger als der Preis ist die Freiheit.
Ich stimme der Einschätzung zu, dass es riskant ist, die App-Strategie vollständig von einem bezahlten, geschlossenen Tool einer kleinen Firma abhängig zu machen.
Aber nachdem bereits Millionen Dollar in andere Lösungen geflossen waren, waren selbst ein paar tausend Dollar für ein neues Tool durch die bürokratischen Hürden kaum durchzubekommen.
Es ist oft nicht so, dass Entwickler kein Geld ausgeben wollen, sondern dass die Organisationsstruktur sie daran hindert.
Wenn man Bugs oder Einschränkungen entdeckt, kann man sie selbst beheben und die Änderung teilen.
Wie beim Auto-Beispiel ist Open Source für Menschen, die lieber an Dingen selbst arbeiten können, deutlich attraktiver.
Anwälte und Ärzte machen zwar auch Pro-bono-Arbeit, kommen aber nicht annähernd an das Ausmaß von Open Source heran.
Wenn ich sehe, wie Skip funktioniert, frage ich mich, ob irgendwann AI-Agenten Code für eine Plattform wie iOS automatisch in nativen Code für eine andere Plattform wie Swift oder Kotlin umwandeln werden.
Ich habe bisher keine wirklich überzeugende Cross-Platform-Mobile-Entwicklungsumgebung gefunden, deshalb fand ich Skip interessant.
Dann habe ich aber gesehen, dass macOS 15 oder neuer und Xcode 16.4 oder neuer erforderlich sind, was nicht meinen Erwartungen entsprach.
Auch die selbstbewusste Aussage „maximale Effizienz ohne zusätzliche Runtime“ fällt auf, aber die Anforderung von 32 GB Arbeitsspeicher überrascht.
Aus Sicht eines Flutter-Entwicklers frage ich mich, warum man Skip überhaupt braucht.
Flutter ist bereits ausgereift und unterstützt nicht nur Mobile, sondern auch Desktop und Web.
Ich bin aber neugierig, wie viel Performance-Gewinn Skip bringt, und werde es vielleicht ausprobieren, wenn sich die DRAM-Preise stabilisieren.
Deshalb wirkt die UI wie aus einer älteren Generation, und genau diese Grenze hat mein Interesse an Skip verstärkt.
Wenn man Dart mag oder eine vollständig angepasste UI will, ist Flutter in Ordnung, aber für ein Business, bei dem ein hochwertiges natives Look-and-Feel wichtig ist, passt Skip besser.
Zugehöriges Issue: Flutter issue #170310
Selbst wenn die Widgets nativ aussehen, wirkt etwas daran unnatürlich, und auch die Animationen sind nicht so flüssig.
Es fühlt sich eine Stufe unter React Native an.
Besonders die Google-Maps-Integration ist furchtbar.
Die Kosten für eine wirklich gute Flutter-App sind am Ende ähnlich hoch wie für eine native App.
Die 32-GB-Anforderung von Skip überrascht nicht, wenn man die gesamte Entwicklungsumgebung mit Xcode, Gradle, Emulatoren usw. berücksichtigt.
Wenn man keine vollständig angepasste UI will, ist es schwierig, das plattformspezifische Gefühl einzufangen.
Der Titel des Beitrags enthält einen zu wenig eindeutigen Softwarenamen; ein etwas beschreibenderer Titel wäre besser gewesen.
Ich habe mir das Skip-GitHub-Repository angesehen, und dort gibt es keine Lizenzdatei.
Deshalb fällt es für mich in die Kategorie „nicht verwenden (DONT USE)“.
Das Skipstone-Repository hat zwar eine Lizenz, bindet Skip aber als Vendor ein, was verwirrend ist.
Das Fehlen der Lizenz war ein Versehen und wird bald korrigiert.
Trotz vieler Versuche ist ein einheitlicher Build für iOS und Android grundsätzlich schwierig.
Es gab viele Ansätze mit HTML, JS, React, Dart, Kotlin und Swift, aber bei einer Größenordnung von mehr als 10 Millionen Installationen sind sie gescheitert.
Zugehöriger Beitrag
Die App von Nubank in Brasilien wurde mit Flutter entwickelt und ist ein großer Dienst mit über 100 Millionen Nutzern.
Ein Erfolgsfaktor war, dass die Codebasis nicht zu groß wurde.
Die Formulierung „Für die Entwicklung mit Skip werden mindestens 32 GB Arbeitsspeicher empfohlen“ hat mich schockiert.
Skip selbst ist leichtgewichtig, und im Headless-Modus geht es auch mit deutlich weniger Speicher.
Die Speicherineffizienz ist nicht Skips Schuld, sondern ein Problem der Toolchain-Struktur von Apple und Google.
Ich wollte die Navigations-App für Sehbehinderte Soundscape Community auf Android portieren, und Skip wirkt dafür wie eine ideale Lösung.
Wenn Accessibility-Funktionen wie TalkBack ebenfalls in native UI übersetzt werden, sollte das gut funktionieren.
Soundscape GitHub-Link
Beispielcode: Skip-Accessibility-Dokumentation
Skip könnte sich als langfristige Cross-Platform-Option für SwiftUI etablieren.
Es wäre gut, wenn Apple sich direkt an diesem Toolset beteiligen oder zumindest Teile von SwiftUI als Open Source freigeben würde.
Wenn die Community Probleme rund um macOS verbessert und damit Flexibilität und Funktionsumfang auf AppKit-Niveau erreicht, würde das Swift-basierte UI-Ökosystem deutlich stärker werden.