A tuition start-up in Laxmi Nagar finishes its app on a Friday and uploads it on Saturday. On Monday the rejection arrives: the privacy policy link opens a blank page, the data disclosure says no data is collected although the app records students’ voices for pronunciation practice, and there is no way to delete an account. A week later a lending start-up in Gurugram is told its app cannot be listed without proof of a regulated lending partner. Neither problem is technical. The stores have their own rules, Indian law has its own, and the documents have to satisfy both and match what the app really does. This page explains how.
Developers expect the stores to test whether an app works. Many are surprised that the most common problems are not bugs but documents: a privacy policy that is missing, generic or contradicted by the app; a data disclosure that leaves out what an analytics library collects; a permission requested without explanation; no way for users to delete their accounts; a listing that promises what the app does not do. Store reviewers compare what the developer says with what the app does, and an inconsistency is treated as a policy violation even when nobody meant to mislead.
The consequences are practical and sometimes severe. A rejected first release delays a launch; a rejected update blocks a bug fix; repeated violations can lead to removal of the app and, in serious cases, termination of the developer account, which can take every app of that developer off the store. For businesses whose customers reach them mainly through an app, that is an existential risk.
Indian law adds its own layer. A privacy policy that satisfies a store reviewer may still fall short of the notice the DPDP Act requires; a subscription flow the store accepts may still be a dark pattern under consumer guidelines; an app that hosts user posts may be an intermediary with duties the store never asks about. This page takes both layers together.
It helps to see the two sets of rules side by side. Neither replaces the other, and meeting one does not guarantee the other.
| Subject | What the stores require | What Indian law adds |
|---|---|---|
| Privacy | Privacy policy link, data disclosure forms, permission rules | DPDP notice, consent, rights, children’s data, security, breach duties |
| Accounts | In-app deletion, and on Google Play a web deletion link | Right to erasure; retention only where law requires |
| Payments | Store billing rules for digital goods; policies on financial apps | RBI rules for lending, payments and wallets; GST |
| User content | Moderation and reporting tools, content policies | Intermediary rules: published rules, grievance officer, takedown timelines |
| Consumers | Honest listings, clear subscription terms | Consumer Protection Act, e-commerce rules, dark pattern guidelines |
| Children | Family and kids programmes, restricted ads and SDKs | Verifiable parental consent under eighteen, no tracking or targeted ads |
| Regulated services | Declarations and licence proof | Licences from RBI, SEBI, IRDAI, FSSAI and others |
Store policies are contracts between the developer and the store, enforced by the store. Indian law is enforced by regulators, consumer commissions and courts. A developer can argue with a reviewer through an appeal; a regulator’s inquiry is a different matter. Documents should be written to satisfy the stricter of the two on each point.
Every app is published from a developer account, and the account determines who is legally the developer, whose name appears on the listing, and who controls the app. Both major stores offer individual and organisation accounts. For a business, an organisation account in the exact legal name of the company, firm or LLP is almost always right: it presents the business, not an individual, as the developer; it survives changes of staff; and it can be transferred with the business.
Organisation accounts generally require verification of the business, commonly using a D-U-N-S number linked to the legal name and address, and confirmation that the person enrolling has authority to bind the business. Stores have also tightened verification of individual developers, and newer individual accounts on Google Play have had to complete a period of closed testing with a minimum number of testers before publishing to everyone. These requirements change, so check the current rules before starting; a delay in verification can hold up a launch for weeks.
The account should be owned by the business and administered through individual logins for each team member with the least access they need, never by sharing one password. If an agency or freelancer is building the app, they should be invited to the business’s account, not publish from their own; our software development guide explains why and how to write that into the contract. The contact details on the account must be real and monitored: policy warnings arrive by email, often with short deadlines.
The listing — name, icon, short and full description, screenshots, video, category and contact details — is both marketing and a legal statement. Stores prohibit misleading metadata: claims the app cannot support, screenshots of features that do not exist, fake endorsements, keyword stuffing, and names or icons that imitate other brands. Indian consumer law independently prohibits misleading advertisements and unfair trade practices, and the Central Consumer Protection Authority has issued guidelines on misleading advertising and endorsements.
Good practice is simple. Describe what the app does today. State clearly which features are paid. Use your own brand and do not use a competitor’s name in a way that suggests association. If the app offers professional services — medical, legal, financial — name the licensed provider. Give a working support email and web page, and, where the store requires business contact details to be shown publicly in certain regions, make sure they are the business’s official details. The listing should link to the privacy policy and, ideally, to the terms.
Every compliance document for an app depends on one piece of homework: an accurate map of the data. Without it, the privacy policy is guesswork and the store forms are wrong. The map should cover:
Developers often need to read each SDK’s own documentation to find out what it collects by default. The map should be updated whenever an SDK is added or upgraded, because a new version can change its data collection. Vendors that process users’ data for the app are processors, and should be under the contract terms described in our data processing agreement guide.
A privacy policy copied from a website template usually fails an app review, because it does not mention device permissions, SDKs or in-app features, and it fails Indian law, because it does not give the notice the DPDP Act requires. The policy for an app should be written from the data map and should:
The structure of a DPDP-compliant notice, and why a foreign template is wrong in India, is covered in our DPDP privacy policy guide. For the app, the important additional point is consistency: the policy, the store forms and the in-app consent screens must tell the same story. Our privacy policy service drafts policies for apps from the data map.
Google Play’s Data safety section and Apple’s privacy details, often called privacy nutrition labels, ask the developer to declare the app’s data practices in a structured form that users see before downloading. They ask, broadly, which categories of data are collected, which are shared with third parties, for what purposes, whether data is linked to the user’s identity or used to track them, whether data is encrypted in transit, and whether users can request deletion.
The forms use the stores’ own definitions, which do not always match everyday language or Indian law. “Collection”, “sharing”, “tracking” and the exemptions for data processed only on the device, or shared with service providers, have specific meanings in each store’s guidance. Answers should be prepared by reading that guidance against the data map, not by guessing. Common mistakes are declaring that no data is collected when an analytics or crash-reporting SDK collects device identifiers, forgetting data sent to a payment or login provider, and failing to update the form when a new SDK is added.
Keep a record of the answers given for each version, and the reasoning behind any judgment call. If a store or a regulator later questions a declaration, that record shows that the business acted carefully.
Third-party SDKs are the most common source of hidden data collection. Advertising networks, analytics tools, attribution services, social login and crash reporters each collect data, and some share it with their own partners. The developer is responsible for what its app does, including what the SDKs inside it do.
On Apple devices, tracking users across other companies’ apps and websites requires the user’s permission through the App Tracking Transparency prompt, and Apple requires privacy manifests for many widely used SDKs, declaring the data they collect and the reasons for using certain device features. On Android, Google Play has policies on the use of advertising identifiers and on SDKs that collect data inappropriately, and developers are responsible for ensuring that SDKs comply. Under Indian law, advertising and behavioural analytics beyond what the service needs will usually require the user’s consent, which must be free, specific, informed and capable of withdrawal, and cannot be bundled with acceptance of the terms.
The practical rule is to keep an SDK inventory, remove SDKs that are not needed, configure the ones that remain to collect the minimum, and switch off advertising and tracking SDKs until the user has consented where consent is required.
Device permissions give an app access to data or functions such as location, contacts, camera, microphone, photos, SMS, call logs, files and accessibility services. Stores classify some as sensitive or restricted, and require that the app use them only for features that genuinely need them, request them in context, and explain why. Google Play requires additional declarations for certain permissions — for example SMS and call log access, background location, broad file access and accessibility services — and may reject apps whose core function does not justify them.
For each sensitive permission, prepare a short justification that names the feature, explains why it cannot work without the permission, and describes what happens to the data. Show a plain-language explanation inside the app before the system prompt appears, and make the app work, in reduced form, if the user refuses. Remove permissions left over from earlier versions or libraries. Many Indian lending apps were removed from stores precisely because they accessed contacts and photos and used them to harass borrowers; that history makes reviewers strict about such access in finance apps.
Both major stores require an app that allows users to create an account to let them initiate deletion of that account from within the app. Google Play also requires a web link, declared in the Play Console, where users can request deletion of their account and data without having the app installed. Deletion must remove the account and associated data, except data the developer must keep for legitimate reasons such as legal obligations, fraud prevention or security, which should be explained.
Under the DPDP Act, individuals have the right to correction and erasure of personal data, and a fiduciary must erase data when the purpose is served or consent is withdrawn, unless the law requires retention. An app’s deletion flow is the natural way to honour these rights. A good deletion page explains what will be deleted, what will be retained and why — for example, invoices that tax law requires to be kept — how long retained data will be held, and how long deletion will take. It should confirm identity without being so onerous that it becomes a dark pattern, and it should also offer the other rights: access, correction and withdrawal of consent. Our DPDP guide on rights explains how requests should be handled.
Apps reach users outside the app too: push notifications, SMS one-time passwords and alerts, emails and messages on WhatsApp or other platforms. Each channel has its own rules. Push notifications for marketing need the user’s permission on the device and should be separable from service notifications, so that a user can turn off offers without losing order updates. Commercial SMS in India must be sent through registered headers and approved templates under the telecom regulator’s framework for unsolicited commercial communication, and promotional messages must respect the customer’s registered preferences. Business messaging platforms require prior opt-in from the user and approved templates for messages sent outside a customer-initiated conversation.
Under the DPDP Act, using a phone number or email for marketing is a purpose that usually needs consent, separate from the consent to create an account. The privacy policy should list each channel and purpose, the app should offer a clear opt-out, and marketing lists should be cleaned when users withdraw consent or delete their accounts.
Education, game and entertainment apps are often used by children, and both stores have stricter rules for apps that target them — restrictions on advertising, on SDKs that are not certified for use with children, on data collection and on links out of the app. The target audience and content rating questionnaires in the developer consoles must be answered honestly; declaring an app for adults when its content and marketing are aimed at children is itself a violation.
Indian law sets a higher bar than many foreign regimes: a child is anyone under eighteen, processing a child’s personal data needs verifiable consent of a parent or lawful guardian, and tracking, behavioural monitoring and targeted advertising directed at children are prohibited, subject to exemptions in the rules. The details are in our DPDP guide on children. For an ed-tech or school app, that usually means sign-up by a parent or through the school, no advertising SDKs, analytics limited to what the service needs, and a privacy notice written so that parents can understand it. A contract “accepted” by a child is also weak, which is another reason for parental sign-up; our EULA guide covers purchases by minors.
An app needs terms that govern its use: who may use it, account rules, acceptable use, payment terms, intellectual property, disclaimers, limits of liability, suspension and termination, governing law and how disputes are handled. Where the app is software licensed to the user, these terms take the form of an end user licence agreement. At least one major store supplies a standard licence that applies when the developer does not provide its own, but it does not deal with subscriptions, user content, professional services or Indian consumer law; our EULA guide explains when to write your own.
Terms should be accepted through a clear action at sign-up, with the version recorded, following the principles in our website terms guide. For apps that deliver professional or regulated services, the terms should identify the licensed provider and the limits of what the app itself does — for example, that a symptom checker is not a diagnosis. A separate disclaimer can help, but it cannot exclude liability the law does not allow to be excluded.
Stores generally require digital goods and services consumed in the app — premium features, subscriptions, virtual items — to be sold through their own billing systems, with defined exceptions, while physical goods and real-world services, such as food delivery or taxi rides, are paid through the developer’s own gateway. In India, the Competition Commission of India in 2022 found that Google had abused its dominant position, including through its Play billing rules, and ordered changes; Google introduced alternative billing options for Indian users, and the proceedings have continued on appeal. Store billing rules and commission rates differ by store and change over time, so check them when designing the payment flow.
Whatever the billing route, subscription terms must be clear: the price, the billing period, when a free trial converts into a paid subscription, how to cancel, what happens to access on cancellation, and the refund policy. Recurring payments made through Indian cards and UPI are also subject to RBI rules on recurring mandates, including pre-debit notification. A refund policy that matches the store’s own refund process avoids promising what the developer cannot deliver, because refunds of store purchases are often handled by the store rather than the developer.
In 2023 the Central Consumer Protection Authority issued guidelines for the prevention and regulation of dark patterns, listing practices that mislead or trick users — among them false urgency, basket sneaking, confirm shaming, forced action, subscription traps, interface interference, bait and switch, drip pricing, disguised advertisements and nagging. The guidelines apply to platforms offering goods or services in India, including apps, and violations can be treated as unfair trade practices or misleading advertisements.
For app designers, the practical test is whether a user can understand and freely choose. Show the full price, including taxes and fees, before payment. Do not add items or insurance to a cart by default. Make cancelling a subscription as easy as starting it. Do not shame users who decline an offer, or repeat the same request after they have said no. Label sponsored content as advertising. Our SaaS guide on consumers discusses subscription traps and recurring payments in more depth, and our EULA guide lists terms consumer commissions are likely to strike down.
If an app lets users post, message, review, upload or list anything that other users can see, it is likely to be an intermediary under the Information Technology Act. The Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 then require it to publish its rules, privacy policy and user agreement; to tell users not to host prohibited categories of content; to remove unlawful content when required by a court order or a government notification; to run a grievance mechanism with a named grievance officer, acknowledging complaints within a short period and resolving them within the prescribed time; and to act faster on certain categories, such as non-consensual intimate images. Larger social media platforms above the notified user threshold have further duties. Complying with these rules is what preserves the intermediary’s protection from liability for users’ content under Section 79.
The stores ask separately for moderation: a way to report objectionable content and users, a way to block abusive users, and a process for acting on reports. The app’s community guidelines, reporting tools and grievance page can be designed to serve both. How these rules appear in website terms is covered in our website terms guide on intermediaries and its section on user content.
An app that sells goods or services online is an e-commerce entity under the Consumer Protection (E-Commerce) Rules, 2020, whether it sells its own inventory or runs a marketplace for other sellers. The rules require, among other things, a grievance officer with published contact details and response times, clear information about sellers on a marketplace, the total price and all charges before purchase, return, refund, exchange, warranty and delivery terms, and country of origin information where applicable, and they prohibit manipulating prices or posting fake reviews. Our website terms guide on e-commerce summarises these duties.
For the app, these translate into screens as well as documents: a seller information panel, a price breakdown before payment, a returns and refunds page, an order history with invoices, and a visible grievance contact. Food businesses listed on a delivery or grocery app must display their food safety licence or registration details, and the app should collect and show them; see our FSSAI registration service.
Financial apps face the strictest store scrutiny in India, because of a history of predatory lending apps and fraud. The requirements come from three directions: store policy, the financial regulator, and general law.
| App type | Regulatory position (check current rules) | What the store typically asks |
|---|---|---|
| Personal loans | Lending only by RBI-regulated entities, directly or through lending service providers, under the RBI’s digital lending rules: disclosures, key fact statement, grievance officer, limits on data access | Financial services declaration; proof of licence or partnership; no access to contacts or photos |
| Payments, wallets | Authorisation from the RBI as a payment aggregator, prepaid instrument issuer or other category, or operation through an authorised partner | Licence details; clear disclosure of the regulated entity |
| Investment advice, stock tips | Registration with SEBI as an investment adviser or research analyst where advice is given | Licence details for financial services |
| Stock broking, mutual funds | SEBI registration of the broker or distributor | Licence details |
| Insurance | IRDAI registration of the insurer, broker or web aggregator | Licence details |
| Crypto and virtual digital assets | Service providers are reporting entities under anti-money-laundering law and must register with the Financial Intelligence Unit | Country-specific policies; stores have removed unregistered platforms at the regulator’s request |
The app’s documents should name the regulated entity on every screen where a financial product is offered, show the grievance officer of that entity, set out fees and charges clearly, and avoid any access to personal data that the service does not need. Recovery practices must be lawful; harassment of borrowers or their contacts is prohibited by the regulator and can amount to criminal offences.
Health apps range from step counters to teleconsultation platforms and online pharmacies, and the legal position differs sharply across that range. Teleconsultation by registered medical practitioners is governed by the Telemedicine Practice Guidelines, which set out how consultations may be conducted and what may be prescribed remotely. The online sale of medicines raises questions under the drugs laws and has been the subject of litigation and draft rules, so an e-pharmacy model needs careful review. Apps that make medical claims, or that function as medical devices, may fall within the medical device rules.
Stores also have health policies: apps must not make misleading health claims, must be clear that they do not replace professional advice unless they are provided by licensed practitioners, and must handle health data carefully. Health information is among the most sensitive personal data an app can hold. The documents should name the practitioners or entities providing clinical services, state the limits of the app, obtain clear consent for any use of health data beyond the service, and apply strong security.
The Promotion and Regulation of Online Gaming Act, 2025 prohibits offering, operating and advertising online money games — games played by depositing money or stakes with the expectation of winning money or other rewards — and the facilitation of payments for them, while providing for the promotion of e-sports and online social games. Store policies on real-money gaming also apply and vary by country. Any game with paid entry, stakes, cash prizes or convertible rewards should be reviewed against the Act and its rules before launch, and marketing should be reviewed too, because advertising prohibited games is itself prohibited.
For ordinary games, the compliance points are age ratings, virtual currency and item terms, in-app purchase controls for children, loot box or random reward disclosures where stores require them, and community rules for chat. The EULA guide covers virtual items and purchases by minors.
Many other categories carry specific expectations:
Where a sector needs a licence, the store may ask for it, and even where it does not, the absence of a licence is a legal problem for the business. It is better to resolve it before launch.
Apps with generative AI features — chatbots, image or voice generation, photo editing — are subject to store policies requiring safeguards against generating prohibited content, ways for users to report offensive output, and disclosure where users interact with AI. Indian rules on deepfakes and synthetically generated content have been developing through advisories and amendments to the intermediary rules, with emphasis on labelling synthetic content and acting quickly against harmful impersonation.
The app’s documents should tell users when they are dealing with AI, explain what happens to prompts, uploads and outputs — including whether they are sent to a third-party model provider or used for training — prohibit misuse such as impersonation and non-consensual imagery, and describe the reporting route. The privacy policy and the store data forms should include data sent to model providers.
Stores increasingly ask about security: encryption in transit is declared in the data forms, some categories of apps are asked about independent security reviews, and apps with serious vulnerabilities can be removed. Under Indian law, the DPDP Act requires reasonable security safeguards, and the CERT-In directions require many cyber security incidents to be reported within six hours of being noticed, with logs kept for a prescribed period.
A small app business should at least encrypt traffic and stored credentials, keep secrets out of the app package, protect its backend with proper authentication, keep libraries updated, test before release, and have a short incident plan naming who does what if data is exposed. The data breach clauses in contracts with its own vendors should support that plan; see our data processing guide on breach notice.
An app that people with disabilities cannot use loses customers and may fall short of legal expectations. The Rights of Persons with Disabilities Act, 2016 requires accessibility in information and communication technology in specified contexts, and public-facing digital services are being pushed towards recognised accessibility standards; the stores publish accessibility guidance for developers and reward accessible apps in their featuring.
The basics are labels for screen readers, sufficient colour contrast, text that scales, touch targets large enough to use, captions for video, and flows that do not depend on colour or gestures alone. Compliance documents can support this: the terms and help pages should say how users can request assistance, and the app’s accessibility statement, if it has one, should be honest about known gaps.
Money from an app reaches the business by different routes, each with its own tax treatment. Sales through a store’s billing are collected by the store, which deducts its commission and pays out the balance; depending on the store and the transaction, the store may act as the seller to the user, or as an agent collecting for the developer, and GST and invoicing follow from that. Sales through the developer’s own gateway are the developer’s own supplies, requiring GST registration above the threshold and proper invoices. Advertising income paid by foreign ad networks may be an export of services. E-commerce operators may be required to deduct tax at source on payments to sellers.
These questions depend on facts and on rules that change, including the recodified income tax law in force from April 2026, and are for your chartered accountant. The compliance documents should at least state prices inclusive or exclusive of GST, identify the seller of record, and explain where users get invoices.
The app’s name and icon are its brand, and they should be cleared and protected before launch. Search the trade marks register and the stores for similar names; a name that conflicts with an existing brand can lead to a store complaint and forced renaming after the app has built a following. File a trademark application for the name and logo in the relevant classes, and consider a copyright registration for distinctive artwork or software.
Stores provide forms for intellectual property complaints against apps that copy names, icons, screenshots or content. A registered mark, clear evidence of first use, and screenshots of both listings make a complaint far more likely to succeed. The same forms can be used against your app, so avoid borrowing other brands’ names or trade dress in your own listing.
Before an app reaches the public, it can be released to limited groups through the stores’ internal, closed and open testing tracks, or through test distribution on Apple devices. Testing is useful for catching compliance problems as well as bugs: a closed test with real users shows whether consent screens, permission prompts and deletion flows work as described. Where the store requires newer developer accounts to complete a closed test before production access, plan the time for it.
If the app needs a login, reviewers need a way in. Provide a working demo account with sample data, or a demo mode, and explain in the review notes how to reach the features that need permissions or payments. An app that reviewers cannot open is usually rejected. Demo accounts should not contain real customer data, and their credentials should be changed after review. Where a feature is available only in India or only to licensed customers, say so and explain how the reviewer can test it.
Every new app and update goes through review. A rejection notice normally cites the policy or guideline breached, sometimes with a screenshot. The best response is methodical:
Appeals should be polite and specific. Arguing that another app does the same thing rarely helps. Where a rejection concerns a genuine legal question — whether a service requires a licence, for example — resolve the legal question first, because the store will usually follow the regulator.
Stores can suspend or remove apps that violate their policies, and repeated or serious violations can lead to termination of the developer account. Removal can also follow a complaint from a rights holder or a request from a regulator. The developer console will usually give a reason and an appeal route; the developer’s agreement with the store limits the store’s liability and gives it wide discretion, so the practical remedy is to fix and appeal rather than to litigate.
Separately, Section 69A of the Information Technology Act empowers the Central Government, following the procedure in the blocking rules, to direct that access to information, including apps, be blocked on grounds such as the sovereignty and integrity of India, security of the State and public order. Large numbers of apps have been blocked under this power. An app business should keep its corporate, ownership and data location details clear and up to date, and should take legal advice promptly if it receives a notice.
A store makes it easy to publish an Indian app worldwide, but each country’s law follows. Distribution in the European Union brings the General Data Protection Regulation if the app offers services to people there, and the stores ask developers distributing in the EU to declare whether they are traders and, if so, to publish verified contact details. Apps for children distributed in the United States must consider its children’s privacy law. Some countries restrict particular categories, such as lending, gambling or dating.
The simplest control is the store’s country availability setting. Launch where the business is ready to comply, and extend distribution only after checking the documents for each new market. Where users outside India are served, the privacy policy may need additional sections rather than a separate policy.
App compliance is not finished at launch. Stores change their policies every year: new target platform versions, new permission rules, new disclosure requirements, new rules for particular sectors. They announce deadlines in the developer console and by email, and apps that miss them may be blocked from updating or hidden from new users. Indian law is moving too, with the DPDP rules coming into force in phases and new rules for AI, gaming and finance.
A light routine works: one person reads every policy email; before each release, the team checks the SDK inventory, permissions, data form and privacy policy against the changes in the release; and once a year, the business reviews all its app documents together. Keep old versions of the privacy policy and terms with their dates, because users and regulators may ask what applied at a particular time.
| Item | Done when |
|---|---|
| Developer account | Organisation account in the business’s legal name, verified, with individual team logins |
| Data map and SDK inventory | Every screen, permission and SDK recorded with purpose and destination |
| Privacy policy | Written from the map, DPDP-compliant, at a public URL and linked in the app |
| Data forms | Data safety and privacy labels answered from the map, record kept |
| Permissions | Only what is needed, explained in the app, declarations filed |
| Account deletion | In-app option and web page working, retention explained |
| Terms or EULA | Accepted at sign-up with version recorded |
| Payments | Correct billing route; subscription and refund terms clear |
| Consumer design | No dark patterns in sign-up, checkout or cancellation |
| User content | Community rules, reporting, blocking, grievance officer |
| Children | Audience declared honestly; parental consent and restrictions if needed |
| Sector licences | Licences or partners in place and named in the app |
| Brand | Name cleared, trade mark filed |
| Support | Working email, web page and grievance contact |
The Laxmi Nagar tuition start-up from the top of this page rebuilt its paperwork from a data map. The map showed that the app collected parents’ and students’ names and phone numbers, recorded students’ voices for pronunciation practice, used an analytics SDK and a crash reporter, and sent payment details to a payment gateway. Most students were between twelve and seventeen.
The company switched sign-up to parents, with a consent step before a child profile could be created; removed an advertising SDK it had added for a future free tier; limited analytics to aggregate usage; stored voice recordings for thirty days unless the parent chose to keep them; and wrote a privacy policy in plain English and Hindi that explained each of these points. The Data safety form declared the voice recordings, the analytics and the payment data, and the target audience was declared honestly. An in-app “delete account” option and a web deletion page explained that fee invoices would be kept as tax law requires. The course terms set out the refund window for a new batch. The app was approved on the next submission, and the privacy policy later satisfied a school that asked for it before recommending the app to parents.
The Gurugram lending start-up had designed its app as a marketplace for small personal loans, with credit decisions made by an NBFC partner. The first submission was rejected because the declaration did not show the regulated lender, and because the app requested access to contacts “for faster verification”.
The company removed contact and photo access entirely, relying on the lender’s own verification through regulated channels. It named the NBFC on the loan screens and in the terms, displayed the key fact statement before acceptance, showed the lender’s grievance officer and its own, and wrote a recovery conduct policy prohibiting contact with anyone other than the borrower. Its agreement with the NBFC was revised to define each party’s role and data responsibilities, with processing terms for data the start-up handled for the lender. The declaration was resubmitted with the NBFC’s registration details and the partnership letter, and the app was approved.
App store compliance documents from us cost ₹3,999 and are ready in 2 – 5 days. We start from your app — its features, permissions, SDKs, users and business model — and prepare the set that the stores and Indian law expect.
| Included | Why it helps |
|---|---|
| App privacy policy from your data map | Passes review and meets the DPDP Act |
| Draft answers for the data safety form and privacy labels | Consistency between app, policy and listing |
| Terms of use or EULA | Clear rules, payments and limits of liability |
| Account deletion and data request pages | Meets store rules and users’ rights |
| Permission justification text | Fewer rejections for sensitive access |
| Subscription, refund, community and grievance pages where needed | Consumer and intermediary compliance |
Licences for regulated services, such as lending or payments, are obtained by the regulated entity; we prepare the app’s documents around them. Should a dispute with a store, a user or a regulator reach an arbitrator, a commission or a court, it is for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it. You can find an advocate through our directory.
Most app rejections are about documents that do not match what the app does. We start from your app’s real features, permissions and SDKs and write the privacy policy, terms, deletion pages and store answers to match — so that the stores and Indian law hear the same story.
Two doors, both free. Clients search a factual directory of enrolled advocates. Advocates apply to be listed on it — no fee, no commission, nothing paid in either direction.
Search Bar Council enrolled advocates by what your matter is about, by court, or by city. Searching and sending a request are both free.
Enrolled advocates anywhere in India can apply to be listed. Your entry is published only after we verify your enrolment number with your State Bar Council.
This directory carries no ratings, no reviews, no rankings and no fees — only the factual particulars the Bar Council of India permits, published at each advocate's own request. Browse the network · Terms for Advocates