I need a way to detect if user install the app from fresh, or after update.
The catch here is that version 1 of my app is already on the App Store, so I cant rely on any user default flag.
I'm now working on version 2, and I want to detect on app launch, if version 1 was installed or not.
any ideas?
If you didn't make the provisions (app defaults etc), there is no other standard/default way of knowing if a previous version was installed .
However, you can still find a way to detect if previous version was installed based on whether in previous version you
created a folder/file in app documents/cache directory or
created an SQLite db or
sent the UUID to a a server or
any other code/feature which can be checked with an 'if exists' code on app launch
If you can't.. there is no other way.
Related
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
I have a React Native app in the Apple App Store and recently released a new version. I'm getting reports from existing users who already had the previous version of the app installed that their new install is either partially upgrading or not upgrading at all, even though the app store is showing that the new version is installed.
In the app store they are seeing the new version number. They do the upgrade and then see the Open button, indicating that the upgrade is complete.
Some users are reporting that they see the old versions splash screen and then the new version of the app is there. Others are reporting that the old app hasn't changed at all even though, as I mentioned, the app store is showing the new one is installed. If the user deletes the app and installs it clean then it is always properly installing the new version.
Any idea why this may be happening? I would think that an upgrade scenario would be simply keeping the app data around while removing the old binary and replacing with the new binary.
I did switch the splash screen loading method from Launch Screen in the old version to Launch Images in the new one. And I have had many javascript changes and new native libraries installed. And my redux store has some different data structures. But I don't know why any of these things would result in a partial upgrade.
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
When users who previously had our iOS 6 app installed on their iPhone, go to the App Store to reinstall our app, they see an iCloud button instead of the INSTALL button.
When they push the iCloud button the App Store installs the version of our app they installed in the past, instead of the latest version. Immediately after the installation the iCloud button changes into an UPDATE button offering to update the app to the latest version.
How can we prevent this behaviour, because the user actually downloads our app twice?
Our app is for free, so there is no need to install a "previously purchased" version.
Also if the user presses the UPDATE button fast, things get screwed up. For some reason this leads to our app being unable to save data to the Documents folder.
This is new behaviour. Have never seen this in the past. Anyone got a clue? The name of our app is Rogerthat
Thanks
I think this issue could be caused if the version set in iTunes Connect and the version set in the info.plist don't match up. For example, we've seen this issue when the version in iTunes Connect was set to 1.01 and the version in the info.plist as 1.0.1
For reasons too convoluted to get into, I had to switch to a completely new project to update an app in the App Store.
Is there anyway to get access to the sandbox of the old app or will the new one just create a completely separate sandbox? In testing my dev builds of the old and new app they are completely different document directories so my archived info doesn't survive the update.
Does going through the app store effect this in any way or am I just out of luck?
I've matched Bundle ID's and provisioning profiles and that hasn't helped anything.
If you are submitting the completely new version as an update, the data in the NSDocumentsDirectory and NSLibraryDirectory will be preserved. If you are creating a new app in iTunes Connect, the data will not be available and there's no way of getting it back (because you can´t access the sandbox of other apps).
To test this, the best thing you can do is to install the old version of the app on your device and run the new one to update it. If you matched the bundle id correctly, instead of creating a new app on the springboard it should update the existing one. Data should be preserved in this update.
Remember to set your version number to something higher than before. For example, if your old app is version 1.0 you should try with 1.1 or 2.0.