Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: update check condition #135

Closed
mstfmedeni opened this issue Feb 21, 2025 · 1 comment
Closed

question: update check condition #135

mstfmedeni opened this issue Feb 21, 2025 · 1 comment

Comments

@mstfmedeni
Copy link
Contributor

We use different bundles and different versions in our application. We have small differences according to the bundle. For example
Test version
Staff version
Release version

There is no problem in the release version, since the version has changed, we can make small updates with the new hot-updater and since the version number will change in the next version, there will be no problem, but in the test version, many builds are loaded for version 1.0 and many small changes are made.

For example, I made two updates with the hot-updater and then I loaded a new testflight update with the same version number. In this case, even if the test flight update is made, the hot-updater update is still made and crushes the changes. This causes a conflict.

-What are your suggestions in this case?
-Are there different checks in the control structure?
-Even if the bundle id is different, it still seems like the update is being made, is this normal?

As a simple solution suggestion, the build number can be included in the version number, so uniqueness can be ensured even if each upload has a testflight version.

thank you

@gronxb
Copy link
Owner

gronxb commented Feb 21, 2025

From my experience, this issue also occurs with Microsoft React Native CodePush.

Including the build number somewhere would complicate version checking on the server side. Since TestFlight is considered a pre-release stage, it makes sense to treat it as a release version.

To manage this, it might be necessary to prevent the wrap from running for TestFlight builds, like the example below:
export default isTestFlight ? App : HotUpdater.wrap(App);

Alternatively, a separate app version can be created specifically for testing to avoid conflicts with the target app version.

Therefore, as this seems to be the intended behavior, it might be difficult to expect additional support from the library

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants