Sending a test build to a client who needs a login: test accounts, passwords and safe ways to share them

Most apps open on a sign in screen. When you send a test build to a client, a QA vendor or an App Store reviewer, the build is only half the delivery: they also need an account to get past that screen. This is where test builds most often stall, and where passwords end up in places they should not be. This guide covers how to set up test accounts for a build, how to hand them over, and the mistakes to avoid.

Start with the right account

The first rule: never share a real person's account, and never your own. Make accounts that exist only for testing.

• One account per role. If the app has an admin and a normal user, make one test account for each, so the tester can see both sides.
• Test data, not real data. Fill the account with sample orders, contacts or messages. A client reviewing a demo should not see real customer data, and a tester should not be able to change it.
• A staging server where you can. If the build points at staging, say so in the note, so nobody wonders why their real account does not work.
• Passwords you can change. Plan to rotate them after the test round, and certainly after a client project ends.
• Skip two factor on test accounts, or document it. A tester who gets stuck on a code sent to your phone cannot continue. If the app needs a second factor, give a test path for it.

Where the login usually goes, and why it goes wrong

In the release notes

Release notes are shown on the install page to anyone with the link, and they often end up in emails, chat previews and webhooks too. A password there is as public as the link itself.

In the chat thread

Chat is quick, but the tester has to find the message again when they install a week later, and the password stays in the chat history long after the test.

In a separate email

Better than release notes, but now the build and the login live in two places, and the next build means another email.

In App Store Connect

For App Review, Apple asks for a demo account in the App Review information of the version. That is the right place for the reviewer, but it does not help your client or QA team, who test before the build ever reaches Apple.

A safer way: the login on the install page

The install page is where testers already are, so the login belongs there, behind the same lock as the build. On AppForShare Pro and Team you can add test accounts to the install page:

• Up to 3 test logins per build or per channel, each with a user name, a password and an optional note such as "staging, admin role". Logins on a channel show on every build in it.
• Testers see them with copy buttons only after the page password or an access code is accepted, or as invited testers of a private project on Team. An open page without a password never shows them. The password stays masked until the tester presses Show.
• They are never sent in emails, webhooks, AI assistant answers or the in-app update check, and never shown on Guest or Free builds.
• Passwords are encrypted with their own data key, wrapped by Google Cloud KMS. In the dashboard you see user names and notes, never the passwords.
• From CI or a script: appforshare link <build> --test-login [email protected] --test-password-stdin --test-note "Staging", with the password read from standard input so it never lands in shell history.

Use test accounts only. The form says so too.

A checklist before you send the build

1. Make the test accounts and fill them with sample data.
2. Check that each one signs in on the exact build you are sending, against the server it points at.
3. Protect the install page with a password, or on Team give each tester an access code or invite them to a private project.
4. Add the logins to the build, or to the channel if every build uses the same ones.
5. Send the install link and, separately, the page password. Never put both in the same public place.
6. After the test round, change the passwords and remove the logins from the build.

For agencies

Client demos are where this matters most. A client opens the link on a phone, between meetings, and should reach the first real screen of the app in under a minute. Put the login on the install page, use a channel link so the client keeps one bookmark for every build, and on Team use the client portal for sign-offs. When the engagement ends, remove the logins and change the passwords; a removed login is deleted, and purged builds take their logins with them.

Other services offer something similar: Zunoy AppShare, for example, lists testing credentials for reviewers on its release pages (see AppForShare vs Zunoy AppShare). Whatever you use, check where the password is shown and who can see it.

Common questions

Is it safe to put a test password on an install page?

It is as safe as the lock in front of it. On AppForShare the login shows only behind a page password, an access code or a private project, and never on an open page. Use test accounts only, never real ones.

Can the tester see the login in the email with the link?

No. Emails and webhooks never carry test logins.

What about App Store review?

Give Apple a demo account in the App Review information in App Store Connect. The install page logins are for your testers and clients before that.