Eine File-based App kann die in C# 9.0 (im Rahmen von .NET 5.0) eingeführten Top-Level Statements verwenden. Das wird der Regelfall sein, bei dem die Ausführung der Datei bei der ersten Zeile beginnt:

Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
Console.WriteLine($"Kompilierungsmodus: {(System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported ? "JIT" : "AOT")}");

Neben der Verwendung von Top-Level Statements ist auch der klassische Stil mit class Program und Main()-Methode in den File-based Apps möglich:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
        Console.WriteLine($"Kompilierungsmodus: {(System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported ? "JIT" : "AOT")}");
    }
}

(rme)

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)