Data Security and Compliance When Sharing Test Builds with AppForShare

Sharing an unreleased app with testers means sending a file that may hold unannounced features, test endpoints and, sometimes, keys that should never have shipped. It also means handling personal data about the testers themselves. This article covers both sides: what data protection rules such as the GDPR expect in general, and what AppForShare does, and does not do, to protect the test builds you share through it.

One point up front: AppForShare holds no security certifications, and using it does not make your app or your company compliant with any law. It is one tool in your process, and the obligations stay with you.

Why test builds need protecting

A test build is a full copy of your app. Anyone who gets the file can install it, look at its screens, and pull it apart to read strings, resources and settings. The common problems are:

• Leaked features: work that is not announced yet reaches people outside the test group.
• Exposed secrets: API keys, private keys or service account files left inside the binary.
• Test data with real people in it: builds pointed at a backend that holds real customer records, or screenshots and logs that contain them.
• Links that live too long: an old link forwarded in a chat keeps working months after the test ended.

Most of these are fixed in your own process, not by a sharing tool.

Compliance basics for app teams

What the GDPR covers

The General Data Protection Regulation applies when you process personal data of people in the European Union, and the UK has a very similar law. Personal data is any information about an identifiable person. In app testing that includes tester names and email addresses, device identifiers such as UDIDs, IP addresses, and any feedback or screenshots that show a person.

A few of its principles matter most when you share builds:

• Lawful basis: you need a reason the law accepts for each use of personal data. Consent is one of six bases; for many tasks, such as running a test program people asked to join, another basis such as a contract or legitimate interest may fit better.
• Data minimisation: collect only what you need. If a tester's email is enough, do not ask for more.
• Storage limitation: keep data only as long as you need it, then delete it.
• Security: protect the data with measures that fit the risk.

Breaches and fines

When a personal data breach happens, the controller usually has to tell the data protection authority within 72 hours of becoming aware of it, and tell the people affected when the risk to them is high. For the most serious violations, fines can reach 20 million euros or 4% of worldwide annual turnover, whichever is higher.

Other laws may apply too, depending on where you and your users are, for example California privacy law, or sector rules in health and finance. This article is general information, not legal advice. If your app handles sensitive data, talk to a lawyer who knows your market.

What AppForShare does to protect shared builds

These are the measures AppForShare actually uses. They are also described in the privacy policy.

Storage and delivery

• AppForShare runs on Google Cloud. Build files are kept in a private Google Cloud Storage bucket in the United States.
• All traffic uses HTTPS. Files are served only through signed download links that expire after a short time, so a copied file address stops working.
• Install pages tell search engines not to index them, and install paths are blocked in the site's robots rules. A link is not a secret, though: anyone who has it can open the page unless you add a password or limit access.
• An old link or QR code never points to someone else's build, because link codes are never reused.

Who can install

• Passwords: on a Free, Pro or Team account you can add a password to a build. Link passwords are stored hashed.
• Link life: links do not live forever. Uploads without an account last 3 days and Free links 7 days. Pro and Team links stay live while the plan is active, and you can delete a build at any time.
• Link controls (Pro and Team): pause a link, set a stop date, or cap the number of installs.
• Private projects (Team): only invited testers can open the build. Team can also give each tester their own access code with a device limit.

Accounts and stored secrets

• Every account can turn on two step sign in with an authenticator app, and AppForShare admin staff must use it.
• Account passwords and API tokens are stored hashed. Webhook URLs are encrypted, and App Store Connect keys, Google Play keys and Android signing keys are encrypted with keys held in Google Cloud KMS.

Data kept about testers

• Install records keep a one way hash of the IP address, not the raw address. Install analytics are kept for 13 months, UDID lookups for 1 day unless saved, and sessions and webhook delivery records for 30 days.
• Service providers are listed in the privacy policy: Google Cloud, Cloudflare, Stripe, SendGrid, and the Google Gemini API only when you start an AI feature.
• Data is stored in the United States. Where the law requires it, transfers rely on Standard Contractual Clauses or equivalent safeguards.
• You can delete your account yourself in Settings. To access, correct or export your data, email [email protected]; requests are answered within 30 days.

The security scan, and its limits

Since November 8, 2026, every .apk and .ipa uploaded with an account gets a security scan at upload. It reads the file, without running the app, and looks for:

• Hardcoded secrets that match high confidence patterns, such as AWS access key ids, Stripe live secret keys, PEM private keys and Google service account files. Only the kind, the file and a masked value are stored, never the full secret.
• Android settings such as app data backup without rules, exported components without a permission, plain HTTP for every host, and a debuggable build.
• iOS settings such as App Transport Security turned off for every domain.
• A short dated list of library versions with public advisories.

Each finding is mapped to an OWASP MASVS category and comes with a fix. Free shows the counts; Pro and Team show every finding, and Team adds a full report and history across builds. See pricing and the security scan docs.

Be clear about what it is: a set of MASVS mapped static checks. It is not a penetration test, it does not test the running app or your backend, and it is not a certification. Checking for known malware is a separate step that runs on every upload. A clean result does not mean the app is secure or compliant. Very large builds may only be read in part, and the report says so.

What AppForShare does not claim

• No SOC 2, ISO 27001 or HIPAA certification, and no GDPR certification.
• No end-to-end encryption and no penetration test reports.
• Google Cloud's own certifications belong to Google, not to AppForShare.
• Using AppForShare does not make your app or your processes compliant.

A short checklist for your team

1. Use test accounts and test data in builds you share; keep real customer records out.
2. Keep secrets out of the app, and read the scan findings before each release.
3. Password protect builds that matter, and use private projects for client or embargoed work.
4. Collect only the tester details you need, and remove testers and builds you no longer need.
5. Turn on two step sign in for everyone on your account.
6. Write down how you handle tester data, and check it with someone who knows the law in your market.

To try these controls on your own builds, create a free account.

Frequently asked questions

Is AppForShare GDPR certified?

No. AppForShare holds no GDPR certification or any other security certification. Its privacy policy explains what it collects, how long it keeps it, which providers process it and how to use your data rights.

Does AppForShare make my app compliant?

No. AppForShare protects the builds you share with HTTPS, signed short lived download links, optional passwords and, on Team, private projects. Compliance depends on how your app and your company handle personal data, which stays your responsibility.

Does the security scan prove my app is secure?

No. It is a static check of the uploaded file for common mistakes such as hardcoded secrets and risky platform settings, mapped to OWASP MASVS categories. It does not run the app and it is not a penetration test. Checking for known malware is a separate step that runs on every upload.

Where are my builds stored?

In a private Google Cloud Storage bucket in the United States, served only over HTTPS through signed links that expire after a short time.