I’d like to use different webapp icons on iOS and everything else. The way to do this is to send different sets of meta tags for each browser based on user agent. This isn’t optimal, but I don’t know any other way to do it.
I’d like to do the detection work server side. Is that possible?
I wonder if it would work doing it client side…
I assume that if you didn’t expose your meteor app directly to the internet, you are probably using nginx or haproxy if you’re self hosting your site.
In nginx, for example, you can look for the user agent and then perform a redirect with a 301 response code. Hope this helps!
Doing it on client side would certainly work. However, it will be subjected to code tampering by the users, and you will be loading unnecessary infos to the clients. I would only do this if it’s some business logic related issues within your site.
Why don’t you give the new ssr feature a try
You can use it to parse the request object for the user agent and insert meta tags based on that information.
I actually figured a way to do it by simply moving some meta tags around. Here’s what I eneded up with:
<link rel="icon" type="image/png" sizes="512x512" href="/online/icons/512.png">
<link rel="icon" type="image/png" sizes="192x192" href="/online/icons/192.png">
<link rel="icon" type="image/png" sizes="144x144" href="/online/icons/144.png">
<link rel="icon" type="image/png" sizes="96x96" href="/online/icons/96.png">
<link rel="icon" type="image/png" sizes="72x72" href="/online/icons/72.png">
<link rel="icon" type="image/png" sizes="48x48" href="/online/icons/48.png">
<link rel="icon" type="image/png" sizes="36x36" href="/online/icons/36.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="1024x1024" href="/online/icons/ios/iTunesArtwork@2x.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="512x512" href="/online/icons/ios/iTunesArtwork.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="180x180" href="/online/icons/ios/icon-60@3x.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="152x152" href="/online/icons/ios/icon-76@2x.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="144x144" href="/online/icons/ios/icon-72@2x.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="120x120" href="/online/icons/ios/icon-60@2x.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="76x76" href="/online/icons/ios/icon-76.png">
<link rel="apple-touch-icon-precomposed" type="image/png" sizes="72x72" href="/online/icons/ios/icon-72.png">
Putting the apple icons under the non-prefixed icons seems to mostly work. There are a few places in Android’s UI where it does use the apple icons, but it does use the correct Android icons when creating a homescreen shortcut. I’m not sure how robust or well supported this is.
I also have the same set of Android icons in my webapp-manifest.json file, which iOS doesn’t support anyway.
This is the app btw, now completely PWA-ified: Q Dice
Kevin N.
The icons are picked on the client side through scripts?
Different platforms use those link tags and some internal algorithm to decide which of those icons to present to the user. These aren’t specific enough though. Android and iOS need different icons (and maybe even different Android versions - I’m not sure what happens to my icons on a Pixel phone for example).
The non-applicable icons are not loaded, that’s efficient. Perhaps this can be a switch statement with a catch all for all the devices that you are not expecting?
One more thought, can this be addressed by saving the images in svg instead of png with the highest dimensions?
It seems from the docs I’ve read that these must all be PNG files.
Hmm, take a look at http://realfavicongenerator.net/ which works quite well, claims to be perfectly cross-platformi offers customization options and offers an api which you can integrate into your build process and automate creation/update of your icons and whatnot.
Furthermore, they keep themselves updated as standards evolve, devices/browsers emerge, etc.
Oh right! I totally forgot about this - thanks!