DEV Community: WAVX solutions

Shopify App Development Cost in India (2026)

WAVX solutions — Mon, 05 Oct 2026 05:49:49 +0000

A custom Shopify app built in India costs roughly what a small custom web application costs, because that is what it is: a web application that talks to Shopify's APIs. On WavX's published cost model, the planning range is about ₹2.2 lakh to ₹3.25 lakh for a small private app that does one job, ₹5.6 lakh to ₹8.25 lakh for a full embedded app with its own data and admin screens, and ₹8.5 lakh to ₹12.5 lakh for a public app sold on the Shopify App Store. These are planning ranges with the assumptions shown below, not quotes. Shopify's own charges (the plan, the transaction fee and, for some features, the Plus plan) are separate, and are listed here as read on Shopify's pricing page on 2 October 2026.

What counts as a Shopify app

Shopify's help centre describes three kinds of app, and the kind decides most of the cost.

Kind	Who it is for	Review by Shopify	Billing through Shopify
Public app	Many stores. Installed from the Shopify App Store, listed or unlisted	Yes, it goes through app review	Yes
Custom app	One store, or several stores inside the same Plus organisation	No	No. Shopify's distribution guide says a custom app cannot charge merchants through Shopify's app billing
App made by Shopify	Any store	Not applicable	Usually free

A custom app is created and managed in Shopify's Dev Dashboard. The older route, creating a custom app inside the Shopify admin, is no longer available for new apps according to the same guide.

Most merchants asking about cost want a custom app: something that connects the store to an accounting system, a courier, a CRM or a warehouse, or that adds a rule Shopify does not have. That is the work described on WavX's custom Shopify app development page.

Planning ranges, with the assumptions shown

WavX does not publish a separate Shopify rate card. A custom app is priced the way any custom web application with integrations is priced, so the figures below come from the software cost estimator, the same model behind every WavX software planning range. The method is simple: take the base for the type of build, add the listed features, and show the result as a range from 15% below to 25% above that subtotal.

App	Assumptions taken from the cost model	Subtotal	Planning range	Planning timeline
Small private app. One job, such as pushing paid orders into an accounting system or tagging customers by a rule	Internal tool base ₹2,00,000 + third-party integrations ₹60,000	₹2,60,000	₹2,21,000 to ₹3,25,000	3–6 weeks
Integration app with reporting. Two-way sync with an ERP, courier or CRM, a status screen and exports	Internal tool base ₹2,00,000 + third-party integrations ₹60,000 + real-time ₹70,000 + exports and reporting ₹50,000	₹3,80,000	₹3,23,000 to ₹4,75,000	6–10 weeks
Full custom app. Embedded admin app with its own database, staff roles, an admin panel and storefront or checkout extensions	Custom web application base ₹4,50,000 + auth and roles ₹60,000 + third-party integrations ₹60,000 + admin panel ₹90,000	₹6,60,000	₹5,61,000 to ₹8,25,000	10–16 weeks
Public App Store app. A product for many merchants, with billing and onboarding	SaaS product base ₹7,00,000 + auth and roles ₹60,000 + payments and billing ₹90,000 + admin panel ₹90,000 + third-party integrations ₹60,000	₹10,00,000	₹8,50,000 to ₹12,50,000	10–16 weeks

Every row assumes the model's small scale (multiplier 1.0) and standard design (multiplier 1.0). The growing scale multiplies the subtotal by 1.3 and the large scale by 1.7. Timelines are the model's bands: a subtotal under ₹3,00,000 maps to 3–6 weeks, under ₹6,00,000 to 6–10 weeks, and anything above to 10–16 weeks.

Three caveats belong next to this table.

The first two rows use the estimator's "internal tool" base. The reasoning is that a back-office sync app with one status screen is closer to an internal tool than to a customer-facing web application. If your app has a substantial interface of its own, read the third row instead.
The model has one line for third-party integrations. An app that connects four systems is not the same job as one that connects a single system, and the real quote reflects that. The table is for budgeting, and a quote follows a written scope.
Smaller jobs exist. WavX's Shopify store setup cost guide puts installing and configuring existing App Store apps at ₹40,000 inside its mid-tier example, and the ecommerce website cost guide says bespoke integration work typically adds ₹30,000 to ₹1,50,000 to a build. If all you need is a short script or a configuration, it may not be an app project at all.

What moves the number

The assumptions column is where a real project differs from the table. These are the questions that change the price, roughly in order of effect.

How many systems, and in which direction. Sending orders out of Shopify is simpler than keeping stock, prices and orders in step both ways, where two systems can disagree and one has to win.
Where the app shows up. An app that only runs in the background is the cheapest. Screens inside the Shopify admin add interface work. Anything the shopper sees on the storefront or in checkout adds design, testing on real devices and stricter performance limits.
Whether it holds its own data. An app that stores nothing and only moves data between two APIs is small. An app with its own database needs backups, access control and a plan for what happens when Shopify and the database disagree.
Volume. A few hundred orders a day can be processed one at a time. Sale-day peaks need queues and retries, because Shopify rate-limits its Admin API by plan. Shopify's pricing page lists API rate limits as standard on Basic and Grow, up to 2x on Advanced and up to 10x on Plus.
The other system. A documented API with a sandbox is quick to integrate. Desktop accounting software, a courier with a spreadsheet upload, or an ERP nobody has credentials for can each take longer than the Shopify side.
Failure handling. What should happen when the ERP is down for an hour? Deciding that, and building the retry and the alert, is a large part of any integration.

Shopify's own fees that sit beside the build

The build cost is paid once. Shopify's fees are paid every month and are set by Shopify, so they are quoted here exactly as shown on Shopify's India pricing page on 2 October 2026.

Plan	Price, billed monthly	Price per month, billed yearly	Fee on third-party payment providers	API rate limits
Basic	₹1,994	₹1,499	2%	Standard
Grow	₹7,447	₹5,599	1%	Standard
Advanced	₹30,164	₹22,680	0.6%	Up to 2x
Plus	From ₹1,75,000	From ₹1,75,000	0.2%	Up to 10x

Three points about these figures.

The transaction fee matters more in India than elsewhere. Shopify Payments is not on Shopify's list of supported countries for India, so an Indian store uses a third-party gateway and pays the percentage in the table on those orders, on top of the gateway's own fee. Shopify's help centre says manual payment methods, including cash on delivery, are not charged this fee.
GST applies. Shopify's billing help page says a store located in India is charged GST on its Shopify fees, and that the exemption for a store that provides its GSTIN applies only to invoices issued after the GSTIN is submitted. Add it to the billing profile before the first bill.
Prices change. Earlier WavX guides quote plan prices as they stood on the day they were written. Use Shopify's page for the current figure.

Shopify does not charge a fee for installing a custom app on your own store. App Store apps are different: each sets its own subscription price.

Plan rules that change the scope

Two Shopify rules decide whether a custom app can do what you want on your current plan. Both are quoted from Shopify's developer documentation as of October 2026.

Shopify Functions. Functions are how an app changes discounts, delivery options, payment methods and cart validation on Shopify's servers. Shopify's documentation says stores on any plan can use public apps from the App Store that contain Functions, and that only stores on a Shopify Plus plan can use custom apps that contain Functions. So a custom discount rule written only for your store needs Plus. On other plans the choices are an App Store app that offers the rule, or a different design. The Scripts to Functions migration guide covers this in detail.

Checkout interface. Shopify's checkout UI extensions reference says extensions for the information, shipping and payment steps are available only to stores on a Shopify Plus plan.

For a store on Basic, Grow or Advanced, this means a requirement such as "hide cash on delivery above ₹5,000 with our own rule" may turn a ₹3 lakh app discussion into a decision about a plan that starts at ₹1,75,000 a month. It is better to find that out before the build than during it.

Costs after launch

A Shopify app is not finished when it is installed. Three recurring costs follow.

Hosting. Shopify's deployment guide describes deployment as moving your code to a hosting service, and names Vercel, Google Cloud Run, Fly.io and Render as options. The app's web backend runs on hosting you pay for. Extensions and Functions are deployed to Shopify with the Shopify CLI. Hosting is billed by the provider you choose and depends on traffic, so no figure is given here.

API versions. Shopify releases a new API version every three months and supports each stable version for at least 12 months. When an app calls a version that has been retired, Shopify responds with the oldest version still supported, which may behave differently. In practice someone has to review and update the app at least once a year. Shopify also marks the REST Admin API as legacy since 1 October 2024, and requires new public apps to use the GraphQL Admin API from 1 April 2025, so an older app built on REST carries a migration cost.

Maintenance. WavX publishes 15% to 25% of the build cost per year as its maintenance band, explained in the app maintenance cost guide.

App	Planning range for the build	Maintenance per year at 15% to 25%
Small private app	₹2,21,000 to ₹3,25,000	₹33,150 to ₹81,250
Integration app with reporting	₹3,23,000 to ₹4,75,000	₹48,450 to ₹1,18,750
Full custom app	₹5,61,000 to ₹8,25,000	₹84,150 to ₹2,06,250
Public App Store app	₹8,50,000 to ₹12,50,000	₹1,27,500 to ₹3,12,500

The low figure is 15% of the low end of the range and the high figure is 25% of the high end.

A worked example over three years

Take the second row: an app that keeps orders and stock in step between Shopify and an ERP, with a status screen and exports.

Line	Low	High
Build, year one	₹3,23,000	₹4,75,000
Maintenance, year two	₹48,450	₹1,18,750
Maintenance, year three	₹48,450	₹1,18,750
Three-year total, before hosting and GST	₹4,19,900	₹7,12,500

This follows the cost model's own method, which treats the first year's maintenance as part of the build. It is a model for budgeting. Hosting, Shopify's plan and any fee charged by the other system are extra.

The useful comparison is the monthly cost of doing the same job by hand or with a subscription app. ₹4,19,900 over 36 months is about ₹11,700 a month, and ₹7,12,500 is about ₹19,800 a month. If the work the app replaces costs less than that, the app does not pay for itself on cost alone.

If the app is going on the App Store

A public app is a product business, and its costs go beyond the build.

Review. A public app goes through Shopify's app review before it can be installed from the App Store.
Revenue share. As of October 2026, Shopify's revenue share page says a developer keeps 100% of the first US$1,000,000 in gross app revenue earned from 1 January 2025 and 85% above that, with a one-time US$19 registration fee per partner account and a 2.9% processing fee on billing.
Support and onboarding. Every merchant who installs the app can raise a ticket. That is a running cost a custom app for one store does not have.
Many stores, many edge cases. Themes, plans, currencies and other apps differ from store to store, so testing takes longer.

The fourth row of the table is a starting point for a first version, not the cost of running an app business.

When you should not build an app

A page about app pricing should say when the answer is not to buy one.

An App Store app already does it. Shopify's help centre says apps made by Shopify are usually free, and a third-party app such as Judge.me Product Reviews lists its paid plan at US$15 a month as of October 2026. A custom build rarely beats that on cost. The comparison, with real subscription prices over two years, is in custom Shopify app or App Store app.
The process is still changing. If the team has not settled how returns or wholesale orders should work, software will fix the wrong process in place. Run it by hand for a month first.
The need is seasonal. A rule needed for one sale is better handled with Shopify's built-in discounts or a monthly app you cancel afterwards.
The rule needs Plus and you are not on Plus. A custom app with Functions will not run on your plan. Look for a public app first.
The other system has no way in. If the ERP or courier offers no API and no file exchange, the app cannot be built reliably at any price. The first job is on that side.

What to write down before asking for a quote

A scope on one page gets a firmer number than a conversation. These six answers are enough for any developer to price the work, WavX included.

What the app must do, as a list of events: "when an order is paid, create an invoice in the accounting system".
Which systems it touches, and whether each has an API and test credentials.
Your Shopify plan, and whether the app needs to change discounts, shipping, payments or checkout.
Daily order volume on a normal day and on your biggest sale day.
Who uses the app's screens, if it has any, and what they need to see.
What should happen when something fails, and who should be told.

With those, the planning ranges above can be replaced by a quote. The wider Shopify work WavX offers is listed on the Shopify and app development page.

Sources

Shopify India pricing: plan prices, third-party payment provider fees, API rate limits, read 2 October 2026
Shopify Help Center: types of apps, read 2 October 2026
Shopify developer documentation: app distribution, read 2 October 2026
Shopify developer documentation: Shopify Functions, plan availability, read 2 October 2026
Shopify developer documentation: checkout UI extensions, read 2 October 2026
Shopify developer documentation: API versioning, read 2 October 2026
Shopify developer documentation: REST Admin API legacy notice, read 2 October 2026
Shopify developer documentation: app deployment, read 2 October 2026
Shopify developer documentation: App Store revenue share, read 2 October 2026
Shopify App Store: Judge.me Product Reviews pricing, read 2 October 2026
Shopify Help Center: Shopify Payments supported countries, read 2 October 2026
Shopify Help Center: third-party transaction fees, read 2 October 2026
Shopify Help Center: taxes on Shopify bills for India, read 2 October 2026

Service Workers and Caching Strategies, Explained with Code

WAVX solutions — Sun, 04 Oct 2026 17:49:20 +0000

A service worker is a JavaScript file the browser runs in the background, separate from your pages, that can intercept every network request those pages make. A caching strategy is the rule it applies to one kind of request: answer from a cache, go to the network, or combine the two. Most sites need three rules: cache first for versioned CSS, JavaScript and fonts; network first for HTML pages, with an offline fallback; and stale-while-revalidate for images. Anything that changes data or involves money goes straight to the network.

The code in this guide is written against the Service Worker and Cache APIs as documented on MDN, web.dev and Chrome for Developers on 2 October 2026. It is an example for this article, not a published, device-tested demo. Run it in the browsers your visitors use before you ship it.

If the term is new, start with the short definition of a service worker, or with what a progressive web app is.

What a service worker is allowed to do

Four rules explain most of the surprises.

HTTPS only. MDN states that service workers are restricted to running across HTTPS. localhost counts as secure so that you can develop locally.
Scope follows the file's location. By default a worker controls only URLs in or below the directory it is served from. A file at /js/sw.js controls /js/ and nothing else. To control the whole site, serve it from the root as /sw.js. A server can widen the scope with the Service-Worker-Allowed response header.
It does not control the page that installs it. On the first visit the page loads without a worker, registers one, and stays uncontrolled until the next load unless the worker calls clients.claim(). Do not judge your caching on a first visit.
It is event-driven. The browser starts the worker when an event such as fetch or push arrives and may stop it afterwards. Treat variables in the worker as temporary and keep anything that must survive in the Cache API or IndexedDB.

The five caching strategies

These names come from Jake Archibald's Offline Cookbook on web.dev and are used the same way in the Chrome and MDN documentation.

Strategy	What it does	How fresh	Works offline	Use it for
Cache only	Answers from the cache and never touches the network	As fresh as the last release	Yes	Files stored at install: the offline page, the app shell
Network only	Passes the request through untouched	Always current	No	POST requests, cart, checkout, payments, analytics pings
Cache first, falling back to network	Looks in the cache; on a miss, fetches and stores	Stale until the file name or cache name changes	Yes, once stored	Hashed CSS, JavaScript and fonts
Network first, falling back to cache	Tries the network; on failure, serves the last stored copy	Current whenever online	Yes, for pages already visited	HTML pages, API reads that should be current
Stale-while-revalidate	Serves the cached copy at once and refreshes the cache in the background	One visit behind	Yes, once stored	Product images, avatars, content that can be slightly old

MDN's caching guide makes the point that matters most: a single app normally uses several of these, one per type of resource. Choosing one strategy for the whole site is the usual beginner mistake.

A complete service worker

Save this as sw.js at the root of the site. It stores an offline page and two core files at install, removes old caches when a new version activates, and routes each request to one of three strategies.

// sw.js
const VERSION = "v1";
const STATIC_CACHE = `static-${VERSION}`;
const PAGE_CACHE = `pages-${VERSION}`;
const IMAGE_CACHE = `images-${VERSION}`;
const OFFLINE_URL = "/offline.html";
const PRECACHE = [OFFLINE_URL, "/styles/main.css", "/scripts/app.js"];
const NEVER_CACHE = ["/api/", "/cart", "/checkout", "/account"];

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(STATIC_CACHE).then((cache) => cache.addAll(PRECACHE))
  );
});

self.addEventListener("activate", (event) => {
  const keep = [STATIC_CACHE, PAGE_CACHE, IMAGE_CACHE];
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(
        keys.filter((key) => !keep.includes(key)).map((key) => caches.delete(key))
      )
    )
  );
});

async function putInCache(cacheName, request, response) {
  const cache = await caches.open(cacheName);
  await cache.put(request, response);
}

async function cacheFirst(event, cacheName) {
  const cached = await caches.match(event.request);
  if (cached) return cached;
  const response = await fetch(event.request);
  if (response.ok) {
    event.waitUntil(putInCache(cacheName, event.request, response.clone()));
  }
  return response;
}

async function networkFirst(event, cacheName) {
  try {
    const response = await fetch(event.request);
    if (response.ok) {
      event.waitUntil(putInCache(cacheName, event.request, response.clone()));
    }
    return response;
  } catch (error) {
    const cached = await caches.match(event.request);
    return cached || (await caches.match(OFFLINE_URL)) || Response.error();
  }
}

async function staleWhileRevalidate(event, cacheName) {
  const cached = await caches.match(event.request);
  const network = fetch(event.request).then((response) => {
    if (response.ok) {
      event.waitUntil(putInCache(cacheName, event.request, response.clone()));
    }
    return response;
  });
  if (cached) {
    event.waitUntil(network.catch(() => undefined));
    return cached;
  }
  return network;
}

self.addEventListener("fetch", (event) => {
  const { request } = event;
  const url = new URL(request.url);

  // Leave non-GET and cross-origin requests to the browser.
  if (request.method !== "GET" || url.origin !== self.location.origin) return;

  // Network only: never store cart, checkout, account or API traffic.
  if (NEVER_CACHE.some((path) => url.pathname.startsWith(path))) return;

  if (request.mode === "navigate") {
    event.respondWith(networkFirst(event, PAGE_CACHE));
  } else if (["style", "script", "font"].includes(request.destination)) {
    event.respondWith(cacheFirst(event, STATIC_CACHE));
  } else if (request.destination === "image") {
    event.respondWith(staleWhileRevalidate(event, IMAGE_CACHE));
  }
});

<script>
  if ("serviceWorker" in navigator) {
    window.addEventListener("load", () => {
      navigator.serviceWorker.register("/sw.js").catch((error) => {
        console.error("Service worker registration failed:", error);
      });
    });
  }
</script>

You also need a plain /offline.html page that does not depend on anything outside the precache list.

How each part behaves

Install. cache.addAll() is all or nothing. MDN documents that it rejects if any response is outside the 200 range, and when the promise passed to event.waitUntil() rejects, the install fails. One wrong path in PRECACHE therefore means no service worker at all. Keep the list short and check every entry.

Activate. MDN recommends cleaning up old caches in the activate event, because at that point no earlier version of the worker is running. The VERSION constant is what makes this work: change it and every old cache is deleted on activation.

Cache first. Fast, and dangerous with file names that never change. If /styles/main.css is stored under cache first, visitors keep the old file until VERSION changes. Either bump VERSION on every release or, better, use hashed file names such as main.4f9a1c.css, which most build tools produce.

Network first. The right default for HTML. Online visitors always get the current page; offline visitors get the last copy they saw, and the offline page for anything they have not visited. The cost is that a slow connection is still slow, because the cache is consulted only after the network fails.

Stale-while-revalidate. The visitor sees the stored image at once and the worker refreshes the cache behind it, so a changed image appears on the following visit. Do not use it for prices, stock levels or anything a customer acts on.

Three details in the code are easy to get wrong:

response.clone(). A response body can be read once. The clone goes to the cache and the original goes to the page.
response.ok. Without this check a 404 or 500 page gets cached and served again. It also skips opaque cross-origin responses, whose reported status is 0.
event.waitUntil(). It tells the browser the worker still has work to finish after the response has been returned. MDN's own example uses the same pattern for the cache write.

What must never be cached

The early return statements in the fetch handler matter more than the strategies. Requests that fall through are handled by the browser as if no worker existed.

Anything that is not a GET request. MDN notes that caching is never appropriate for requests such as POST.
Cart, checkout and payment pages and the calls behind them.
Login, account and order-history pages. A page cached for one user must never be shown to another on a shared device.
API responses that carry prices, stock, balances or anything else that must be current.
Third-party scripts for payments and analytics. Let them load normally.

On an online store, serving a stale price from a cache is worse than showing an error. The guide to PWAs for e-commerce in India covers the split for a storefront.

How updates reach users

This is the part that catches teams after launch.

The browser checks for a new worker on every navigation to a page in scope, and on events such as push unless it checked in the previous 24 hours. The lifecycle article on web.dev notes that most browsers ignore HTTP caching headers for this check by default; the updateViaCache option on register() controls it.
Any byte of difference counts. If the new sw.js differs at all, it is installed alongside the old one. Changing VERSION is enough.
The new worker waits. It activates only when the old worker controls no open pages. A visitor who keeps a tab open keeps the old version.
You can skip the wait. Calling self.skipWaiting() in the install handler activates the new worker immediately. The risk is that a page loaded with old HTML is suddenly served by new logic and new assets. Skip waiting only if your pages tolerate that, or prompt the visitor to reload.

Whichever you choose, write it down. When someone asks why the old version is still showing after a release, the answer is almost always in this list.

Storage limits and eviction

A cache is borrowed space. As of October 2026, MDN documents these limits:

Browser	Per-origin limit	Notes
Chrome, Edge and other Chromium browsers	Up to 60% of total disk size	Same in best-effort and persistent modes
Firefox	The smaller of 10% of disk or 10 GiB	Up to 50% of disk if persistent storage is granted
Safari, from iOS 17 and macOS 14	Around 60% of total disk for browser apps	Around 15% for other apps that embed web content

When a device runs short of space, browsers delete data for the least recently used origins first. Safari also deletes script-created data, which includes service worker registrations and caches, for a site with no user interaction in seven days of browser use when cross-site tracking prevention is on. navigator.storage.estimate() reports approximate usage and navigator.storage.persist() asks the browser not to evict your origin.

The practical rule: cache only what can be downloaded again, and never treat the cache as the only copy of user data. iPhone specifics are in PWAs on iPhone: what works and what does not.

Two newer options

Navigation preload lets the browser start the network request for a page while the service worker is still starting up, which removes a delay from network-first navigations. MDN's compatibility data lists it from Chrome 59, Firefox 99 and Safari 15.4.

The static routing API (InstallEvent.addRoutes()) lets a worker declare routes that the browser can handle without starting the worker at all. The same data lists it from Chrome 123 and Safari 27, released in September 2026, and not in Firefox, so treat it as an optimisation and not something to depend on.

Hand-written or a library

Workbox, described in the Chrome documentation as production-ready service worker libraries and tooling, wraps the same strategies in modules for routing, precaching and expiry. It earns its place when the precache list should be generated by the build, when caches need size or age limits, or when there are many routes. For Next.js projects, the Next.js documentation names Serwist as one option for service-worker-based offline caching.

For a site with three or four rules, a hand-written file like the one above is easier to reason about, and nothing in it is hidden.

Testing before release

Chrome DevTools has what you need in the Application panel:

Service Workers shows the registered worker and its state, with controls to go offline, update on reload, bypass the worker for network, and unregister it.
Cache Storage lists every cache and the responses in it.
Clear storage unregisters workers and wipes caches in one click, so you can repeat a first visit.

Test four things: a first visit, a repeat visit, a repeat visit with the Offline box ticked, and a release with a new VERSION. Then repeat on a real Android phone and a real iPhone.

A kill switch

A faulty service worker keeps serving whatever it cached, to every returning visitor, until it is replaced. Chrome's documentation on removing buggy service workers recommends deploying a replacement worker that has no fetch handler, so that the browser handles every request itself. The file below follows that advice and also deletes the caches and unregisters the worker. Keep it ready.

// sw.js (emergency replacement)
self.addEventListener("install", () => self.skipWaiting());

self.addEventListener("activate", (event) => {
  event.waitUntil(
    (async () => {
      const keys = await caches.keys();
      await Promise.all(keys.map((key) => caches.delete(key)));
      await self.registration.unregister();
    })()
  );
});

Deploy it at the same URL as the worker it replaces. The browser picks it up at its next update check, which is why the fix is a new file at that address and not a change anywhere else.

When you do not need a service worker

A service worker adds a second cache with its own rules, and a new class of bug. It is not worth it when:

The site is a brochure or a blog that visitors read once. Correct HTTP cache headers and a CDN give most of the speed benefit with none of the risk.
Nobody will own it. A worker written at launch and never revisited is how sites end up serving a months-old home page.
The real problem is a slow first load. A service worker cannot help a first visit, because it is not in control yet. Fix images, scripts and server response time first.

It is worth it when visitors return often, when connections drop in the middle of a task, or when the site should be installable and usable offline. That is the case for a progressive web app, and it is the work WavX takes on under PWA development, including the caching rules, the update plan and the testing described here.

Sources

MDN: Using Service Workers, read 2 October 2026
MDN: Caching (Progressive web apps guide), read 2 October 2026
MDN: ServiceWorkerContainer.register(), read 2 October 2026
MDN: Cache.addAll(), read 2 October 2026
MDN: Storage quotas and eviction criteria, read 2 October 2026
MDN browser-compat-data, the data behind MDN's compatibility tables (NavigationPreloadManager, InstallEvent.addRoutes), read 2 October 2026
web.dev: The Offline Cookbook, read 2 October 2026
web.dev: The service worker lifecycle, read 2 October 2026
Chrome for Developers: Strategies for service worker caching, read 2 October 2026
Chrome for Developers: Workbox, read 2 October 2026
Chrome for Developers: Removing buggy service workers, read 2 October 2026
Chrome for Developers: Debug Progressive Web Apps, read 2 October 2026
WebKit: Full Third-Party Cookie Blocking and More (seven-day cap on script-writable storage), read 2 October 2026
Next.js documentation: Progressive Web Applications, read 2 October 2026

PWAs on iPhone: What Works and What Does Not (October 2026)

WAVX solutions — Sun, 04 Oct 2026 05:48:41 +0000

As of October 2026, per the sources below, a progressive web app on iPhone can be added to the Home Screen, open in its own window without browser controls, work offline through a service worker, send push notifications and show a badge on its icon. It cannot show an automatic install prompt, sync data in the background, or reach Bluetooth, NFC or USB devices. Push notifications work only after the user has added the app to the Home Screen.

How this page was compiled. Every row below comes from WebKit's release posts, Apple's developer documentation or MDN's browser compatibility data, all read on 2 October 2026. Safari 27, which ships with iOS 27, was released in September 2026 and is the current version. This is a reading of documentation, not a device test. A checklist for confirming the items that matter to your product is at the end.

Support table: installing and launching

Capability	On iPhone	Since	Notes
Add to Home Screen from Safari	Works	Long-standing	From iOS 26, every site added to the Home Screen opens as a web app by default. The user can switch off "Open as Web App".
Add to Home Screen from Chrome, Edge, Firefox	Works	iOS 16.4	Through the Share menu of those browsers
Automatic install prompt (`beforeinstallprompt`)	Not supported		The event exists only in Chromium browsers
Own window (`display: standalone`)	Works	iOS 11.3	MDN's data lists `fullscreen` and `minimal-ui` as unsupported in Safari
Icons from the manifest	Works	iOS 15.4	Used only when the page has no `apple-touch-icon` and the icon's `purpose` is `any` or unset
Manifest `id`	Works	iOS 16.4	Lets the same app be installed more than once
Manifest `shortcuts`	Not supported		Listed for Safari on Mac from 17.4, not for iOS

Support table: offline, storage and background work

Capability	On iPhone	Since	Notes
Service worker and Cache API	Works	iOS 11.3	The basis of offline support
Storage quota	Around 60% of disk per origin	iOS 17	A Home Screen web app has the same quota as the site in the browser
Persistent storage request	Works	iOS 15.2	Safari decides using heuristics, including whether the site is opened as a Home Screen web app
Navigation preload	Works	iOS 15.4
Service worker static routing	Works	iOS 27	New in Safari 27
Background Sync	Not supported
Periodic Background Sync	Not supported
Background Fetch	Not supported

Support table: notifications

Capability	On iPhone	Since	Notes
Web Push	Works, with conditions	iOS 16.4	Home Screen web apps only; permission must follow a tap; every push must show a notification
Declarative Web Push	Works	iOS 18.4	Home Screen web apps; no service worker needed to display the notification
Badge on the app icon (Badging API)	Works	iOS 16.4	Home Screen web apps only
Focus modes	Works	iOS 16.4	Web app notifications follow the user's Focus settings
Action buttons, image and vibration pattern on a notification	Not supported		MDN's data lists these notification options as unsupported in Safari

Support table: device features

Capability	On iPhone	Since	Notes
Camera and microphone (`navigator.mediaDevices`)	Works	iOS 11
Geolocation	Works	Long-standing
Web Share	Works	iOS 12.2
Screen Wake Lock	Works	iOS 16.4 in Safari, iOS 18.4 in Home Screen web apps	Did not work in Home Screen web apps before 18.4
Web Bluetooth	Not supported
Web NFC	Not supported
WebUSB	Not supported
Vibration API	Not supported
Contact Picker	Off by default		Behind a preference flag from iOS 14.5
Detect an installed native app (`getInstalledRelatedApps`)	Not supported

Installing: there is no prompt, so explain it

On Android, Chrome fires beforeinstallprompt and a site can show its own install button. Safari does not support that event, and MDN's installability guide states plainly that it is not supported on iOS. On iPhone the user installs by hand:

Open the Share menu in the browser.
Tap Add to Home Screen.
Confirm the name and tap Add.

WebKit's notes for Safari 26 describe what changed last year. Before iOS 26, a site opened as a web app only if it had a manifest with a suitable display value or the older Apple meta tag; otherwise the Home Screen icon opened a browser tab. From iOS 26, every site added to the Home Screen opens as a web app by default, and WebKit describes this as zero requirements for installability in Safari.

Keep the manifest anyway. It still sets the name, icon and start address, and visitors on older iOS versions need "display": "standalone" to get the app window at all.

Since most people do not know the Share menu route, show a hint to iPhone visitors who have not installed yet:

<p id="ios-install-hint" hidden>
  To install this app: tap the Share button, then "Add to Home Screen".
</p>
<script>
  const isIPhone = /iPhone/.test(navigator.userAgent);
  const isInstalled = window.matchMedia("(display-mode: standalone)").matches;
  if (isIPhone && !isInstalled) {
    document.querySelector("#ios-install-hint").hidden = false;
  }
</script>

If install is not working at all, the checks are in PWA not installing.

Push notifications on iPhone: the exact conditions

Web Push arrived on iPhone in iOS 16.4. It uses the same standards as other browsers: the Push API, the Notifications API and a service worker. The conditions are what catch people out.

The app must be on the Home Screen. MDN's data notes that on iOS the Notification interface is undefined unless the page is a web app saved to the Home Screen. In a Safari tab there is nothing to call.
Permission must follow a tap. Apple's documentation says to give the user a control such as a button and to call the subscription method immediately from that gesture's event handler.
Every push must be shown. Apple states that Safari does not support invisible push notifications, and that if you do not present a notification Safari revokes the push permission for your site.
No developer account is needed. Apple's documentation says you do not need to join the Apple Developer Program to send web push notifications.
Your server must reach Apple's push service. If outbound traffic is restricted, Apple says to allow https://*.push.apple.com.

Once granted, WebKit says these notifications behave like those from other apps: they show on the Lock Screen, in Notification Center and on a paired Apple Watch.

The subscription code is the same as for any browser. The service worker registration is fetched before the click so that subscribe() runs directly inside the tap handler.

// Page script (type="module"). VAPID_PUBLIC_KEY is your server's public key.
function urlBase64ToUint8Array(base64String) {
  const padding = "=".repeat((4 - (base64String.length % 4)) % 4);
  const base64 = (base64String + padding).replace(/-/g, "+").replace(/_/g, "/");
  return Uint8Array.from(atob(base64), (char) => char.charCodeAt(0));
}

const button = document.querySelector("#enable-alerts");
const pushSupported = "Notification" in window && "PushManager" in window;

if (!pushSupported) {
  // On iPhone this is the case in a Safari tab. Ask the user to install first.
  button.hidden = true;
} else {
  const registration = await navigator.serviceWorker.ready;
  button.addEventListener("click", async () => {
    try {
      const subscription = await registration.pushManager.subscribe({
        userVisibleOnly: true,
        applicationServerKey: urlBase64ToUint8Array(VAPID_PUBLIC_KEY),
      });
      await fetch("/api/push/subscribe", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(subscription),
      });
    } catch (error) {
      console.error("Push subscription failed:", error);
    }
  });
}

Declarative Web Push, from iOS 18.4

WebKit added Declarative Web Push in iOS 18.4 for web apps on the Home Screen. The push message itself is a JSON description of the notification, and the browser displays it without running any JavaScript. The format in WebKit's announcement looks like this:

{
  "web_push": 8030,
  "notification": {
    "title": "Your order has shipped",
    "body": "Tap to see tracking details.",
    "navigate": "https://www.example.com/orders/1042",
    "silent": false,
    "app_badge": "1"
  }
}

WebKit designed it to be backwards compatible: a browser that understands the format handles it itself, and an older browser passes the same message to your service worker. A push handler that reads the same shape covers both:

// In sw.js
self.addEventListener("push", (event) => {
  const payload = event.data ? event.data.json() : {};
  const note = payload.notification || {};
  event.waitUntil(
    self.registration.showNotification(note.title || "Update", {
      body: note.body || "",
      data: { url: note.navigate || "/" },
    })
  );
});

self.addEventListener("notificationclick", (event) => {
  event.notification.close();
  event.waitUntil(clients.openWindow(event.notification.data.url));
});

Offline and storage on iPhone

Service workers have been in Safari on iOS since 11.3, so the caching rules in service workers and caching strategies apply. Three iPhone-specific points:

Quota is generous, eviction is the risk. WebKit's storage policy, in force from iOS 17, allows an origin up to around 60% of total disk in a browser app, and a Home Screen web app gets the same. WebKit may still evict data when the overall quota is exceeded, when the device is under storage pressure, or when the user has not interacted with the site for some time.

The seven-day rule is aimed at browser tabs. Safari deletes a site's script-writable storage, including service worker registrations and caches, after seven days of Safari use without interaction on that site. WebKit's post introducing the rule says web apps added to the Home Screen have their own counter based on actual use of the app, and that it does not expect their first-party data to be deleted.

An installed app has its own storage. web.dev's installation guide says each installation on Apple devices has isolated storage. Plan for a visitor who was signed in on your site in Safari to sign in again inside the installed app.

Because Background Sync is not available, anything queued offline has to be sent while the app is open. Detect the feature and fall back:

// Page script (type="module"). flushOutbox() sends whatever is queued.
const registration = await navigator.serviceWorker.ready;

if ("sync" in registration) {
  await registration.sync.register("send-outbox");
} else {
  // iPhone: retry when the app is open and the connection returns.
  window.addEventListener("online", flushOutbox);
  if (navigator.onLine) flushOutbox();
}

What the gaps rule out

If your product needs	On iPhone as a PWA
Uploads or sync that finish after the app is closed	Not possible. Work completes only while the app is open.
Bluetooth devices, NFC tags or USB hardware	Not possible. This needs a native app.
A one-tap install button	Not possible. The user must use the Share menu.
Notification buttons such as "Reply" or "Mark done"	Not available. A tap can only open the app.
A listing people can find in the App Store	A PWA is not listed there. This needs a native app.
Content, catalogue, booking, ordering, account pages	Works.
Offline reading of pages already visited	Works.
Order and reminder notifications for installed users	Works, from iOS 16.4.

How iPhone support has changed

iOS version	What arrived
11.3	Service workers; `display: standalone` from the manifest
12.2	Web Share
15.4	Manifest icons; navigation preload
16.4	Web Push, Badging API, Add to Home Screen from third-party browsers, manifest `id`, Screen Wake Lock in Safari
17	New storage quotas; Add to Home Screen from in-app Safari views
18.4	Declarative Web Push; Screen Wake Lock inside Home Screen web apps
26	Every site added to the Home Screen opens as a web app by default
27	Service worker static routing API

Support has moved in one direction since 2023, but the missing items in the tables above have stayed missing through several releases. Plan around what exists today.

PWA or native app for iPhone users

Start with how many of your users this affects. Statcounter puts iOS at 6.05% of mobile web usage in India in September 2026, against 93.89% for Android. For a product aimed at the Indian mass market, the iPhone gaps touch a small share of users. For a premium, urban or export audience the share can be far higher, so check your own analytics before deciding.

A PWA is usually enough on iPhone when the product is content, commerce, booking or an internal tool, and when notifications are useful but not critical. WavX builds these under PWA development.

A native app is the better choice when the product depends on background work, hardware over Bluetooth or NFC, App Store discovery, or notifications that must reach every user and not only those who installed from the Share menu. That is mobile app development, and it costs more to build and maintain.

Many products do both in sequence: a PWA first, a native app later if usage justifies it. The broader comparison is in PWA vs native app and website vs app vs PWA. If you already have a site, turning it into a PWA is the smaller first step. The full set of PWA guides is on the PWA development hub.

Check it on your own devices

Documentation and behaviour can differ, and iOS changes several times a year. Before you commit to a plan, run these on a real iPhone and write down the iOS version and the date:

Add the site to the Home Screen from Safari and from one other browser. Does it open in its own window with the right name and icon?
Turn on aeroplane mode and open it. Does the offline page or cached content appear?
Subscribe to push from inside the installed app, lock the phone and send a test message.
Set and clear the icon badge.
Sign in, close the app, wait a week and open it again. Are you still signed in?
Repeat on the oldest iOS version you intend to support.

Sources

WebKit: Web Push for Web Apps on iOS and iPadOS, read 2 October 2026
WebKit: WebKit Features in Safari 16.4, read 2 October 2026
WebKit: WebKit Features in Safari 17.0, read 2 October 2026
WebKit: Updates to Storage Policy, read 2 October 2026
WebKit: Full Third-Party Cookie Blocking and More, read 2 October 2026
WebKit: Meet Declarative Web Push, read 2 October 2026
WebKit: WebKit Features in Safari 18.4, read 2 October 2026
WebKit: News from WWDC25, WebKit in Safari 26 beta, read 2 October 2026
WebKit: WebKit Features in Safari 26.0, read 2 October 2026
WebKit: WebKit Features for Safari 27.0, read 2 October 2026
Apple Developer Documentation: Sending web push notifications in web apps and browsers, read 2 October 2026
MDN browser-compat-data, the data behind MDN's compatibility tables, read 2 October 2026
MDN: Making PWAs installable, read 2 October 2026
MDN: Window beforeinstallprompt event, read 2 October 2026
MDN: Offline and background operation, read 2 October 2026
web.dev: Learn PWA, Installation, read 2 October 2026
Statcounter Global Stats: Mobile Operating System Market Share in India, read 2 October 2026

How AI answer engines choose what to cite: the evidence, graded

WAVX solutions — Sat, 03 Oct 2026 17:32:16 +0000

AI answer engines search first and write second. ChatGPT, Google's AI Overviews and AI Mode, Perplexity, Copilot and Claude each run one or more searches, read the pages that come back, and write an answer that links to some of them. So the first condition is plain: the engine's search crawler must be able to fetch your page. Beyond that, no vendor publishes its selection rules, and the published research supports far fewer conclusions than most articles on this subject claim. This review lists each common claim, the source behind it, the date, and how strong the evidence is.

How the evidence is graded

Not all evidence is equal. A vendor's documentation tells you its rules but not its ranking. A correlation across thousands of sites tells you what cited pages have in common but not what caused the citation. Each claim below carries one of five grades.

Grade	What it means	What it can support
Controlled experiment	One thing was changed and the result compared with an unchanged baseline	A causal claim, within the conditions tested
Matched-control study	Pages that changed are compared with similar pages that did not, on live engines	A causal claim with caveats
Large observational dataset	Many pages or prompts were measured, with no intervention	A pattern or correlation, not a cause
Vendor documentation	The company that runs the engine states how its product works	The rules for eligibility. Says little about ranking
Small sample or anecdote	A few prompts, one site, or a report from a third party	A reason to test, nothing more

Most of the independent research comes from companies that sell search and AI visibility software: Ahrefs, Semrush and Profound. Their datasets are large and their methods are published, but they are not neutral parties. That is noted here once and applies throughout.

What the engines themselves document

Every engine documents how a page becomes eligible. None documents how it picks between eligible pages.

Engine	What its own documentation states	Source and date
Google AI Overviews and AI Mode	A page must be indexed and eligible to be shown with a snippet. There are "no additional requirements" and no special optimisation. Both features may use "query fan-out", issuing several related searches. Responses are grounded in pages retrieved by Google's core ranking systems	Google Search Central, AI features page (last updated 10 December 2025) and generative AI optimisation guide (last updated 10 July 2026)
ChatGPT search	OAI-SearchBot is the crawler used to surface sites in ChatGPT search. Sites that opt out of it "will not be shown in ChatGPT search answers", though they may still appear as navigational links. A robots.txt change takes about 24 hours to apply	OpenAI crawler documentation, read 2 October 2026
Claude	Claude-SearchBot indexes content for search, and Claude-User fetches pages when a user asks. Blocking either "may reduce your site's visibility" in user search results	Anthropic help centre, read 2 October 2026
Perplexity	PerplexityBot is "designed to surface and link websites in search results on Perplexity" and should be allowed in robots.txt for a site to appear. Perplexity-User fetches pages on a user's request and generally ignores robots.txt	Perplexity documentation, read 2 October 2026
Copilot and Bing	Copilot breaks pages into smaller pieces and assembles answers from several sources. Crawlability, metadata, internal linking and backlinks "remain essential". Microsoft adds that no practice ensures selection	Microsoft Advertising blog, 8 October 2025

Grade for all of the above: vendor documentation. It is reliable on eligibility and should be treated as the starting checklist. The crawler names and what each one does are collected in the AI crawler directory.

One more vendor fact matters. Since 2026 Google has offered a Search Console setting, the Search generative AI control, that includes or excludes a site from AI Overviews and AI Mode. Inclusion is the default. A site that has been excluded there cannot appear, whatever else it does.

The claims, graded

Claim	Evidence	Source and date	Grade
The engine's search crawler must be able to fetch the page	Stated by every vendor	Google, OpenAI, Anthropic, Perplexity documentation	Vendor documentation. Treat as a requirement
Pages cited in AI Overviews usually rank in Google's top 10	76% of cited pages ranked in the top 10 in July 2025. An updated study found about 38% in March 2026	Ahrefs, 21 July 2025 and 2 March 2026	Large observational dataset. The overlap is real and has fallen
ChatGPT, Gemini and Copilot cite what Google ranks	Across 15,000 prompts, about 12% of cited links were in Google's top 10 for the same prompt. Perplexity was the exception at 28.6%	Ahrefs, 11 August 2025	Large observational dataset
Brands mentioned on other sites are mentioned more in AI Overviews	Across 75,000 brands, branded web mentions had the strongest correlation with AI Overview mentions (0.664)	Ahrefs, 26 May 2025	Large observational dataset. Correlation only
Adding statistics, quotations and cited sources raises visibility	30 to 40% relative improvement on one visibility measure, in a simulated engine	Aggarwal and others, KDD 2024 (arXiv 2311.09735)	Controlled experiment, not run on today's engines
"Best X" list articles are what ChatGPT cites for recommendations	Across 750 prompts, such lists were 43.8% of cited page types	Ahrefs, 4 December 2025	Observational, with manual categorisation
Each engine prefers different sources, and the mix shifts	Reddit and Wikipedia shares differ by engine and moved sharply within weeks	Profound, June 2025; Semrush, 10 November 2025	Large observational datasets
Schema markup gets pages cited	No meaningful uplift after 1,885 pages added JSON-LD, against 4,000 controls	Ahrefs, 11 May 2026	Matched-control study. The best evidence on this question
An llms.txt file gets pages cited	97% of published files received no requests in a month. Google states Search ignores the file	Ahrefs, 15 June 2026; Google, 10 July 2026	Large log study plus vendor documentation
An AI "ranking" can be tracked like a search ranking	The same prompt almost never returned the same list of brands twice	SparkToro and Gumshoe, 27 January 2026	Crowd experiment, not peer reviewed

The sections below explain what each of these does and does not show.

Retrieval comes before everything

Google describes its AI features as retrieval-augmented generation: its systems retrieve pages from the Search index using the core ranking systems, then generate a response from them, with links. It also describes query fan-out, where the model issues a set of related queries to gather more results. OpenAI, Anthropic and Perplexity describe separate crawlers for search and for user-requested fetches.

Two practical consequences follow, and both are well supported.

First, a page that a search crawler cannot fetch cannot be cited from search. Check robots.txt, any firewall or bot-protection rule, and whether the content is present in the HTML the server returns. Microsoft's guidance makes a related point: content hidden in tabs or expandable menus may not be rendered and can be skipped.

Second, the page competes on several queries, not one. Fan-out means the engine may retrieve your page for a sub-question the user never typed. Google's guide warns against reacting to this by publishing a page for every variation: doing so mainly to influence rankings or AI responses falls under its scaled content abuse policy.

How much does ranking in search matter?

Less than it did, and it depends on the engine.

For Google AI Overviews, Ahrefs looked at 1.9 million citations from 1 million AI Overviews in July 2025 and found 76.1% of cited pages ranking in the top 10 for the same query. It repeated the exercise on 863,000 keyword results pages and 4 million cited URLs, published on 2 March 2026. This time 37.9% of cited URLs were in the first ten results, 31.2% were in positions 11 to 100, and 31.0% were beyond 100. Ahrefs attributes the drop to greater reliance on fan-out queries. The two studies did not use identical methods (the first looked only at the three most visible citations), so the size of the fall should be read with care. The direction is consistent with Google's own description of fan-out.

For the assistants, the August 2025 Ahrefs study of 15,000 prompts found that on average 12% of links cited by ChatGPT, Gemini and Copilot appeared in Google's top 10 for the same prompt, and about 80% did not rank in Google for that prompt at all. Perplexity overlapped most, at 28.6%.

What this supports: ranking well in Google is still associated with being cited in AI Overviews, and it is a weak predictor for the assistants. What it does not support: the idea that search ranking no longer matters. The assistants still retrieve from search indexes, but for queries they write themselves.

Brand mentions: the strongest correlation, and only a correlation

Ahrefs' May 2025 study of 75,000 brands used Spearman correlation to compare several factors with how often a brand was mentioned in AI Overviews. Branded web mentions came first at 0.664, then branded anchor text (0.527) and branded search volume (0.392). Domain Rating was 0.326, the number of backlinks 0.218, and the number of pages on the site 0.17. The study also reports that 26% of brands had no AI Overview mentions at all.

The authors state the limit themselves: correlation is not causation. Well-known brands are mentioned more everywhere, including in AI answers. The sample was also restricted to domains with a Domain Rating above 40, so it describes established brands, not new ones.

Google's guide addresses the obvious shortcut. Seeking inauthentic mentions across the web "isn't as helpful as it might seem", because the AI features depend on the same ranking and spam systems as the rest of Search. Google's spam policies, updated on 28 August 2026, now name "attempting to manipulate generative AI responses" as an example of spam.

Statistics, quotations and cited sources: a controlled result with limits

The one controlled experiment in this field is the paper that coined the term generative engine optimisation, published at KDD 2024. The researchers built a benchmark of 10,000 queries and tested nine ways of rewriting a source page. Their engine retrieved the top five Google results for each query and generated an answer with GPT-3.5.

Three methods stood out. Adding citations from credible sources, adding quotations and adding statistics each improved a page's share of the answer by 30 to 40% on a position-adjusted word count measure, and by 15 to 30% on a subjective impression measure. Keyword stuffing did not help. In a smaller check on Perplexity, adding quotations improved the first measure by 22% and keyword stuffing performed 10% worse than the baseline.

One table in the paper deserves more attention than it gets. The gains went mostly to lower-ranked sources. Adding citations raised visibility by 115.1% for the source ranked fifth and lowered it by 30.3% for the source ranked first.

The limits are significant. The pages tested had already been retrieved, so the paper says nothing about getting retrieved in the first place. The main engine was built by the researchers on a model that is now several generations old. The measure is share of words in an answer, not clicks or enquiries. The authors themselves note that methods may need to change as engines evolve. It is fair to say that sourced, specific content was favoured in a controlled setting. It is not fair to quote "40% more visibility" as a result anyone should expect.

List articles and the recommendation question

For prompts that ask which product, tool or agency to use, Ahrefs analysed ChatGPT's responses to 750 prompts and categorised 26,283 source URLs. "Best X" list articles were 43.8% of all page types cited. Of 1,100 such lists with a clear date, 79.1% had been updated in 2025, and 35% of the cited lists sat on low-authority domains, many of which the author describes as questionable.

This is descriptive. It shows what ChatGPT drew on in late 2025 for one kind of prompt. The author does not claim that publishing a list causes recommendations, and notes that many recommendations come from multi-step conversations the study did not cover. A business reading this should also weigh Google's spam policy before publishing a list that ranks itself first.

Each engine cites differently, and the mix moves

Profound analysed 680 million citations between August 2024 and June 2025. Wikipedia was ChatGPT's most cited source at 7.8% of its citations. Reddit led on Perplexity at 6.6% and on Google AI Overviews at 2.2%.

Semrush tracked more than 230,000 prompts weekly from 14 July to 12 October 2025 across ChatGPT search, AI Mode and Perplexity. ChatGPT cited Reddit in close to 60% of responses in early August and around 10% by mid-September. Wikipedia fell from roughly 55% to under 20% over the same period, while both stayed steady on the other two engines.

The lesson is about stability, not about Reddit. A tactic built on one engine's current habits can stop working in a month, for reasons no outsider can see.

Widely repeated claims the evidence does not support

"Add an llms.txt file and AI tools will cite you." Google's guide says Search ignores the file and that it will "neither harm nor help". Ahrefs' log study of 137,210 domains found that 97% of published files were not requested once in May 2026, and that search-retrieval bots made up 1.1% of the requests that did occur. Details are in what llms.txt does and does not do.

"Schema markup makes AI cite your page." Ahrefs found that cited pages are far more likely to carry schema, then tested whether adding it changes anything. Across 1,885 pages and 4,000 matched controls, citations moved by +2.4% on AI Mode and +2.2% on ChatGPT, both indistinguishable from zero, and by -4.6% on AI Overviews. The study covered pages that were already heavily cited, so it does not rule out an effect on pages that are not yet seen at all. Google says structured data is not required for its AI features. Microsoft says schema helps its systems understand content. Keep schema for rich results. Do not buy it as an AI citation tactic.

"Content must be split into small chunks for AI." Google lists this as something site owners can ignore. Microsoft recommends clear headings, lists and tables. These are compatible: organise pages for readers. No independent test shows that chunking beyond that changes citations.

"More pages means more AI visibility." Page count had the weakest correlation of any factor in the Ahrefs brand study (0.17), and Google's guide says a high quantity of pages does not make a site more relevant.

"You must rank first on Google to be cited." The overlap figures above contradict this for every engine measured.

"We can track your position in ChatGPT." In the SparkToro and Gumshoe experiment, 600 volunteers ran 12 prompts 2,961 times across ChatGPT, Claude and Google's AI features. The chance of getting the same list of brands twice in 100 runs was under 1 in 100. The same data showed something more useful: how often a brand appears across many runs is fairly stable. One agency appeared in 85 of 95 responses to a single prompt. Appearance rate over repeated runs is a defensible measure. A position from a single run is not.

"This method gets you cited." No vendor offers that, and no study shows it. Google states that meeting every requirement does not mean a page will be crawled, indexed or served.

What a small business can reasonably do

In order of how well each step is supported:

Confirm that the search crawlers can reach your pages and that the content is in the server's HTML. This is the only step every vendor documents. An AI visibility audit starts here.
Check that the site is included in Google's Search generative AI control and is indexed with snippets allowed.
Publish pages that state specific, dated, sourced facts a model can lift. The controlled evidence, with its limits, points this way, and so does Google's advice on non-commodity content. This is the work described under answer engine optimisation.
Earn real mentions: directory listings, reviews, partner pages, press. It is the strongest correlate and the slowest to build.
Measure with the tools the engines provide and with repeated prompt runs, not single screenshots. See how to measure AI referral traffic in GA4.

If the immediate problem is that an assistant does not name your business, the checks are in why ChatGPT does not mention your business. WavX's wider offer is described under generative engine optimisation.

When this is not worth paying for

If your site has little search visibility and few mentions elsewhere, the evidence says the gap is in ordinary SEO and reputation, not in an AI-specific tactic. Google's guide says as much: optimising for its AI features is still SEO. A business that gets most of its work through referrals or marketplaces may see no return from any of this. And a tracking subscription makes little sense before the basic crawler and indexing checks have been done, which cost nothing.

Limits of this review

It covers published sources read on 2 October 2026. Engines change faster than studies are published. Two of the findings above reversed or shifted within a year.
Most independent data comes from companies with products to sell in this area.
None of the studies was designed around Indian queries or Indian businesses.
Several findings concern Google AI Overviews only and should not be generalised to ChatGPT or Perplexity.
No study measures enquiries or revenue. They measure citations and mentions.

Sources

Google Search Central: AI features and your website, read 2 October 2026
Google Search Central: Optimizing your website for generative AI features on Google Search, read 2 October 2026
Google Search Central: Spam policies for Google web search, read 2 October 2026
Google Search Console Help: Search generative AI control, read 2 October 2026
OpenAI: Overview of OpenAI crawlers, read 2 October 2026
Anthropic: Does Anthropic crawl data from the web, and how can site owners block the crawler?, read 2 October 2026
Perplexity: Perplexity crawlers, read 2 October 2026
Microsoft Advertising: Optimizing your content for inclusion in AI search answers (8 October 2025), read 2 October 2026
Ahrefs: An analysis of AI Overview brand visibility factors, 75K brands (26 May 2025), read 2 October 2026
Ahrefs: 76% of AI Overview citations pull from the top 10 (21 July 2025), read 2 October 2026
Ahrefs: Update, 38% of AI Overview citations pull from the top 10 (2 March 2026), read 2 October 2026
Ahrefs: Only 12% of AI cited URLs rank in Google's top 10 for the original prompt (11 August 2025), read 2 October 2026
Ahrefs: Do self-promotional "best" lists boost ChatGPT visibility? (4 December 2025), read 2 October 2026
Ahrefs: We tracked 1,885 pages adding schema. AI citations barely moved (11 May 2026), read 2 October 2026
Ahrefs: We analyzed 137K sites: 97% of llms.txt files never get read (15 June 2026), read 2 October 2026
Aggarwal and others: GEO: Generative Engine Optimization, KDD 2024 (arXiv 2311.09735), read 2 October 2026
Semrush: The most-cited domains in AI, a 3-month study (10 November 2025), read 2 October 2026
Profound: AI platform citation patterns (5 June 2025, updated August 2025), read 2 October 2026
SparkToro: AIs are highly inconsistent when recommending brands or products (27 January 2026), read 2 October 2026 from the Internet Archive copy dated 1 October 2026

Custom Shopify Theme Development Cost in India (2026)

WAVX solutions — Sat, 03 Oct 2026 05:27:34 +0000

A custom Shopify theme, designed for one brand and coded in Liquid, falls inside the ₹1,50,000 to ₹4,50,000 planning range WavX already publishes for a custom-designed Shopify store. Buying a ready theme is far cheaper: on 2 October 2026 the Shopify Theme Store listed paid themes from US$100 to US$500 as a one-time purchase, and 24 themes free. For most new stores the bought theme is the right first choice. A custom theme earns its cost when the brand, the product page or the buying flow needs something no listed theme does.

The three routes and what each costs

There are three ways to get a storefront on Shopify, and they differ by an order of magnitude.

Route	What you pay for the theme	What you pay a developer	Source of the figure
Free theme, configured	Nothing. 24 free themes listed	₹25,000 to ₹75,000 for a basic template setup of the whole store	Shopify Theme Store, 2 October 2026; WavX store setup guide
Paid theme, adjusted	US$100 to US$500, once, for one store	₹15,000 to ₹40,000 to adjust an off-the-shelf theme	Shopify Theme Store, 2 October 2026; WavX store setup guide
Custom theme	Nothing to Shopify	₹1,50,000 to ₹4,50,000 for a custom-designed store, of which design and theme development are the largest part	WavX store setup guide

The rupee figures are planning ranges that WavX has already published in its Shopify store setup cost guide. They are quoted from that page so the two agree. WavX's cost model has no separate theme line items, so no new rate is introduced here, and a firm figure is quoted after scoping.

Theme Store prices are in US dollars. At a round ₹100 to the dollar, which is a convenience for arithmetic and not a quoted exchange rate, US$100 to US$500 is about ₹10,000 to ₹50,000. Your card's rate on the day applies.

What the Shopify Theme Store charges and what you get

These are the facts as read on Shopify's own pages on 2 October 2026.

Paid themes. 1,275 paid themes were listed. Sorted by price, the cheapest were US$100 and the most expensive US$500.
Free themes. 24 free themes were listed, including Dawn, Horizon, Refresh, Craft and Sense.
Who makes them. Shopify's help centre says free themes are developed by Shopify, and paid themes come from third-party developers.
Who supports them. Help with customising a free theme is supported by Shopify. For a paid theme, general support and updates come from the theme's developer.
Trying before buying. You can preview up to 19 paid themes at a time, customise a previewed theme in the theme editor, and keep those customisations if you buy it.
Licence. A theme bought from the Theme Store is licensed exclusively to the store where the purchase was made.
Updates. Shopify applies automated updates to Theme Store themes for bugs and security issues. A new theme version can be added as a draft and tested before it is published. If the theme's code has been edited, the update either includes the edits or reports that they could not be included, and Shopify advises saving a copy of customised code before updating.

The last point is the hidden cost of a heavily edited paid theme. Every code edit is something that may have to be reapplied by hand when the theme's developer ships a new version. A theme changed only through its settings has no code edits to carry over. A theme with a rewritten product page does.

What a custom theme build includes

A Shopify theme is a folder of files with a fixed structure. Shopify's theme architecture documentation lists the directories: layout, templates, sections, blocks, snippets, assets, config and locales. Templates decide what each type of page shows. Sections and blocks are the pieces a merchant can add, remove and reorder in the theme editor. The code is Liquid, JSON, CSS and JavaScript.

A custom theme means writing those files for one store instead of buying them. In practice the work is:

Wireframes for each unique page: home, collection, product, cart, and any landing or content pages.
Visual design in Figma, for mobile first and then desktop.
Theme development: sections and blocks for every design element, with settings so the team can edit content without a developer.
Product page logic: variants, size guides, bundles, delivery estimates, whatever the catalogue needs.
App blocks: space in the templates for the apps the store uses, such as reviews. Shopify's theme app extensions work with Online Store 2.0 themes, so a custom theme has to support them properly.
Testing on real phones and browsers, then launch.

This is the work described on WavX's Shopify theme development page.

Where the money goes

The store setup guide breaks a ₹3,50,000 mid-tier Shopify build into eight steps. Four of them are the theme.

Step in the published example	Cost	Duration	Part of the theme?
Discovery and wireframing	₹25,000	1 week	Yes
UI/UX design	₹60,000	2 weeks	Yes
Theme development and Liquid customisation	₹1,20,000	3 weeks	Yes
App integration and configuration	₹40,000	1 week	No
Payment and logistics integration	₹20,000	0.5 week	No
Data migration and catalogue setup	₹35,000	1 week	No
UAT and bug fixing	₹35,000	1 week	Yes, mostly
Deployment and go-live	₹15,000	0.5 week	No
Total	₹3,50,000	10 weeks

The theme-related lines come to ₹2,40,000 over about 7 weeks. That is one worked example for a mid-sized store, and it should be read as a guide to proportions: in this example design, theme code and testing are about two-thirds of the build, and the rest is setup that a bought theme needs too.

The same guide gives ₹50,000 to ₹2,00,000 for custom design on its own. The ecommerce website cost guide lists a Shopify custom theme or Plus build at ₹1,50,000 to ₹5,00,000 and above. That row also covers Plus builds, which is why its upper end is higher.

What makes a theme build cost more

The planning range is wide because themes differ in size. These decide where in the range a project lands.

Number of unique templates. A store with one product template and one collection template is small. A store where gift sets, made-to-order items and subscriptions each need their own product page has three product pages to design, build and test.
Sections the team can edit. Every section with settings takes longer to build than a fixed block of HTML, and saves a developer call each time the content changes. More editable sections means more build cost and lower running cost.
Product page logic. Variant pickers with swatches, size charts per category, pin-code delivery estimates, bundles and personalisation fields are each a piece of work.
Motion and media. Video backgrounds, scroll effects and 3D viewers cost time to build and time to keep fast.
Languages and markets. Each language needs translated strings in the theme's locale files and a design that survives longer text.
Content readiness. A design built around real photography and real copy is finished once. A design built around placeholders is usually adjusted again when the real content arrives.
Moving from another platform. URL redirects, imported content and old page designs to match all add work that has nothing to do with the theme's code.

Paid theme or custom theme

Question	A paid theme is enough when	A custom theme is worth pricing when
Brand	The brand can live inside a good theme's layout with its own colours, type and photography	The layout itself is part of the brand, and no listed theme comes close
Product page	Products are simple: a few variants, standard images, a description	The product needs configuration, bundles, fitting guidance or content that standard templates cannot hold
Team	Nobody on the team will edit code	You have, or will pay for, someone to maintain the code
Stage	The store is new and the offer is still being tested	The store has steady sales and you know from data which pages lose buyers
Budget	The build budget is under about ₹1,50,000	The budget covers the build and yearly maintenance
Apps	The apps you need provide blocks that fit the theme	Apps need to sit inside a custom layout
Speed	The theme you chose performs well in Shopify's data	A measured problem remains after apps and media have been cleaned up

A middle route exists and is often the best value: buy a paid theme whose structure is close, and pay for a small number of custom sections built as additions and kept separate from the theme's own files. Additions kept in their own section files are much easier to carry through a theme update than edits to the theme's own files, and the bill is usually closer to the ₹15,000 to ₹40,000 adjustment band than to a custom build. This works when the changes are additions. It stops working when the request is to rebuild the theme's product page or cart.

A custom theme is not automatically faster

Speed is the most common reason given for going custom, so it is worth checking against public data.

Shopify publishes aggregated Core Web Vitals results by theme. The table, last updated on 29 September 2026, covers 127 themes and reports the share of stores on each theme where at least 75% of visitors had a good experience on all three measures. It counts active stores on a custom domain with at least 100 daily events, on one of the theme's three latest versions, over the previous seven days.

Theme	Stores passing all three Core Web Vitals
Dawn (free)	89.1%
Horizon (free)	87.1%
Refresh (free)	86.7%
Craft (free)	93.4%
Impulse (paid, US$500)	92.5%
Highest theme in the table	97.5%
Lowest theme in the table	37.2%

Two conclusions follow. First, a well-chosen bought theme already performs well on most stores that use it, including the free ones. Second, the spread between themes is large, so checking this table before buying a theme is worth ten minutes.

What usually slows a Shopify store is what gets added afterwards. Shopify's help centre lists theme code, apps, images, videos, carousels, social media feeds and analytics as things that affect performance. A custom theme can help because it carries only the features the store uses. It cannot fix twelve app scripts and uncompressed images. If the store is slow today, read why a Shopify store is slow and look at speed optimisation before commissioning a new theme. No developer can promise a score before the store is built and carrying real content.

Costs after the build

A bought theme is maintained by its developer. A custom theme is maintained by you.

Platform changes. Shopify keeps adding to the theme platform. A custom theme only gains new platform features when someone builds them in.
New pages and campaigns. If the theme was built with editable sections, most campaign pages need no developer. If not, each one is a small project.
App changes. Adding or removing an app can need template changes.
Fixes. Browsers and devices change, and a theme needs occasional repair.

WavX publishes 15% to 25% of build cost per year as its maintenance band for software it builds, explained in the app maintenance cost guide. Applied to the ₹1,50,000 to ₹4,50,000 range, that is ₹22,500 to ₹1,12,500 a year. A theme with little custom logic sits at the low end.

Over three years, with maintenance in years two and three, the model gives ₹1,95,000 to ₹6,75,000 for a custom-designed store. The paid-theme route over the same period is the theme price once, the adjustment fee once, and whatever further changes you ask for.

When you should not commission a custom theme

The store has not launched. You do not yet know which pages matter. Launch on a good theme, learn from real orders, and spend on design once the data says where.
The problem is traffic or product, not design. A new theme does not create demand. If few people reach the product page, the theme is not the constraint.
The request is "make it look premium". That is usually photography, typography and copy, all of which work inside a bought theme.
Nobody will maintain it. A custom theme with no owner ages badly. A paid theme keeps receiving its developer's updates.
Headless is being considered for speed. That is a bigger decision with a higher bill, covered in when headless Shopify is worth it.

What to ask before you pay for a theme build

These questions separate a real custom theme from a bought theme with a new colour scheme, and they apply to any developer, WavX included.

Is this built from a starter theme or from a purchased theme? Either is acceptable, as long as you are told which.
Which sections will the team be able to edit in the theme editor, and which are fixed?
How will apps be placed: through app blocks, or by pasting code into templates?
Where is the code kept, and will it be handed over in a repository you own?
What was tested, on which phones, and what were the Core Web Vitals results on the finished store with real content?
What is included after launch, for how long, and what does a change cost after that?

A developer who answers these plainly is giving you a custom theme you can live with. One who cannot is selling a theme you will be afraid to touch.

Sources

Shopify Theme Store: paid themes sorted by price, low to high, read 2 October 2026
Shopify Theme Store: paid themes sorted by price, high to low, read 2 October 2026
Shopify Theme Store: free themes, read 2 October 2026
Shopify Help Center: adding themes, licensing, previews and support, read 2 October 2026
Shopify Help Center: updating themes, read 2 October 2026
Shopify developer documentation: theme architecture, read 2 October 2026
Shopify developer documentation: theme app extensions, read 2 October 2026
Shopify: aggregated Core Web Vitals performance by theme, updated 29 September 2026, read 2 October 2026
Shopify Help Center: online store web performance, read 2 October 2026