Non-Play Store installation methods

[foxyseta]

The old React Native client is also regularly updated on F-Droid. I was told at zulip/zulip-mobile#5795 (comment) that eventually APKs for the Flutter client will be made available as GitHub Releases, too. Will any store other than Google Play also feature the new client?

[foxyseta]

Bump

[gnprice]

Thanks. Yeah, it's probably time we started posting release APKs on GitHub.

I'm planning to make a v0.0.15 release this week. So I'll see about working that into the release process then.

[gnprice]

@foxyseta Release made — please take a look!
https://github.com/zulip/zulip-flutter/releases/tag/v0.0.15

[rajveermalviya]

@gnprice I think we should keep this open to also investigate publishing to F-Droid, which would require a build that doesn't depend on Google Play services (com.google.gms:google-services):

• F-Droid Inclusion Policy
• FAQ

So, that will mean we would need to integrate something like UnifiedPush for notifications (which may also need changes to server).

[foxyseta]

Had to uninstall 0.0.14 before installing 0.0.15 via apk for some reason. Anyway, yes, the original post is talking about stores.

[gnprice]

Had to uninstall 0.0.14 before installing 0.0.15 via apk for some reason.

Yeah, that's expected. Android requires that when the APKs are signed with different keys, and the signing keys we're using for this app in the Play Store and in the GitHub release artifacts are different:

• The APKs you get from the Play Store are signed by a key that was generated in Google's infrastructure and lives only there.

• The APK and AAB uploaded to GitHub are signed by our own key, at build time. (The same AAB, with the same signature, is the artifact I upload in turn to the Play Store. The Play Store breaks that apart and recombines its contents in order to make a smaller APK specialized to each user device's CPU architecture and display density.)

When you make upgrades within either of those distribution channels, the signing key will remain the same and you shouldn't need to uninstall in order to upgrade.

[gnprice]

For F-Droid, the production/legacy zulip-mobile app is there today. So I expect that when this app is ready and we start rolling it out to replace the legacy app — that is, when we start publishing builds of this app with the package ID com.zulipmobile, rather than com.zulip.flutter, so that it offers a direct upgrade from the legacy app — we'll also go on to have this app appear on F-Droid too.

The way the existing F-Droid version of zulip-mobile works is that the F-Droid build just removes the notification support. So that's what I expect would initially happen with this app too.

There's an issue thread in the zulip-mobile (or maybe zulip/zulip?) tracker where we've talked about UnifiedPush and things like it. That might be something we do in the future. We won't have attention to spare for that before we complete the migration from zulip-mobile to zulip-flutter, though.

[devurandom]

There's an issue thread in the zulip-mobile (or maybe zulip/zulip?) tracker where we've talked about UnifiedPush and things like it.

That's probably zulip/zulip-mobile#3838 (and it's duplicate, zulip/zulip-mobile#5712).

I split out the feature request for UnifiedPush into #1198, so it can be considered separately.