I have this situation.
I have an already published react native app (both ios and android) (1.0.1).
So far, all the changes needed were made using OTA, so I had a jenkins pipeline which was trigger each time I was pushing anything to production branch. One of the main steps here is expo publish —release-channel prod-1, so I’m having the release channel called prod-1 here.
Now, I had to add some dependencies, therefore I am not allowed to use the OTA for these ones.
Here comes the questions:
What happens if I accidentally publish the current changes (which includes not accepted OTA changes) to the release channel prod-1?
Should I create a new release channel for these new changes called prod-2, then create the build for it, then submit it to stores for approval, then once approved released it in production?
If so, what will happen with the initial release called prod-1, in case I will need to do any changes on that one, should I simply publish again to prod-1 and an OTA will be performed for all the users using the old all version?
I was thinking about this flow, please confirm me if this is right or if you have any other ideas:
Create a new branch called production-v1 where I will merge what I have now on production, with a pipeline for automatically publishing the changes to prod-1 (OTA - if needed for the users using the old app).
Change the production pipeline so instead of using the release channel prod-1, it will use prod-2
Merge the main into production so it will trigger a new publish to prod-2 channel
Submit the build to the stores and once approved, I should be able to release the new version for the users using the old app.
Please let me know if I’m missing anything here, or if my approach is wrong. Thank you so much!
Related
This may sound paradoxical. My goal is to find a tool which automates the process of logging in to App Store Connect, and click the Make App Available button. This is because my team has an internal process of releasing changes to our products. There are a lot of things to do but we also have tools to automate all of those. So I'm looking for something to append to our release automation tools so the whole release process is completely automated.
Problem statement
Because we need to have full control over the release time. Sometimes, in a company environment, after all the testing is done, we want to release the app, and start monitoring usage on that day. On Google Play, this is not a problem. We can expect an app we submit for release to go live shortly after the submission. But on App Store Connect, with the current submit for review process, we have no control over the review time.
Using Fastlane, setting the automatic_release flag to true, it would mean the app could go live at weekends. If a problem occurred with that new version, no ones would be on hand to quickly fix the issue.
Or the other option, setting the auto_release date, we could still run into the same problem if the review process took longer than the defined release date.
Is there a way to submit for review with the "Manually release this version" option, then, after the approval, have some tools/apis that would log in to App Store Connect and press the Make App Available for us?
You can list all available Fastlane actions on GitHub.
If you can't find a predefined action for your need, it's worth to check Fastlane Spaceship module for low level API calls:
spaceship exposes both the Apple Developer Center and the App Store Connect API. It’s super fast, well tested and supports all of the operations you can do via the browser. It powers parts of fastlane, and can be leveraged for more advanced fastlane features.
While searching in the Spaceship source code I found that app releasing is already added:
for phased release use: release
for immediate release to all user, use: release_to_all_users
I don't have a chance to test this, but the following snippet might help to start if you're not familiar with Spaceship. Put this in Fastfile then call it from where you need:
lane :release_app do
require "spaceship"
Spaceship::Tunes.login('email#example.com')
app = Spaceship::Application.find('com.example.app')
app.release_to_all_users
end
I've just published an app on Apple's store and I'm wondering about having multiple versions of the same app for testing on TestFlight. Of course dev doesn't stop when publishing... from now on I'll have to update the app store version (v1.0.0) with bug fixes (v1.0.1, v1.0.2, ...) and before doing so I'd like to check them in test flight to ensure the fix was appropriate.
My problem is that I'm already starting to develop the next version with further functionalities of the app which will become v1.1
So ideally I'd like to have my app available both for my bug fixes, for instance v1.0.2 and also my next version v1.1.0 (this will include all bug fixes made to the store version and also many new features, refactors, redesign, etc)
I know that if I build and upload to the apple store connect a build with v1.1.0 (next version) I won't be able to upload one for a built with a bug fix on the current app store version (v1.0.2) since this version would be lower than the one I uploaded (next version)
Is there a way to accomplish this? I've read this article https://savvyapps.com/blog/using-testflight-to-distribute-multiple-versions-ios-app which solution is to create extra applications in iTunes with different app ids and bind them to different certificates. But what will happen when the next release is ready to be in the store? I would have to release it and then disable the previous one? How may this affect my users? Will they have to re-install a new app rather than updating it?
I really need to start testing and checking the next release of my app in TestFlight and also support the current one with updates if something pops up. Thanks in advance!
I am able to upload multiple versions of the app to TestFlight. Each upload requires a higher version/build number, but you can switch the TestFlight test version between them as need be for testing.
Once I submit a particular build for release, however, I seem to lose the TestFlight access to the old builds.
In short, you can have many builds available in TestFlight, but once you submit the app for release, you have to start over making builds for TestFlight.
You keep talking about numbers like v1.0.1. That looks like a public-facing version string, with a major, minor, and patch number.
But that is not what TestFlight cares about. Well, it cares to some extent. But all TestFlight really cares about is that every new build you upload has a new build number. This is just an integer which you simply increment every time you submit a new build.
So you could have v1.0.1(23) on the App Store, and then on TestFlight you could upload v1.0.2(24) which starts moving forward toward version 1.0.2, but also upload v1.0.2(25) which is actually an attempt at a prospective version 1.1. TestFlight doesn't know or care what these different builds signify. They can all exist simultaneously on TestFlight. Keeping them all straight and on their individual trajectories is up to you.
The problem, as you might expect, is the app review process.
In order to get Apple to review an app update, it has to be pointing at my production server. In order for that to work, I must update the build on my production server. But of course I don't want to do that until the app update is available in the Apple Store.
Now this isn't a problem if I've only made changes that can be deployed via hot code push ... but changes that can be deployed via hot code push don't need a new app wrapper anyway. I'm concerned about things like new node modules, or an updated meteor version.
Anybody know how meteor expects us to handle this?
(And in case it's useful, here's my related meteor forum post: https://forums.meteor.com/t/whats-the-right-way-to-do-updates-via-the-apple-store/28491)
According to the meteor forums, the right way to do this is to package a separate release that just includes the wrapper-breaking changes (an update to the meteor version, for example).
Once that has been deployed (and "all users" have received it) then you can deploy updates that change the app interface.
... and since there's really no such thing as "all users" receiving the update, I'm thinking it might also be good to have the client know about breaking app wrapper versions and lock down somehow if the client's wrapper version is incompatible.
I currently have an app on iTunesConnect with a few hundred external beta testers using it. Important to note, we will have 2000 testers by the end of the month. I want to push new builds to this app- and this, I know how to do.
What I don't know is, what is the expected behavior for my beta users when I add a new build?
Our company cares a lot about user experience, and we don't want to have our current testers of our current build open the version that they've already installed, only to see it crash because I added a new build that i'm hoping will just update their current version automatically.
Apple does a good job of making a developer think this might happen. I've searched everywhere to find this answer in the docs- please help! After selecting a newly approved build to switch to in the External Testing portal, upon selecting Save, this alert appears:
(405 is the first build, 407 is the new build)
So, what happens when I save this- will users be notified that they need to update the app?
Will the "update" happen automatically for them if they've already installed the first build?
If they open the already installed version, will it simply crash?
If so, what can I do to prevent this from happening?
My team will likely want to send out 1-2 builds / week (of the same app, with fixes and improvements) to the same group of testers until we're ready to officially launch the app. I'd hate to think this would crash the app on them every time. As far as I know, there is no way for me to test this before performing this action- I'm already added as an Internal Tester, but that's a completely different UX in TestFlight (builds are made available to internal testers immediately after uploading)
If you think this has been asked already:
This is not a duplicate of this question- because I haven't attempted to send out the build yet. I want to make sure that linked issue does not happen to my testers!
My question is unlike this one where the user did not know how to properly increase his build number, unlike this one, referring to testing a new build of an app that already has a version in the app store, unlike this one which refers to a bug in the app store where a user couldn't initiate an external test after uploading a build, and unlike this one where the user just didn't know how the iTunesConnect portal works.
We've been using git flow for our iOS projects happily for a while now. However, something dawned on me today which means we're actually not following the git flow specification.
When we start doing the final testing of a release, we release a BETA version to several hundred people within our organization. Now, this BETA is basically a Release Candidate since no additional bugs may be found in which case it's ready for App Store release. Since there's 7+ days of review time we always upload this BETA to iTunes Connect and set it to wait for review.
We release this BETA from a tag on the master branch after merging in its release branch. However, git flow dictates that the master branch must reflect what is currently in production. Now, there will always be a wait time until it's actually in production (so we can't not break the git flow model), but if serious bugs are found in this BETA, we remove it from the review queue meaning it's not going to be released, and now the latest commit on master is not reflective of what's going to be in production.
How do you get around this in your workflow?
We release this BETA from a tag on the master branch after merging in its release branch.
However, git flow dictates that the master branch must reflect what is currently in production.
So, why would you do that if the BETA is not currently in production? :)
I mean, the release branch is meant precisely to track the lifecycle of release candidates while they are being evaluated, regardless if that means internal testing, beta users testing or, why not, App Store review process.
So, I’d suggest you keep the release branch open during the entire lifecycle of your BETA and build from there the version submitted to the App Store:
If you get a rejection or have any problem with it, you can still tweak it and resubmit a new candidate from that same release branch.
Once you get the App Store approval, you can then close the release branch (which merges all changes both to master and develop) and set it live on the App Store.