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
Related
I have a Flutter developed App that I want to upload for App Store Review.
The App has been successfully uploaded through Xcode as you can see here— https://prntscr.com/26m7w94
Sadly, the Build doesn’t appear in my App Connect Build section as you can see here— https://prnt.sc/26no755
When I try to re-upload, it let’s me know that the Build is already uploaded to App Store Connect as you can see here— https://prnt.sc/26no84v
I have written to Apple and I don’t understand the answers they are giving me. They are just talking off-point.
Now I have waited for 8 days for this build to appear, but this uploaded build is not appearing.
Without this Build appearing, I cannot Submit to App Store Review.
Everything in the App Store Connect Form has been completely filled. Only Build remains to be added as you can see here— https://prntscr.com/26no94s
I can’t figure out what to do next, and this is 8(eight) wasted days gone by, with me not knowing what next to do.
Has anyone here faced this kind of problem before? How did you solve it?
Regards
Check in the TestFlight section. There might be a yellow triangle next to your build. You may need to answer some additional questions such as encryption usage etc. Just click on the triangle to answer and your build should be available afterwards.
Sometimes the answer to this issue is that there is actually a problem with App Store Connect (like right now).
You can check for issues on the Apple Developer System Status page.
For me changing the version from X.X.X to X.X.X+1 (2.2.2 -> 2.2.3) fixed the issue.
Sometimes it happens and I have also faced this problem .I successfully uploaded my bundle from Xcode but not found in connect.
I waited 30 minutes and refreshed .Then my bundle came in App Store connect.
Solution 1 : wait for some time & Refresh ,
Solution 2 : Create another Bundle and push to connect using Transporter (You can download transporter from appStore)
If the build doesn't show up on App Store Connect. You may want to check your email (the one you used as your Apple Id when uploading the build).
In my case Apple sent me an automatic email telling me that my build had some issues. Xcode didn't complain about anything and neither App Store Connect.
UPDATE: This might have boiled down to timing. After changing the version number to 1.0.0, that build showed up immediately. Half an hour later, the 0.0.1 build appeared out of the blue as well.
If you've set your version number to 0.0.1+X because you thought that makes sense while the app is still under development, change that back to 1.0.0+X. The upload will succeed, but app store connect won't list the build without a leading "1." in the version number.
Make sure no webviews are used in your app. It will not show builds in App Store Connect and neither XCode nor Apple will say that anything is wrong.
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
The app is in the App Store. The phone companion app installs on the phone just fine, but for some users it (randomly) fails to appear/install on the watch. The app does not show up in the "My Watch" listing in the iPhone Watch app either.
I saw a variety of advice sites saying this can be resolved by doing things like resetting / re-pairing the watch. Also, the app has always been approved pretty swiftly when submitting to the App Store.
So my question is: can it be something code/setup related that can be fixed at the dev level? Or is this just a pesky Apple bug?
Most users are on latest iOS/watchOS versions (11.4/4.3.1)
OK, so problem was a mismatch between OS version on the device and the target version for the watch extension in XCode. If the target version is greater then the watchOS version on Apple Watch, the app will not show up in the Watch app listing and will not install, when auto-install is on. Unfortunately, all this will happen silently, with no warning or cue in the UI.
I have a serious issue which I cannot seem to solve.
Recently I have made an update to an IOS app, and when testing in XCODE as both Ad-Hoc, Debug, and installing via the .IPA on a device the issue cannot be replicated. However when I download the app from the App Store, it crashes.
Does anyone know how this could happen, and any potential solutions? I am getting lots of complaints from users, and not sure what to do?
Could part of the binary upload have got corrupted?
Probably you always compiled your app in debug mode. But when sent to App Store you made a release compile. click the arrow in the run button select scheme and chose "release mode" and run your app it will probably crash.
check if you used NSParameterAssert as they are not called in release mode
I cannot say why your live App Store application is crashing and the debug version is not. Two possible solutions:
Crash reports:
To find out why your application crashed, you might want to check if there are any crash reports available on iTunes Connect. Log in on iTunes Connect and click on your application. Scroll down to Crash Reports. You will find out more about why your application is crashing here.
More information about crash reports here at Apple's own iOS Developer Library.
Prerelease your app with TestFlight: For in the future: test your application by uploading it on iTunes Connect and testing it with TestFlight first before submitting the application to the iTunes Store. This will save you a lot of (review) time if you find a error.
I realize this is an old thread but I had the same issue with my App that I released. Meaning it worked fine in testing, but when I released it it would crash. The culprit ended up being the fact that I am using In App Purchases. I have two items that can be "bought" but I had only enabled one of them. In testing it was able to read both of them, but with the release version, it was only pulling the one that was enabled down, creating the crash. The fix was simply enabling the disabled item. I didn't even have to redistribute the app, though I had to wait for it to "percolate" through... Anyway this may help someone in the future.
Check if your app is looking for too many IAPs.
I just had this problem and my problem was I had deleted an IAP from the App Store, but didn't remove it from the app code.
For some reason it only crashed when downloaded; I used a promo code to do this before launching my app.
Thanks to Tornado for the inspiration to try this variation.
I read in this Stackoverflow question that to simulate an app upgrade on an iPhone, you should install a new Ad Hoc IPA of the file via iTunes.
You can therefore check if the users data is still intact after an update.
I use TestFlight and quite often install new development versions of the app from there. Does this also simulate an app update?
You can test this by saving some data from the app, and doing the TestFlight upgrade. If the data are still there, then I think that shows that it does behave like an app upgrade.
When I did these sorts of updates, I think the data stayed, but I recommend testing to be sure.