Privacy Policy

AppForShare (appforshare.io) lets developers upload iOS and Android builds and share them through an install link and QR code. It is operated by ZenTalk LLC, Houston, Texas, United States ("we", "us"). ZenTalk LLC is the controller of the personal data described here.

On the Team plan an account can show its own name and logo instead of ours on its install pages and in the emails its testers get. This policy still applies to those pages and emails, and the account that shared the build is responsible for telling you who it is.

Questions about this policy or your data: [email protected].

Account details. Your name, email address, a hashed password if you set one, your country if you give it, a profile picture if your account had one on the earlier version of AppForShare, and whether your email is verified. If you turn on two step sign in, we also store an encrypted authenticator key and hashed recovery codes. If you add a passkey, we store its public key, the name you give it, and when it was added and last used; the private key stays on your device or in your password manager. Email sign in codes are stored only as a hash and expire after 10 minutes.

Sign in with Google or GitHub. If you use these, we receive your name, email address and the account ID the provider gives us. Details are in section 3.

Builds you upload. The IPA or APK file and what we read from it: app name, bundle or package ID, version, icon, minimum OS, file size, and for iOS ad hoc builds the device IDs listed in the provisioning profile. Plus anything you add, such as release notes, project names, a link password (stored hashed), the labels of extra share links you add to a build and a note when you retire a build.

Installs and page views. When someone opens an install page or installs a build we record the date, device type, OS version, device model when the device reports it, the country, and a one way hash of the IP address. We do not keep the raw IP address for these records. When the install came through an extra share link, we also note which link and count it for that link. Build owners see these counts in their analytics.

Tester feedback. When a tester sends feedback from an install page we keep what they write, the screenshots or screen recording they attach, the name and email they choose to give, the device type, model and OS version, the screen size and language their browser reports, the country, the full browser user agent and a one way hash of the IP address. The build owner and their team see it. It is deleted when they delete the report or when the build's files are removed. When the feedback is sent through a developer's in-app feedback link, we also keep the screen name and the extra info text the app passes in the link, and that it came from inside the app. On a build uploaded without an account (a guest upload) the same details are kept, a screen recording is not taken, and the person who uploaded the build reads the feedback only through their private manage link; we send no email about it. It moves into their account if they sign up and keep the build, and is otherwise deleted when the build's files are removed, at the latest 7 days after the guest link ends.

Crash dashboard link. If a workspace adds the address of its crash reporting tool to a project, we keep only that address and show it, filled in with the build's version, next to builds and feedback. We do not collect or receive crash data.

Workspace activity. We keep a short line for actions in a workspace, such as an upload, a build put into a channel, a paused link or a ticked checklist step, with the name of the team member who did it. Lines about tester feedback name no tester and hold none of their words. The workspace's team sees the feed on Team, and the lines are deleted with the account.

Device IDs (UDID). If you use our UDID tool on an iPhone or iPad, the device sends its UDID, model, iOS version, device name, and where it has them its serial number, IMEI, ICCID and Wi-Fi MAC address. We show the result to you and delete it after one day unless you save the device to your account, where it stays until you remove it. If you send your device through a developer's onboarding link, we also keep the name and email address you enter, and the device goes into that developer's device list; they see your name, email, device model, UDID and the hardware ids your device shared. We email you once when a build that includes your device is ready.

Remember this device. After a UDID check you can tap Remember this device. Your iPhone's UDID, model and name are then kept in a signed cookie named afs_device in that browser only, for up to 400 days, so iOS install pages on appforshare.io can tell you whether a build includes your iPhone. We store nothing new on our side for this. Forget it on any install page removes the cookie. If you send your iPhone to the developer from an install page, we keep the name and email you enter and the device, the same as an onboarding link request.

Emailed install links. When a developer emails a build's install link to you, we keep your email address with that build, who sent it and when, so the same build is not mailed to you twice and the developer can see who got it. The mail has no tracking.

Teams and testers. Email addresses (and names, if given) of team members and testers you invite, their role, when a tester last opened a private install page, the tester groups you make, and per project when each tester was invited or reminded, last opened an install page and last installed a build. We also keep the language a tester's emails go out in: the one the workspace picks, or the language their browser showed the install page in.

Join links. If you join a project's testers through a developer's join link, we keep the email address and the name you enter, which link you joined through and when. To prove the address we email you a confirm link that works for 24 hours; it carries your email and name in signed form and nothing is saved until you open it. After that you are a tester of that workspace like any invited tester, and the developer sees your name, email and which builds you open and install.

Channel followers. If you ask for an email about new builds on a channel page ("Email me new builds"), we keep your email address (encrypted), the page language and when you asked and confirmed. You get one confirmation email; nothing else is sent until you confirm, and an unconfirmed address is deleted after 48 hours. After that you get one email when the developer puts a new build into that channel, at most one every 6 hours, each with a link that stops them at once. The developer sees only a count and a masked form of your address (such as jo***@example.com), can remove you, and never sees which builds you install. Your address is deleted when you stop the emails, when the developer removes you or deletes the channel, or when the account closes.

Client projects. If a workspace adds you as a client, we keep the email address (and name and company, if the workspace gives them), when you signed in to the client portal with the IP address and browser of each sign in link and session, the feedback you post, and an activity log of the project. Files a workspace delivers are stored with their SHA-256. A workspace can remove you at any time, and the data goes when the workspace deletes its account.

Signatures. When you sign an agreement or a sign-off in the client portal, we keep the signed text, the name (and company and job title, if asked) and the signature you drew or typed, the email address your sign in link proved, your IP address, browser and the time, and the signed PDF, which is emailed to you and to the workspace. This record stays with the workspace even if a signature is later revoked, and goes when the workspace deletes its account. Anyone who has a copy of a signed PDF can check it on our verify page; the page shows the document title, the workspace, the signer's name, the date and whether it was revoked, never the text, email address or IP address. The file you check there is not uploaded: only its SHA-256 is sent.

Free tools in your browser. The IPA inspector, the APK analyzer and the app icon generator read your file in your browser. It is not uploaded and we do not see it, unless you choose to share the build, which uploads it like any other build.

Integrations. Slack, Discord or other webhook URLs you add, stored encrypted, and a 30 day record of delivery results. API tokens you create are stored hashed. For apps you connect with OAuth (for example Claude or Cursor using the MCP server) we keep the app's name and the addresses it registered, which workspace you approved, when it was last used, and hashed access and refresh tokens, until you disconnect it.

Microsoft Teams app. When someone messages the AppForShare bot or pastes an install link in Teams, Microsoft sends us the Teams user ID and name, tenant ID, conversation ID, the message text and the pasted link. We use them only to answer that request and store none of them. Link previews show only what the public install page already shows, and nothing for password protected links. The app has no Microsoft Graph access and reads no files.

Jira app. The Jira app sends us only the issue or project key being viewed, with the AppForShare API token a Jira admin saved. That token is kept in Atlassian's Forge secret storage; we keep only its hash, as for any API token. We send back build details from that token's account (app name, version, platform, date, release notes start, install link, QR code, GitHub branch and commit) for display; Jira does not store them. The app reads no issue titles, descriptions, comments or user details. Removing the token or uninstalling the app stops all access.

Push notifications. If you turn on notifications on a device, we keep the push address your browser gives us (a URL at your browser's push service), its encryption keys, a short device label such as "iPhone app", when it was added and when it last got a notification, and which kinds of notification you turned off. Turning notifications off on that device, or removing it in Settings, deletes it. We also delete it when the push service tells us it no longer works.

AppForShare iPhone and Android app. The app signs in to the same account and shows the same data as the website; it has no ads, no analytics and no tracking. If you allow notifications, we keep the push token Apple or Google gives the app, the platform, the app version, a short device label such as "Google Pixel 8 (Android 15)", when it was added and when it last got a notification. Signing out deletes the token; it is also deleted when Apple or Google tells us it no longer works. Push messages go through Apple Push Notification service or Firebase Cloud Messaging and carry only the notification text and the page to open. You can delete your account inside the app (Account, Delete account), which deletes it the same way as on the website.

Store connections. If you connect App Store Connect or Google Play, we keep the API key or service account key you upload, encrypted with a key held in Google Cloud KMS and never shown again, the key ID and issuer ID, the apps you chose to share, and a log of every call we make to Apple or Google with it. If you use our Google service account instead of a key, we keep its email address. We read only what the features you use need, such as app names, build and review status, and customer reviews. Disconnecting deletes the key at once.

Android signing keys. When you upload an .aab, we make a test signing key for your workspace and keep it, with its password, encrypted with a key held in Google Cloud KMS. If an Admin adds your own upload keystore (Pro and Team), we keep the file, its alias and passwords the same way, plus its certificate fingerprint, who added it and when. We open a key only to sign the APK made from an .aab you uploaded. Removing your keystore in Settings deletes it at once; the test key is deleted with your account.

iOS signing certificate. If an Owner or Admin adds a signing certificate for re-signing iOS builds (Pro and Team), we keep the .p12 file and its password encrypted with a key held in Google Cloud KMS and never show them again, plus the certificate name, team, kind, SHA-1, expiry, who added it and when. We open it only to re-sign a build of your own workspace, in a private temporary folder that is removed after the run. Removing the certificate in Settings deletes it at once.

Single sign on. If a Team workspace connects an identity provider, we keep its settings (SAML addresses and certificate fingerprints, or the OpenID Connect issuer and client ID), the verified company domain, and the provider's certificates or client secret encrypted with a key held in Google Cloud KMS. For each person who signs in through it we keep the provider's user ID, the email address, the group names the provider sent at the last sign in, and the sign in times.

Microsoft Intune. If a Team workspace connects Microsoft Intune, we keep the tenant ID, the client ID and the client secret, the secret encrypted with a key held in Google Cloud KMS, and a record of each build sent. Builds are sent only to the workspace's own Intune through Microsoft Graph.

Tester email server. If a Team workspace adds its own mail server for tester emails, we keep the server address, port, user name, From and Reply-To, and the password encrypted with a key held in Google Cloud KMS. Tester emails then pass through that server, which the workspace runs. We keep a delivery log with masked addresses.

Where build files are stored. Build files (.ipa, .apk and kept .aab) are stored on Google Cloud Storage in the United States. On Team, an Admin can choose, for new uploads, our storage in the European Union when Settings offers it, or the workspace's own Amazon S3, S3 compatible or Google Cloud Storage bucket. For an own bucket we keep its address, folder and access key, the key encrypted with a key held in Google Cloud KMS and never shown again. We only write, read and delete our own build files there and never list the bucket. Disconnecting stops new uploads to it; its key is deleted once no build is left in it. Builds already uploaded stay where they are. Install pages, icons, feedback and account data stay with us in the United States.

Payments. Stripe handles card details; we never see or store your full card number. We keep your plan, subscription status, Stripe customer ID, invoice amounts and dates.

Messages and reports. What you send through the contact form or a "Report this app" form, with your email if you give it and a hash of your IP address. A report must say why; the reason and details of the reported build are sent to Google Gemini for an automated review (see Who we share it with), and we keep its result with the report. The owner of a reported build sees the reason you wrote, never your email or who you are.

Removed files. When our staff remove a build for abuse, we keep the SHA-256 fingerprint of its file, the reason and the date, so the same file is refused if it is uploaded again. We keep nothing else about it: not the file, the account or the uploader.

Malware check. Every uploaded build is checked for known malware on our own servers with ClamAV. The SHA-256 hash of the file (not the file) is sent to MalwareBazaar, run by abuse.ch, to check it against known malware. We keep the result with the build: the status, the date, the engines used and any signature that matched. A build that matches is held until our staff review it.

Technical data. For each signed in session, the IP address and browser user agent, so you can see where you are signed in and so we can spot account abuse. Our servers also keep short lived request logs.

When you choose "Continue with Google" we ask Google only for the basic scopes openid, email and profile. We use them for one purpose: to create your AppForShare account or sign you in to it. We store your Google account ID, name and email address. We do not request access to Gmail, Drive, Contacts or any other Google data.

We do not sell Google user data, use it for advertising, use it to train AI or machine learning models, or share it with anyone except as needed to run the service (section 5) or to comply with the law. AppForShare's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

GitHub sign in works the same way: we read your GitHub user ID, name and primary verified email, and nothing from your repositories.

You can unlink either provider by deleting your account (section 9), or revoke our access at any time from your Google or GitHub account settings.

• To run the service: store and process your builds, serve install links, show analytics, run teams, testers and integrations (performance of our contract with you).
• To bill paid plans and keep tax and accounting records (contract and legal obligation).
• To send service email: email verification, password resets, receipts, usage alerts, and notices about your builds or account (contract).
• To keep AppForShare safe: rate limits, bot checks, reviewing abuse reports and removing malware or infringing apps (legitimate interest).
• To answer your messages (legitimate interest, or contract if you are a customer).

We do not sell personal data, we do not show ads, and we do not use advertising cookies. Website analytics are described under Cookies.

People you share with. Anyone with an install link can see the app name, icon, version and release notes, unless the link is password protected or limited to invited testers. Team members see the workspace's builds and analytics.

Service providers who process data for us under contract:

• Google Cloud: servers, database and file storage.
• Cloudflare: network delivery, security and the Turnstile bot check.
• Stripe: payments and invoices.
• Twilio SendGrid: sending email.
• The push service of your browser (Apple, Google, Mozilla or Microsoft): delivering push notifications, only if you turn them on. The notification text is encrypted so the push service cannot read it.
• Google Analytics: website visit statistics (see Cookies).
• Google and GitHub: sign in, only if you use them.
• Google Gemini API: AI features, only when you start one (for example a fix plan). We send build details such as the app name, version and check results, never the app file. Google does not use this data to train its models.
• Google Gemini API, for reports: the reason written in a "Report this app" form and details of the reported build (app name, bundle ID, platform, permissions, security check results, whether it has an account, how many earlier reports it has) go to Google Gemini for an automated review, so our team can sort reports. The reporter's email and IP address are never sent. A person on our team makes every decision.

Malware lookups. To check uploads against known malware, we send the SHA-256 hash of each uploaded file to MalwareBazaar, a public malware database run by abuse.ch. Only the hash is sent: never the file, your account or anything about you.

Destinations you choose. Build events, and store release events if you pick them, go to the Slack, Discord or webhook URLs you add. If an upload through the Diawi compatible API names a callback_url, we call that https address once with the result (the job id, status, link code, install link and QR code address). We keep the address with the upload record and make no retries. If a workspace turns on the daily install email for a project, the account owner gets one email a day with that project's installs by build, device model and country, and the names and email addresses of invited testers who installed.

Apple and Google stores. When you connect a store, we call the App Store Connect API or the Google Play Developer API with your key, only for your account and the apps you shared. If you connected through another workspace's invite link, that workspace sees the shared apps and the activity log, and you can disconnect at any time. For shared Apple apps, App Store Connect sends review and build notifications to AppForShare. We keep the latest release status of each shared app and a history of its changes until the connection is removed. We also keep the customer reviews of shared apps (the reviewer's public nickname, rating, text, country or language, app version and device as the store gives them) and your replies, until the app is unshared or the connection is removed. When you ask for an AI reply draft, the review text and your reply notes are sent to Google Gemini. If a workspace links a tester group to a TestFlight group, the email address and name of each member are sent to Apple to add them as a TestFlight tester, and we keep Apple's status for each one (invited, accepted, installed) until the link or the tester is removed. If a workspace registers test devices on Apple, the device name and UDID are sent to Apple, and we keep a copy of the device list of the connected Apple account until the connection is removed. If an Admin turns on Hands free for a project, devices that testers send through that project's onboarding link are registered on the workspace's Apple account with its own App Store Connect key without a person pressing the button, the ad hoc profile may be made again and the project's GitHub build started; every call to Apple is kept in the connection's log. When you edit an App Store or Google Play listing, we keep each changed field with the text before and after, who changed it and when, until the app is unshared or the connection is removed; screenshots and graphics you upload are sent to Apple or Google and not kept by us. When you ask for an AI translation, the listing text of the language you translate from is sent to Google Gemini. When you get an App Store version ready for review, the App Review contact (name, phone, email), the sign in details for the reviewer and your notes are sent to Apple and not kept by us; we keep who picked the build, sent the version for review, canceled or released it, and when, until the app is unshared or the connection is removed. If you connect GitHub for builds, we keep the GitHub account or organization name, the installation and repository ids and names, the build settings and, per build run, who started it, its status, commit and link, until you remove the setup or uninstall the app. The App Store Connect key you choose is sent to GitHub as an encrypted Actions secret of that repository; GitHub keeps it until the setup is removed. For an Android build to Google Play, the run uploads the app bundle straight to Google Play through an upload address we open with your connection, so we never receive the file; we keep only the version code and the result. Setups made before 1 November 2026 still send the bundle to us first; we hand it to Google Play and delete our copy right after. We never read your code.

Legal. We may disclose data if the law requires it, to answer valid legal process, or to protect our users and the service. If AppForShare is sold or merged, data moves with it under this policy.

• Account data: while your account is open. When you delete it we remove your personal details and builds; a record without personal details stays so we can keep billing history.
• Builds: until you delete them or the link expires (3 days for uploads without an account, 7 days on Free, while subscribed on paid plans). Files are then removed after a 7 day grace period.
• Install and page view analytics: 13 months.
• UDID lookups: 1 day unless you save the device.
• Onboarding link requests (name, email, device): 13 months, or 1 day if the device was never sent.
• Sessions: 30 days after last use. Verification and password reset links: deleted 1 day after they expire.
• Webhook delivery records: 30 days.
• Payment records: as long as tax law requires.
• Contact messages and abuse reports: as long as needed to handle them and keep the service safe.
• Fingerprints of files removed for abuse: until staff lift the block.

Cookies the service needs to work:

• A session cookie that keeps you signed in (30 days).
• A short cookie, about 10 minutes, that protects Google and GitHub sign in from forgery.
• A cookie that lets an invited tester open private install pages.
• afs_device, only if you tap Remember this device after a UDID check: your iPhone's UDID, model and name, signed, in that browser, for up to 400 days. Forget it on any install page removes it.

Your light or dark theme choice and your cookie choice are saved in your browser's local storage. Cloudflare may set its own security cookies.

Analytics cookies. On appforshare.io we use Google Analytics, loaded through Google Tag Manager, to count visits and see which pages people use. It sets cookies named _ga that last up to 2 years. In the EEA, the UK and Switzerland these cookies are only set after you accept them in the cookie banner; elsewhere they are on by default. You can change your choice at any time with Cookie settings at the bottom of every page. We use no advertising cookies and do not share this data for ads.

Data travels over HTTPS. Passwords, API tokens and link passwords are stored hashed; webhook URLs and admin verification keys are encrypted. Every account can turn on two step sign in. Admin access requires it and is logged. No system is perfectly secure; if a breach affects your data we will tell you and the authorities as the law requires.

You can edit your details, delete builds, remove testers and integrations, and cancel your plan from your dashboard.

Depending on where you live (for example the EU, UK or California) you may have the right to access, correct, delete or export your data, to object to or restrict some uses, and to withdraw consent. You can delete your account yourself in Settings on the website or under Account in the AppForShare app; Delete your account or data explains how and what is kept. To use any other right, or if you cannot sign in, email [email protected] from the address on your account. We answer within 30 days. We do not treat you differently for using these rights. You may also complain to your local data protection authority.

We are based in the United States and our servers are in the United States. If you use AppForShare from elsewhere, your data is transferred there, except build files a Team workspace chose to store in the European Union or in its own bucket. Where the law requires it we rely on Standard Contractual Clauses or equivalent safeguards with our providers.

AppForShare is a tool for developers and is not meant for children. You must be at least 13 (16 in the EEA and UK) to create an account. If you believe a child has given us personal data, email [email protected] and we will delete it.

If we change this policy we will update the date above, and for significant changes we will email account holders before they take effect. Questions or requests: [email protected], or ZenTalk LLC, Houston, Texas, United States.