In one paragraph
Apple touch icon missing means this homepage check did not recognise the icon arrangement its heuristics accept. A valid apple-touch-icon declaration with a different filename can warn, while multiple unrelated favicons can pass. Declare a real appropriate asset and test actual saved-site behaviour on supported devices. This informational result is not a site-functionality, accessibility, or search-ranking certificate.
Why it matters
Apple's documented touch-icon mechanism identifies artwork for saved web clips and related supported contexts. A declared link can point to a custom pathname; the filename does not generally have to contain apple-touch when the declaration correctly identifies it.
Apple's archived Safari guide documents PNG icons and several device sizes, including 180 by 180. It is historical guidance, not proof every current Safari surface chooses exactly one asset or always uses one fallback. Review actual supported environments and current platform behaviour.
General favicons, touch icons, and manifest assets can coexist for different uses. Do not assume two icon links prove a correct touch asset or that one file declaration covers every browser's installation presentation.
How WebAuditOS evaluates this finding
The supplied homepage rule inspects its recognised icon declarations and passes if a recorded path contains apple-touch or if more than one icon link is found. Otherwise it warns informationally; missing or unreadable homepage content can be ungraded.
It does not fetch the root-file convention or validate bytes, dimensions, format, or actual iOS selection. A correct single custom-name touch icon can warn, and two favicons can create a false pass. These are product recognition limits rather than platform requirements.
How to fix it
- Inspect the homepage's actual source and all relevant icon generators. Determine whether a framework or CMS already creates a touch declaration before adding competing links.
- Provide an appropriate real PNG asset and a correct declaration. For example:
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">The file must actually have the stated dimensions and suitable artwork. The conventional filename is illustrative, not a requirement to rename a valid custom asset solely for the detector.
- Keep artwork suitable for the supported saved-site context. Test crop, legibility, padding, and platform styling rather than assuming a desktop logo will work at icon scale.
- Verify public retrieval, status, content type, and image bytes without privileged access. A declaration pointing at an HTML error page is not an icon.
- Review optional additional sizes or manifest assets according to the actual product and devices. Do not create an arbitrary second favicon solely to satisfy this check's loose pass condition.
- Test adding the page to the home screen or relevant saved-site context on representative devices. Clear or account for platform caching when comparing old and new artwork.
- Check other templates if users can save deep routes. A homepage-only observation does not validate all emitted metadata.
- Rescan and record any known filename false positive. Judge actual asset correctness and presentation separately from the informational detector result.
What the fix can break
An icon rename can leave cached pages referencing a removed file. Coordinate assets and cache behaviour rather than changing only the link string.
Duplicated generators can make selection unclear. Assign one intentional source for each supported icon purpose.
Do not spend effort making the counter green while the declared asset fails retrieval or misrepresents the site's identity.
Questions
Must a linked icon filename contain apple-touch?
No. Apple's documented link mechanism supports a custom path. This scanner's filename requirement is a heuristic limitation.
Do two favicon links prove a touch icon exists?
No. They can satisfy the supplied loose rule without providing the appropriate asset.
Does the check fetch or inspect the image?
Not under the supplied scope. Verify delivery and actual presentation separately.
Which related checks help?
Review viewport presence, target size, and the mobile usability guide.