Gegen Vibe-Coding fürs iPhone hat Apple erklärtermaßen keine Einwände. Wer aber auf diese Weise Web-Apps am App Store vorbei entwickeln lässt, geht dem iPhone-Hersteller offenbar zu weit: Dies haben jetzt zwei Anbieter von Vibe-Coding-Apps zu spüren bekommen, deren geplante Updates von Apples App-Store-Kontrolle abgelehnt wurden. Das Unternehmen selbst verweist auf Verstöße gegen die Regeln und zeigt einen möglichen Lösungsweg auf.

Erst vor kurzem hat Apple selbst einen großen Vorstoß in Richtung Vibe-Coding unternommen. Mit der Einführung von agentischer KI in Apples Entwicklungsumgebung Xcode ist es seit Version 26.3 so einfach wie noch nie, ohne Kenntnis von Programmiersprachen ganze Apps entwickeln zu lassen. Dennoch nimmt die Entwicklung dort ihren klassischen Weg, wie Apple ihn seit Anbeginn des App Stores einfordert: Die Entwicklung findet am Mac statt und die fertige App kann der Entwickler sich wahlweise lokal zum Testen installieren, per TestFlight an größere Testerkreise verteilen oder dem App Review zur Prüfung vorlegen, um sie im App Store zu veröffentlichen.

Maßgeschneiderte Apps im Browser

Die beiden Vibe-Coding-Apps Replit und Vibecode gehen einen anderen Weg. Sie dienen weniger dazu, Apps zu erstellen, die auch andere nutzen. Stattdessen werben die Anbieter damit, dass Nutzer sich ohne Programmierkenntnisse maßgeschneiderte Web-Apps erstellen lassen können. Gibt es also keine passende App im App Store, die den Wünschen gerecht wird, können sich Nutzer per Vibe-Coding einfach eine eigene erstellen lassen. Allerdings besteht dadurch je nach Funktionsumfang auch die Möglichkeit, Alternativen zu Kauf- oder Abo-Apps erschaffen zu lassen. Und dann gehen nicht nur deren Entwickler leer aus, sondern auch Apple als Ladenbetreiber, der pro Verkauf eine Provision bekommt.

Aus Apples Sicht sei der Grund für das Blockieren der Updates allerdings ein ganz anderer, berichtet das Apple-Blog 9to5Mac. So gehe es dem Hüter des App Stores in Wirklichkeit darum, dass es Apps untersagt sei, Code nachzuladen oder auszuführen, der ihre Funktionalität verändere. Dies ist eigentlich eine Vorschrift, die Fake-Apps verhindern soll, die etwa im Gewand einer harmlosen App im App Store erscheinen, dann jedoch in Wirklichkeit Inhalte nachladen, die gegen die Regeln verstoßen. Apple wendet die entsprechenden Paragrafen der Nutzungsbedingungen des Entwicklerprogramms nunmehr auch auf Vibe-Coding-Apps an. Konkret beruft sich Apple dabei auf App Store Guideline 2.5.2 sowie Abschnitt 3.3.1(B) des Developer Program License. Dies berichtete zuvor bereits The Information.

Unversöhnlich gibt sich Apple allerdings nicht. In drei Telefongesprächen in zwei Monaten habe man den betroffenen Entwicklern mögliche Lösungswege aufgezeigt. Einer soll sein, dass App-Vorschauen im Browser angezeigt werden, anstatt sie innerhalb der App zu generieren. Diesen Umstand dürften die Anbieter der Vibe-Coding-Apps aber eher als unnötige Mühsal für ihre Nutzer ansehen, weil diese dann ständig zwischen zwei verschiedenen Apps – Browser und Vibe-Coding-App – wechseln müssten.

(mki)

Das Unternehmen Wasmer, das hinter der gleichnamigen WebAssembly-Runtime steht, hat Edge.js veröffentlicht. Die quelloffene JavaScript-Runtime ist darauf spezialisiert, Node.js-Workloads auf sichere Weise in WebAssembly-Sandboxen auszuführen. Insbesondere für die Anwendungsfälle KI und Edge Computing soll sich Edge.js eignen.

Nicht zu verwechseln ist die neue JavaScript-Runtime Edge.js mit dem älteren .NET-Projekt Edge.js.

Edge.js für sichere Node.js-Anwendungen

Wie das Wasmer-Team die Beweggründe hinter der neuen Runtime erklärt, hat Node.js zwei Schwierigkeiten: Es ist an V8 als einzige JavaScript-Engine gebunden und kann Workloads nicht sicher ohne Containerisierung oder Hardwarevirtualisierung ausführen. Das haben auch andere Anbieter wie Deno oder Bun erkannt und eigene JavaScript-Runtimes entwickelt, doch Wasmer besitzt mit Edge.js nach eigenen Angaben die erste vollständig in einer Sandbox laufende Variante ohne Docker-Container.

Edge.js verwendet die Node-API (ehemals N-API) als Abstraktions-Layer, eine API für das Erstellen nativer Add-ons, die als Teil von Node.js gepflegt wird und die V8-Engine wegabstrahiert. Dadurch lassen sich in Edge.js auch JavaScriptCore und QuickJS als JavaScript-Engines einsetzen. Für das System-Call-Sandboxing kommt WASIX zum Einsatz, ein Superset des modularen System-Interfaces für WebAssembly namens WASI (WebAssembly System Interface).

Laut Wasmer setzt Edge.js auf die Kompatibilität mit Node.js 24 und kann alles ausführen, was auch Node.js ausführen kann – darunter alle entsprechenden Frameworks wie Next.js oder Astro. Derzeit ist Edge.js 5 fünf bis 20 Prozent langsamer als Node.js bei nativer Ausführung, und 30 Prozent langsamer bei vollem Sandboxing mit Wasmer. Auch die Start-up-Zeiten von Anwendungen sind langsamer als bei Node.js. An der Geschwindigkeit plant das Entwicklungsteam auf dem Weg zu Edge.js 1.0 zu arbeiten. Ein konkretes Ziel lautet, dass Edge.js für die meisten Workloads schneller sein soll als Bun oder Deno.

Per KI-Coding zu Edge.js

Das Wasmer-Team gibt an, für die Implementierung von Edge.js auf künstliche Intelligenz, hauptsächlich auf OpenAI GPT-5.4, zurückgegriffen zu haben. Ein kleineres Start-up wie Wasmer hätte ansonsten mindestens ein oder zwei Jahre für dieses Projekt gebraucht, statt lediglich weniger Wochen. Dank des KI-Coding-Agenten OpenAI Codex konnten sich demnach auch Developer im Team ohne Expertise in C++ oder Node.js beim Bugfixing einbringen.

Weitere Informationen zum initialen Edge.js-Release bietet der Wasmer-Blog.

(mai)

Das Update der Entwicklungsumgebung IntelliJ IDEA 2025.3.4 von JetBrains unterstützt nun das am 17. März veröffentlichte Java 26 vollständig. Außerdem spendiert die Firma dem Agenten-Framework Koog eine Java-API.

Entwicklerinnen und Entwickler können nach dem Update mit allen zehn der großen Neuerungen von Java 26 arbeiten, mit den fünf stabilen, wie HTTP/3, und den fünf Previews, wie Pattern Matching mit Primitives.

Um Preview-Funktionen freizuschalten, stellt man die Sprachstufe in der IDE auf „Language level to 26 (Preview) – Primitive types in patterns (Fourth preview)“. Dann blendet IntelliJ alle Hilfen auch für diese Sprachstufe an, einschließlich Inspections and Quick-fixes ein. Bei den Preview-Funktionen zeigt das Tool zusätzlich einen Warnhinweis, da Anwender sie möglicherweise nicht in Code für die Produktion einsetzen möchten.

JetBrains unterstützt auch noch unreife Incubator-Funktionen von Java 26 wie die Verctor API. Zur Nutzung ist ein spezieller Schalter erforderlich: --add-modules jdk.incubator.vector.

Darüber hinaus gibt es kleinere Bugfixes und Verbesserungen in der IDE. Beispielsweise beseitigt das Update einen Fehler, der falsche HTTP-Requests auslöst; und der Tab für Dependencies in der Funktion Analyze Cyclic Dependencies öffnet sich nun richtig. Im DB-Explorer lassen sich jetzt Knoten von Abfragedateien verstecken und beim Language Server für Astro gibt es Verbesserungen im automatischen Vervollständigen.

Für den Einsatz von Java 26 ist das entsprechende JDK erforderlich. Das lässt sich direkt in IntelliJ oder mithilfe von Tools wie SDKMAN laden. Ebenfalls zum Download steht ein neuer Build von Project Valhalla. Das Update von IntelliJ lässt sich innerhalb der IDE mit der Toolbox installieren, über Ubuntu-Snaps oder von der Webseite laden.

Koog und Kotlin

Neu von JetBrains ist zudem eine Java-API für das Agenten-Framework Koog, die Zugriff auf alle Funktionen des ursprünglich rein für Kotlin entwickelten Frameworks bietet: Planung und Organisation von agentischen Workflows, alle größeren Modelle, Spring Boot oder Observability.

Ebenfalls ein Update gibt es für die Programmiersprache Kotlin 2.3.30, das ein neues Modell für die Nutzung der C-Bibliotheken bietet und kompatibel zu Gradle 9.3 ist.

(who)