Distribution decisions for an Indian consumer app are made under constraints that Western product teams rarely face. A large share of your target users hold devices with limited storage that is already close to full, on data plans they are conscious of, and they uninstall applications routinely to make room. That reality should shape the build long before it shapes the marketing.
Install size is the first lever and it is underestimated. Every additional megabyte reduces the proportion of people who complete an install on a slow connection, and a large application is the first thing deleted when storage runs out. Shipping split builds by device architecture rather than one universal binary, moving optional assets to on-demand delivery, auditing what each third-party SDK adds, and removing the ones nobody can name a use for — these routinely halve an application's size and cost nothing in functionality.
Android dominates the market here by a wide margin, which has two consequences. The first is that your engineering effort should follow that distribution rather than being split evenly, and testing needs to happen on mid-range and older devices rather than on the newest flagship in the office. The second is that Android's more open distribution model gives you options iOS does not — a website install for users who cannot or will not use a store, and alternative app stores that reach segments the main store does not.
Weigh those alternatives honestly rather than reflexively. Distributing outside the main store means you own updates, you own the trust problem of asking a user to permit an install from an unfamiliar source, and you lose the discovery the store provides. It suits a business with its own distribution — a lender with a field force, a platform with an existing customer base to notify — and suits a consumer product hoping to be found considerably less.
Whichever route, plan around review times you do not control. Store review can take hours or several days, rejections happen for reasons unconnected to your code, and a policy interpretation can change between releases. The practical defences are the same ones that make any release safer: keep server-controlled feature flags so behaviour can change without a new binary, keep a release ready rather than starting one when something breaks, and never let a campaign date depend on somebody else's queue.
Finally, remember that installation is not adoption. The metric that matters is not installs but the proportion still active after a week and after a month, segmented by device class and by connection quality. Products in this market frequently discover that their retention problem is concentrated entirely in one device tier — and that the fix is a smaller build and a faster first screen rather than anything to do with the product itself.
