If you are launching a branded ordering app for your café, there is a step between “the app works” and “the app is live” that catches almost everyone: the privacy disclosures. Apple calls its version App Privacy — most people know them as privacy nutrition labels. Google calls its version the Data safety form. Neither is optional, both are your legal responsibility rather than your developer’s, and both are enforced against the app’s actual behaviour rather than your best guess.
The good news is that a café ordering app is one of the simpler cases in the entire App Store. You are not running an ad network. You are taking coffee orders. This guide walks through what both stores ask, what a typical Square-based ordering app actually collects, and the handful of places where owners get it wrong.
What are privacy labels and the Data safety form?
They are the same idea implemented twice. Both stores make you declare, in a structured form, what data your app collects and what you do with it. Both then render that declaration on your public store listing so a customer can read it before downloading.
Apple’s App Privacy lives in App Store Connect — open your app, choose App Privacy in the sidebar, and select Get Started. Apple is explicit that “this information is required to submit new apps and app updates to the App Store.” It renders on your product page under three headings: Data Used to Track You, Data Linked to You, and Data Not Linked to You.
Google’s Data safety form lives in Play Console on the App content page. Google’s rule is broader than most owners expect: “All developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open, or production testing tracks.” And critically — “Even developers with apps that do not collect any user data must complete this form and provide a link to their privacy policy.” There is no “we don’t collect anything, so skip it” exit.
One point deserves emphasis because it is the most common cause of an inaccurate declaration: third-party SDKs count as your collection. Apple’s guidance is that you “need to identify all of the data you or your third-party partners collect,” where partners include analytics tools, ad networks and third-party SDKs. If you dropped in a crash reporter and never thought about it again, it is still yours to declare.
What does a Square-based café ordering app actually collect?
Here is the honest map for a typical order-ahead app built on Square. Treat this as a starting point for your own audit, not a form you can copy. Both stores put the responsibility on you specifically because only you can see your build — as Google puts it, “Only you possess all the information required to complete the Data safety form.”
| What the app touches | Apple data category | Typically linked to identity? | Why it exists |
|---|---|---|---|
| Name | Contact Info | Yes | Calling the order out; receipts |
| Email or phone (login / OTP) | Contact Info | Yes | Authentication, order updates |
| Account ID | Identifiers → User ID | Yes | Tying orders and loyalty to a person |
| Order history | Purchases → Purchase History | Yes | Reorder, loyalty accrual, receipts |
| Push notification token | Identifiers → Device ID | Usually | Sending order-ready alerts |
| Crash & performance data | Diagnostics | Often not | Keeping the app from breaking |
| Store selection / pickup location | Location (coarse) | Varies | Choosing which shop to order from |
| Card number | Generally not declared | — | See below |
That last row is the one worth understanding, because it is the most commonly botched.
Why card numbers usually aren’t on your label
Square’s In-App Payments SDK tokenizes the card on the device: as Square describes it, “the SDK tokenizes those details and returns a nonce, which is a single-use token that refers to the credit card details,” with the result that “developers don’t need to deal with raw credit card information, which is kept out of PCI scope.”
The practical consequence is that a typical café app declares Purchases → Purchase History and not Financial Info → Payment Info, because the card number never reaches your servers. With Apple Pay or Google Pay the number is never exposed to the app at all.
Be precise here rather than sweeping: the card digits do pass through Square’s own card-entry UI on the device before tokenization. The accurate sentence is “card numbers never reach our servers,” not “card numbers never touch the app.” If you are unsure how your build handles this, ask your developer before you tick a box you are attesting to.
Do you need the App Tracking Transparency prompt?
Usually no — and this is where a lot of café apps over-declare out of caution, which is its own kind of inaccuracy.
Apple’s definition is specific: “Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.”
Read that carefully. Knowing that Dave buys a flat white every Tuesday, and sending Dave a push notification about flat whites, is not tracking. It is first-party data about your own customer in your own app. Tracking is when that data gets joined with data from other companies’ properties for advertising.
If you do track, App Tracking Transparency applies: “you need to receive the user’s permission through the AppTrackingTransparency (ATT) framework in order to track them or access their device’s advertising identifier,” along with a purpose string explaining why. Note the direction of causation — doing the tracking is what requires the prompt; the label is just where you disclose it. And Apple closes the obvious loophole: hashing an email to use as an advertising identifier still requires the ATT prompt, and an ad SDK that combines your users’ data with other developers’ apps counts as tracking “even if you don’t use the SDK for these purposes.”
The upshot for most cafés: a plain order-ahead, loyalty and push notification app has no reason to track, needs no ATT prompt, and should declare nothing under Data Used to Track You. Add an advertising SDK and you have changed your answer.
The requirements owners forget
Four things sit outside the two forms but block a launch just as effectively.
1. The privacy policy goes in two places, not one. Both stores require it in the store metadata and inside the app. Apple’s guideline 5.1.1(i): “All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner.” Google’s: “You must link to a privacy policy on your app’s store listing page and within your app.” The in-app half is the one people miss.
2. Your policy has to actually say the required things. Apple expects it to identify what data is collected and how, confirm that third parties provide equal protection, and “explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user’s data.” A three-line policy will not clear this.
3. Account deletion needs two paths. If users can create an account in your app — and an OTP login is squarely an account — Google requires that you “provide users with an in-app path to delete their app accounts and associated data” and “provide a web link resource where users can request app account deletion and associated data deletion.” That web link goes into the Data safety form. This has been in force since 2024; it is a settled baseline, not something coming down the pipe.
4. Encryption in transit and optional-collection flags. The Data safety form asks whether all user data is encrypted in transit and whether each data type’s collection is optional or required. Any competently built app is using HTTPS throughout, but you still have to say so.
What happens if you get it wrong?
Let’s be accurate rather than alarming, because the internet is full of overstatement here.
Google’s stated position: “When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action,” and “Apps that don’t become compliant are subject to policy enforcement, like blocked updates or removal from Google Play.” Worth noting what Google explicitly does not claim — it does not systematically verify your form against your code. It disclaims that role: “we cannot make determinations on behalf of the developers of how they handle user data.” Enforcement follows discovery.
On Apple’s side, when you publish your App Privacy answers you agree that they “are accurate, comply with the App Review Guidelines and applicable law, and that you will promptly update your responses if your data practices change.” That attestation is the mechanism — an inaccurate label is a breach of a commitment you made, wrapped inside a review process that already rejects apps for incomplete or misleading metadata. Inaccurate privacy disclosures show up regularly among the reasons a first submission gets bounced, which is why publishing to the App Store and Google Play is worth treating as its own project step rather than an afterthought.
The realistic risk for an honest café app is not a dramatic takedown. It is a rejected first submission that costs you a week, right when you told your regulars the app was coming.
Keeping it accurate after launch
The declarations are living documents. Apple is clear: “You’re responsible for keeping your responses accurate and up to date… You may update your answers at any time, and you do not need to submit an app update in order to change your answers.”
So build one habit: any time someone adds an SDK, re-open both forms. The realistic triggers for a café are adding analytics, adding a crash reporter, adding a marketing or attribution tool, or turning on a feature that asks for location. Each of those can silently change what is true about your app while your label keeps saying the old thing.
One 2026 change worth a glance if — and only if — your app uses precise location: Google’s April 2026 policy update introduced “the location button as the recommended minimum scope for precise location” and added guidance on precise versus approximate location disclosures in the Data safety section. Most café apps need coarse location at most, for picking a store, so this likely does not touch you. Nothing else in the 2025–2026 store policy cycle changes the baseline for an ordering app.
Who fills this in if a vendor builds your app?
Ask three questions before you sign anything, because the answers determine how much of this lands on your desk.
- Who owns the developer accounts? This decides who can edit the declarations, and it matters far more if you ever change vendors.
- What do the app and every one of its SDKs collect? You need a real list, not a reassurance. You are the one attesting.
- Can I see the completed forms before submission? A vendor who has done this before will have a standard, accurate answer ready in minutes.
A good white-label provider treats the privacy disclosures as part of shipping, not as your homework. This is one of the quieter arguments for building on infrastructure that already handles payments properly: when Square tokenizes the card, the highest-stakes category on the whole form answers itself.
That is the approach Tany takes — branded iOS and Android ordering apps built on your existing Square POS, with the store listings, disclosures and review process handled as part of the launch, at $99 CAD/month per location. But the principles above hold no matter who builds your app, and you should be able to answer “what does my app collect?” yourself either way.
Wrap up
Privacy disclosures are a paperwork problem that looks like a legal problem. For a café ordering app the substance is genuinely small: you collect a name, a login identifier, an order history, a push token and some crash data; you don’t handle raw card numbers because Square tokenizes them; and you almost certainly don’t track anyone.
Write that down accurately, publish a real privacy policy at a stable URL and link it in both places, ship the two account deletion paths, and re-check the forms whenever an SDK changes. That is the whole job — and doing it properly the first time is the difference between launching on schedule and explaining to your regulars why the app slipped another week.
Sources
- Apple — App Privacy Details on the App Store
- Apple — Manage app privacy (App Store Connect Help)
- Apple — User Privacy and Data Use (App Tracking Transparency)
- Apple — App Review Guidelines
- Google Play — Provide information for Google Play’s Data safety section
- Google Play — App account deletion requirements
- Google Play — User Data policy
- Google Play — Policy announcement, April 2026 (location & contacts permissions)
- Square — Introducing the In-App Payments SDK (tokenization and PCI scope)