1 in 3 of India's most popular apps don't open from links to their own website (2026 data)
We checked the deep link files of 114 of India's most popular apps on their main domains. 38 don't open the app on iOS, Android or both, and for 55 a link without the www can't open the app on Android. What we found, and how to check your own domain.
We checked the deep link set-up of 114 of India's most popular apps, across 17 categories, on 27 October 2026. For 38 of them (1 in 3), a link to the app's main website doesn't open the app on iOS, Android or both. It opens in the browser instead.
That's a finding about each app's main domain (brand.com and www.brand.com). Many apps also use a separate link domain, which we didn't check. The full list of limits is at the end.
The short version
- 1 in 3 miss on at least one platform. 38 of 114 apps don't have working deep link files for iOS, Android or both on their main domain. 22 miss on both.
- The
wwwis the most common Android gap. 66 apps redirectbrand.com/.well-known/...towww.brand.com. Google doesn't follow that redirect, so for 55 apps (48%) a link shared asbrand.com/offercan't open the app on Android. The same link withwww.works. - Works on iPhone, fails on Android. Apple's CDN still had the right file for the bare domain in 53 of those 66 cases. So the team taps the link on an iPhone, it opens the app, and the Android gap goes unnoticed.
| Apps | Share | |
|---|---|---|
| Open the app on both iOS and Android | 76 | 67% |
| Open the app on one platform only | 16 | 14% |
| Open the app on neither | 22 | 19% |
How we checked 114 apps
The apps. 114 popular apps used in India, in 17 categories. We picked them from public rankings (Sensor Tower's India market reports for Q1 and Q2 2026, AppTweak's most-downloaded finance apps in India, and NPCI UPI market share as reported by Outlook Business). For categories those lists don't rank in detail, such as travel, edtech, OTT, news, health, jobs and government, we added the long-standing category leaders. That part is our judgement, not a ranking. We left out global platforms that aren't India-specific (WhatsApp, Instagram, YouTube, Google Pay).
The domain. Each app's own main website domain, for example brand.com. When the bare domain redirected the files to www.brand.com, we checked the www host too and counted the app as working if either host worked. That came to 180 hosts.
The files. Phones decide whether a link opens an app by reading two small files on the link's domain:
- iOS:
https://brand.com/.well-known/apple-app-site-association(the AASA file). iPhones don't fetch it from your site. They read the copy on Apple's CDN,https://app-site-association.cdn-apple.com/a/v1/brand.com. - Android:
https://brand.com/.well-known/assetlinks.json, which Android verifies through Google's Digital Asset Links API.
The tool. The same code that runs our free Universal Link and App Link Validator. For each host it requested only those two files, Apple's CDN copy and Google's API answer. No redirects followed, a 5-second timeout, one domain at a time with a pause in between. No logins, no app pages.
What "works" means. We used what phones rely on:
- iOS works: Apple's CDN has a valid file that lists at least one app for Universal Links.
- Android works: Google's Digital Asset Links API returns at least one statement that lets the app handle the domain's links.
If you want the background on these files first, our guide to setting up both files explains them.
How many of India's top apps have working deep links?
| Platform | Links open the app | Share of 114 |
|---|---|---|
| iOS | 81 | 71% |
| Android | 87 | 76% |
| Both | 76 | 67% |
| At least one platform misses | 38 | 33% |
| Both platforms miss | 22 | 19% |
16 apps work on one platform only: 11 on Android only and 5 on iOS only. Android-first, iOS-later is the more common pattern. Often the Android file is in place and verified while the AASA URL returns a plain 404.
We also ran every file through the validator's strict checks: no errors for either file, on the domain or its www. 57 apps (50%) pass. Most apps that open from links but fail the strict checks do so because their server blocked or timed out our checker while Apple and Google could still read the file (more on that below).
Which categories get deep links right?
| Category | Apps | iOS works | Android works | Both |
|---|---|---|---|---|
| Food & quick commerce | 9 | 9 | 8 | 8 (89%) |
| OTT & audio | 12 | 12 | 10 | 10 (83%) |
| Travel | 12 | 11 | 10 | 10 (83%) |
| Health | 6 | 5 | 6 | 5 (83%) |
| Shopping | 14 | 10 | 11 | 10 (71%) |
| News | 7 | 5 | 6 | 5 (71%) |
| Social & community | 7 | 5 | 6 | 4 (57%) |
| Fintech / UPI | 9 | 5 | 6 | 5 (56%) |
| Edtech | 9 | 4 | 6 | 4 (44%) |
| Investing | 7 | 3 | 4 | 3 (43%) |
| Banking | 5 | 0 | 0 | 0 |
| Six smaller categories* | 17 | 12 | 14 | 12 |
* Jobs, services & classifieds, government, sports & gaming, mobility and telecom, each with 4 apps or fewer: too few for percentages. All 9 apps in jobs, services & classifieds and government open from links on both platforms.
Apps whose growth depends on shared links do best: food delivery and quick commerce, OTT and travel. None of the 5 banking apps publishes working files on its main domain. That is likely a deliberate choice, since banks have good reasons not to open the app from web links that a phishing page could imitate. Edtech and investing are the most mixed.
The #1 mistake: www and the bare domain
Most websites send brand.com to www.brand.com with a 301 redirect. For web pages that's sensible. For the two deep link files it splits the platforms:
| Request | What happens |
|---|---|
brand.com/.well-known/assetlinks.json |
301 to www.brand.com/.... Google's API answers: "Redirect encountered while fetching statements ... redirects are disallowed for security reasons". Android doesn't verify brand.com. |
www.brand.com/.well-known/assetlinks.json |
200 with the file. Android verifies www.brand.com. |
brand.com on iPhone |
Apple's CDN usually still has a good copy for brand.com, so the link opens the app. |
In numbers: 66 of 114 apps (58%) redirect the files on the bare domain. For 55 of them (48% of all 114), Android verifies www but rejects the bare domain. Apple's CDN still had the right file for the bare domain in 53 of the 66 (80%).
A typical case: a leading e-commerce app serves both files correctly on www.brand.com, but brand.com/.well-known/assetlinks.json returns a 301. On an iPhone, brand.com/sale opens the app. On Android it opens Chrome. This pattern shows up in every category we checked.
Why it matters in India: links travel by WhatsApp forward, SMS and push, and people shorten and retype them. The www is the first thing to go.
Apple's documentation asks for the file with no redirects, so don't rely on the CDN's tolerance either. The fix is on the server: exempt /.well-known/ from the redirect so both hosts answer with a 200, and list both hosts in the app. The step-by-step version, with server config, is in our guide to fixing Android App Links that don't verify.
Other mistakes we found
These break links too, but each affects fewer apps:
| Problem | Apps | What breaks |
|---|---|---|
Bare domain redirects the files to www |
55 | Android, for links without www |
| No AASA file (404) | 12 | iOS |
| No assetlinks.json (404) | 8 | Android |
| A web page (HTML) served instead of the file | 3 | iOS or Android for 2 of them; for the third, Apple's CDN still has a copy |
AASA has no applinks section |
2 | iOS, on that domain |
| assetlinks.json present, but Google reads no statements | 2 | Android |
| Invalid JSON | 1 | iOS |
| AASA in the obsolete iOS 9 format | 1 | iOS |
| File on the site, but Apple's CDN has nothing | 1 | iOS |
Some examples, without names:
- The file is a web page. A large edtech platform answers both AASA locations with its own website, over 128 KB of HTML. Apple sees a page, not a file, and its CDN has nothing for the domain. This often happens when a single-page app's catch-all route answers every unknown URL with a 200.
- One trailing comma. One app's AASA has a comma after the last path. JSON doesn't allow it, Apple's CDN stored the broken copy, and Universal Links are off for the whole domain. The Android file next to it is fine.
- A format iOS stopped reading. One app still uses the original iOS 9 layout, with
detailsas an object keyed by app ID instead of an array. Current iOS versions don't read it. - Android done, iOS not yet. A top investing app's assetlinks.json verifies with Google, but its AASA URL returns a 404. The same link opens the app on Android and Safari on iPhone.
If your links open the browser on iPhone, our iOS Universal Links checklist goes through each of these in order.
What doesn't matter as much as you'd think
Some details look wrong in a validator but didn't stop any app from working:
| Detail | How common | Effect we saw |
|---|---|---|
AASA served with a content type other than application/json |
28 of 62 valid files (45%) | None: Apple's CDN read them |
AASA in the older paths format instead of iOS 13+ components |
60 of 82 files (73%) | None |
AASA only at the legacy root path, not /.well-known/ |
10 apps | None: Apple still reads the root path |
Paytm serves its AASA as binary/octet-stream, CRED, super.money, Pocket FM and Chingari as application/octet-stream, and all of them open the app on iPhone. Groww, Kuku FM and UMANG all use the paths format, and their links work. PharmEasy, ShareChat and Unacademy serve the AASA from the root path, and Apple reads it there.
Use application/json and /.well-known/ on a new set-up anyway; it's the safe default. But if your links are broken, these aren't the first things to chase.
One more pattern that doesn't break links today: for 19 apps (17%), the server blocked or timed out our checker while Apple and Google could read the file. Users aren't affected. Developers are: curl and validators see a 403, and debugging gets confusing. If that protection ever starts blocking Apple's or Google's crawler, links break with no warning.
What it costs: links that open the browser
When a Universal Link or App Link isn't verified, the phone opens the link in a browser: Safari, Chrome, or the in-app browser of WhatsApp or Instagram. The user lands on the mobile website, often logged out, and the offer, referral or screen the link promised is lost.
On Android the rule got stricter with Android 12. Google's behaviour changes page says a web link resolves to an app "only if your app is approved for the specific domain contained in that web intent. If your app isn't approved for the domain, the web intent resolves to the user's default browser app instead."
That's why a missing www matters. A WhatsApp forward of brand.com/offer that opens the browser costs the same as no deep link at all. In-app browsers add their own problems; we cover those in deep links in Instagram and Facebook's in-app browser.
Check your own domain in 30 seconds
Paste your domain into the free Universal Link and App Link Validator. No sign-up. It fetches both files the way Apple and Google do, shows Apple's CDN copy and Google's answer, and tells you what to fix.
Check both hosts, because they're verified separately:
yourapp.comwww.yourapp.com
If one says "redirects" and the other passes, you have the gap 55 of these apps have. Every result has a shareable link: here's what a clean result looks like for umang.gov.in.
After a fix, test on real devices too. Our guide to testing deep links on Android and iOS has the adb and simulator commands.
The apps that get it right
Ten apps serve both files directly on the domain their links use, with a 200, as application/json, and both Apple and Google read them:
| App | Category | Domain |
|---|---|---|
| Groww | Investing | groww.in |
| Namma Yatri | Mobility | nammayatri.in |
| Kuku FM | OTT & audio | kukufm.com |
| Moj | Social & community | mojapp.in |
| Pratilipi | Social & community | pratilipi.com |
| apna | Jobs | apna.co |
| Internshala | Jobs | internshala.com |
| Dailyhunt | News | dailyhunt.in |
| Inshorts | News | inshorts.com |
| UMANG | Government | umang.gov.in |
None of them does anything unusual. The files live on the domain people share, there's no redirect in front of them, and the content is plain JSON. A government app, UMANG, has one of the cleanest set-ups in the list.
Run one of the apps in this study? Email support@codeonair.com and we'll share what we found for your domain.
Limits of this study
- Main domain only. Many apps send links from a separate domain, such as
go.brand.com,dl.brand.comor a link service's domain. An app with nothing on its main domain may have working links elsewhere, or may not use web links on purpose. The finding is "links to the main website don't open the app", not "the app has no deep links". - App side not checked. We didn't look at entitlements, intent filters or
autoVerify. That needs the app binary. An app can have perfect files and still not claim the domain. - One run, from one network. One check from a network in India on 27 October 2026. When our checker got a 403 or a timeout but Apple or Google could read the file, we didn't count it as broken.
- Apple's CDN timing. Apple refreshes its CDN copy on its own schedule, so it can lag the live file by a day or more.
- A curated sample. The 114 apps are popular, not a random sample, and the category picks are partly our judgement.
Things change after every web deploy. The validator always shows the current state of a domain.
FAQ
Why does my link open in Chrome instead of my app?
Android couldn't verify the link's domain for your app. Since Android 12, an unverified link opens in the default browser. The most common cause in our data is a redirect on /.well-known/assetlinks.json, usually bare domain to www. Check the exact host in the link with the validator, then follow the Android App Links guide.
Does Apple follow redirects for the AASA file?
Apple's documentation asks you to serve the file with no redirects. In our check, Apple's CDN still had the right file for the bare domain in 53 of 66 apps that redirect it, but don't rely on that: serve the file directly on every host with a 200.
Do I need both the www and the bare domain?
Yes, if links use both. Each host is verified on its own. Both brand.com and www.brand.com must serve both files with a 200, and the app must list both: two applinks: entries in Associated Domains on iOS, and both hosts in the intent filter on Android. The files' contents can be identical.
Does the AASA file need the application/json content type?
In our check it didn't matter: Apple's CDN read files served as application/octet-stream, binary/octet-stream, text/plain and with no content type at all. Use application/json anyway; it's the safe choice and it keeps validators quiet.
How long does Apple's CDN take to update?
Apple doesn't publish a schedule; a change can take a day or more to show. Devices read the CDN copy, not your site, so a fix isn't live on iPhones until the CDN has it. The validator shows Apple's CDN copy next to your live file, so you can see whether it has caught up. For development, Apple's associated domains entitlement has a developer mode that reads your server directly.
Can a separate link domain like go.brand.com fix this?
Yes. A subdomain used only for links has no website redirects in front of it, so the files are easier to keep right. You still need both files on it and the domain listed in the app. That's how CodeOnAir AppLinks works: each app gets a link domain with both files generated and served for you.
Check your domain free with the Universal Link and App Link Validator: both files, Apple's CDN and Google's API, no sign-up.
Or let CodeOnAir host your links with both files served correctly. Sign up free: the Free plan includes 100 app links on yourapp.codeonair.com, no card.
Data: CodeOnAir check of 114 apps' main domains (180 hosts), 27 October 2026. Android 12 quote from developer.android.com, checked the same day.