Deploy iOS and Android applications to App Store and Google Play (#1009)

[SleepySquash]

Part of #1009
Requires #1052
Requires #1051

Synopsis

Signed iOS and Android applications need to be deployed onto App Store and Google Play.

Solution

Deploy applications to TestFlight and Google Play's internal track.

Checklist

• Created PR:
  • In draft mode
  • Name contains issue reference
  • Has type and k:: labels applied
• Before review:
  • Documentation is updated (if required)
  • Tests are updated (if required)
  • Changes conform code style
  • CHANGELOG entry is added (if required)
  • FCM (final commit message) is posted or updated
  • Draft mode is removed
• Review is completed and changes are approved
  • FCM (final commit message) is approved
• Before merge:
  • Milestone is set
  • PR's name and description are correct and up-to-date
  • All temporary labels are removed

[SleepySquash]

While adding App Store and Google Play binaries upload automatization, I've encountered the same problem that was earlier discovered regarding the application versioning.

1. First of all, application's version: Apple doesn't allow version to have anything except X.Y.Z. No strings, only integers. This doesn't meet our current versioning: 0.1.0-alpha.13.5. This is also the reason the currently uploaded application is being version 0.1.2.
2. Application's build number also should increment and never decrement. If not specified, a 1 is used, however it should be 101 for Google Play already, this one I've been manually inserting with the --build-number flag when building.

The first problem can be resolved by finally releasing 0.1.0 version and using minors and patches bump ups. When application can be considered stable, we should release 1.0.0. And each new iteration should bump up the major version. Say "no" to zerover slavery!

The second problem can be fixed by:

• generating a build number from the current X.Y.Z (e.g. multiplying each number and then summing them up);
• using timestamp;
• manually embedding build number into the version (X.Y.Z+1, X.Y.Z+1234, etc).

The following formula may be used:

major * 1 000 000 + minor * 10 000 + patch * 100

This will convert to:

0.1.0 = 10 000
1.2.3 = 1 010 300
3.95.4 = 3 950 400

However, I do have a concern that possibly 3.101.0 is possible, which will result in 4.0.0's build number being lower. Thus it seems to be that using timestamp for build number is a bit more safe approach.

The safest approach is to manually embed the build number into the version: +1234. But this way we should ensure that the build number isn't used anywhere it shouldn't be used.

Examples

1. RustDesk, open source TeamViewer alternative, uses Flutter for desktop and mobile clients. And they simply keep in the pubspec.yaml both the version and the code: version: 1.2.6+44.
2. immich, an open source self-hosted alternative to Google Photos, uses Flutter for mobile apps, which too stores both the version and build number in its pubspec.yaml: version: 1.106.4+144.
3. spotube too: https://github.com/KRTirtho/spotube/blob/master/pubspec.yaml
4. localsend too: https://github.com/localsend/localsend/blob/main/app/pubspec.yaml
5. ente too: https://github.com/ente-io/ente/blob/main/mobile/pubspec.yaml

[SleepySquash]

Due to versioning differences with App Store requirements, which were finally solved, we should wait for 0.2.0 release to continue working on this PR, as otherwise we won't be able to upload 0.1.0 version with 0.1.2 already submitted in the App Store.

[tyranron]

Discussed.