PWAs auf iOS 14 Beta: Subtile Änderungen

Es ist wieder an der Zeit, dass wir alle Änderungen mit der neuesten iOS-Version – iOS 14 Beta 6 – untersuchen und mit Ihnen besprechen, was sich geändert hat, was es Neues in Bezug auf den Stand der PWA-Einführung auf iOS gibt. Wie in unserem letzten PWA-Artikel für iOS 13 zu sehen war, gab es in der letzten Version viele gute Neuigkeiten, und es sah ganz danach aus, als würde Apple PWA-freundlicher werden. Aber halten sie ihr Tempo bei der PWA-Einführung aufrecht oder lassen sie PWA ganz fallen, aus Angst, App-Einnahmen zu verlieren? Um das herauszufinden, sind wir hier.

Versionshinweise

Hier sind einige der wichtigen Änderungen, von denen wir wissen , dass sie in dieser neuen Version zu Safari kommen (einige der irrelevanten Teile wurden weggelassen):

• Unterstützung für Safari-Weberweiterungen unter macOS.
• Unterstützung für HTTP/3.
• Verbesserte Erfolgsrate von Webplattformtests für WebDriver, XHR+Fetch, Service Workers, CSS und SVG.
• Vollständige Blockierung von Drittanbieter-Cookies und die Speicherzugriffs-API im Modus „Privates Surfen“ aktiviert.
• Unterstützung für Flash entfernt
• Authentifikator für die Web-Authentifizierungsplattform mit Face ID oder Touch ID hinzugefügt, je nachdem, welche Funktion vorhanden ist.

Wir können sagen, woran Sie denken – nicht so bedeutende Änderungen, nicht wahr? Nun, es stellt sich heraus, dass PWA iOS 14 mehr zu bieten hat, als man denkt.

Mehr darin graben

Dies ist der Teil, in dem wir uns eingehender mit dem Betriebssystem befassen und uns über den aktuellen Stand von PWA in iOS 14 informieren – einschließlich der Änderungen und der Verbesserung von PWA und was wir erwarten können, wenn iOS 14 weltweit stabil veröffentlicht wird.

Die Güter

Erstes Zeichen von Service Worker

In diesem Update gibt es eine neue WebKit-Funktion namens App-Bound Domains , und wenn diese Funktion aktiviert ist, kann die Service Worker-API tatsächlich auf den gebundenen Domains aktiviert werden. Obwohl es keine offizielle Dokumentation darüber gibt, was wir von Servicemitarbeitern erwarten können – und es gibt auch keine Bestätigung darüber, ob diese Funktion erhalten bleibt oder nicht – halten wir sie dennoch für eine sehr vielversprechende Nachricht für PWA-Enthusiasten da draußen.

App-gebundene Domänen

Was diese neue Funktion auf den Tisch bringt, ist eine Möglichkeit für Entwickler, die In-App-Navigation auf eine Reihe von Domänen zu beschränken und so den Endbenutzern mehr Sicherheit zu garantieren. Diese „anwendungsgebundenen“ Domänen werden in der Datei info.plist unter dem Schlüssel WKAppBoundDomains wie folgt angegeben:

 <plist-version="1.0">
<dict>
<key>WKAppBoundDomains</key>
<Array>
    <string>beispiel1.com</string>
    <string>beispiel2.org</string>
    ...
</array>
</dict>

Wenn die anwendungsgebundenen Domains aktiviert sind, können wir jetzt Servicemitarbeiter registrieren lassen:

Es gibt jedoch nur vage Erklärungen, warum Service Worker aktiviert werden, wenn wir App-Bound Domains konfiguriert haben. Und da es keine Möglichkeit gibt, Instanzen von Service Workern zu debuggen, ist das Ganze selbst für erfahrenere Entwickler noch relativ vage.

Nehmen wir zum Beispiel Cache-Speicher – das bestimmende Merkmal von Servicemitarbeitern. Es ist nirgendwo unter Storage in Safari DevTools und der Service Worker-Registrierung zu finden, um die erfahrenen Entwickler zu zitieren, die die Hauptarbeit geleistet haben: „wird nicht mit Safari, Web-Apps auf dem Startbildschirm oder anderen Apps geteilt, die WKWebView und App Bound Domains verwenden gleichen Ursprungs.“

Obwohl wir noch nicht das vollständige Bild haben, ist die Tatsache, dass Service Worker eine Sache in iOS ist, immer noch ein Grund zum Feiern, und wir können nur hoffen, dass die stabile Version uns ein vollständigeres Bild geben kann.

Neue Unterstützung für TouchID und FaceID

Touch ID und Face ID wurden kürzlich auf der Apple Worldwide Developers Conference (WWDC) vorgestellt und sind jetzt endlich über die WebAuthn-API auf Safari verfügbar. Wenn diese Funktionen integriert sind, bieten sie ein reibungsloses Erlebnis für Ihre PWA und sorgen wiederum für ein besseres Benutzererlebnis.

Möglichkeit, den Standardbrowser zu ändern

Ab iOS 14 können Nutzer nun endlich verschiedene Browser als Standard auswählen . Dies ist (irgendwie) ein netter Schritt von Apple und eine gute Nachricht für Apple-Benutzer überall, da das Ändern von Standard-Apps vorher einfach nicht möglich war. Aber halten Sie sich noch zurück, das bedeutet nicht, dass Apple-Benutzer von all den aufregenden Funktionen profitieren können, die verschiedene Webbrowser-Engines mit sich bringen werden – tatsächlich ist es alles dasselbe. Browser von Drittanbietern unterliegen immer noch der Einschränkung, sich auf Apples WebKit als zugrunde liegende Browser-Engine zu verlassen, was bedeutet, dass Ihre neuen Standard-Webbrowser zwar äußerlich glänzend und anders aussehen, im Inneren jedoch nichts wirklich geändert wird.

Geolokalisierung für das Web

Was ist also los mit dem Status der W3C-Geolocation-API in Safari? Nun, es gibt einige Änderungen, die zu einer besseren Standortverfolgung führen, aber nicht als direkte Folge von Verbesserungen, die an der W3C-Geolocation-API vorgenommen wurden. Seltsam? Wir wissen. Lassen Sie uns mehr darauf eingehen:

Wenn in der neuen Betaversion von iOS 14 der genaue Standort pro App aktiviert ist, können wir Safari unseren ungefähren Standort verfolgen lassen:

Der ungefähre Standort ist nur dem Betriebssystem bekannt, und während der Analyse dieses neuen Standortverfolgungsverhaltens in iOS hat niemand wirklich eine schlüssige Antwort darauf gefunden, wie das neue iOS 14 Beta 6 PWAs ungefähre Standorte liefert. Aber wenn man sich die bisherigen Daten ansieht, erscheint es vielversprechend. Unten ist ein Beispiel aus der Arbeit von Flirt, das Iguazu als Tracking-Standort verwendet.

Wie Sie sehen können, bestimmt und zeigt die API den Standort des Subjekts genau an. Wir vermuten, dass dieses beeindruckende Ergebnis etwas mit den kommenden Änderungen an der Core Location API zu tun hat, die in diesem WWDC2020-Video gezeigt wurden.

App-Clips – könnte eine gute Sache sein

Mit dem neuen App Clip können Entwickler einfach durch die Verwendung eines Meta-Tags ein „PWA-installationsähnliches“ Erlebnis bereitstellen:

 <meta name="apple-itunes-app" content="app-id=myAppStoreID, app-clip-bundle-id=appClipBundleID, affiliate-data=myAffiliateData, app-argument=myAppArgument“>

Sie können sich vorstellen, dass diese neue App-Clip -Funktion ähnlich wie die Instant App auf Android funktioniert, nur dass sie sich mehr auf NFC- und QR-Scanning konzentriert – und die Benutzer dazu bringt, schließlich native Apps zu installieren.

Was ist das Potenzial dieser neuen Funktion? Wir wissen es nicht – aber es könnte sich als ein Schritt in Richtung der installierbaren PWAs erweisen, die wir auf Android haben.

Die Bösen

Neue App-Galerie ignoriert PWAs

Die neue App-Bibliothek ist eine automatisierte Funktion, die Ihre App nach App-Nutzung, Kategorien usw. sortiert und organisiert. PWAs, die dem Startbildschirm hinzugefügt werden, können jetzt trotz dieses Verhaltens den Vorteil haben, dass sie auf dem Startbildschirm des Benutzers und unter der Kategorie „Webclips“ angezeigt werden ist nicht konsistent und unterliegt Veränderungen.

Tatsächlich haben frühe Tester festgestellt, dass PWAs ignoriert und überhaupt nicht in der neuen App-Bibliothek angezeigt werden – sei es in der Gruppe „ Kürzlich hinzugefügt “ oder „ Vorschläge “. Obwohl es schön sein könnte, dass PWAs die gleiche Behandlung wie native Apps erhalten, ist dies dennoch eine schockierende Nachricht für uns, da wir nicht erwartet haben, dass PWAs einfach ignoriert werden.

Keine Änderung an der Unterstützung von Web-App-Manifesten

Wie zu erwarten war, gibt es keinerlei Bewegung von Apple, um auf die Unterstützung von Web App Manifest zu drängen. Der Status für die Unterstützung von Web-App-Manifesten bleibt Teilweise unterstützt , was bedeutet, dass keine Unterstützung für icons , minimal-ui , fullscreen , orientation oder theme-color besteht.

Statusleiste

Es wäre zwar schön zu sehen, dass iOS den/die Wert(e) von theme-color aus dem Web-App-Manifest übernimmt, aber wir müssten uns in der Zwischenzeit mit weniger zufrieden geben. Ab iOS 14 Beta-Version 5 können wir keine weiße Statusleiste mehr haben und die einzigen akzeptierten Werte sind black und black-translucent .

Die Hässlichen

Kernfunktionen werden immer noch nicht unterstützt

Es ist ein großes Update, aber etwas scheint immer noch zu fehlen. Es hat wahrscheinlich hauptsächlich etwas damit zu tun, dass einige Kernfunktionen von PWA immer noch nicht unterstützt werden und es fast keine Bewegung von Apple gibt, um auf diese Funktionen zu drängen:

• Web-Push
• Hintergrundsynchronisierung
• Seitenlebenszyklus
• Servicemitarbeiter auf WebViews (d. h. keine PWAs auf Chrome, Firefox, Instagram oder Facebook, wo das Surfen im Internet nicht das Hauptziel ist)
• Universelle Links / Linkerfassung

Fazit

Wie denkst du über all diese kommenden Veränderungen? Was uns betrifft, haben wir das Gefühl, dass wir nach Überprüfung aller Änderungen mit einer enttäuschenden Note zurückbleiben. Es gibt einige Änderungen – z. B. App-Bound Domains, Geolocation – die ein Schritt in die richtige Richtung zu sein scheinen, aber Apple hat sich nicht wirklich die Mühe gemacht, in diesem Update auf mehr Kernfunktionen von PWA zu drängen. Und es macht Sinn, vermuten wir, da wir hier über Apple sprechen – von dem wir schon immer wussten, dass es so unerbittlich gegen das Internet ist.