In the releases overview of my app in the Developer Console of Google play I can see the following Releases prepared for publishing:
I have 2 releases ready to publish, but I only want to publish the latest (GREEN) and skip the 3.15 Release, which is marked as RED.
How can this be done?
Related
I've pushed version 3.0.3 of my app to the Google Play Console, and want to undo it. I know they don't allow you to do this once it's In Review, so what I'm wondering now is, does the next version I push have to be 3.0.4? Or is there a way I can go from, for example, 3.0.3(5) to 3.0.3(6)?
I developed an app with React Native and distributed it with Expo. I published the final version into Google Play and Apple Store.
Some time later I discovered in Expo's docs on Publishing that expo publish allows you to create an OTA ("over the air") update that is built into Expo and updates the app automatically, according to this answer:
The standalone app knows to look for updates at your app's published url.
This I tested and worked very well.
However, now I see that people downloading the app from the stores (that is, either Google Play or Apple Store) apparently get the initial version of the app, not the updated one.
What is the exact workflow for the OTA updates? Do they go and "replace" the existing version in Google Play and Apple Store the first time they open it? Or do they need to open it over again to get the update?
And what exactly triggers the update of the app?
We've been having similar problems. I can see two things which might be causing this in your case:
Check in app.json if updates.fallbackToCacheTimeout is set. If it's set, that's how long expo will try to download the latest update before showing the last downloaded version (which will be the initial version after initial download).
If you have a large update, expo will try downloading the update for 30s before showing the last version of your app.
Check here for more info: https://docs.expo.io/versions/latest/guides/configuring-ota-updates/
OTA updates do not replace the version downloaded from the app store, they are stored first in the device's cache before being run on app start after download. Source https://docs.expo.io/versions/latest/sdk/updates/
Update downloads are automatically triggered on app start, then, depending on the settings it will either wait (as long as updates.fallbackToCacheTimeout allows) before showing the app, or show it immediately.
You can force the app to run the latest update (if you have one waiting) by just force quitting the app, then restarting.
Hope this helps!
I'm using Expo.io for publishing my over-the-air updates. I have submitted several new official updates (so new SDK/IPA files) to the App and Play store. I'm still using the same version of Expo as before. Will my over the air updates go out to the previous versions(people haven't gotten the offical app/play store update)? Or are the old versions stuck until the user manually updates to the latest version so that they can get OTA updates again?
If you upload a new build to the app store and play store, the user will need to download the build in order to get OTA updates for that build.
If you just build and push to the expo server, the user will be able to get OTA updates without any download.
The standalone app knows to look for updates at your app's published url.
From the documentation : Publishing Guide
When you build the binary, the current version of your app JavaScript
is bundled so that it loads immediately the first time the app opens.
But you’re not stuck with that version of your code, you can publish
updates at any time after that without needing to re-build the binary.
For example, if you find a bug or want to add some functionality to
the app after submitting the binary.
The standalone app knows to look for updates at your app’s published
url, and if you publish an update then the next time a user opens your
app they will automatically download the new version. These are
commonly referred to as “Over the Air” (OTA) updates, the
functionality is similar to CodePush, but it is built into Expo so you
don’t need to install anything.
Core expo team member #ide answered your question in this comment:
The way Expo, the publishing system, and versions work is this:
The Expo client and standalone apps support multiple SDK versions (ex: 18, 17, 16, 15).
When you publish your project, the Expo server saves your project bundle and the "sdkVersion" value in exp.json or app.json.
When the Expo client loads your project, the server sends back the latest bundle with the greatest SDK version that your client supports. So if your client supports SDKs 15 through 18 and you've published your project with SDK 15 and SDK 16, the server will send back the latest bundle for SDK 16.
So if you had published your project with SDK 16 before but then went back to SDK 15, any client that supports SDK 16 would still receive the old SDK 16 bundle.
The old Play Store versions will still get OTA (exp publish) updates as long as the published URL hasn't changed, which you can set in your app.json. This is because that URL is hardcoded into the native code (it's in MainActivity.java for Android).
Your published URL will be expo.io/#your-username/slug. From app.json's documentation:
slug
Required. The friendly url name for publishing. eg: expo.io/#your-username/slug.
Downloading beta app from testflight app gives error at the end, says "Unable to download app at this time" on all my devices.
No error is in itune connect upload. App displayed and received notification on adding new app to testflight beta. But everytime same error.
This happened to me when I wasn't using the correct provisioning profile. Very frustrating error that doesn't provide any useful info, and leaves the previous installed version of your test build in a state where it cannot be launched. After I switched my provisioning profile to 'Automatic', bumped the build number, and submitted a new version to iTunes connect I was able to download the new build.
I'm seeing a similar error. I don't know for sure, but I suspect doing things in this order may have something to do with it (this seems to mirror what emrys57 is facing).
You have issued a previous TestFlight release (download/install was working).
You then submitted that version for formal review for publication in the App Store.
While the app submission is still under review, now you uploaded a new TestFlight build with an updated version number (but did not resubmit for App Store review).
It could be that while the app is under review something prevents the download. I seem to recall reading about something like this in one of the guides, but I can't remember where off the top of my head. In my case, as an internal tester I even face the error "Unable to download app at this time", regardless of whether I already have a previous version with the same bundle ID already installed or if I don't have the app already installed (i.e., it's fully uninstalled). I wonder if an accepted App Store review will clear up the issue; it doesn't seem like a good idea to resubmit that latest build for further App Store review if the version previously submitted is what you actually want released.
In my case, for the general testing audience, I have a separate bundle ID that is exclusively for beta testing. And that version is never submitted for App Store review (the one that's slated for App Store review I only use for the purpose of smoketesting the upgrade process with internal testers). That bundle ID for beta had to go through the one-time full TestFlight external review for the initial TestFlight external beta testing. But I've been able to keep adding new versions to that beta-only bundle ID for subsequent TestFlight releases without an issue.
I'm using the new beta version functionality in iTunes Connect. I uploaded a build (98) to iTunes Connect, set up some internal testers and they downloaded that build.
Now I've updated the build with a new version (build 99) and that's been uploaded to iTunes Connect, but I can't see how to provoke the system into pushing this new version out to the users and their TestFlight app.
I'm set up as a tester on a couple of devices (both with my developer ID as well as with another id) and I can still only see build 98.
On the iTunes Connect screen build 98 is listed as inactive (which is correct because it has been superseded by build 99), but build 99 only says 'invite testers', but I've invited all those I want to invite.
It says that users will 'automatically receive new builds', but how long does it take? I was hoping it would be instant. Is there a way to provoke iTunes Connect into sending out the update notifications so my users can test the new version?
I'm not sure if this is a bug in TestFlight but toggle off and then on again the "TestFlight Beta Testing" switch. As soon as you do it all your internal testers should get notified of the new build.
Another option is to simply go into the new Build Details and save it.