feat: expose a way to detect newer releases

[felangel]

Description

As a customer, I want to be able to use pkg:shorebird_code_push to determine whether the app running on a users' device is the latest published release so that in addition to prompting for programmatic patch installs, I can also prompt the user to update the app from the AppStore/PlayStore etc.

Sample Flow:

1. User launches app
2. Check if there is a newer release available
   a. If yes, prompt to update from the store
3. Check if there is a new patch available
   a. If yes, prompt to download and install patch

[erickzanardo]

I feel this is similar to: shorebirdtech/updater#140

[dndeus]

Yes I think it's practically the same. A valid point is raised on that thread https://github.com/shorebirdtech/updater/issues/140#issuecomment-2066859166

1. Users will have a new Shorebird release before it's available in the store. The end user is probably more interested in what's available to them rather than what Shorebird knows about.
2. The releases endpoints all require a logged in Shorebird user, which won't be available to devices in the field. We could make a pared-down publicly-available endpoint that simply returns which release versions are available for which platforms, but going back to the point above, I'm not sure how useful this would be.

[bryanoltman]

Yeah, I'm not sure how helpful it is to know that there's a new shorebird release in the context of deciding whether to update, as that release might not be available to the user yet. Something like https://developer.apple.com/documentation/appstoreconnectapi/read_app_store_version_information or https://developers.google.com/android-publisher is probably a better solution to this problem.

[dndeus]

I haven't tried yet but I thing the upgrader package can do the job when there is a new release in the app stores while having the patch of the new release in shorebird on hold. Having a patch on a new shorebird release won't affect users that currently have installed previous releases anyway.

At the end of the day a new release to both shorebird and to the app stores should be done when we add to the app a new package that interacts with native code or installing a cocoapod or something like that.

Having releases otherwise defeats the purpose of having code push altogether.

is It a valid assumption??

I think the biggest culprit is that we can't code push native code changes like I mentioned before but it's ok

[bryanoltman]

The upgrader package looks reasonable.

I think your response correct, but I would say that

Having releases otherwise defeats the purpose of having code push altogether.

isn't true for a few reasons:

1. Users will always see the base release version of your app when they download it from the store. If the release gets too far out of sync with your patches, this is no good.
2. The App Store and the play store both have rules against introducing significant new functionality without review, and code push should not be used to skirt store policies.
3. On iOS, patched code will run slower, so it's ideal to keep as much running code in the release build as possible.

[dndeus]

Got it, I'll keep that in mind