Open felangel opened 2 weeks ago
I feel this is similar to: https://github.com/shorebirdtech/updater/issues/140
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
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.
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
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:
Got it, I'll keep that in mind
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: