What publishing an app from India actually takes in 2026
Budget four to eight weeks between the build being finished and the app being live on both stores, and expect most of that window to go on paperwork rather than code. Account verification, privacy declarations and the first round of rejections are what move launch dates; the engineering is usually the part that finishes on time.
You are dealing with two different systems. Google Play leans on automated checks plus human policy review on anything flagged; Apple puts a human reviewer on a real device with your app in front of them. Both have to say yes, and a rejection on either side restarts that store’s clock.
One caution first. Developer account fees, review turnaround times and policy compliance deadlines all change, sometimes more than once a year, and they differ by country and account type. Do not plan a launch from a number in a blog post, including this one. Read the current requirements on the Google Play developer policy pages and the Apple App Store Review Guidelines. If you are still costing the build, our mobile app development cost guide for India covers that side.
Individual or organisation: decide before you register anything
Both stores offer a personal account and an organisation account. The choice is not cosmetic and switching later is painful, so make it before a single form is filled.
An individual account publishes under a person’s name. On Google Play, personal accounts must display a verified name and contact address on the listing, so a founder’s home address can end up public, and on Apple only that person can hold the account. New individual Play accounts face an extra gate: a closed test with a minimum number of real testers, run for a minimum period, before production access is granted. Both the tester count and the duration have been revised since that rule appeared, so check the current requirement.
An organisation account publishes under the company name, supports multiple users with separate roles, and looks like a business to the person deciding whether to install. For anything commercial or client-facing, it is the only sane choice.
What an Indian company needs for the organisation route
Both Google and Apple verify organisations through Dun and Bradstreet. You need a D-U-N-S number for your legal entity, and the details in that record have to match your incorporation documents. Indian companies get stuck here more than anywhere else in the process.
Have these lined up and consistent before you apply: the exact legal name from the Certificate of Incorporation, including whether it reads Private Limited or Pvt Ltd; the registered address as filed, not the office you actually sit in; a working company phone number that someone answers; a live website on your own domain; and an email address on that same domain, never a Gmail address. Apple in particular may verify by calling the number in the public record, and a director’s personal mobile listed against the D-U-N-S record is a common reason enrolment stalls.
A D-U-N-S number can take a while to issue, and corrections are slower than fresh requests, so start it before design rather than after the build. If you will charge for the app or sell anything digital inside it, you also need a payments profile with the company bank account, PAN and GST details, plus the tax forms each store requires from non-US sellers. Proprietorships and unregistered firms may not qualify as an organisation on both stores, so confirm before promising a company-branded listing.
Store listing assets, and what always gets redone
Listing assets get underestimated because they look like design work. They are really a compliance exercise with a design layer on top.
Required screenshot sizes change as new devices launch, especially on Apple, so re-check the current specification instead of reusing last year’s export settings. Design the frames so the text still reads at thumbnail size, because that is where most people see them.
| Asset | Google Play | Apple App Store | What usually gets it redone |
|---|---|---|---|
| App icon | 512 x 512 PNG | 1024 x 1024 PNG, no transparency | Badges like New or Free baked into the icon, or a store rating drawn on it |
| Feature graphic | 1024 x 500, required | Not used | Text placed where the play button overlaps it |
| Screenshots | Phone set, plus tablet sets if you claim tablet support | One set per required device size, iPad set if the app runs on iPad | Screens that do not exist in the shipped build, or a competitor logo visible in the frame |
| Title and subtitle | Short title, short description, full description | Name, subtitle, promotional text, description | Keyword stuffing, all caps, emoji, or ranking claims such as number one |
| Preview video | Optional, hosted on YouTube | Optional, captured from a real device | Marketing footage that is not actual app capture |
| Content declarations | Content rating questionnaire, target audience, ads, financial features | Age rating questionnaire, export compliance on every build | Answers that contradict what the app actually does |
Two rules save the most rework: never mention another platform, a price or a promotion in listing copy, and never show a screen the reviewer cannot reach in the build you submitted.
Privacy policy, data declarations and permissions
A missing or unreachable privacy policy is one of the most common blockers on both stores, and it is entirely avoidable. The policy has to sit at a public URL that loads without a login, without a redirect chain, and on a phone. A PDF on a shared drive, a page behind a staging password, or a link to your homepage will all fail.
The page has to name the app, list what data is collected and why, name the third parties that receive it, state retention, and give a working deletion route and a contact address. Host it on your main company website so it stays under your control. If the domain lapses the policy URL dies and the app can be pulled, which is why keeping the domain and hosting in the business’s own account counts as app compliance, not housekeeping.
The declaration layer is separate from the policy. Google Play has the Data safety form; Apple has privacy labels, and third-party SDKs on iOS are expected to ship privacy manifests. The declaration must match what the app and every embedded SDK actually do. An ad network added in week two collects identifiers whether or not anyone told the person filling in the form, and a mismatch found later is treated as misrepresentation, which is worse than a rejection.
If your app has accounts, it needs an in-app way to delete the account and the data, plus a web route to request the same thing. This one quietly catches a lot of Indian apps that were built before the requirement existed.
Justify every permission, or remove it
Treat the permission list as something you will defend line by line. Background location, SMS and call log access, broad storage access, querying all installed packages and accessibility services are restricted or sensitive, and several need a written justification, a declaration form or a demonstration video before they are allowed.
On iOS, every purpose string must say specifically what the app does with the data; generic wording such as this app needs camera access gets rejected, naming the feature does not. Audit what the build actually requests before submitting, because SDKs drag in permissions nobody chose. The fastest fix for a permission you cannot justify is deleting the feature behind it.
Test accounts and reviewer notes: the OTP trap
Apple’s reviewer will try to use your app. If they cannot get past the login screen, you get rejected, and the reason will be vague. Google’s reviewers hit the same wall on flagged apps.
The classic Indian failure is phone-number OTP login. A reviewer outside India cannot receive your SMS, and your OTP provider may not deliver to their number at all. Ship a test number with a fixed code, or a demo bypass account, and put the credentials in the review notes field every single time you submit. Do not assume the note from the previous version carries over.
Give a demo account that is populated, not empty; an account with no orders, no chats and no history makes the app look broken. Keep the backend live on the production URL throughout the review window, not on a staging box someone shuts down over the weekend. If a flow needs hardware the reviewer will not have, attach a short screen recording and explain it in the notes. If content is India-only, say so and give them a way to see it anyway.
Release tracks and staged rollout
Neither store expects you to go from your laptop to every user in one step, and doing so turns small bugs into one-star reviews you cannot delete.
On Google Play, work up through internal, closed and open testing before production. Production supports a staged rollout, so release to a small percentage first, watch crash and ANR rates for a day or two, then increase; if something breaks you halt the rollout instead of issuing a public apology. On Apple, use TestFlight, remembering that external groups need a beta review of their own, then phased release plus the manual release option so launch timing is yours, not the queue’s.
Whatever you do, do not book a launch event or a paid campaign against your first submission date. Book it against a version that is already approved and sitting on manual release.
Why Indian apps get rejected or delayed
Most rejections are not mysterious. They cluster around the same handful of causes, and almost all of them are decided before a single line of review feedback arrives.
| What happens | Why it is flagged | The fix |
|---|---|---|
| App is a website in a wrapper | Minimum functionality: it offers nothing the mobile browser does not | Add native value such as offline use, push or camera, or ship a mobile site instead |
| Reviewer cannot log in | OTP does not reach a foreign number, or the demo account is dead | Fixed-code test account in the review notes on every submission |
| Only Google or Facebook login offered on iOS | Apple requires its own sign-in option alongside third-party social logins | Add Sign in with Apple, or add an email and password route |
| Digital goods sold through an Indian payment gateway | Digital content and subscriptions must use the store billing system; physical goods and real-world services must not | Classify what you sell, then read the current billing policy including India’s alternative billing options |
| Lending, investment or insurance features | Financial services policy requires licence proof or a declaration from a regulated partner for India | Gather regulator documentation first; this category is human-reviewed and slow |
| Data safety form does not match the SDKs | Declared collection differs from observed network behaviour | Audit every SDK, then re-declare on any release that adds one |
| Crash or blank screen on first launch | Reviewer device, locale or network differs from your test phones | Test a cold install on a clean device, a slow connection and a non-Indian locale |
| Placeholder content or test data | Lorem ipsum, dummy products, coming soon screens or a test payment mode | Ship complete, or hide the incomplete section behind a flag |
| Update refused months later | Android target API level requirements rise every year | Plan one compliance release a year even if the product has not changed |
Two categories deserve a warning. Real-money gaming is heavily restricted and store policy tracks Indian law, so verify the position before building anything there. Health, medical and financial claims in listing copy are scrutinised closely, so describe what the app does, not what it will achieve for the user.
A calendar that survives contact with reality
Sequence it like this. D-U-N-S and account verification start first and run in parallel with development, because they are the longest pole and depend on other people. Listing assets, the privacy policy page and the data declarations are prepared while the build is finished. Internal and closed testing happen before you open the submission form. Launch comms are scheduled only after an approved build exists.
Assume at least one rejection on Apple for a first submission and treat a clean pass as a bonus. A rejection means a fix, a new build and a new place in the queue, which is why four to eight weeks is a sensible planning window even when actual review times are much faster.
Who owns the store accounts: the business, never the agency
This is the single most expensive mistake in Indian app projects, and it is usually made in week one to save a few days. The developer accounts, the D-U-N-S record, the payments profile, the app signing keys and the domain must all belong to the business that owns the product.
When an agency publishes your app under its own account, the listing, the install base, the reviews and the ratings are legally theirs. Transfers between accounts are possible on both stores but come with conditions, need the current holder’s active cooperation, and some configurations cannot be transferred at all. If the relationship ends badly you republish from zero and lose every rating. A policy strike caused by another client’s app on that account can also take yours down.
The correct arrangement is simple. The business creates and owns both accounts, holds the account holder credentials and the two-factor device, and adds the agency as a user with the permissions it needs and nothing more. Access can then be revoked in seconds. Any developer who resists that is telling you something useful, which is worth remembering when choosing a development company in India. Keep the upload and signing keys somewhere the business controls too: a lost Android signing key is one of the few unrecoverable mistakes here.
After launch: the obligations that never stop
Getting listed is a milestone, not an end state. Apple membership renews annually and lapsing removes your apps from sale. Android target API requirements rise every year, so an app that is never touched will eventually stop accepting updates and can be hidden from new users. Both stores also de-list apps that have been abandoned for long periods.
The ongoing list is short but non-negotiable. Keep the privacy policy URL alive and accurate. Re-declare data collection when SDKs change. Watch crash and ANR rates, because poor stability affects how the store treats your listing. Renew Apple certificates and provisioning profiles before they expire. Respond to reviews. Process account and data deletion requests. Read the policy emails, because compliance deadlines are announced by email and missing one is how apps get removed without warning.
Budget for this rather than discovering it later. Our app maintenance cost guide and website maintenance service explain what a realistic ongoing scope looks like. If your app has a backend, admin panel or integrations behind it, that custom software layer needs the same attention as the binary.
Your next step
Do one thing this week: apply for your D-U-N-S number in the company’s exact legal name and put the privacy policy live at a permanent URL on your own domain. Those two items cause more delay than everything else combined, and both can be started before the app exists.
Codelith Lab is based in Pune and builds and ships apps for businesses across India, always under the client’s own store accounts. If you want the publishing path checked before you build, see our mobile app development service or get in touch with the team with what you are planning.
