We want our testers to be able to:
1) Replace an installed Tesflight version of our app (test-version) when installing the App Store released version of our app (app_store-version) without loosing their data (all inside the app bundle, Core Data and other DBs, Keychain data, User Defaults).
2) vice versa
Replace an installed app_store-version with an test-version without loosing the above mentioned data.
The only information I found is in the Testflight documentation:
...If you already have the live version of the app installed on your
device, the beta version of the app will replace the live version.
When you’ve downloaded the beta app, you’ll see an orange dot next to
its name that identifies it as a beta. ...
I did not find any information regarding the opposite case (... if you already have a test-version installed, the app_store-version will replace it...) nor if the above mentioned data is kept when replacing the app.
Apple Developer Support told me that they do not have this knowledge. :-/
My Questions are:
1) Is is possible to replace a Tesflight version of our app (test-version) with a App Store released version of our app (app_store-version) without loosing the above mentioned data?
2) Is is possible to replace a App Store released version of our app (app_store-version) with a Tesflight version of our app (test-version) without loosing the above mentioned data?
3) If 1+2 is possible, which parameters are taken into account to replace/ not replace an app? (BundleID only, BundleID & BundleVersion ...)
You can override TestFlight and App Store version like regular updates. But, in order to do that, the Next Version should have a build number greater than the installed one.
That means that you cannot install the TestFlight version, release it on the App Store and upgrade, because the build numbers will be the same
Related
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.
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 was trying to test update scenario from live App Store app build to RC using TestFlight, but TestFlight gives me alert "You already have this app installed. Do you want to replace..." (see below screenshot). After confirmation, all data from App Store version is gone.
Steps I do:
Install live app from the App Store
Login and do some operations to get data in the app and Keychain
Go to TestFlight iOS app
Tap "Install" button in TestFlight -> alert "You already have this app installed" appears
If I tap choose Install, new build is installed
Result:
The app's content including Shared Container (data shared with Extensions) and Keychain are completely wiped when I open the app again
Edit: The alert in TestFlight appears with any app (I have tried multiple different apps from different dev accounts). The actual data deletion happens only for some.
My question:
Is this expected behaviour from TestFlight or is it any issue with my app? I'm not aware of any changes between versions which could cause any issues.
I believe this was not happening before (the last time I tried was few weeks ago).
I couldn't find any documentation or release notes regarding TestFlight app behaviour or changes.
Did anyone experience the same issue? Or do you know any resources describing this behaviour?
Thanks for any answers!
After long research, trials and errors, creating radar and releasing update to App Store, I have an answer:
Alert is there always and does not have relation to losing data.
The alert with warning about possible lose of data is being displayed always for any app being installed from TestFlight over the Non TestFlight Build.
This was true for any of multiple apps I have tried.
identifierForVendor changes when overwriting app with TestFlight build.
When you have App Store version of the app installed and overwrite it with build from TestFlight, result of [[UIDevice currentDevice] identifierForVendor] changes
This is unexpected since it is not mentioned in the documentation (see below)
In my case unexpected change of identifierForVendor was causing "loose of data" which wasn't actual lose of data, but it is happening only for TestFlight builds which you cannot debug, so it was hard to find the issue.
Documentation of [[UIDevice currentDevice] identifierForVendor] says:
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. The value can also change when installing test builds using Xcode or when installing an app on a device using ad-hoc distribution.
as per best of my knowledge,
if you have installed application from App Store (suppose of version number 1.0) on your device, and lets say your are again downloading/installing same app with same version number 1.0 from TestFlight, you will get above message.
This is because you are trying to install app with same version and bundle id that already does exists on device.Offcourse you will lose data/settings of app, as its replacing your app not updating.I also gone through this scenario.
If you have the full version of an app installed on your device and you install the same Beta App, your app data may be corrupted or lost and may not be recoverable. You should back up your information before installing a Beta App.
http://www.apple.com/legal/internet-services/itunes/testflight/sren/terms.html
I don't know how this happens
I have uploaded a new version of my app which contains some DB (Used CoreData) changes (server side changes too). I have added new model so that the DB changes do not causes any crash.
Downloading the app freshly works fine. If an older version of the app is in cloud, then when i try to install the app (shows cloud icon), older version gets downloaded and casues a crash. Is there a way to prevent the iCloud from restoring/downloading the older verion?
The following steps solved my problem.
In itunes connect click on the app icon.
Select 'Rights and Pricing'
Now select 'Manage iCloud settings for this app'
Now check the versions that you don't want the users to download from iCloud.
Let me credit #grgarside for his answer here -> https://apple.stackexchange.com/a/254181/121124
iTunes Connect → My Apps → app → App Store → Pricing & Availability → Last-Compatible Version Settings → Available Versions.
is the new flow sequence, you are looking for.
I am writing this as a new answer, as the user interface has changed a lot as compared to the 2013 version.
here is the 2017 version
No, you can't prevent users from using their own backups, and you shouldn't either. You've probably handled the update badly if your app crashes on restoring the version (possibly updating?). Core data model versioning and migrating is what you need when updating the core data model in the current app version and want to keep backwards compatibility.
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.