Publish releases through self-serve channels

[gnprice]

Currently when we cut an alpha release, it's available only through channels that require us to specifically add someone to a list before they can download the build:

• On iOS, it goes via TestFlight to an "internal testing" group.
• On Android, it goes via the Play Store as an "internal testing" release.

These are convenient because they don't require going through any review process, and don't require filling out a detailed app-store profile for the app with description, screenshots, and so on.

But conversely the reason Google and Apple are OK with not requiring a review step for these channels is that their distribution is limited:

• For both channels, we need to explicitly add the user to an access list.
• For iOS/TestFlight, an "internal tester" must further be a member of our Apple Developer Program team, which generally means a Kandra employee.
• For Android/Google Play, there's also a limit of 100 "internal testers", though that's not particularly tight for our purposes.

As the app becomes readier and we want more people to try it, we'll want to distribute builds through more open, self-serve channels, like our beta channel for zulip-mobile.

• For iOS, this means an "external testing" group in TestFlight.
• For Android, this means a Google Play "open testing" release. (There's also an intermediate status of "closed testing", but AFAICT the only advantage that offers over "internal testing" is to lift the 100-person limit.)
• For Android, we can also publish a build here on GitHub.

For at least the Google Play case, this requires filling out a Google Play profile for the app and submitting that for review. For both that and TestFlight, it involves review latency for new releases.

[gnprice]

For at least the Google Play case, this requires filling out a Google Play profile for the app and submitting that for review.

I did this part today. After filling out all the forms (mostly by copying from our existing profile for the production app), this involved promoting the current alpha release from "internal testing" to a "closed testing" track. That's functionally indistinguishable for us — it'll still be an ACL we manage — but it adds abilities like managing access through Google Groups or Google Workspace organizations and having over 100 total testers, and so they have it require review.

So hopefully we'll get approval there next week. Then all that's left for making a self-serve beta through Google Play will be to promote a release further, to "open testing".

I haven't yet investigated what's involved in opening up our TestFlight beta to be self-serve. I'll plan to do that on Monday.

[gnprice]

This should probably block on:

• Make a distinct launch icon for the app #390

(Which shouldn't take long — I'll adapt what we have for debug builds in zulip-mobile.)

[gnprice]

OK, I've gone through the relevant screens of TestFlight. I think we'll be all ready there once we post our next alpha (a v0.0.6) — we should then be able to promote that to a beta, and have it go through TestFlight review for the first time.

This one was a lot simpler than on Google Play — in TestFlight they have a "Test Information" form that is a way, way stripped-down version of the information needed for the public App Store. It's a description of the app; a URL for the privacy policy, and another for the marketing page; an email address for feedback; and then details of a test account they can log in with to try the app. That's it, and I've now filled that out.

Then I've created an "external testing" group of testers, and added my personal email address to it so it's nonempty, and I believe the remaining step in order to go through TestFlight review is to add a build. It won't let me do that, but the reason appears to be that the current build we have uploaded (v0.0.5, the only alpha that hasn't reached its 90-day expiration date) is marked as "internal":

That presumably corresponds to this caveat in Apple's docs:

Builds uploaded as TestFlight Internal Only from Xcode or Xcode Cloud are indicated as internal under the build number. Builds with this indicator can only be added to internal tester groups.

So I guess v0.0.5 was uploaded as "TestFlight Internal Only". And so when we make v0.0.6, we just need to upload it instead as "TestFlight & App Store". Then I can add that build to the "External Testers" group; it'll go through review; and once it's been through review, I can create a public link for the group and we can post that link for people to join the beta.

[gnprice]

And so when we make v0.0.6, we just need to upload it instead as "TestFlight & App Store". Then I can add that build to the "External Testers" group; it'll go through review; and once it's been through review, I can create a public link for the group

And this worked! So I think we're now all set to send a release through self-serve beta channels.

[gnprice]

This is done, as of last Friday. We announced the beta:
https://chat.zulip.org/#narrow/stream/2-general/topic/Flutter/near/1708729
and people have successfully installed it through both Google Play and TestFlight.