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.
Related
I wonder if there is any way to distribute different versions of same app (same means same bundle id, same account) in Apple Appstore.
Lets say, I want to distribute, MyApp (com.stackoverflow.myapp) version v1.2 but there is already a version v1.1 open to public. Is it possible to keep both version open for public. And fixing issues and release different sub version like, v1.1.2 and v1.2.2.
As far as I know with single bundle its not possible. But still I am curious if there is any workaround.
When you release a new version on to the app store, you can now select an option for a "phased release", where the update is shown to current users incrementally over a 7 day period, but at the end of that seven day period the updated version is available to everyone. Also, new users will get the latest release when they install from the App Store.
You cannot maintain two "active" releases on the store.
If you want to test a new version or new features with a limited set of users then TestFlight may be an appropriate tool.
You can use whatever versioning system you want (such as semantic versioning), but you can't distribute multiple versions of an app at a time without uploading them to the App Store as 2 entirely different apps
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.
I have an app which is rejected for multiple times stating Apple can't check the app as the app is not loading beyond Splash screen.
When I check it at my end, its working fine with no issues.
So now what I have decided is to check through the TestFlight. For that I upload new version of app with build as 1.5.4.5 and its working fine.
Now I am looking for a way to add 1.5.4.4 for testflight, however I can't.
Can someone point me in right direction on how can I add those old builds for testflight? I want to check those builds at my end on multiple devices.
No, you can't use an old version as the build number must increase, you can checkout old code and make a new build from it then upload that.
I released an update for my App and it was approved. It was approve despite the fact that it included a serious localization bug where most users are getting the wrong language. Is there any way to quickly revert back to the previous version, suspend current downloads of the current version, or anything else that might help aid this issue?
I did read the following thread from a couple years ago:
Can I revert to my previous version app in iTunes Connect?
I was hoping maybe there is a more painless solution to this now.
Btw, I did thoroughly test the version before it was added as a new version. So, I'm still not entirely sure what's wrong or how to fix it.
It is not possible to revert the app version. You can upload the previous version as new version again to fix this.
One thing you can do is : "Expediting an App Review"
Please check the following link.
https://developer.apple.com/appstore/contact/?topic=expedite
Thanks
Here's a snippet from iTunes Connect Help page :
Question: The new version of my app on the App Store has a bug. Can I use a previous version to replace it?
No. You cannot revert to a previous version on the App Store. You must submit a new version.
Source : iTunes Connect FAQ
Obviously the alternative would be to submit a new build but ask for expedited app review.
But that means that either your app is event-related or you have a critical bug that you need fixed as soon as possible.
I believe that you can prepare for problems by creating a fallback version with a higher version number and submitting it for approval with manual publishing. That should cause it to be quiescent in your store until you choose to fall back, and you publish it.
I am not certain whether you can then submit improved versions with a lower version number than your fallback version.
I had to do this recently. I was able to adjust a previous version archive. I started by copying the archive and opening the copy, then editing the info.plist files, adjusting/incrementing both the version and build numbers at both the archive and app package levels. Then uploaded to iTunes, which recognized it as a new version.
Preface: I agree with the other posts here that you can't perform a rollback through the iTunes Connect itself. Even if you could, you'd suffer the lag time it takes for users to update to the rolled-back-version. But that doesn't mean we can't still rollback apps.
Retroactively, you cannot rollback an app. Proactively, however, you can instrument your app to enable future rollbacks after a build has been released and installed.
High-level steps:
Build each version of your application as a framework
For each release build, include both the current and old framework versions
On app boot, decided which framework to load and execute (include sane defaults)
When you want to rollback, update the cached values across all user devices and wait for the next app open.
This strategy uses similar mechanics to feature flags which are commonly used to enable/disable features without re-releasing. However, in this case, you're "feature-flagging" your entire app version.
Is feature flagging between embedded libraries against App Store Guidelines?
No. Embedding two versions of your app into one release is not against App Store review guidelines:
4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g.
HTML5-based games, bots, etc.), as long as code distribution isn’t the
main purpose of the app, the code is not offered in a store or
store-like interface, and provided that the software (1) is free or
purchased using in-app purchase; (2) only uses capabilities available
in a standard WebKit view (e.g. it must open and run natively in
Safari without modifications or additional software); your app must
use WebKit and JavaScript Core to run third-party software and should
not attempt to extend or expose native platform APIs to third-party
software;
Similar to feature flags, all code that you plan to run is included in the binary that you submit for review. What's more, as long as you are rolling back to releases that Apple already reviewed and approved, you're not breaking the spirit of the guidelines.
Does this hurt performance?
I've profiled this approach against many of the popular and heavy open-source iOS apps including Wikipedia, Signal, Firefox, etc. You can be smart about deduping assets and shared libraries, resulting in a sandwiched-app-bundle size of about 1.2x the original size (really just depending on how much code you changed). You also incur about a 50ms startup cost when choosing which version of the app to boot.
IMO, both time and size increases are worthwhile in return for the ability to selectively rollback users experiencing issues while you take time implementing a fix.
Do real apps do this?
Major apps feature-flag between dylibs all the time when launching new features and optimizing performance. I have also heard of major tech companies using this app-level pattern for their largest releases. I have a personal app in the App Store using this pattern, and I have helped other developers do the same.
How can someone do this for their app
If you are comfortable going deep on the Xcode build system, you can follow the steps outlined above and with some fiddling, start feature flagging your app version on boot. Note that you'll also need some form of caching and a server endpoint to update the on-device flag.
The implementation described above is also exactly how screenplay.dev implements iOS rollbacks. The tool:
Adds two build targets to your Xcode project, one for building the framework version, and one for bundling the final release build.
Serves as a repository for your old app build versions.
Provides a web UI for toggling live versions.
I submitted my Full and Lite version of my iOS App to the Apple App Store for an incremental release (1.2) - both Apps are already For Sale. I added In-App purchases to my Lite version.
My Full version was approved, but my Lite version was not. In discussing with Apple, they have provided a screen shot showing that they can't access the In-App functionality in the Lite version, but the screenshot is from my Full version, which doesn't have that functionality.
I'm appealing, and am hopeful that they will address.
This is the first time any App I've had was rejected, and I have several questions that I would appreciate any suggestions from developers who have gone through this.
Is there a way for me to run the exact code that I submitted from the Organizer/Archive so that I can verify that my Lite version is indeed the Lite version and not the Full version? I can see them in on the local file system, and there are 2 different, distinct files that have different sizes.
If I have to rebuild my App and resubmit can I do that from the same archive that is in Organizer?
If I have to rebuild, I think I'm in a bit of trouble, because I've been heads down on the next release for the past week and a half. Is there a way to access the version that was used to build the archive?
thanks.
You can resign the released version to be an adhoc version and run it on your device.
If it requires a new build it won't let you submit with the same version number which will probably stop you from using the same archive unfortunately.
It has been my practice to make a snapshot for every release for this case. If you don't have a saved snapshot or if you aren't using source control then you may be out of luck on that one.