The Security Conundrum: Safeguarding Your App with AppForShare

Keeping a mobile app secure takes two separate efforts: testing the app itself for vulnerabilities, and protecting the unreleased builds you share with testers. AppForShare helps with the second one. It keeps test builds private with HTTPS, signed short lived download links, optional passwords and, on Team, private projects for invited testers. It does not scan, test or monitor your app's code for security issues; for that you need dedicated security testing practices and tools.

Part 1: Securing the app itself

Phones hold contacts, messages, payment details and health data, so mobile apps are a target. The common risks are well known:

• Insecure data storage: tokens or personal data stored in plain text on the device.
• Weak network security: missing TLS, accepting invalid certificates, or leaking data in logs.
• Weak authentication and authorization: sessions that never expire, or APIs that trust the client too much.
• Exposed secrets: API keys and credentials hardcoded in the app binary.
• Excessive permissions: asking for more device access than the app needs.

How to test for them

A good reference is the OWASP Mobile Application Security project, which publishes the Mobile Application Security Verification Standard (MASVS) and the Mobile Application Security Testing Guide (MASTG). They describe what to check and how. In practice, a security testing routine includes:

1. Secure code review of authentication, storage and networking code.
2. Static analysis of the source and the built binary for known weaknesses and hardcoded secrets.
3. Dynamic testing of the running app on real devices, including intercepting its network traffic.
4. Backend API testing, since most mobile data lives on the server.
5. Repeating the checks on every significant release, not just once.

Platform specifics

• Android: review requested permissions, use the Android Keystore for keys, enable code shrinking and obfuscation for release builds, and configure network security to block cleartext traffic.
• iOS: store secrets in the Keychain, keep App Transport Security enabled, use data protection classes for files, and declare data use accurately in your privacy details.

All of these need the app installed on real devices during testing, which is where build distribution comes in.

Part 2: Protecting the builds you share

Unreleased builds can contain features you have not announced, test endpoints and debug settings. Sending them as email attachments or public file links spreads copies you cannot withdraw. A distribution service should keep builds private and under your control.

What AppForShare does

• HTTPS everywhere: all pages and downloads are served over HTTPS.
• Signed, short lived download links: the file itself is only served through signed links that expire quickly, so a copied download URL stops working.
• Private storage: build files are stored on Google Cloud Storage in the US (us-east4) in a private bucket, never publicly listed.
• Password per build: on Free, Pro and Team you can require a password before anyone can install.
• Private projects (Team): only testers you invite can open the project's builds, and you can see who installed.
• Link lifetime: guest links expire after 3 days and Free links after 7 days, so old builds do not linger. Deleted builds can be restored for 7 days, then the file is removed for good.
• No reused links: an old link or QR code never points to someone else's build.
• Privacy by default: IP addresses are stored hashed, install analytics are kept for 13 months and UDID lookups for 1 day. AppForShare staff use mandatory two factor authentication for admin access, and abuse reports are reviewed by staff.

Details are in the privacy policy and in how AppForShare protects your files.

What AppForShare does not do

To be clear about the limits:

• It does not scan apps for malware or vulnerabilities, review code, or monitor apps at runtime.
• It does not offer end-to-end encryption, and it holds no security certifications such as SOC 2 or ISO 27001.
• It has no in-app SDK, so it does not see what your app does on the device.

Use AppForShare to get builds to testers privately, and use security testing tools and practices for the app itself.

A practical checklist for secure test distribution

1. Strip debug menus, test credentials and verbose logging from builds shared outside the team.
2. Point test builds at a staging backend, not production data.
3. Password protect builds for clients and unreleased features, and share passwords through a different channel than the link.
4. On iOS, use Ad Hoc signing so only registered devices can install. See registering a UDID.
5. On Team, keep sensitive projects private and invite only the testers who need them.
6. Delete builds that are no longer needed.

Frequently asked questions

Does AppForShare test my app for security vulnerabilities?

No. AppForShare does not scan, review or monitor your app's code. It protects the test builds you share. Use security testing practices such as those in the OWASP MASVS and MASTG for the app itself.

How does AppForShare keep shared builds private?

Builds are stored in a private Google Cloud Storage bucket and served only over HTTPS through signed, short lived download links. You can add a password to any build on a Free, Pro or Team account, and Team private projects only open for invited testers.

Can someone reuse an old AppForShare download link?

Download links are signed and expire quickly, so a copied file URL stops working. Old install links or QR codes never point to someone else's build because links are never reused.

Is AppForShare SOC 2 or ISO 27001 certified?

No. AppForShare does not hold security certifications. Its privacy policy lists the measures it uses, such as HTTPS, signed links, hashed IP addresses and mandatory two factor authentication for admin staff.