Privacy Policy for MyApp Studio

Last updated: October 18, 2026

This Privacy Policy explains how MyApp Studio, a product of Clearbrook Software LLC ("the App," "we," "us," or "our"), collects, uses, stores, and shares information when you use our Android and iOS applications, related backend services, and our marketing website (myappstudio.app).

MyApp Studio is an AI-powered app builder. You describe an app you want by voice or text, and the App generates a working mini-application ("a MyApp") that runs inside MyApp Studio. On Android, a MyApp can optionally be pinned to your home screen as its own launcher icon, which opens it directly inside MyApp Studio.

1. Information We Collect

1.1 Account Information

We use Google Sign-In and, on iOS, Sign in with Apple (both via Firebase Authentication) as the only ways to sign in. When you sign in, we receive and store:

• Your account's user ID, as provided by Google or Apple
• Your name and email address, as provided by the sign-in provider. With Sign in with Apple, you can choose Apple's Hide My Email option, in which case we receive Apple's private relay address instead of your real email address; Apple also only shares your name and email on your first sign-in.

We do not have or use any other login method, and we never receive your Google or Apple password.

Alongside your account we also store: which version of these Terms and this Privacy Policy you accepted and when, whether you have agreed to the AI data-sharing described in Section 7, your onboarding progress and the order of the MyApps in your app list, and the email addresses of any users you have blocked (Section 1.7).

1.2 Content You Create

To build and edit your MyApps, we collect and store:

• The prompts describing the MyApp you want to build or change: the text you type, or — in voice mode — the transcript your device produces from what you say (we never receive the audio itself; see "Voice input" below)
• The generated application data itself: app names, themes, table/column definitions, and the row data you enter into your MyApps (e.g., a workout log's exercise names and rep counts, or photos you take with your camera, or choose from your device, for an image field, which are compressed before being stored as part of that MyApp's data)
• Custom code generated for "custom" view types (HTML/CSS/JavaScript produced by the AI to render your MyApp)
• Metadata about elements you tap on in the live preview (e.g., which column or row you selected), sent to power AI-assisted, targeted edits
• The contents of a file you choose to send into one of your MyApps. Some MyApps are built to accept a file — a spreadsheet export (.csv, .tsv), a text, Markdown or JSON file, a contact card (.vcf), or a calendar file (.ics) — which you send from another app using your phone's own share or "open in" sheet. You pick the file and which MyApp receives it (if only one of your MyApps accepts that kind of file, it goes straight there); nothing is read that you did not send, and the App never browses your device's files, photos, contacts or calendar on its own. What the file contained then becomes that MyApp's data, stored and handled exactly like anything else you enter into it (Sections 1.3 and 1.4)
• A link, a piece of text, or a contact you choose to share into one of your MyApps. Some MyApps are built to accept a link — for example a recipe page shared from your browser — or text shared from a message, note or email. As with files, you pick what to share and which MyApp receives it, and what you choose to keep becomes that MyApp's data; an entry made from a link keeps the link itself. On iPhone, what you share is passed to MyApp Studio through a temporary storage area on your device that only MyApp Studio can read; it is deleted when MyApp Studio opens it, and anything left unopened for more than 30 minutes is never used and is discarded the next time MyApp Studio or its share option runs. If you ask a MyApp to get a link's contents (for example "Get the recipe"), your device downloads that one page directly from the website — identifying itself as a mobile web browser — so that website sees the request, including your device's IP address, as coming from your device, and can set cookies that are kept inside MyApp Studio (separately from your web browser); our servers do not fetch it. The page is read on your device, and its text, together with the link and the page's title, is sent to our backend and to Google's Gemini models only if that MyApp then uses an AI-powered lookup (Section 1.2.1) to turn it into entries — in which case it is handled like any other AI lookup input
• To avoid importing the same share twice, the App keeps a short list of the last few things you shared in (a reference to each file, or a one-way fingerprint of shared text) on your device only; it is never sent to us and is cleared when you log out from the account menu

Voice input: If you use voice mode, your speech is transcribed into text by your device's built-in speech recognition service (on Android, the system speech recognizer, typically provided by Google; on iOS, Apple's speech recognition service). Depending on your device and its settings, that platform service may process the audio on-device or on the platform provider's (Google's or Apple's) servers, according to your device's own configuration and the platform provider's terms. Your raw voice audio is never sent to our backend; only the resulting text transcript is, and from there it is handled exactly like a typed prompt. To speak the assistant's replies aloud, the reply text is sent through our backend to Google's Gemini text-to-speech model, which generates the audio played back to you. We do not record or retain raw audio recordings; the text transcripts and responses are what gets stored as part of your conversation and app data.

Before the microphone is ever activated, the App shows an in-app "Use Microphone" / "Type instead" prompt — your microphone is never opened automatically, and the operating system's microphone permission dialog is never triggered, without you first explicitly choosing "Use Microphone" in this prompt. This in-app confirmation is requested again every time you switch from typing back to voice mode, not just the first time.

The App requests camera access only so that generated MyApps can offer to take a photo for an image field. (Some MyApps built earlier also read a barcode from the camera image, entirely on your device; that feature is removed the next time the assistant successfully rebuilds such a MyApp.) MyApp Studio no longer builds MyApps that open your photo library or files; some MyApps built earlier offer to pick a photo or file, which opens your phone's own picker so you choose what to add, and that option is removed the next time the assistant successfully rebuilds such a MyApp. The App never reads your photo library or files on its own.

Device actions: a MyApp can offer buttons that open your phone's dialer, text-message or email composer, maps app, web browser or share sheet, pre-filled with values from that MyApp. For a call, message, email or share, nothing is sent until you complete it yourself in that app; a map search or web page opens straight away, so the maps service or website receives the search or request as soon as you tap. We receive nothing from any of these. A map search opens in Apple Maps on iOS, and in your maps app or Google Maps on Android.

1.2.1 AI-Powered Runtime Lookups ("AI Actions")

Some MyApps include an opt-in feature that looks up data from AI — and, for certain lookups, from web search — while you're using the app: for example, a food log that fills in nutrition facts when you type a food name, or a recipe app that generates timer steps for a dish. This feature exists in a MyApp either because you saw and approved it as part of the build plan when creating or modifying that app — it is never added silently to an app you build — or because it came with a MyApp another user shared with you, or is part of a group MyApp you joined (including lookups the group's creator adds after you join — Section 1.7), in which case the AI data-sharing consent you gave when you first signed in (Section 7) is what covers it. Either way, you can see which lookups a MyApp uses, and every use counts toward the daily AI usage allowance (Section 1.6) of whoever runs it — in a group MyApp, that is the member on whose device the lookup runs, not the group's creator.

When you trigger one of these lookups:

• What the MyApp gives that lookup as its input is sent to Google's Gemini models to generate the requested result. Usually that is the value(s) you entered into the lookup's input field (e.g., a food name, a recipe title) — including when that field belongs to an entry you are adding to a personal table (Section 1.4), such as the food you are logging in a food diary — but a MyApp can also be built to give a lookup entries already in its non-personal tables, or a link, file or text you shared into it (Section 1.2) — for example, to suggest meals from a pantry list.
• For lookups marked as needing current information ("grounded" lookups — e.g., a price or availability check), that input is also used to perform a Google Search, and the search results are used to ground Gemini's answer. Non-grounded lookups do not use Google Search.
• We log the actual request text sent to Gemini and the actual response returned to your MyApp for these lookups (not just a summary) — see Section 1.5.

Data in a MyApp that a lookup is not given as its input is not sent to Gemini or Google Search by this feature. MyApps are built so that a lookup is not given entries already saved in a personal table, or anything calculated from them — subject to the limits described in Section 1.4. In a group MyApp, in addition, a lookup can be built to read from the group's shared tables, so its input can include content any member entered there — including rows other members added — along with members' display names and which rows are whose (Section 1.7).

To avoid repeating identical lookups, we keep the results of short lookups (for example, the nutrition facts for "banana") in a shared cache keyed by a one-way fingerprint of the input, and return a cached result to anyone who makes the same lookup. The cache does not record who made a lookup or the input itself, so it is not linked to your account. Lookups whose input is longer than about 1,000 characters (such as the text of most pages you share in) are never cached. A cached result can repeat what its input said, and cached results are kept indefinitely.

1.3 Application Data Storage

All MyApps you build, including their schema, custom code, and the data you enter into them (table rows, form submissions, etc.), are stored in:

• Locally on your device, in the App's private local storage, so the app works offline.
• Remotely, in our Google Firestore database, tied to your account's user ID, so your MyApps sync across your devices.

Two kinds of MyApp data are also stored outside your account: the copy kept with a share link you create (Section 1.7), and the shared tables of a group MyApp, which belong to the group rather than to any one member (Section 1.7).

1.4 End-to-End Encryption of Personal Table Data

When a table inside a MyApp is identified as personal — for example a journal, mood log, or health measurement tracker — the row content of that table is end-to-end encrypted on your device before it is stored or synced (the one exception, a value you hand to an AI-powered lookup while entering it, is described below):

This classification is made automatically by the AI as it designs your MyApp (based on cues like "journal," "log," or "history" versus static reference content such as recipes or presets), not something you manually tag yourself. It's a best-effort classification: the AI can occasionally misclassify a table (marking personal content as non-personal, or vice versa), so we cannot guarantee that every sensitive table you create will be encrypted, or that every encrypted table actually contains sensitive data. If a table is misclassified, you can ask the AI assistant to fix the classification as a follow-up edit, the same way you'd request any other change to your MyApp.

• Each device generates an AES-256 encryption key, protected by your device's secure, operating-system-managed credential storage (the Android Keystore system on Android; the Keychain on iOS), with no setup required.
• Personal table row values are encrypted (AES-256-GCM) on-device prior to being saved locally or synced to Firestore. Column/table structure (names, types) is not encrypted, since the AI needs to see the shape of your data to build and edit the MyApp — only the row content is opaque.
• Our backend and Firestore database only ever see ciphertext for these rows. When the AI model regenerates or modifies a MyApp's schema, the backend always discards whatever the model echoed back for personal rows and restores your real (still-encrypted) data instead — saved personal row content is never sent to, or reconstructed by, the Gemini model when it builds or edits your MyApp. Before a personal table is included as context in any AI prompt, its rows are replaced with a placeholder (e.g., "[personal data omitted: 4 encrypted row(s)]").
• Multi-device sync is opt-in. By default, your encryption key lives only on your device, protected by that device's OS-managed credential storage — personal data will not appear on a second device until you explicitly enable sync. If you choose to enable it, you set a passphrase; your key is then wrapped using that passphrase and the wrapped (still-encrypted) copy is stored on our servers so you can unlock it on another device. We never transmit or store your passphrase itself, and we cannot derive your encryption key or read your personal data without it. If you forget your passphrase, your personal data cannot be recovered by you or by us.
• To detect when a device holds a different encryption key than the one your account's data was encrypted with (for example, after signing in on a new device), we store a one-way cryptographic fingerprint (SHA-256 hash) of your encryption key on our servers. This fingerprint cannot be reversed to recover the key and reveals nothing about your data; it only lets your devices recognize whether their local key matches your account's.

Encryption protects what is saved in a personal table. It does not apply at the moment you use an AI-powered lookup (Section 1.2.1): if you tap a lookup while entering something — for example, looking up the calories of a food you are logging in a personal food diary — what you entered is sent to Gemini and recorded in our logs as that lookup's request (Section 1.5), even though the entry is then saved encrypted. MyApp Studio builds MyApps so that a lookup never reads back entries already saved in a personal table, or totals or summaries calculated from them. That rule is applied when a MyApp is built or edited, so a MyApp built before October 2026 may not follow it until its next edit, and because MyApps are generated by AI we cannot guarantee that every MyApp follows it.

Tables not classified as personal are not end-to-end encrypted and are visible to our backend and AI models in the ordinary course of generating and editing your MyApp, as described elsewhere in this policy.

1.5 Usage and Activity Logs

We maintain the following operational logs, all of which are accessible only to us (no third party) and used to run, debug, and manage the cost of the service:

• Per-user activity log (/users/{uid}/logs): every create/chat/AI-lookup action you take is logged with a timestamp, an action label (e.g. "chat", "create", or which AI lookup you used), the relevant app ID, and AI token counts. This log does not store your prompt text or any AI response content.
• Pipeline event log (eventLogs): a more granular, cross-user log capturing each step of the AI generation pipeline (chat, design, coding, automated QA checks, AI quality review, text-to-speech, AI-powered runtime lookups ("AI Actions," Section 1.2.1)), along with share-link and reaction activity (Section 1.7), the fact that you opened a MyApp (normally once per MyApp per day on each device), and errors reported automatically by a running MyApp or by the App's own sync and on-device reminder components (for reminders, only timing and status information — never the reminder's text), each tagged with your account ID, app ID, outcome (success/failure), AI model and cost, and — for troubleshooting — a truncated prompt summary (first 200 characters) and, on failure, error/diagnostic detail (up to 2,000 characters, which may include an error message and code-level stack trace). For AI-powered runtime lookups specifically, we additionally log the actual request text sent to Gemini and the actual response returned to your MyApp (each capped at 10,000 characters), which can include a link you shared into that MyApp and the text of its page (Section 1.2) — unlike other pipeline steps, where only a short summary is kept — because these are structured, typed calls scoped to a single action you approved, rather than open-ended chat. This log powers an internal admin analytics dashboard (usage, cost, and failure trends) that only we, as operators, can access via an admin-restricted account; it is not exposed to other users or third parties.
• Flag log (flags): if you flag a MyApp for review, we record the app, your account ID and email, the app owner's account ID and email (if it's not your own app), and the reason you provided, and send an email alert to the developer. We review flagged reports within 24 hours. If we restrict a MyApp after review, its owner receives a notification saying so; it does not say who flagged it. If you report another member of a group MyApp (Section 1.7), the report records the group, your account ID and email, the reported member's account ID and email, the group creator's account ID, your reason, and a copy of up to 20 of the reported member's most recent rows in the group's shared tables (ones they added or last changed), so we can see what was written; it is emailed to us the same way and reviewed within 24 hours. The reported member is not told who reported them.
• Feedback (feedback): if you send us feedback from within the App, we store your account ID, email address, the MyApp it concerns (if any), and your message, and email a copy to our support inbox. Rating the AI assistant's reply (👍 or 👎) sends feedback the same way, with the text of that reply as the message. If we reply, the reply is stored with your feedback and delivered to you as an in-app notification.

Because personal table rows are end-to-end encrypted before they reach our backend (Section 1.4), the saved content of those tables is never present in any of these logs. A prompt summary, or an AI lookup's logged request/response, could include personal information only if you directly typed or spoke it into a chat prompt or a lookup's input field (including a field of an entry you were adding to a personal table when you used the lookup, Section 1.4), or it was in an entry in one of the MyApp's non-personal tables that the MyApp gave a lookup as its input (Section 1.2.1), or you asked a MyApp to use an AI lookup on a link, file or text you shared into it (Section 1.2) — in which case that link and that page's, file's or text's contents are part of the logged request (as opposed to entering it into an encrypted personal table) — or, in a group MyApp, a lookup run on any member's device used content from the group's shared tables (Section 1.7), which is then part of that member's logged request.

1.6 App Slot and AI Usage Data

The App tracks usage against free and subscription allowances: every account is granted a starting allotment of app creations ("app slots") and a daily allowance of AI-powered features, and we store and update:

• How many app slots your account has used out of its allotment (/users/{uid}/billing/account)
• A durable record, keyed on your account's email address or phone number rather than your account ID (it also notes the account ID that most recently used it), of how many app slots that identity has ever used, when the App first saw that email address or phone number (which can decide whether an introductory allotment applies), and, once changes are counted across your apps, the time of each change it made in the last 12 months — retained so the free allotment cannot be re-claimed by deleting and recreating an account (Section 4). Entries older than 12 months are removed by a routine cleanup, normally within a day.
• Your AI usage against the daily allowance and, internally, the dollar cost of that usage — an operational cost/abuse-prevention measure, not something billed or shown to you as a spendable balance

1.6.1 Optional Subscriptions and Purchases

Where the App offers an optional subscription, the purchase is made and paid through Apple (App Store) or Google (Google Play); we never receive or store your card number, bank details or other payment credentials. To honour the subscription we use RevenueCat (RevenueCat, Inc.), a subscription-management service that acts as our processor, and your MyApp Studio account ID is your customer ID there. RevenueCat receives information in the situations below, whether or not you go on to subscribe, and also receives your account ID when we ask it to delete any record it holds after you delete your account (Section 4):

• When you open the subscription screen, buy a subscription or restore purchases, the App links your account ID to RevenueCat, and RevenueCat's software development kit sends it technical information from your device, such as an anonymous identifier, device and operating-system type, app version, country and IP address. While the App remains open, it then updates that link if you sign in or out.
• When we check whether you have a subscription — if you reach the limit of your free apps or changes on a version of the App that offers subscriptions, or when a stored subscription has expired — our servers ask RevenueCat about your account ID, which creates a customer record there for it if none existed.

If you subscribe, RevenueCat also receives, from Apple or Google, what is needed to confirm what you bought: the product and store, purchase, renewal and expiry dates and subscription status. From RevenueCat we store, in your account's private billing record (/users/{uid}/billing/account), whether you have an active subscription and its plan, product, store, current period, expiry, whether it will renew, and when we last checked. In the durable slot record described in Section 1.6 we also store, for subscription apps, the times of those created in the last 12 months (which is how the plan's rolling limits are counted) and the total number ever created with a subscription. Apple and Google keep your purchase and payment history under their own privacy policies.

1.7 Sharing Features

If you choose to share a MyApp, the App creates a share link. We store a copy of the shared MyApp's data alongside that link, together with your email address and the display name from your sign-in provider. A link stops working when it expires (after 30 days) or when you replace it, but the stored copy is kept until you delete your account (Section 4). We do not collect recipients' email addresses when you create a link — a link is delivered by you, over whatever channel you choose, and anyone who opens it while signed in receives their own copy of the MyApp into their account inbox. The copy includes the rows of the MyApp's tables, except personal tables (below) and any other tables you choose to exclude under "Advanced" in the share dialog.

What recipients see about you. Anyone who opens your link is shown the MyApp's name and your display name. Your email address is stored with the copy they receive, because blocking works by email address, and it is shown to them in two cases: if your sign-in provider did not give us a display name for you (this can happen with Sign in with Apple, in which case it may be Apple's private relay address), and for MyApps shared before we began recording display names. If a recipient blocks you, the notification confirming the block, and their list of blocked users, show your email address.

What senders see about recipients. If you accept a MyApp someone shared with you, or send its creator a ❤️ reaction, the person who shared it is notified in the App and by push notification, and that notification includes your email address.

Personal tables are always excluded from shares. When you share a MyApp, any table the AI has classified as personal (Section 1.4) is left out of the copy sent to the recipient — they receive the table structure but no rows. This is enforced on our servers regardless of what the sending device asks for, and the share dialog shows those tables as locked rather than offering to include them.

Blocking and flagging. You can block another user (from the Sharing Settings screen, or when declining a shared app); this also immediately removes any apps that user has already shared with you from your library. You can also flag any MyApp in your library — your own or one shared with you — for our review; if the flagged app came from another user, flagging it also blocks that user and removes their other apps from your library, the same as blocking them directly. You're shown this consequence in the app before you confirm either action. You can also turn off incoming shares entirely in Sharing Settings.

Group MyApps work differently, and the difference matters for your privacy. Everything above describes sending someone a copy of a MyApp: they get their own, and the two diverge from that moment. A group MyApp is the other thing — one app that several invited people use at the same time, where some tables are shared and every member sees the same rows as they are added.

• The contents of a group MyApp's shared tables are readable by us. This is the important difference from a personal MyApp. Personal tables (Section 1.4) are encrypted on your device with a key we never receive, so we cannot read them. A shared table cannot work that way: its rows have to be delivered to every other member's phone, and no key exists that all of them hold and we do not. Shared tables are therefore never classified as personal, and their contents are stored in our database in a form we can read, protected by access rules that limit them to the group's members rather than by encryption. If something is too sensitive for that, keep it in a personal MyApp, or in one of the group app's private tables.
• Private tables inside a group MyApp stay yours. A group MyApp can also contain tables that are yours alone — your own notes, your own reminders. Those are stored under your account like any other MyApp's tables, are not sent to other members, and if the AI classified them as personal they are encrypted exactly as described in Section 1.4. If you leave a group, are removed from it, or the group is deleted, your copy of the app is removed from your library, and with it the contents of your private tables in that app.
• What other members can see about you. Every member of a group can see the display name your sign-in provider gave us when you joined, everything you enter into that group's shared tables, and which rows you added or last changed, and when. Members can also see the internal account identifiers of the group's other members, but not their email addresses — with these exceptions. When you join a group, its creator is notified, and that notification includes your email address. And the creator's email address is stored with each member's copy of the app, as it is with a shared copy (above), and is shown to members if the creator has no display name on file, or to a member who blocks the creator (or flags the group app), as described above for shared copies.
• What the group's creator controls. Whoever created the group can invite people, remove a member (or remove and ban them, so that no invite link to that group lets them back in), edit or delete rows in the shared tables (depending on how the app was built), change the app, and delete the group for everyone. Only the creator can change a group app; when they do, its design (never another member's rows) is sent to Gemini as described in Section 3. If the creator, while editing, taps an element on screen to ask the AI about it, details of that element are included in the request — up to 30 characters of its visible text on a custom screen, or the label and value of a tapped chart bar — and these can come from a shared row.
• AI lookups in a group MyApp. A group MyApp can include AI-powered lookups (Section 1.2.1), and its creator can add them after you join — the join screen in current versions of the App says so. A lookup runs on a member's own device, and when it does, it can use content from the group's shared tables as its input — including rows you added, and members' display names and which rows are whose — which is then sent to Google's Gemini (and, for grounded lookups, used in a Google Search) and logged with the request, as described in Sections 1.2.1 and 1.5. That log entry belongs to the member on whose device the lookup ran and counts toward their daily AI allowance, not yours; because it is their record, deleting your account does not remove your content from it (Section 4), nor from a cached result of a short lookup, which is linked to no one (Section 1.2.1). Content in your private tables in a group MyApp, and anything in a personal table, is never part of another member's lookup. If something you would put in a shared table should not be sent to an AI provider at another member's request, keep it out of the group.
• Invite links. A group invite link stores no copy of the app's data; a member's copy is built from the live app when they join. Anyone holding the link — it can be forwarded — can see the app's name and the creator's display name without signing in, and can join while it is valid (30 days, unless the creator replaces it), up to the group's member limit. The creator's email address is stored with the invite but not shown on it.
• Leaving and being removed. Rows you added to a group's shared tables remain part of the group after you leave or are removed, still recorded as yours, so the remaining members keep the group's records. They are de-attributed only if you delete your account (Section 4).
• Reporting and blocking other members. From the group's member list, anyone in a group can report another member to us (see the flag log in Section 1.5) or block them — including someone who has left but whose rows are still in the group. Blocking a member hides the rows they add or edit in shared tables from your view, in every group you are both in — everyone else still sees them — refuses anything they share with you or invite you to, removes MyApps they already shared with you, and takes you out of any group they created. It is recorded with the display name they had in the group, never their email address, and you can undo it in Sharing Settings. Blocking a group's creator also removes you from every group they created and refuses their future invites. When the creator blocks a member, that member is removed and banned. Turning off incoming shares also refuses group invites. Unblocking someone in Sharing Settings shows their rows again.

1.8 Notifications

If you grant notification permission, the App can:

• Schedule local, on-device reminders (e.g., a timer you set inside a MyApp) using your device's local notification scheduling system. These reminders are scheduled and fired entirely on your device, and their content is never sent to our servers. On Android, technical diagnostics about whether a reminder was scheduled and delivered (timing and permission state, never its text) are sent to our pipeline event log (Section 1.5) so we can fix reminder failures.
• Receive push notifications via Firebase Cloud Messaging (and, on iOS, Apple Push Notification service) — for example when someone accepts or sends a ❤️ to a MyApp you shared, when we reply to your feedback, when a MyApp of yours is restricted after review, or, for group MyApps (Section 1.7), when someone joins a group you created, when you are removed from a group, or when a group you belong to is deleted. Notifications about another user's action include that user's email address where Section 1.7 says so. To enable this, we store a device push token associated with your account. The same notifications are also kept in your in-app notification list.

1.9 Information We Do Not Collect

We do not use any advertising SDKs, analytics/tracking SDKs (e.g., no Firebase Analytics, no Crashlytics, no ad networks), and we do not collect device identifiers for our own purposes (the only exception is the technical information our subscription processor receives in the situations described in Section 1.6.1), location data, contacts, or browsing history. We do not sell your data. A link you deliberately share into a MyApp (Section 1.2) is content you chose to put there, not browsing history: the App never reads what you view in your browser or any other app.

This remains true of your device's address book and calendar specifically: the App never reads them, has no permission to, and never asks for one. Contact or calendar information reaches a MyApp only if you put it there yourself — by typing it in, or by sending it a contact card or calendar file through your phone's share sheet, or sharing a contact from your Contacts app (Section 1.2) — in which case it is content you chose to put into your own MyApp, not information we collected from your device.

1.10 Marketing Website Email Signups

If you provide your email address through the "Get updates" signup on our marketing website, we store that address, the fact that it came from the website signup, and your browser's user-agent string, so we can send you news about MyApp Studio. To prevent automated abuse of the form, we also record the submitting IP address and email address in a rate-limiting record; it is used only to count recent submissions, and is deleted the next time you or the same IP address submit the form more than an hour later; otherwise it is kept until we clear old records manually. This list is entirely separate from the Account Information described in Section 1.1 — providing your email here does not create an App account, and signing in to the App does not add you to this list.

1.11 Website Contact and Account-Deletion Request Forms

If you use the Contact Us form or the account-deletion request form on our website, the name, email address, subject and message (or deletion reason) you enter are emailed to our support inbox; they are not stored in our database. As with the signup form, we record the submitting IP address and email address in a rate-limiting record to prevent abuse of the form.

2. How We Use Your Information

We use the information described above to:

• Authenticate you and keep your MyApps in sync across devices
• Generate, render, and modify your MyApps using Google's Gemini AI models, and — for MyApps that include an AI-powered runtime lookup you've approved — fetch the looked-up data at the moment you use it (Section 1.2.1)
• Encrypt and, if you opt in, sync your personal table data across your own devices
• Let you share MyApps with, and receive MyApps from, other users you choose to interact with, and use group MyApps together with the people you invite (Section 1.7)
• Read a file, link or text you choose to send into one of your MyApps (Section 1.2)
• Let you block other users and flag MyApps for review, to support trust and safety — including automatically removing apps from a blocked or flagged sender
• Track your app-slot usage and AI usage against your daily allowance (Section 1.6)
• Check whether you have a subscription, confirm subscriptions you buy through Apple or Google, keep your plan up to date, and count your plan's allowances (Section 1.6.1)
• Deliver notifications you've requested or that relate to sharing activity
• Send you news about MyApp Studio and related product updates, if you sign up for email updates on our marketing website (Section 1.10)
• Respond to feedback you send from the App and to messages you send through our website forms (Sections 1.5 and 1.11)
• Maintain audit and pipeline-event logs for debugging, abuse prevention, reliability monitoring, and to track AI usage costs (visible only to us via an internal admin dashboard)
• Operate, maintain, and improve the reliability of the App and backend services

3. How We Share Your Information

We do not sell, rent, or trade your personal information. We share information only as follows. Every service provider listed below that processes your information on our behalf is contractually bound to provide the same or equal protection of your information as stated in this Privacy Policy, and we do not share personal data with a provider that has not made that commitment. Apple and Google are the exception when they sell you a subscription or deliver a notification: there they act under their own terms and privacy policies, as described below. In particular, we use the paid tier of Google's Gemini API: under Google's terms for paid services, Google does not use your prompts or responses to improve or train its products, processes them in accordance with Google's Data Processing Addendum for Products Where Google is a Data Processor, and logs them only for a limited period, solely to detect abuse and to meet legal or regulatory obligations. (Lookups that use Google Search carry an additional 30-day retention — see the Google Search entry below.)

• Google Cloud / Firebase (our infrastructure provider): Authentication, Firestore (database), Cloud Functions (backend logic), Cloud Messaging (push notifications), and Hosting (which serves our website — the marketing, privacy, terms, contact, account-deletion-request and share- and group-invite pages — and the internal admin dashboard referred to in Section 2) are all built on Google Firebase, and the internal analytics archive of our pipeline event log (Sections 1.5 and 4) is kept in Google BigQuery. Flag reports, in-app feedback, website form messages and operational alerts are delivered to our support inbox through Gmail. Google processes this data on our behalf, subject to Google's own data processing terms. End-to-end encrypted personal data stored in Firestore is unreadable to Google as well as to us.
• Google Gemini API: The text of your prompts (including on-device transcripts of your spoken prompts in voice mode) and the current MyApp schema (with any personal table rows redacted to a placeholder, per Section 1.4) are sent to Google's Gemini models so the AI can generate or modify your MyApp and provide a quality review. In voice mode, the assistant's reply text is also sent to a Gemini text-to-speech model to generate the spoken audio you hear. If a MyApp uses an AI-powered runtime lookup (Section 1.2.1), the input that MyApp gives the lookup — the value(s) you enter into it, or entries already in the MyApp's non-personal tables, or, where it reads a link, file or text you shared in (Section 1.2), the link, the page's title and the page's, file's or text's contents, or, in a group MyApp, content from the group's shared tables, which may have been entered by any member, and members' display names (Section 1.7) — are separately sent to Gemini each time you use it, in addition to the design-time calls described above. Google's handling of API data is governed by the Gemini API terms in effect at the time of use; because we use the paid tier, those terms mean your prompts and responses are not used to improve or train Google's models and are not read by human reviewers for that purpose (see the paragraph above this list).
• Google Search (for "grounded" AI lookups only): Some AI-powered runtime lookups (Section 1.2.1) are marked as needing current information, such as prices or availability. For those specific lookups only, the input that lookup is given (Section 1.2.1) is used to perform a Google Search as part of generating the result. Other lookups, and all other App functionality, do not use Google Search. For these grounded lookups, Google states that it stores the query, the context sent with it, and the result for thirty (30) days, to produce grounded results and search suggestions and to debug and test the systems behind Search grounding — a longer and broader retention than the abuse-detection logging described above. On the paid tier we use, that processing is covered by the same Data Processing Addendum.
• RevenueCat, Apple and Google (subscriptions): RevenueCat processes your account ID and the device and subscription information described in Section 1.6.1 on our behalf, in the situations described there, to confirm purchases and keep your plan in sync, subject to its own data processing terms. Apple (App Store) and Google (Google Play) process the payment itself and keep your purchase history; we never receive your payment credentials.
• Apple: on iOS, push notifications are delivered through Apple Push Notification service, so their text (which can include another user's email address, Section 1.7) passes through Apple. If you signed in with Apple and delete your account from within the App, we ask Apple to revoke MyApp Studio's access to your Apple ID.
• Other users you choose to share with: If you share a MyApp, anyone who opens your link while signed in receives a copy of that MyApp's data in their inbox — the rows of its tables, except personal tables (always excluded) and any you chose to exclude, per Section 1.7. When someone accepts a MyApp you shared with them or reacts to it, you see their email address, and they may see yours, as described in Section 1.7.
• Other members of a group MyApp you join or create: Everything you enter into that group's shared tables is visible to every other member, along with your display name and which rows are yours, and it can be used as the input to an AI-powered lookup the group's app offers, run on any member's device, which sends it to Gemini under that member's account. This is the point of a group MyApp rather than an incidental disclosure, and it is described in full in Section 1.7.
• Flag reports: If you flag a MyApp, the report (app name/ID, your identity, the app owner's identity, and your stated reason) is visible only to us as the developer/operator — never to other users or third parties. If you report a reply from the AI assistant, the report also carries as much of that reply's text as fits; a report about AI-generated content in a MyApp carries your stated reason and the MyApp's name and ID.
• Legal requirements: We may disclose information if required to do so by law, or in good faith belief that such action is necessary to comply with legal process, protect our rights, or protect the safety of users or the public.

We do not have any other third-party advertising, analytics, or data-broker integrations.

4. Data Retention and Deletion

• Your MyApps, logs, and account data are retained for as long as your account exists, so that your MyApps remain available and synced.
• Deleting a MyApp from the Dashboard removes it from your device and from your account in our database. A share link you already created for it keeps its stored copy until you delete your account (Section 1.7), and copies other people already accepted stay in their accounts. Deleting a group MyApp you created deletes it for every member; deleting one you joined means leaving that group (Section 1.7).
• You may delete your account and all associated data (MyApps, your per-user activity log, shares, notifications, push tokens, and any passphrase-wrapped encryption key copy) at any time, in one of three ways: directly within the App via the account menu's Delete Account option, by submitting our account deletion request form, or by contacting us at the email below. Account deletion permanently removes your Firebase Authentication record and all Firestore data stored under your account. It also removes the data we keep about you outside your account: any feedback you submitted from within the App, any share links you created, any share invitations you sent that a recipient had not yet accepted or declined, and your pipeline event log entries (Section 1.5). For group MyApps (Section 1.7), any group you created is deleted for all of its members, who are notified, and you are removed from every group you had joined.
• Pipeline event log entries are stripped rather than deleted in our internal analytics archive. The pipeline event log described in Section 1.5 is also copied to an internal analytics archive we use for cost and reliability reporting. When you delete your account, we remove from those archived entries everything that ties them to you — your account ID, the app name, the prompt summary, any AI lookup request and response text, and any error detail — and keep only anonymous operational figures: which pipeline step ran, whether it succeeded, which AI model was used, token counts, cost, and the timestamp. (If another user's attempt to share with you was refused because of your sharing settings or your block list, that event is recorded under the sender's account and its detail can include your account ID; it is not removed when you delete your account.) What remains does not otherwise identify you, and we keep it so that our historical cost and reliability records stay accurate. This step, and the removal of your live pipeline event log entries, completes in the background, normally within a few hours of your request rather than instantly, because the archive does not accept changes to very recently written entries; everything else described above is removed at the time of the request. The archived entries also keep the ID of the MyApp they concerned; that MyApp itself is deleted with your account.
• Flag log entries are retained after account deletion. The flag log entries described in Section 1.5 (the cross-user flags collection) are not deleted when you delete your account — whether you made the report or were the subject of it, including the copy of a reported group member's rows a report carries. These entries are not stored under your account and are accessible only to us via Admin-SDK-restricted, operator-only access — we retain them for moderation and abuse-prevention purposes even after account deletion.
• Rows you wrote in a group MyApp are kept, with your name removed. When you delete your account, the rows you added to the shared tables of a group you joined are not deleted (a group you created is deleted with your account, rows and all, as described above) — they are that group's data, and removing them would take away work the other members depend on and may not be able to reconstruct. What we remove is the link to you: the record of which account created and last changed each row is cleared, so the row remains part of the group's records without being attributable to you. Anything you typed into such a row (including any names) stays as written. This applies only to shared tables; anything in a group app's private tables is yours and is deleted with the rest of your account.
• Some information about you remains in other users' accounts. Your email address stays on copies of MyApps you shared that others already accepted, on notifications they received when you accepted or reacted to a MyApp they shared or joined a group they created, and on their list of blocked users if they blocked you (for someone who blocked you from inside a group MyApp, that entry holds the display name you had in the group, not your email address). Likewise, if an AI lookup run on another group member's device used content you had entered into the group's shared tables, or your display name (Section 1.7), that content stays in the logged request recorded under their account. Deleting your account does not reach into other people's accounts to remove these.
• Subscription records on deletion. Deleting your account deletes your private billing record at once and, in the background (normally within a few hours), asks RevenueCat to delete the customer record it holds for your account ID; if a subscription is still active, renewal notices from Apple or Google may cause RevenueCat to create a record for it again until you cancel. The durable slot record described in Section 1.6, which is kept after deletion (below), retains when your email address or phone number was first seen, the number of free apps it has used, the total number of apps it created with a subscription, the times of its subscription app creations and of its changes from the last 12 months, and the account ID that most recently used it. Apple and Google keep their own purchase and payment records under their policies, and deleting your account does not cancel a subscription: cancel it in the App Store or Google Play.
• The app-slot usage record described in Section 1.6 is also retained after account deletion. Because it is keyed on your email address or phone number rather than your account ID, deleting your account does not delete it or anything it holds (Sections 1.6 and 1.6.1), including the number of free and subscription apps it has used, the first-seen date, the change and subscription-app times, and the account ID that most recently used it. This is intentional, so the free app-slot allotment cannot be re-claimed by deleting and recreating an account.
• Short-lived abuse-prevention and spending counters for your account (rate limits and daily AI-usage totals) are not deleted with your account; they hold no content and expire on their own within days. Cached AI lookup results (Section 1.2.1) are not linked to any account, so they are not affected by deleting yours.
• Logging out of the App (from the account menu) does not delete data stored in Firestore, but it clears the App's local copy of your MyApps, and the App's locally stored encryption key, from that device; signing back in downloads your MyApps again. If you have not enabled multi-device sync for personal data (Section 1.4), logging out, losing your device, uninstalling the App, or clearing its data can make the corresponding personal table content permanently unrecoverable; the App warns you before logout if you have personal data protected only by a device-local key.
• Marketing website email signups (Section 1.10) are kept until you ask us to remove you; contact us using the information in Section 9 to be removed, as we don't currently offer a self-service unsubscribe link. This list is unrelated to your App account, if you have one, and is not affected by deleting your account.

5. Data Security

We rely on Firebase's security infrastructure and on-device cryptography, including:

• Encryption in transit (HTTPS/TLS) for all communication between the App and our backend
• End-to-end encryption (AES-256-GCM) of personal table row content, performed on-device, with keys protected by your device's OS-managed credential storage (Android Keystore / iOS Keychain) and, optionally, a user-chosen passphrase (Section 1.4)
• Firestore security rules that restrict access to a user's MyApps, logs, shares, notifications, and device tokens to that authenticated user only — except that a group MyApp's shared tables and member list are readable by that group's members, and its shared tables writable by them within the limits the app sets (Section 1.7)
• Access to the internal admin analytics dashboard restricted to specific operator accounts via a Firebase Authentication custom claim
• Authentication via Firebase Auth with Google Sign-In or Sign in with Apple, rather than passwords we manage ourselves

No method of electronic storage or transmission is 100% secure, and we cannot guarantee absolute security. Note that end-to-end encryption protects personal table content — table/column names and the fact that a personal table exists are not encrypted — that it does not apply to the shared tables of a group MyApp (Section 1.7), and that it does not cover a value at the moment you hand it to an AI-powered lookup while entering it (Section 1.4).

6. Children's Privacy

MyApp Studio is not directed to children under 13, and we do not knowingly collect personal information from children under 13. If you believe a child has provided us with personal information, please contact us so we can delete it.

7. Your Choices and Rights

• Camera, microphone and speech-recognition permissions are optional and only used for the features described above (voice prompts, and the camera features in generated MyApps); you can decline or revoke them at any time in your device's system settings, with reduced functionality (e.g., text-only input) as a result. For the microphone specifically, the App also asks for your explicit in-app confirmation ("Use Microphone" / "Type instead") before ever opening it or triggering the system permission dialog, every time you enter voice mode — see Section 1.2.
• Notification permission is optional; declining it disables local reminders and push notifications. On Android, the App may also ask to schedule exact alarms, so that a reminder set in a MyApp fires on time and is restored after your phone restarts.
• Sharing: you can turn off incoming shares and group invites, and block individual users, in Sharing Settings (Section 1.7).
• AI data-sharing consent: before you can build or edit a MyApp, the App shows you a dedicated screen naming Google's Gemini AI, describing what is sent to it, and asking you to agree — separately from accepting our Terms of Service. You can withdraw that consent at any time from the account menu, under About → AI Data Sharing. Because MyApp Studio builds and edits MyApps using Gemini, it cannot do those things without this consent: withdrawing it signs you out, and you can agree again whenever you sign back in. Nothing is deleted: your MyApps and their data stay in your account, and signing back in and agreeing again restores access to them exactly as before. (Because withdrawing signs you out, you cannot open a MyApp in the App while consent is withdrawn.)
• Marketing email opt-out: if you signed up for updates on our marketing website, you can ask to be removed at any time (Section 4) — this signup is separate from, and not required for, using the App.
• Personal table encryption is applied automatically to tables the AI classifies as personal (Section 1.4); if a table is classified wrongly, you can ask the assistant to change it. Multi-device sync of that encrypted data is opt-in and requires you to set a passphrase that we never see.
• Logging out from the account menu clears your local data cache and locally stored encryption key from the device (Section 4) — unlike the sign-out that follows withdrawing AI consent, above, which leaves them in place; signing back in downloads your MyApps again, and your personal data stays readable only if you enabled multi-device sync with a passphrase. Deleting your account (Section 4) removes your local cache as well as your server-side data.
• Depending on your location, you may have rights under applicable law (such as the GDPR or CCPA) to access, correct, export, or delete your personal data. To exercise these rights, contact us using the information below. Note that we cannot read or export the content of end-to-end encrypted personal tables on your behalf — only you, with your key or passphrase, can.
• Legal bases (EEA and UK): we process your information to provide the App and any subscription you buy (performance of our contract with you); to prevent abuse, keep the service secure and operate it (our legitimate interests, including the durable slot record in Section 1.6); with your consent where we ask for it (the AI data-sharing consent above, and the microphone and notification permissions); and where the law requires it.
• International transfers: we and our service providers, including Google and RevenueCat, process your information in the United States. Where the law requires it, these transfers rely on the European Commission's standard contractual clauses or the EU–U.S. Data Privacy Framework, as applicable to each provider.
• Complaints: if you are in the EEA or the UK and believe we have not handled your information lawfully, you can complain to your local data-protection authority, though we would like the chance to address it first.
• California residents: we do not sell or "share" (for cross-context behavioral advertising) your personal information, and we will not treat you differently for exercising your privacy rights. If we decline a request, you can ask us to reconsider by replying to our answer.

8. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be reflected by updating the "Last updated" date above and will be announced in the App, where we may ask you to review and accept the revised policy before you continue. Continued use of the App after changes take effect constitutes acceptance of the revised policy.

9. Contact Us

If you have questions about this Privacy Policy or wish to exercise your data rights, contact us at:

Email: support@myappstudio.app