The application update process via app store (on the device by a lambda user) is not very well documented. I've sum up all this to these questions :
what happens when the user updates his app? Is everything erased, or just some part of the app?
so what is kept, what is not kept?
how to test the application update in a development environment ?
when user updates an app, Documents folder is stored as is, including NSUserDefaults (but, sometimes user download app via iTunes and replace the whole application, crying 'OMG! update killed all my levels progress!');
Application bundle is erased and replaced by new one (anyway, it is readonly for user);
Re-deployment of new build version will be enough;
Related
We have built an inhouse version of an iPhone application that is to replace another that is already available from another developer.
I was wondering if you think we can use "app transfer" from the previous developer and in turn replace it with our own app. Previous developer has agreed for the transfer (ofcouse excluding his code). Therefore our question is if we can transfer his app to our development name and then replace the app with our own. Our goal is that the current users of this app will receive ours as an update to what they already have and not as a different app.
In short, transfer and replace so users get our app as an update.
Note:
Please note that as we were unaware of this "transfer" we submitted yesterday our version of the app with a slightly different name. Should we cancel submition (as it is still pending for validation) and follow some route you may suggest in your replies, or stay as it is now?
If you keep the Appidentifier the same between the original version and the new version you will submit, this should work as expected. (But nobody has much know-ho of the new "transfer" option yet)
So, you process would be as follows:
Hand the old developer your TeamID and your Apple ID
The old developer transfers the current App over to your team
Once done (no clue how long that takes), you have the app in your itunes connect
Now you add a new version of the App to itunes connect and mark it as ready to upload
You upload your newly coded app that meets these criteria:
Application Bundle Identifier is the same as with the App you're updating
Your new App is signed with a correct certifcate/provisioning profile (just correct for the appid, doesn't have to be the same one)
The BundelVersion and BundleShortVersionString are at higher than those of the already submitted applications.
So basically, it will work just like a regular update.
I'm making my first iOS app. And I have a question.In my app I want to save the current state of the app: levels completed, score reached, money, in-App purchases, etc. in a Settings.plist. The problem is, how can I place this plist so that if the user updates the app, he/she not to lose these settings. I read about The app sandbox, but I don't understand
how it works, and how can I manage that from Xcode.
You should store these settings in the NSUserDefaults. They are kept when new app versions are installed, so you won't have any problems.
Two points:
a) When you update your app after its in the app store by submitting a new version of the same app the files created by the old version will not be lost. So you can store whatever you like in the app's Document or Library directories and expect it to still be there after an update. The Library/Caches directory will not be backed up or restored by iTunes so don't put anything there that you can't re-create. If you submit a different version of the app (not an update but a new app, so you have two separate apps in the app store, perhaps free and paid) there is no way that I know of for the new version to get to the files that the first version created.
b) It's easy for the user to read, delete, or change whatever files you create in Documents/ or Library/. It can be done with an app on his/her Mac such as iExplorer (downloadable from macroplant.com). So be aware that if the file is human-readable, which a .plist file is, the user can change it to improve his/her score, get more consumables, or whatever. You can prevent that by encrypting the data, or somehow obscuring the meaning, or by some kind of checksum scheme so you can at least detect that it was changed. Any of those measures involve complications of course and may not be worth the trouble.
BTW... if you're developing an app that uses data files iExplorer is a great debugging tool. I have no vested interest in it except that I've learned how to use it and want it to continue to be supported. There are probably other apps that do the same thing but this one works great and is fast and easy to use.
I am porting an Android app for BlackBerry and during tests I see my saved user data (properties and a list of activities) disapearing each time I upload my newly build BAR to the device.
Will this happen on every update of the app?
On Android, my local data stays permanently on uploading and installing new versions.
I do not want to use shared storage for this data to avoid too many permissions, since the user won't understand why I need this shared storage (user could wonder about if I want to steal his other data).
This seems to be an issue of the Android VM version used at that specific time. In the meantime, the behaviour is as one would expect it, and all user data stays even after app update.
I am developing several apps for AppStore, with different bundle IDs, but similar logic. Now I am working on a new concept, which covers all the logic from those apps into one common project. Hence, I would like to prepare a new app, that is intended to replace all the old apps. How can I ensure that?
To be clear, I want all the users to install the new app, run it, so that it can transfer data and functionality from old apps installed on user's device. How can I do that, so that all data and functionality will be kept depending on which old apps had each user installed, and Apple will be OK with such a change and behavior?
This is not possible, you will have to replace all the old apps with new once. You can't update the app bundle ID in a new version.
I need to change the bundle identifier of my iPhone app before I can upload it to the app store. However, I also have data in my Core Data store which want to continue using even after I change the bundle identifier. However, it seems that the bundle identifier is how the iPhone knows whether apps are identical with one another, so I end up with two distinct copies of the app -- with two distinct core data stores -- on my phone! I know that I can download the sqlite data store through the Xcode organizer, how can I make sure that my data transfers to the new app package with the new bundle identifier?
With some exceptions for OS4 every app (identified by it's BI) has it's own isolated storage on the phone.
If you really have to change this (will also disable free updates for buyers of the "old version") you have to find an external migration way.
A lot of apps offer some kind of "backup" (on a PC / MAC or something else).
What we did for a customer was to establish a website which allows "short time data storage".
So that the old app could upload the data - and the new one loads it down.
Of course this means updating your old app first for the "export".
But the idea "your app lives in it's own isolated world" also means that you have no access to the data of other apps.
From the point of security this is imporant and good.
For building "app suites" where the apps want to share data it's bad.
But apples made enhancments for this in OS4 - which (I guess) won't help you in your case, since "sharing apps" must also be special designed.
I know this question is very old, but I just noticed it while looking for the answer to the same problem and thought it still might be useful for others. The original poster half-answered his own question, but didn't quite take the next step.
If you have not yet released your app on the app store and you want to change your bundle identifier, it is possible to copy your CoreData store from one sandbox to another using the Xcode organizer as suggested above. Obviously, this is only useful for your own device (which I think is what the original poster wanted to do); this process won't allow data to be transferred on other users' devices if they've bought your app, so DON'T change your bundle identifier after your app has been released.
First, run the old app (the one with the old bundle identifier) on your device. In the Xcode organizer, select your device, then Applications, then select the app (with the old identifier) and download the data to your mac.
Then install the new app on your device (build and run it, then quit). In the Xcode organizer (and on the device itself) you should now be able to see two apps, one with each bundle identifier. Select the one with the new identifier, select upload and upload the data file you saved from the old sandbox. You should now have access to all your old data in the new app. Very handy if you don't want to recreate all the data.