You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Safari on iOS is slowly catching up with the web manifest spec. iOS 15.4 can now grab an icon form the manifest, instead of requiring the apple-touch-icon, and it will happily install the app even though apple-mobile-web-app-capable isn't defined.
Rant
Safari uses icons with purpose: any instead of using maskable like any other browser would do. This creates a lot of issues, especially because any icons usually have transparency, which might not play well with an app icon. Too bad you're probably thinking, Safari did what Safari does and didn't implement the spec properly. Okay, but then you can simply define an apple-touch-icon again, and that will override the icons from the manifest, right? At least that is what Safari says. Wrong! My testing showed that Safari 15.6 completely ignores the apple-touch-icon when there is a manifest available. So they made sure to break both implementations. I can also guarantee you that this behavior will change randomly in the coming browser versions.
All of this is such a classic Safari move. Do the right thing, but don't do it properly, and then also make sure to break the things that did work properly before, and then make sure to not document any of it.
At this point, you don't need to define anything that is Apple-specific, for an app to work on Apple devices. It is however still a slightly better experience if you do, most notably because splash screens don't work unless you define them specifically for Apple.
Therefore I propose to put all Apple-specific content behind a flag. Maybe even multiple flags:
--apple-touch Generate app icons specifically for Apple devices
--apple-splash Generate splash screens for Apple devices
--apple-meta Add legacy Apple meta tags to output (apple-mobile-web-app-capable)
I would personally like to be able to turn all of it off.
The text was updated successfully, but these errors were encountered:
Hey @atjn, thanks for creating this issue. iOS specific tags and images should be configurable indeed.
In fact, I'm busy with designing the next major version of the library, which will allow custom profiles where users will have full control on image and tag generation, and choosing target platforms.
Safari on iOS is slowly catching up with the web manifest spec. iOS 15.4 can now grab an icon form the manifest, instead of requiring the
apple-touch-icon
, and it will happily install the app even thoughapple-mobile-web-app-capable
isn't defined.Rant
Safari uses icons with
purpose: any
instead of usingmaskable
like any other browser would do. This creates a lot of issues, especially becauseany
icons usually have transparency, which might not play well with an app icon. Too bad you're probably thinking, Safari did what Safari does and didn't implement the spec properly. Okay, but then you can simply define anapple-touch-icon
again, and that will override the icons from the manifest, right? At least that is what Safari says. Wrong! My testing showed that Safari 15.6 completely ignores theapple-touch-icon
when there is a manifest available. So they made sure to break both implementations. I can also guarantee you that this behavior will change randomly in the coming browser versions.Another classic is the
apple-mobile-web-app-capable
meta tag. Safari says you need to define it in order to launch a PWA in full screen mode, but my testing shows that it makes no difference to the app launch experience.All of this is such a classic Safari move. Do the right thing, but don't do it properly, and then also make sure to break the things that did work properly before, and then make sure to not document any of it.
At this point, you don't need to define anything that is Apple-specific, for an app to work on Apple devices. It is however still a slightly better experience if you do, most notably because splash screens don't work unless you define them specifically for Apple.
Therefore I propose to put all Apple-specific content behind a flag. Maybe even multiple flags:
I would personally like to be able to turn all of it off.
The text was updated successfully, but these errors were encountered: