Post not yet marked as solved
Service Workers are difficult to debug without proper tooling. Current tools available in Safari makes it difficult to understand the lifecycle of the SW, the Cache Storage contents, to reload or remove registration and other actions. It's even more difficult when doing remote debugging to an iOS or iPadOS device where the Service Workers appears as a different context without proper explanation.
Post not yet marked as solved
There is a new feature in WebKit, App-Bound Domains - https://webkit.org/blog/10882/app-bound-domains/; the WebKit team mentioned the use case ShopApp self-hosted content and I want to see if the App Store will accept an app that has only self-hosted content.
In my testing over the first iOS/iPad14 beta, I've found that WKWebView with App-Bound Domains enabled, supports the Service Workers API on the bound domains, and that feature can be used to "install" locally the resources from a web server, and finally render web app content from there in the WKWebView.
At the same time we have some rules in the AppStore in Section 4.7 being placed - https://developer.apple.com/app-store/review/guidelines/#third-party-software and a note from last year regarding HTML5 Apps in the App Store - https://developer.apple.com/news/?id=09062019b.
Let's say we have an app that complies with all AppStore rules if it's developed using for example Swift and SwiftUI. Is the same app valid in the AppStore if the content is rendered by the WKWebView served from the Service Worker in a bound domain?
Post not yet marked as solved
Are there any plans to provide an API to manage shortcut icons in the Home Screen. Currently only Safari and Shortcuts apps can create more icons in the home screen but there are many use cases where making shortcuts with a deep link into an app is actually a good idea. It's also something expectable on a more desktop-like experience such as the one today on iPadOS
Post not yet marked as solved
For example, regarding service worker registration, IndexedDB, Web Storage and Cache Storage, what's the quota per origin and when the data might be deleted (time- or storage pressure-related) in these cases:
With Safari
With an installed standalone homescreen webapp
Can we see debugging data in DevTools regarding this?
Post not yet marked as solved
WebViews can be insecure when loading external URLs and they don't have the same level of performance and API access that in Safari; Also in Safari View Controller there is always a Safari minimal user interface that is not suitable for some specific use cases and it's also probable rejected from AppStore when used.
Can you prepare a solution similar to Trusted Web Activities on Android that can render fullscreen web content from a public URL on the Safari context for App Store apps? For security purposes it can be used only for origins previously linked with the App with, for example, the Apple App Site Association File.
Post not yet marked as solved
Several meta elements where created by Safari and WebKit in the past to offer better experiences. Some of them such as mobile-web-app-capable can be replaced today with a Web App Manifest with display: standalone, however there are others that are currently marked as deprecated in the console if used, without an alternative. Are they deprecated? What's the alternative?
One example is mobile-web-app-status-bar-style. It's values white, black and black-translucent don't have alternatives as theme_color and display: fullscreen from the Web App Manifests are ignored.
Post not yet marked as solved
With the Storage API, developers can query current origin quota for storage and request persistence of the data when some conditions are met (such as activity or added to the home screen).
Post not yet marked as solved
During 2018, Safari on iOS started to support a partial implementation of the Web App Manifest spec that is overriding the apple-mobile-web-app-capable meta tags and consequent other sub meta data. But not all the spec is implemented and there is no documentation about this. In fact, even in WebKit Feature Status, the feature is marked as In Development and not as Partially Supported.
Properties that are not supported, but should be easy to implement based on current technologies on iOS are:
display: minimal-ui and display: fullscreen
theme_color for the status bar color scheme
icons, probably with purpose="maskable"
orientation
related_applications and prefer_related_applications to replace the old apple-itunes-app meta tag
shortcuts from the App Shortcut spec
Post not yet marked as solved
The current experience of adding a shortcut to the Home Screen is the same from the first versions of iPhoneOS and there a lot of use cases for a better user experience for current websites and apps: Do not let the user add the same shortcut more than once if it's the same start_url or current URL if no manifest is defined
Promote Add to the Home Screen for webapps that are using display: standalone in the Web App Manifest and/or having a Service Worker registered, similar to other engines: Chromium and Gecko with the PWA Installability Criteria, or if not, implement the beforeinstallprompt event from the Web App Manifest spec
Post not yet marked as solved
Lot of new iOS/iPadOS versions add new bugs at the OS level for home screen web apps (standalone apps). For example, on latest versions, when you search the shortcut in the hone screen, it appears but when clicked, it opens the URL in Safari and not within the standalone experience. This is just one example of many (some of them reported for years, some other maybe not reported), but it feels that with every Safari version or iOS/iPad version no one is making a basic UI test over home screen web apps. These issues seems simple to solve if someone takes ownership of the platform and decide to test it on every new version
firt.