Solfreaks ComplyKit is our app privacy compliance service: we find out what your app and its SDKs really collect, then make the app, the store forms and the privacy policy agree with each other. That covers policy and terms, Google Play's Data safety form, Apple's privacy labels and manifests, consent prompts, account deletion and permission wording.
One thing before anything else. We're software developers, not a law firm, and nothing here is legal advice. We establish what the code does and write it down accurately. Whether that satisfies the law in your market is a question for a qualified lawyer, and for anything high-stakes we'll tell you to ask one.
Where apps usually get caught
The common problem isn't a missing policy. It's a policy that says one thing while an SDK does another. An analytics library or ad network collects device identifiers, the Data safety form says no data is collected, and the next update comes back with a rejection or a policy warning. Account creation is the other trap: both stores expect people who can sign up in your app to be able to delete the account without emailing support.
What we deliver
- A data inventory. Each piece of data your app and its SDKs collect, why, where it goes and how long it's kept, built from the code and from watching network traffic.
- Store form answers. Google Play Data safety and Apple's App Privacy details, prepared from the inventory for you to review and submit.
- Privacy manifests. For iOS, covering the required-reason APIs your app calls, plus a check that the third-party SDKs you use ship their own.
- Policy and terms drafts. Written in plain language from the inventory, ready for your lawyer to review and adjust.
- Consent and permission prompts. Consent screens that hold SDKs back until the user answers, and honest explanations before camera, location, contacts or notification requests.
- Account deletion. Inside the app and on a web page, with a backend that really removes or anonymises the data.
- Children's app checks. If kids might use the app: Google Play's Families policy, COPPA basics, Apple's Kids category rules and which SDKs have to go.
How a privacy review goes
- Audit. We read the code, list every SDK and run the app through a traffic inspector. A mid-sized app usually takes a few days.
- Your questions list. Some answers only you have: retention periods, which vendors sit behind the scenes, where servers are hosted, who gets the data.
- Fix the app. We remove or reconfigure SDKs and add consent screens, deletion flows and manifests. It's the longest step, from a few days to a few weeks if the backend needs changes.
- Write the paperwork. Policy drafts, store form answers and permission strings, all taken from the same inventory so they can't contradict each other.
- Review and submit. You, and your lawyer if you have one, check the drafts. We can submit through your store accounts and answer reviewer questions.
UK and EU users, and children
For users in the UK and EU the technical basics are consent where it's needed, the right to access and delete data, data minimisation, and openness about who processes it. We build the mechanisms: consent gating, export and deletion, retention rules. Children's apps are stricter. COPPA in the US covers children under 13, Google Play's Families policy limits which SDKs you can use, and the safest design often collects almost nothing. If children might use your app, tell us at the start, because it changes the ad and analytics tools you can pick. For the ads side, see our app monetisation work.
Who this fits, and who needs more
It fits apps heading for a first store submission, apps that have had a rejection or policy warning about data, and apps adding ads, analytics or a new SDK. If you're adding event tracking at the same time, our analytics setup works from the same inventory.
This won't cover you if you need a legal opinion, a certification such as ISO 27001, or a formal impact assessment. We can supply technical facts for those, but we can't sign them off. Apps that handle patient records need more than this page covers; our healthcare software work looks at that separately.
What affects the price and the timeline
The cost follows the number of platforms, how many SDKs and data flows the app has, whether children are in the audience, and whether the backend needs deletion or export features built. We offer a fixed-scope project, and a monthly option that keeps forms and manifests current as the stores change their rules, alongside our app maintenance plans. A standard app typically takes one to three weeks, and backend changes add to that. The quote follows a short discovery call.
Why Solfreaks for privacy work
We're small, we're in Rawalpindi, and our working hours overlap with the UK and the Gulf, so questions get answered the same day. We've published apps on Google Play and filled in its forms for real, which is different from reading the help page. The store accounts stay yours, and so do the inventory, the manifests and the drafts. If a rejection has landed in your inbox, tell us what you need and send us the message.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- OWASP/mastgOWASP Mobile Application Security Testing Guide.
- OWASP/masvsOWASP Mobile Application Security Verification Standard.
Frequently asked questions
Can you write our privacy policy?
We draft it from the data inventory, so it describes what your app really does. We're not lawyers, so treat our draft as a well-informed starting point and have a qualified person review it, especially if you serve users in regulated markets or collect sensitive data. A policy copied from another app without checking the SDKs is how mismatches begin.
Do we need to update the Data safety form after every release?
Only when what you collect or share changes, but that happens more easily than people expect. Adding an SDK, a new permission or a new analytics event can all change the answers, and Google can act on forms that don't match behaviour. We keep the inventory current when we work on your app, and a review before each major release catches drift.
Do we really need account deletion?
If your app lets people create an account, both stores ask for a way to delete it. Apple expects it inside the app, and Google Play expects it in the app plus a web link where people can request deletion without installing anything. The rules have details and deadlines, so we check the current wording and build the flow, including the backend part.
What if an SDK collects more than we expected?
It happens often, and we find it by reading the code and inspecting traffic. Then you have options: switch off the extra collection if the SDK allows it, replace the SDK, or disclose the collection honestly in the policy and store forms. We lay out the trade-offs and you choose. We don't recommend hiding it, because stores and users do notice.
Do you build apps for children?
We can, with conditions. Apps aimed at children have fewer ad and analytics options, and both stores have specific rules. In practice that means choosing SDKs approved for child-directed use, collecting as little as possible and getting parental consent where the law requires it. We'd also ask you to take legal advice early, since the rules differ by country.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
