Supabase and Apple Public Pages: privacy policy and support details

Map the Supabase architecture first

A useful page starts with a data-flow inventory, not a vendor name. Write down each Supabase capability in your deployed project and the path from the iOS client to the service.

• Supabase Auth: account credentials, provider identifiers, email addresses, or other login attributes may be stored when you enable those methods.
• Postgres tables: application records are entirely your schema. Profile fields, messages, orders, preferences, or support data are not implied by the Supabase SDK; inspect your migrations and inserts.
• Storage: avatars, attachments, documents, and media depend on the buckets and upload paths your app exposes.
• Realtime: subscriptions can deliver changes from your tables, but the data categories still come from the rows you publish.
• Edge Functions or other services: server-side calls may forward data to payment, analytics, email, or AI providers that need their own disclosure.

The privacy policy Public Page should identify Supabase as a service provider where it processes data for your app, but it should also name your categories and purposes. “We use Supabase” is not a meaningful account of what happens to a user's data. Conversely, do not copy a Supabase feature list into the policy if your app never enables Auth, Storage, or realtime.

Handle Auth as configuration-dependent

Supabase Auth is optional, so the first question is whether your app actually offers accounts through it. If it does, document the account identifier and the sign-in attributes your enabled methods use. Email login can involve an email address; anonymous or OAuth flows can create different records. If you attach a display name, avatar URL, provider subject, or custom claims, include those only when your code sends or stores them.

Your policy should explain why Auth data is used: creating and securing the account, signing the user in, associating app content with the account, sending account messages, or preventing abuse. If you use magic links or password resets, explain the delivery channel without exposing tokens or operational details. If you use an identity provider, distinguish the provider's role from Supabase's role and link users to the relevant provider policy through your normal legal review process.

The catalog table on this page is generated from Declora's Supabase Service Profile. It suggests an application-functionality purpose and, when Auth is enabled, a user ID; email is configuration-dependent. Those are prompts for confirmation, not declarations made solely because the Supabase package is installed.

Explain your database and Storage behavior

A user should be able to understand what happens to the content they create. List the data categories in your tables in ordinary language: for example, profile information, preferences, posts, messages, or purchase entitlements. Say whether the data is required for a feature, how it is linked to an account, and who can access it through the app.

For Storage, describe uploads separately from database rows. An avatar or attachment can contain personal information even when the file path contains only a generated ID. Explain the purpose of the upload, any visibility setting, and what happens when a user replaces or deletes it. If your Storage bucket is public, do not call the content private. Test the URL behavior from a logged-out browser before publishing that claim.

Row Level Security is an important implementation control, but it is not a disclosure category. You can mention that access rules are used to limit data access if that is accurate, yet the policy still needs to explain the information collected. A policy that says “data is secured by RLS” while a public bucket exposes user files gives the wrong assurance.

Build Apple-friendly public access

Your privacy policy URL in App Store Connect must resolve to a stable page that a reviewer and a user can open. The page should identify the app and developer, state an effective or last-updated date, explain the categories and purposes, name relevant service providers, and give a contact method for privacy questions. Keep the URL on the same canonical domain you use in your listing, and test it over HTTPS on mobile and desktop.

The support Public Page should be operational rather than decorative. Include a monitored email or form, the app name, and instructions for account, login, missing content, and data questions. Do not require a user to sign in to report that they cannot sign in. Ask users not to send passwords, one-time codes, or private keys.

If the app creates accounts, your deletion instructions must describe the actual in-app path and what happens to Supabase Auth, Postgres rows, Storage objects, and downstream records. Apple does not consider a logout button or a support email alone to be a complete account-deletion control. A web page can explain the process and receive a request, but it should not replace the in-app initiation required for an account-creating app.

Keep the pages synchronized with implementation

Supabase schemas evolve quickly. Treat a migration, new bucket, Auth provider, or Edge Function as a documentation change. When you add a profile field, ask whether it is personal information, whether it is sent to Supabase, and whether a new purpose or retention period belongs in the policy. When you add a third-party call inside an Edge Function, update the provider list and the relevant store answers instead of assuming the backend makes it invisible.

A useful review checklist is:

1. Export or inspect production migrations and list user-linked columns.
2. List enabled Auth providers and the attributes each one creates.
3. Enumerate Storage buckets, visibility, and deletion behavior.
4. Trace realtime and function payloads to any outside service.
5. Test privacy, support, and deletion pages without logging in.
6. Compare the pages with confirmed Apple App Privacy answers and your app's behavior.

Common mistakes

• Declaring every Supabase feature instead of the features your app enables.
• Treating an Auth user ID as anonymous even though it links to a profile row.
• Forgetting Storage objects when describing deletion or user content.
• Publishing a privacy URL that works only after a dashboard login or redirects unexpectedly.
• Calling a support email an account-deletion flow when the app creates accounts.
• Assuming Row Level Security, private buckets, or a generated UUID removes the need to disclose the underlying data.

Where Declora fits

Declora's App Passport lets you confirm Supabase-specific App Facts such as whether Auth is enabled and whether email login is used, then keeps Apple Store Answers and Public Pages derived from that same set of facts. Its Consistency Check is useful when a schema or provider change makes one output stale. Review the generated pages and wording for your actual project at declora.app. Declora is not a law firm, does not provide legal advice, and cannot guarantee approval by Apple or any other reviewer.

FAQ

Does choosing Supabase mean I must declare email collection?

No. Supabase Auth is optional, and email depends on the authentication methods and fields your app actually uses. Confirm whether email login or email delivery is enabled, whether your own code stores the address, and whether another provider receives it before selecting a category or writing the policy.

Should my privacy page list Postgres columns one by one?

Not necessarily. Group columns into understandable categories and explain their purpose, account linkage, access, and retention. Keep enough detail for a user to understand what the app collects, and make sure the groups cover the real schema rather than a generic Supabase example.

Is a public Storage bucket compatible with a privacy policy that says uploads are private?

No. The page must match the deployed access behavior. Check bucket visibility and signed or public URLs from a logged-out session, then describe who can access uploaded content and how deletion works.

Can a Supabase deletion request replace in-app deletion on iOS?

No, not when the app lets users create accounts. Your app needs a findable in-app control that starts the deletion, and your backend must handle Auth, database, Storage, and downstream records according to your real process. A public page can explain the process and provide an additional request channel.

Does Declora inspect my Supabase project automatically?

No. Its Service Profile suggests facts and follow-up questions based on common configurations; you confirm production behavior. Declora helps align the resulting store answers and Public Pages, but it does not provide legal advice or guarantee store approval.