OpenAI ist der erste Anbieter der großen KI-Chatbots, der den Sprung in Apples iPhone-Fahrzeugintegration CarPlay schafft. Die in der Nacht zum Mittwoch erschienene neue Version 1.2026.078 für iOS soll das Feature nachrüsten, berichten Nutzer sowie Macrumors. Die Umsetzung ist relativ einfach gehalten, was allerdings mit Apples Vorgaben zu tun hat, die möglichst wenig Ablenkungspotenzial für Auto-Apps sicherstellen sollen.

Minimalistische App

Apple hatte im Rahmen von iOS 26.4 erstmals erlaubt, KI-Anwendungen als weitere CarPlay-Kategorie festzulegen. Apple ist sehr vorsichtig damit, welche Apps für die iPhone-Fahrzeugintegration freigegeben werden. So sind etwa weder Browser noch Video-Apps offiziell erlaubt. In Sachen Video wird Apple allerdings selbst nachlegen, plant Apple TV für geparkte Fahrzeuge, wobei dies nur in bestimmten Modellen via „AirPlay in the Car“ möglich sein wird.

ChatGPT landet automatisch in CarPlay, sobald die iOS-App aktualisiert wurde – das Icon sollte auf der letzten Seite zu sehen sein. Die App an sich ist rein als Sprachbedienung ausgelegt: Startet man sie, wird der Voice Chat sofort aktiv. Dann kann man beliebige Fragen stellen und bekommt direkt im Auto die passenden Antworten. Auf dem Bildschirm selbst passiert allerdings nichts, weder Texte noch Bilder sind erlaubt. Auch das hat wiederum mit Apples Vorgaben zu tun, die besagen, dass auch Chatbots nicht mit Content für die Augen antworten dürfen, egal, wie dieser dargestellt wird.

Die Konkurrenten sollten schnell folgen

Immerhin: Die ChatGPT-App kann auf bestehende Chat-Verläufe zugreifen sowie über Projekte. Dazu gibt es eine Übersicht. Die Chats sollten (samt Text) später auch direkt in der App auf dem iPhone (sowie auf Mac und im Web) zu finden sein. Die Sprachsteuerung nutzt Apples übliches Template. Eine direkte Aktivierung von ChatGPT über den Siri-Knopf im Auto ist nicht vorgesehen.

Es ist davon auszugehen, dass nach OpenAI auch die Konkurrenten Anthropic (Claude) und Google (Gemini) sehr bald mit ihren eigenen Apps nachziehen dürften. Die Umsetzung ist, wie ChatGPT vormacht, nicht schwer. Nutzer müssen sich aber des erwähnt eingeschränkten Nutzungsumfangs bewusst sein, der von Apple vorgegeben ist. Auch bei Textnachrichten und SMS zeigt CarPlay seit Jahren keinen Text an, lässt sie Siri vorlesen, was jeweils eine Weile dauern kann.

(bsc)

Der Übergang von klassischen Dynpro- und Web-Dynpro-Oberflächen zu SAP Fiori Elements stellt viele ABAP-Entwickler vor grundlegende Herausforderungen. Statt imperativer Programmierung in der SE80 bestimmen nun CDS-Annotationen und das ABAP RESTful Application Programming Model (RAP) das Erscheinungsbild der Oberflächen. Marian Zeis, unabhängiger SAP-Entwickler und aktiv in der AG UI-Technologien der DSAG engagiert, ordnet ein, was der Wandel für die Praxis bedeutet.

heise developer: Was ist die größte Herausforderung bei der UI-Entwicklung mit SAP Fiori Elements, wenn man bisher mit Web Dynpro ABAP oder Dynpro gearbeitet hat?

Zeis: Wenn man bisher primär mit Dynpro, Web Dynpro ABAP oder klassischen ALVs gearbeitet hat, ist die größte Herausforderung aus meiner Sicht, dass man plötzlich nicht mehr nur in der klassischen ABAP-Welt unterwegs ist.

Der erste Bruch ist schon beim Werkzeug: Man arbeitet nicht mehr hauptsächlich in der SE80, sondern in Eclipse mit den ABAP Development Tools. Dazu kommt mit RAP und Fiori Elements ein deutlich stärkerer service- und annotationsgetriebener Ansatz.

Die eigentliche Herausforderung ist für mich aber, dass Frontend-Themen näher an den ABAP-Entwickler heranrücken. Im Standard kann Fiori Elements zwar viel über Annotationen und Metadaten abbilden, aber sobald man erweitern will oder spezielleres Verhalten benötigt, kommt man schnell auch mit UI5 und teilweise JavaScript in Berührung. Genau dieser Wechsel im Denken ist für viele die größte Umstellung.

heise developer: Inwieweit muss oder sollte man die Benutzeroberflächen schon bei der Backend-Entwicklung mitdenken? Muss man mit ABAP CDS eine ganz neue Sprache lernen, um Annotationen verwenden zu können?

Zeis: Die Bedienoberfläche sollte man aus meiner Sicht sehr früh mitdenken, möglichst schon beim Datenmodell und bei den Services. Das war früher im Kern auch schon so, aber im RAP-Umfeld ist es noch wichtiger, weil sich die spätere Oberfläche stark aus dem Backend-Modell ableitet.

Gerade bei Fiori Elements steckt viel UI-Logik schon in den CDS-Views und Annotationen. Wenn das Modell fachlich unsauber ist oder die Daten nicht sinnvoll geschnitten sind, sieht man das später direkt in der Anwendung. Gute Oberflächen entstehen deshalb hier zu einem großen Teil schon im Backend.

Zu ABAP CDS würde ich sagen: Ja, man muss etwas Neues lernen, aber nicht komplett bei null anfangen. Es ist eine andere Denkweise, weil es stärker um Modellierung, Semantik und Annotationen geht. Und genau daran führt künftig kaum ein Weg vorbei. Gerade wenn SAP in Richtung generativer UI denkt, werden saubere Fachobjekte und ein gutes Backend-Modell eher noch wichtiger.

heise developer: Werden ABAP- und UI-Entwicklung überhaupt noch benötigt, wenn Anwenderinnen und Anwender bald nur noch über Joule mit dem SAP-System interagieren?

Zeis: ABAP wird uns aus meiner Sicht auf jeden Fall noch lange begleiten. Dass SAP ABAP weiter als modern positioniert und insbesondere auch im Cloud-Umfeld ausbaut, zeigt deutlich, dass das kein Auslaufmodell ist.

Bei der UI-Entwicklung ist die Frage spannender. Mit Joule und generativer UI kommt natürlich eine neue Art der Interaktion dazu, also stärker kontextbezogene und dynamische Oberflächen. Das wird sicher verändern, wie man SAP-Anwendungen künftig denkt.

Trotzdem glaube ich nicht, dass ABAP- und UI-Entwicklung dadurch überflüssig werden. Es wird weiterhin viele Prozesse geben, bei denen strukturierte Oberflächen, Listen, Formulare oder geführte Abläufe sinnvoller sind als eine reine Chat-Interaktion. Ich glaube deshalb eher an eine Koexistenz: Joule wird wichtiger, aber klassische Anwendungen verschwinden nicht einfach.

heise developer: Herr Zeis, vielen Dank für das Interview!

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(map)

Ein Internetbenutzer, insbesondere wenn er über eine Suchmaschine nach Informationen fahndet, hat in etwa die Aufmerksamkeitsspanne eines Eichhörnchens auf bewusstseinserweiternden Drogen. Ein kleiner Reiz und er springt zum nächsten Ast. Das ist herausfordernd für Seitenbetreiber: Lädt eine Website zu lange, sind Nutzer schneller weg, bevor der Webserver alle Inhalte ausgeliefert hat.

Schnelle Absprünge wiederum bekommt auch Google mit und die Seite sinkt in der Gunst der Suchmaschine. Gerade WordPress ist von Haus aus nicht für überragende Geschwindigkeit bekannt. Ansätze, um WordPress-Seiten zu beschleunigen, gibt es mehrere. Meistens greifen sie per Plug-in tief in die WordPress-Instanz ein.

Ein anderer Weg: Man stellt WordPress den Cache-Server Vinyl zur Seite, der fertig gerenderte HTML-Seiten im RAM vorhält, und degradiert WordPress zum Zulieferer für den Cache. Wir versprechen nicht zu viel: Durch den Umbau, den wir in diesem Artikel beschreiben, werden Sie Ihre WordPress-Seite nicht wiedererkennen. Ganz nebenbei erfahren Sie, wie Sie Ihre Website mit dem Werkzeug k6 systematisch unter Last testen.

Das war die Leseprobe unseres heise-Plus-Artikels „Rasante WordPress-Seiten mit Vinyl Cache“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.