Favicon & Touch-Icon Development: Complete Set for Sites and PWAs
Often a site looks great on desktop, but on mobile devices the icon in bookmarks or on the home screen turns out blurry or gets cropped. This happens because each platform requires its own size and format. Developers frequently forget icons for PWA, causing the app to fail Lighthouse checks. Or they use a single favicon.ico for everything, making it blurry on Retina. We solve these problems for you. Our team has over 10 years of vectorization and rasterization experience and has completed 500+ icon sets, ensuring reliable results. Our engineers have deep expertise in PNG optimization, SVG viewBox configuration, and cache-busting hash integration.
What Sizes and Formats Do Modern Browsers Need?
A modern favicon set is not a single file but a complete artifact for different scenarios. Below is the minimum list of files a site should have:
- favicon.ico: 16×16 and 32×32 multi-size ICO container for browser backward compatibility.
- favicon-16x16.png: 16×16 for Chrome address bar.
- favicon-32x32.png: 32×32 for Safari and Retina.
- apple-touch-icon.png: 180×180 for iOS 'Add to Home Screen'.
- android-chrome-192x192.png: 192×192 for Android Chrome.
- android-chrome-512x512.png: 512×512 for PWA splash screen.
- mstile-150x150.png: 150×150 for Windows tile (msapplication-TileImage).
- safari-pinned-tab.svg: monochrome SVG for Safari Pinned Tab.
If you use PWA, you must include a manifest with correct icon references. Learn more about manifests at developer.mozilla.org.
Automated generation of the set is 3 times faster than manually preparing each file.
Why Is Maskable Icon Support Important for Android?
Android adapts icons to different shapes—circle, squircle. Without the "purpose": "maskable" attribute, the system may crop the icon unpredictably. To avoid this, the source must have a safe zone: a 40-pixel margin from the edges for a 512×512 size. In the manifest, it looks like this:
{
"icons": [
{ "src": "/android-chrome-192x192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/android-chrome-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "any maskable" }
]
}
What Is Included in the Work?
We prepare a complete set for your site. The deliverables include 12 files: 1 SVG source, 1 ICO, 9 PNGs, and 1 manifest.json.
- Original SVG file with correct viewBox and safe zone for maskable.
- All required raster files (from 16×16 to 512×512) in PNG and ICO.
- Correct
manifest.json with all icons and their purpose.
- Meta tags for
<head>: apple-touch-icon, icon, msapplication-TileImage, safari-pinned-tab.
- Testing on real devices: iOS, Android, Windows, and different browsers.
- Integration consultation and post-implementation support.
Deliverables:
- Full icon set (SVG, PNG, ICO) with correct metadata and cache-busting hashes.
- Properly configured manifest.json.
- HTML snippet for
<head> including all meta tags.
- Documentation explaining icon paths and purposes.
- 1 month of support for any issues.
How We Prepare the Set: Step-by-Step Process
- Analyze the original logo. Check if it works at small sizes. If not, simplify contours.
- Create an SVG source with appropriate viewBox. Draw or adapt the logo in vector with a margin for maskable.
- Automatically generate the full set using custom scripts for consistency (PNG optimization via pngquant, ICO creation via ImageMagick).
- Configure
manifest.json. Set paths, purpose, maskable, sizes.
- Insert meta tags into
<head>. All 8 variants, including msapplication-TileImage and apple-touch-icon.
- Test on real devices: iOS, Android, Windows, and browsers.
Typical Mistakes and Solutions
-
Missing apple-touch-icon 180×180: Icon not displayed on iOS. Always include 180×180 PNG with apple-touch-icon meta tag.
- Incorrect path in manifest: PWA does not load icons. Ensure paths are relative from the root and files are accessible.
-
Missing maskable purpose: Android crops icon incorrectly. Add purpose: "any maskable" for 192 and 512 icons.
- SVG for Safari Pinned Tab not monochrome: Does not color to theme color. Use only black fill, no gradients.
-
Logo too complex for 16×16: Loses readability. Create a simplified version for 16×16.
We guarantee that after our work, all icons will display correctly on all devices.
Timelines and Cost
Preparation of a full set takes from 0.5 to 1 business day. Pricing starts at $150 for basic sets and can go up to $300 for complex logo adaptations. You save up to 50% compared to manual per-file generation.
Order Icon Preparation
Contact us to discuss your project. We will prepare icons that work everywhere—on iOS, Android, Windows, and in browsers.
What happens when your website isn't available offline?
A news site loses 40% of returning readers when articles fail to load on the subway. A fintech dashboard becomes useless during a commute. PWA app development solves that by turning your website into an installable application that works without internet, sends push notifications, and loads instantly. One codebase replaces two native teams. Over 7 years we have delivered 30+ PWA projects for e-commerce, fintech, and enterprise portals — each with measurable business impact. Contact us for a free PWA readiness assessment — we will audit your current application and estimate the effort.
How does Service Worker manage network requests?
Service Worker — a JavaScript proxy running in a separate thread — intercepts every HTTP request and decides the response source: cache, network, or a mix. Three core strategies solve most real-world scenarios.
| Caching strategy |
Typical assets |
Offline behavior |
| Cache First |
JS/CSS with content hash (e.g. main.a1b2c3.js) |
Instant load from cache |
| Network First |
API calls for orders, payments |
Live data on success, cached fallback on failure |
| Stale While Revalidate |
News feeds, search results |
Immediate cache, then background update |
Assets with content hashes never change — they can be cached permanently. Stale While Revalidate gives instant response while keeping data fresh within seconds. Google's Workbox automates versioning and cache invalidation; without it a correct Service Worker would require 300+ lines of code. Vite + vite-plugin-pwa generates a production-ready Service Worker from a few lines of config:
import { VitePWA } from 'vite-plugin-pwa';
export default {
plugins: [
VitePWA({
registerType: 'autoUpdate',
includeAssets: ['favicon.ico'],
manifest: { /* name, icons, start_url, display */ },
workbox: {
globPatterns: ['**/*.{js,css,html,ico,png,svg}'],
runtimeCaching: [
{ urlPattern: /^https?:\/\/api\./,
handler: 'NetworkFirst',
options: { cacheName: 'api-cache' }
}
]
}
})
];
};
How is offline mode implemented in practice?
"Works offline" means different things for a news site vs. a CRM. Three typical scenarios:
-
Offline reading (news, docs): Service Worker caches pages on first visit — Stale While Revalidate + Background Sync restores queued interactions when connectivity returns.
-
Offline editing (notes, tasks): IndexedDB stores local data, Background Sync API queues operations and pushes them automatically even if the browser tab is closed. Limitation: Background Sync is supported only in Chromium (~84% of desktop and mobile users).
-
Offline forms: user taps 'Send' without internet — data is preserved in IndexedDB and submitted when the connection is restored. Critical for medical and insurance claim forms.
One commonly underestimated problem: sync conflicts. If user A edits a record offline and user B changes it online, a resolution strategy (last-write-wins, three-way merge, or showing a conflict UI) must be designed upfront. We always address these scenarios during the architecture phase.
Common pitfalls we see in practice: lack of fallback UI (users see a white screen), wrong cache strategy for user-specific data (using Cache First for authenticated API calls), ignoring Service Worker scope (worker placed too deep), and skipping precache validation. Workbox automates cache versioning to avoid expired assets.
How do Web Push notifications work?
Web Push delivers messages through the browser's Push Service (FCM for Chrome/Edge, APNs for Safari). User grants permission → browser subscribes → you receive an endpoint and key → your backend sends a message via the web-push library (Node.js) or equivalent. VAPID keys are generated once, subscriptions stored in a database. iOS (16.4+) supports Web Push only for installed PWAs; Chrome/Firefox/Edge support it without installation. A/B testing send times and content is standard practice — irrelevant notifications cause churn rates above 30%.
Why choose PWA over native applications?
Building and maintaining native iOS and Android apps costs 2–3x more than a single PWA. One codebase, unified business logic, automatic updates — no App Store review delays. PWA lifts conversion by 36% on average (Google aggregated data). Web Push re-engages users at 4x the rate of email when messages are personalized. We have delivered PWA-solutions for high‑traffic e‑commerce platforms (12M monthly sessions) and enterprise fintech dashboards — each project included Core Web Vitals optimisation to pass Google's eligibility criteria. In our experience, PWA engagement metrics are 2–3x higher than mobile web alone, and push notification click-through rates are 7x better than email.
What does turnkey PWA development include?
| Stage |
Result |
Timeline |
| Audit of current application |
PWA‑score report, scenario analysis |
1–2 days |
| Design of offline scenarios |
Technical documentation, prototype |
2–3 days |
| Service Worker + manifest development |
Production code, automated tests |
5–10 days |
| Web Push integration (optional) |
Backend endpoint, subscription logic |
3–5 days |
| Testing on real devices |
Compatibility report, fixes |
3–5 days |
| Deployment & documentation |
Access, instructions, 1‑month warranty |
1–2 days |
Deliverables you receive
- Full source code (Service Worker, manifest, push backend) in your repository.
- Testing guide with Lighthouse audit results and real‑device reports.
- Push notification dashboard or API endpoint for your marketing team.
- Performance monitoring – instruction for checking Core Web Vitals after deployment.
- 1 month of post‑launch support – bug fixes and minor adjustments.
What is App Shell architecture?
App Shell pre‑caches the minimal HTML, CSS and JavaScript needed to render the application chrome on first load. After the shell is cached, subsequent visits render instantly even on slow or offline connections. This technique is paired with dynamic content loading for a native‑like experience.
Process and timeline (from audit to go‑live)
- Audit: Lighthouse PWA score, offline scenario analysis.
- Prioritise valuable offline use cases (based on user behaviour data).
- Configure Service Worker via Workbox, implement manifest.
- Integrate Web Push (if required).
- Test on real devices – Chrome DevTools, Safari Web Inspector, Android Chrome.
- Deploy, hand over documentation, train the team.
Estimated timelines: basic PWA (manifest + Service Worker + static cache) – 1–2 weeks on top of existing application. Add Web Push – 1–2 weeks. Offline editing with IndexedDB and Background Sync – 3–6 weeks depending on data complexity. Cost is calculated individually after a free audit. On average, a PWA project costs 40–60% less than building two native apps – and you save recurring App Store fees. Get in touch for a free consultation – we will assess your project and propose the optimal implementation plan.
Further reading
