LaunchTrust
Log inStart trial

Detector registry

Do I Need Terms of Service for My App?

Find out if your app needs terms of service, what stores expect, and how LaunchTrust detects a terms link before you submit.

Updated 2026-06-19do I need terms of service for my appSignals, not a verdict
Run free scanStart trial

If you sell anything, run accounts, or take subscriptions, the honest answer is usually yes. A terms of service document (also called terms of use, terms and conditions, or an end-user license agreement) is the contract between you and the people who use your app. It sets the ground rules: who may use the service, what happens to their account, how payments and renewals work, and how disputes get handled. App stores and consumer-protection rules frequently expect this document to exist and to be reachable before a user commits.

For an indie developer or a small store owner shipping fast, terms of service is easy to defer until a reviewer or a customer dispute forces the issue. It is also one of the first things a marketplace reviewer looks for. LaunchTrust helps you catch a missing terms link before it costs you an approval, so you can fix it on your own schedule rather than after a rejection.

What LaunchTrust checks

The terms_of_service detector fetches one of your public pages and reads its HTML. It is a positive-polarity signal: a present terms link is the thing you want, so "detected" is the reassuring state and "not detected" is the prompt to act. The scan runs in two passes:

  1. Link pass. It scans anchor href attributes for terms-related tokens, including terms, tos, conditions, and several non-English equivalents such as kosullar (Turkish), agb, and nutzungsbedingungen (German). If a matching link is found, the result is detected at informational severity.
  2. Wording pass. If no link matches, it looks in the page text for terms phrasing — "terms of service", "terms of use", "terms & conditions", plus localized variants like "kullanım koşulları", "nutzungsbedingungen", and "conditions générales / d'utilisation". A match here returns detected at low severity, because wording without a clear link is a weaker signal than a real link.

If neither pass matches, the result is not detected at low severity, meaning the scan did not find a terms link or terms wording on the page it fetched. If the page cannot be fetched or parsed, the result is unable to determine.

Read the output as a signal, not a judgment. Detected means a terms link or wording appeared on the fetched page; it does not confirm the terms are complete, current, or right for your business. Not detected means no terms reference surfaced — the page may genuinely lack one, or the link may live behind a script-rendered menu, on a different URL, or in an account flow the passive scan did not reach. The detector looks only at the single public surface you provide; it does not open the linked terms page or assess its quality.

Why it matters

Terms of service maps to consumer-protection expectations more than to a single named statute. App marketplaces and payment platforms commonly expect a clear agreement that governs paid use, subscriptions, and content. Apple's App Review process, for example, frequently looks for an EULA or terms for apps with accounts or purchases, and Google Play expects developers to be transparent about the terms under which the app operates. A missing or broken terms link is a frequent, avoidable cause of review friction.

For e-commerce, consumer law in many regions assumes a visible set of terms covering ordering, delivery, and the customer relationship. In the UK and the EU, distance-selling and consumer-contract rules expect traders to surface contract terms before purchase — see the UK distance selling checklist for how this fits alongside refund and cancellation duties. The exact obligation depends on what you sell and where your users are, so treat terms as commonly expected rather than universally mandatory. None of this means a generic copied template makes you safe; it means the absence of any terms is a visible, easily fixed gap.

A concrete example

Here is the kind of evidence a link-pass match is built on — a plain footer anchor:

<a href="/legal/terms-of-service">Terms of Service</a>

That single link satisfies the detector's link pass and returns detected. Localized footers match too: a German site linking href="/agb" or a Turkish site linking href="/kullanim-kosullari" both register. By contrast, a page that mentions "By using this app you agree to our terms" in body copy but has no clickable link would match the wording pass instead — still detected, but a weaker, low-severity signal, because users and reviewers cannot actually reach the document.

How to address it

  1. Decide what your terms must cover. For most apps: acceptable use, account and termination rules, intellectual-property ownership, disclaimers and limitation of liability, governing law, and how changes are communicated. For paid products, add purchase, billing, and renewal terms.
  2. Pair terms with the related documents. Terms rarely stand alone. Add a privacy policy, a refund and cancellation policy where you sell, and clear subscription auto-renewal disclosure if you bill recurringly.
  3. Publish a real, reachable page. Give it a stable URL like /legal/terms and make sure it returns content without requiring a login. Avoid linking to a PDF buried in cloud storage.
  4. Link it where the scan can see it. Put a Terms of Service anchor in your global footer and inside any signup or checkout flow. A real href link is the strongest signal — stronger than body text alone.
  5. Add a contact route. Many consumer rules expect users to be able to reach you; a visible contact or imprint link reinforces the terms.
  6. Get legal review where stakes are real. Templates are a starting point, not a finish line. If you take payments, handle minors, or operate across multiple countries, have a professional review the wording.
  7. Re-scan after publishing to confirm the link is now detected on the live page, and spot-check that it actually resolves.

Check this in 30 seconds

You do not need to read your whole HTML by hand. Point LaunchTrust's free scanner at your live URL and it will tell you whether a terms-of-service signal is detected, not detected, or unable to determine, alongside the matched text it found and your privacy policy, refund policy, and contact signals. It is a fast pre-submission read of your public surface, so you find a missing terms link before a reviewer or a customer does — not a rewrite of your legal docs.

FAQ

Do I need terms of service for my app? Most apps and stores benefit from one, and marketplaces plus consumer rules commonly expect it — especially if you have accounts, user content, or payments. Whether it is strictly mandatory depends on your model and jurisdiction, so treat "almost always advisable" as the practical answer and confirm specifics for your situation.

Does a detected terms link mean my app is legally OK? No. Detected only means a terms link or terms wording appeared on the page that was scanned. It says nothing about whether the document is complete, current, or appropriate for your business. LaunchTrust surfaces a signal, not a verdict, and it is not legal advice or certification. Use it to spot gaps, then get professional review where it counts.

Why did the scan say "not detected" when I have a terms page? The passive scan reads one public page's HTML. If your terms link is rendered by JavaScript after load, lives only in an account area, or sits on a URL the scan did not fetch, it can be missed. Add a plain footer link and re-scan.

What is the difference between terms of service and a privacy policy? Terms of service is the contract governing how people may use your app. A privacy policy explains what data you collect and how you handle it. They are separate documents, and stores frequently expect both. This detector only checks for the terms link.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.