Shopify hat in der API-Version 2026-10-rc der POS UI Extensions ein neues Event hinzugefügt: navigatesuccess. Es feuert, sobald die Zielseite ihre native Transition abgeschlossen hat. Das klingt nach einer technischen Kleinigkeit. Für Extensions mit mehreren Screens am Kassenterminal ist es der Fix für einen echten Race Condition. Der Pull Request im öffentlichen ui-extensions-Repository wurde bereits gemergt.
Bisher verließen sich Entwickler auf currententrychange. Dieses Event löst aus, sobald currentEntry wechselt. Der sichtbare Screen ist dann noch nicht fertig gerendert. Auch das Promise von navigate() wartet nicht auf den Übergang, es resolve bereits beim Commit der Navigation. Wer nach dem Event sofort Daten speichert oder ein Lade-Icon versteckt, arbeitet gegen einen noch nicht fertigen Screen.
Was genau ändert sich in der API?
navigatesuccess feuert erst, wenn die Zielseite ihre native Transition beendet hat. Der Callback erhält ein standardkonformes Event. Bei Rückwärtsnavigationen gilt eine Regel: Der Listener muss auf der Screen registriert werden, die wieder erscheint. Jede Screen läuft in einer eigenen Sandbox. Module-level-Variablen und Closures werden nicht über Navigationen geteilt, Datenübergaben erfolgen über die state-Option von navigate() oder die Storage API.
Shopify folgt damit dem Web-Standard. Die Navigation API des HTML-Standards hat navigatesuccess seit Januar 2026 Baseline-Status, dokumentiert von MDN. Aktuelle Chrome-, Edge- und Safari-Versionen unterstützen das Event. Shopify übernimmt die Semantik in die POS-Umgebung, in der Screens native Übergänge durchlaufen. Im Juli 2026 hatte Shopify bereits das Background-Extension-Target pos.app.ready.data eingeführt, das Extensions erlaubt, POS-Events wie transactioncomplete über die gesamte Session zu beobachten. navigatesuccess setzt genau in diese Richtung: präzise, zeitlich korrekte Hookpoints statt Annäherung über Timing-Werkzeuge.
Warum reicht currententrychange nicht aus?
Stellen Sie sich eine Loyalty-Extension vor, die am Kassenterminal zwischen zwei Screens wechselt: Punkte sammeln, Bestätigung, zurück zum Warenkorb. Speichert die App den Fortschritt nach currententrychange, steckt die Bestätigung noch im Übergang. Der Kunde tippt weiter, die Eingabe geht verloren. Genau dieses Fenster schließt das neue Event. Das Gegenteil passiert genauso: Ein Lade-Icon, das nach currententrychange verschwindet, blendet der Kunde eine noch halb gerendete Seite.
Betroffen sind alle Multi-Screen-Flows: B2B-Preise am Terminal, individuelle Rabatte, Abonnement-Verwaltung, Druck-Extensions. Jede App, die zwischen Screens hin- und herwechselt und dabei Zustand speichert, läuft bisher gegen die Uhr der nativen Transition.
currententrychange feuert beim Wechsel des Eintrags. navigatesuccess feuert, wenn der Screen da ist.
Was Entwickler jetzt tun sollten
Extensions, die aktuell currententrychange nutzen, sollten prüfen, ob der Callback von der Sichtbarkeit der Zielseite abhängt. Ist das der Fall, Umstellung auf navigatesuccess. Der API-Wechsel erfolgt über die shopify.extension.toml mit der API-Version 2026-10-rc. Testen sollte das Update auf einem Development-Store mit aktueller POS-App-Version, idealerweise mit derselben Hardware wie im Ladenbetrieb, weil native Transitions auf schwächerem Gerät länger dauern.
Händler mit eigenen POS-Apps sollten den Release-Plan ihres Entwicklers abklären, bevor die nächste POS-App-Version ausgerollt wird. Der Aufwand ist gering, das Risiko eines Datenverlusts an der Kasse ist es nicht.