Terms and conditions for apps: EULAs, store rules, and in-app terms

Prepare a public terms page, then connect it to the screens where users make an agreement. A permanent settings link helps people find the terms later; signup and purchase links let them review the relevant version before committing. Check that every link opens the same current document and that the acceptance wording is clear. Include these locations:

1. Store listing: on Apple, the custom EULA field or a terms link in the app description; on Google Play, the description or your developer website.
2. Signup screen: a clear statement next to the create account button, such as “By creating an account, you agree to the Terms of Service”, with tappable links to the terms and privacy policy.
3. Paywall: subscription title, length, price, and links to the terms and privacy policy, close to the purchase button.
4. Settings or about screen: permanent links users can find later.
5. Change notices: an in-app message or email when material terms change.

Use stable public URLs so the store listing and the app never point at a broken page. For ways to publish a link that stays live, see how to get a privacy policy URL; the same approach works for terms.

Legal Policy Generator produces both documents from your answers. The questionnaire, full preview, and simple HTML and PDF download are free with no account. Generated terms are not legal advice.

Every app distributed through a major store already comes with some license terms, so the real question is whether that default covers what your app does. Usually it does not if your app has:

• accounts or logins, which need rules on security, suspension, and deletion
• subscriptions or in-app purchases, which need clear renewal and cancellation terms
• user content, such as posts, chats, reviews, or uploads
• community or multiplayer features, which need conduct rules and moderation
• a connected service, such as a web dashboard, API, or cloud sync

A simple offline utility with no accounts or purchases may be adequately served by the store license. Almost everything else benefits from your own terms of service, because store licenses deal with the software, not with how you run the service around it.

The same feature-by-feature logic applies to privacy. If you are still building that side, read how to make a privacy policy for an app, because the store listing will ask for a privacy policy URL before it asks about terms.

Apple's Licensed Application End User License Agreement, known as the Standard EULA, opens with a simple statement: apps made available through the App Store are licensed, not sold. According to App Store Connect Help, Apple applies it in all countries and regions whenever you do not provide a custom EULA.

The Standard EULA covers software license basics:

• a non-transferable license to use the app on Apple-branded products the user owns or controls, subject to Apple's usage rules
• restrictions on copying, reverse engineering, and redistribution, except where law permits
• permission for the licensor to collect technical data used for updates and support
• termination of the license if the user breaks its terms
• warranty disclaimers and liability limits

What it does not cover is your service. It says nothing about your account rules, community guidelines, subscription tiers, moderation process, or when you may suspend a user. For anything beyond the license itself, you need terms of service of your own, linked from the app and its listing.

You can replace the Standard EULA by entering a custom license agreement in App Store Connect, under App Information. Apple accepts plain text only, strips HTML, and lets you choose the countries or regions where it applies.

Consider a custom EULA when:

• your license terms differ materially, for example business-only use or seat limits
• you need license restrictions the Standard EULA does not include
• you want one document combining license and service terms for iOS users

A custom EULA must meet Apple's minimum terms for developer EULAs. Among other points, it has to:

1. acknowledge that the agreement is between you and the user, not Apple
2. state that you, not Apple, are responsible for maintenance and support
3. make you responsible for product claims and intellectual property claims
4. include your name, address, and contact details
5. name Apple and its subsidiaries as third-party beneficiaries

Many developers find it simpler to keep the Standard EULA for the license and publish separate terms of service for the service, an approach that also works on Android and the web.

Google Play works differently. Section 5.3 of the Google Play Developer Distribution Agreement lets you attach your own end user license agreement to your app, says the Distribution Agreement prevails if the two conflict, and states that Google is not responsible for your EULA's terms. The agreement also makes you responsible for supporting and maintaining your app and for handling user complaints about it.

For users, Google Play's own terms grant a basic license to use content obtained through Play, and they note that apps may come with additional terms from the developer.

In practice, most Android developers:

• publish terms of service at a stable public URL
• link them from the Play listing description or the developer website
• show them inside the app at signup and in settings

If you ship on both platforms, one set of terms of service can usually cover both, with channel-specific paragraphs where billing, refunds, or store rules differ. The App Terms of Service generator builds that structure from your answers, so iOS and Android users read one coherent agreement.

Billing is where app terms most often go wrong, because the store, not you, runs much of the transaction.

• Say who bills. Purchases through Apple or Google Play are processed by the store under its terms. Purchases on your website through a provider such as Stripe follow your own terms.
• Describe cancellation accurately. Store subscriptions are typically managed and cancelled in the user's store account settings. Tell users where to go.
• Do not promise refunds you cannot issue. Refunds for store purchases run through the store's processes. State your own refund policy only for channels you control.
• Explain the offer before purchase. Apple's guideline 3.1.2(c) asks you to describe clearly what users get for the price before asking them to subscribe.
• Link terms and privacy policy in the app. For auto-renewable subscriptions, Apple's developer agreement requires these links to be accessible within the app, and App Review commonly checks the listing for a terms link too.

US law adds rules for recurring charges, including the Restore Online Shoppers' Confidence Act and California's automatic renewal law. Legal Policy Generator's subscription and auto-renewal sections, including California wording, activate when your answers show recurring billing.

If users can post, chat, share, or upload, your terms need rules for that content, and Apple's App Review Guidelines set a floor. Guideline 1.2 requires apps with user-generated content or social networking services to include:

• a method for filtering objectionable material from being posted
• a mechanism to report offensive content, with timely responses
• the ability to block abusive users
• published contact information so users can reach you

The guideline also says it is your responsibility to remove content that violates the guidelines, your terms of service, or your community standards, which assumes you have terms to point to.

Your app terms should therefore cover:

• who owns user content and the license you need to display it
• prohibited content and conduct
• how reports are handled and which actions you may take
• how users can appeal or complain

If the app is offered in the EU, the Digital Services Act also requires your terms to describe content restrictions and moderation procedures. Games with chat or user-created levels face the same questions; see the privacy policy guide for games for the data side.

App terms should say when you can suspend or close an account, what happens to purchases and content, and how users can leave.

• Your right to suspend or terminate: tie it to defined breaches, such as fraud, abuse, or repeated infringement, and say whether you will give notice where practical.
• The user's right to leave: Apple requires apps that support account creation to offer account deletion within the app, and Google Play requires apps that allow account creation to offer deletion both in the app and through a web link. Your terms should point to that route.
• What happens to paid content: be honest about unused credit, virtual items, or subscriptions after termination. Store subscriptions may need to be cancelled separately in the store account, so say so plainly.
• What survives termination: license restrictions, liability limits, and dispute clauses commonly continue.

Keep the deletion wording consistent with your privacy policy's retention section. If one document says data is deleted immediately and the other says 90 days, you have created a contradiction that users, reviewers, and regulators can all find.