--- title: "Die Branche kehrt zu Native zurück. Ihre App musste das nie" description: "Native oder Cross-Platform 2026: Warum die Branche zu Swift und Kotlin zurückkehrt, warum GoodBarber-Apps immer nativ waren und was Sie vorher prüfen." canonical_url: "https://de.goodbarber.com/blog/die-branche-kehrt-zu-native-zurück-ihre-app-musste-das-nie-a1446/" lang: de date: 2026-09-11 last_updated: 2026-09-15 --- # Die Branche kehrt zu Native zurück. Ihre App musste das nie [Zurück](/blog/mach-es-r13/) # Die Branche kehrt zu Native zurück. Ihre App musste das nie Written by [Mathieu Poli](https://de.goodbarber.com/blog/author/mathieu-poli/) on Freitag 11 September 2026· Letzte Aktualisierung: Dienstag 15 September 2026 ## Diesen Monat hat Shopify angekündigt, alle seine mobilen Apps zurück zu Swift und Kotlin zu bringen, sechs Jahre nach der Umstellung auf React Native. Die Branche nennt es eine Rückkehr zu Native. GoodBarber-Apps sind nie weg gewesen: Wir haben 2011 auf Native gesetzt, als der größte Teil der Branche das Gegenteil tat. Hier lesen Sie, was diese Wette für Ihre App bedeutet, was sie kostet, wovor sie Sie schützt und was Sie prüfen sollten, bevor Sie einen App Builder wählen. ## Native oder Cross-Platform: Was die Begriffe wirklich bedeuten ![](https://cmsphoto.ww-cdn.com/superstatic/129568/art/grande/97995343-68228861.jpg?v=1789130565.408716) Eine mit GoodBarber erstellte iOS-App wird in Swift kompiliert. Eine Android-App wird in Kotlin kompiliert. Das sind die Sprachen, die Apple und Google für ihre eigenen Apps verwenden, und das Ergebnis ist eine echte [native App](https://de.goodbarber.com/glossary/native-app/): eine Binärdatei, die Sie im App Store und bei Google Play einreichen, genau wie es eine Entwicklungsagentur tun würde. Eine dritte Engine erzeugt eine Progressive Web App für den Browser und den Desktop. Alle drei werden aus demselben Back-Office generiert: Sie gestalten Ihre App einmal, und jede Engine rendert sie korrekt für ihre Plattform. Die Details dieser Technologie finden Sie auf unserer Seite zur [nativen Technologie](https://de.goodbarber.com/native/technology/). Cross-Platform-Frameworks wie React Native oder Flutter gehen einen anderen Weg: eine gemeinsame Codebasis, die auf beiden Plattformen über eine Zwischenschicht dargestellt wird. Das ist ein legitimer Ansatz, und jahrelang war er der pragmatischste für ein Unternehmen, das eine einzige App baut. Es ist auch der Weg, den wir bewusst nicht gegangen sind. ## Warum wir 2011 auf Native gesetzt haben Als wir unsere ersten Engines gebaut haben, lautete die Frage nicht, welche Technologie in jenem Jahr die beste App hervorbrachte. Sie lautete, welche Schicht in zehn Jahren noch da sein würde. Die Plattformen würden es sein: Apple und Google würden ihre Betriebssysteme, ihre Werkzeuge und ihre SDKs nicht aufgeben. Alles dazwischen, die Frameworks, die den Entwicklern die Plattformen ersparen wollten, musste sich sein Jahrzehnt erst noch verdienen. Also haben wir direkt auf der Schicht gebaut, die mit Sicherheit bleiben würde, und alles, was darauf gestapelt wurde, als vorübergehend behandelt. Die folgenden Jahre haben diese Lesart auf die Probe gestellt. Alle paar Jahre wurde ein neues Framework als die Zukunft des Mobile vorgestellt: PhoneGap, React Native, Xamarin, Flutter. Wir haben die ernsthaftesten geprüft und jedes Mal verzichtet, aus derselben Frage nach der Lebensdauer. Dann kamen die Antworten: [Adobe hat PhoneGap 2020 eingestellt](https://cordova.apache.org/announcements/2020/08/14/goodbye-phonegap.html), [Microsoft hat den Support für Xamarin 2024 beendet](https://dotnet.microsoft.com/en-us/platform/support/policy/xamarin). Die Zwischenschicht wechselte immer wieder den Namen. iOS und Android behielten ihren. Die Wette hat ihren Preis. Drei Engines bedeuten drei Teams, drei Fachkompetenzen und drei Implementierungen, die im Gleichschritt bleiben müssen, und genau deshalb konnten sich die meisten Unternehmen, die eine einzige App bauen, das nicht leisten. Eine Plattform kann es: Die Engines werden einmal gebaut und über jede App abgeschrieben, die sie erzeugt. Fünfzehn Jahre native App-Erstellung beruhen auf dieser Rechnung, und deshalb erreichen diese Kosten Sie nie. Engines, Hosting, Push-Infrastruktur und die Veröffentlichung in den Stores sind im Abonnement enthalten. ## Was das für Ihre App bedeutet Ihre App läuft auf dem Fundament, das Apple und Google selbst pflegen, nicht auf einer Schicht, deren Zukunft von der Roadmap eines dritten Unternehmens abhängt. Wird ein Framework eingestellt, passiert Ihrer App nichts. Entwickelt sich iOS oder Android weiter, übernehmen unsere Engines die Änderung einmal, zentral, und Ihre App wird in der neuen Version neu generiert, ohne dass Sie etwas anfassen. Eine vor Jahren konfigurierte App ist heute eine aktuelle App. Es zeigt sich auch in dem, was Ihre Nutzer spüren, unterhalb dessen, was die meisten benennen können: ein Scrollen, das exakt der Physik des Systems folgt, Übergänge, die zum Betriebssystem gehören, haptisches Feedback, eine schwebende Tab-Leiste, ein Media-Player, der weiterläuft, wenn der Bildschirm dunkel wird, lokale Benachrichtigungen, die von der App selbst ausgelöst werden, wenn jemand einen Geofence betritt, ganz ohne Server. Nichts davon wird konfiguriert. Es kommt mit der Art, wie die App gebaut ist, und Ihre Nutzer fassen es in einem Wort zusammen: „professionell“. ## Warum es 2026 mehr zählt In diesem Jahr hat sich etwas daran geändert, wie Softwareteams über Mobile sprechen. Im September 2026 hat [Shopify angekündigt](https://shopify.engineering/back-to-native), alle seine mobilen Apps zurück zu Swift und Kotlin zu bringen, sechs Jahre nach der Umstellung auf React Native, und der Grund ist nicht, dass Native plötzlich besser geworden wäre. Der Grund ist, dass KI den wichtigsten Anlass beseitigt hat, es zu vermeiden: die Kosten, dieselbe App zweimal zu bauen. Wenn Modelle und Agenten den Großteil der Übersetzung und der Tests zwischen den Plattformen übernehmen, verliert die gemeinsame Codebasis ihr wirtschaftliches Argument, und die eigene Sprache der Plattform wird wieder zum Standard. Wir mussten diese Reise nie antreten, und die Wette hat sich auf eine Weise ausgezahlt, die wir nicht geplant hatten: Wir hatten erwartet, dass die Zeit es beweisen würde, und der Beweis kam stattdessen von der KI. Unser Head of Frontend Engineering, Mathieu Poli, erzählt diese Geschichte von innen, einschließlich der Frameworks, die wir unterwegs geprüft haben: [Everyone is going back to native. We never left](https://dev.to/goodbarber/everyone-is-going-back-to-native-we-never-left-and-the-bet-paid-in-a-way-we-didnt-expect-58lp). ## Was Sie prüfen sollten, wenn Sie einen nativen App Builder wählen Stellen Sie eine einzige Frage: Was erzeugt die Plattform tatsächlich? Eine kompilierte Swift-Binärdatei und eine kompilierte Kotlin-Binärdatei, in beiden Stores unter Ihrem Namen eingereicht, sind etwas anderes als eine für Mobilgeräte verpackte Web-App. Lassen Sie sich eine App auf einem echten Gerät zeigen und achten Sie auf das Scrollen, die Übergänge und die Tab-Leiste. Wenn die Antwort nativ ist, spüren Sie es, bevor es Ihnen jemand erklärt. Sie können es selbst testen: [Starten Sie eine kostenlose Testphase](https://de.goodbarber.com/create/templates/), bauen Sie eine erste Version Ihrer App und installieren Sie sie auf Ihrem Smartphone. ## FAQ **Sind GoodBarber-Apps wirklich nativ?** Ja. Die iOS-App wird in Swift und die Android-App in Kotlin kompiliert, und beide werden als echte Binärdateien unter Ihrem Namen im App Store und bei Google Play eingereicht. Die dritte Engine, die Progressive Web App, läuft bewusst im Browser. **Native App oder PWA, was soll ich wählen?** Beide entstehen aus demselben GoodBarber-Projekt, es ist also selten ein Entweder-oder; [wie Sie zwischen Website, App und PWA entscheiden](https://de.goodbarber.com/blog/website-oder-app-ihre-pwa-ist-ganz-nebenbei-beides-a1418/), hat einen eigenen Artikel. Die nativen Apps sind die, die Ihre Nutzer in den Stores finden und die Ihnen das Scrollen, die Übergänge und die Gerätefunktionen der jeweiligen Plattform geben; die PWA ergänzt den Browser und den Desktop. **Kostet eine native App mehr?** Nicht mit einem App Builder. Die Engines werden einmal gebaut und über alle Apps der Plattform abgeschrieben, sodass ihre Kosten, zusammen mit Hosting, Push-Infrastruktur und Store-Veröffentlichung, im Abonnement enthalten sind. Der Preis des doppelten Bauens gilt nur für die Individualentwicklung, und er ist der Grund, warum die Branche nach Alternativen gesucht hat. ![Mathieu Poli](https://blog.goodbarber.com/_public/profile/65/6553d00ecdbe15f8aac2da7dddcff47648fdd791-default.jpg) Über den Autor[Mathieu Poli](https://de.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering Ich bin Head of Frontend Engineering bei GoodBarber. Ich leite die Teams, die die Rendering-Engines im Herzen unserer No-Code-Plattform entwickeln: Sie sind es, die die Projekte unserer Nutzer zum Leben erwecken und in native Apps verwandeln – flüssig und sorgfältig gestaltet. Alles, was man auf dem Bildschirm sieht und bedient, geht durch ihre Hände. Als Pionier des mobilen No-Code, begeistert von Softwarearchitektur und Produktdesign, unterrichte ich außerdem an Universitäten und privaten Hochschulen. Hier schreibe ich über Frontend-Engineering, Produktdesign und KI – und über all das, was passiert, wenn diese drei Welten aufeinandertreffen. [Mehr erfahren](https://de.goodbarber.com/blog/author/mathieu-poli/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/hellomathieup)[![X](https://portal.ww-cdn.com/portal_static/svg/base2021/x.820492c586dd.svg)](https://x.com/hellomathieup/)