Currently, RFG creates something like 10 Apple Touch icons:
apple-touch-icon-57x57.png to apple-touch-icon-180x180.png (9 icons).
These pictures are built and declared after Apple specs.
The browser finds the right icon for its screen:
We can be confident the icon won't be blurred or anything when scaled down. This is especially important when the original picture as a particular style (eg. pixel art -> use something like Nearest Neighbor).
It's quicker than scaling down. Well, this shouldn't make much difference...
When files are in root: various browsers find what they are looking for at first sight (eg. /apple-touch-icon-74x74.png):
Quicker, the user experience maybe be (slightly!) improved.
Less annoying 404 errors in the logs.
There are a lot of files. When in root, they pollute the root directly, which is an issue for the web developer who always has these annoying files in plain sight. This issue can be mitigated (web server configuration to map a touch-icon directory to the root directory, use Gulp/Grunt to move these files at deployment time...).
There are a lot of HTML declarations:
This is 700+ bytes at the top of each page. Definitely not good, especially for this nice-to-have.
This is an issue for the web developer: these declarations are ugly. They hurt my feelings.
Naive solution: two policies, the "light package" and the "full package". Sounds good. However, this is not that simple. For example, if files are in the root directory, I would like:
Only one declaration (I want light HTML).
All icons: apple-touch-icon.png, apple-touch-icon-144x144.png, apple-touch-icon-precomposed-120x120.png... after all, these files don't annoy me (I use Gulp to put them in root at the last minute), they will prevent as many 404 as possible...
This leads to two settings:
The amount of icons:
Only one (apple-touch-icon.png, 180x180)
The classic (apple-touch-icon.png, apple-touch-icon-ZZZxZZZ.png and apple-touch-icon-precomposed.png)
The full package (apple-touch-icon.png, apple-touch-icon-ZZZxZZZ.png, apple-touch-icon-precomposed.png and apple-touch-icon-precomposed-ZZZxZZZ.png)
The amount of declarations:
Only one (apple-touch-icon.png)
The classic (apple-touch-icon-ZZZxZZZ.png)
These settings depend on the location of the files (root or not) and possibly the scaling algorithm that was chosen by the user of RFG. Some testing must be done in this area.
Note: declaring the precomposed icons is quite useless. It was useful before iOS 7 when you didn't want iOS to manipulate your icon (the gloss effect). RFG doesn't (and won't) let you play with this deprecated feature.
The implementation must meet a requirement: all this must be kept as simple as possible. Most users just want icons that work, not tedious choices.
To do this, we add an "Options" tab in the iOS section of the icon editor. In this tab, the default selection matches current RFG behavior, or maybe a lighter package (to be decided after the experiments with the scaling algorithm).
Right now I'm not comfortable with the next steps until I know more about the scaling algorithm issue. So I consider these experiments as the next TODO to go.
The text was updated successfully, but these errors were encountered:
Done. Conclusion: you can usually provide a single, 180x180 icon. iOS scaling is fine. The only exception is when the wanted scaling algorithm is particular (eg. Nearest Neighbor). But even in this case, although iOS scaling is not perfect, it's okay.