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.
Related
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 just released an iPhone app update and certain features don't work when the app is updated. More specifically, a plist that I download and store in Documents isn't displayed.
This worked fine in the previous app version and works fine if the new version is downloaded directly from the App Store. If someone upgrades, then uninstalls and reinstalls the app, that works too.
Does anyone know what's going on here? Apparently the app upgrade process completely replaces the app bundle but keeps external files and settings (NSUserdefaults, etc.).
More importantly, does anyone know how to fix this? My last resort is contacting my substantial user base and telling them to uninstall and reinstall, which is bad for my reputation.
Any help is appreciated!
It may be possible to write some code that checks the plist in the document folder against the plist in your bundle and then move the new plist to the documents folder, or at least updates the old key-values to your new key-values.
This is the way that preset Core Data stores are initialised.
i want to save a file outside of my application bundle as a backup of database so that when user reinstall my app or my app crashes he can backup his data from that location.
Apple already does this, with iTunes.
What you are asking is technically against apple's policy, unless you store it off site, on a server (which you could easily do)
If you have a lot of applications, I'm not aware of the policy, but perhaps you could make an app to back up your other app's data.
I'm considering including some large movies in my app, but I don't want users to have to re-download the movies each time they get an update. When a user downloads an update from the app store, do they end up re-downloading the entire bundle? Or only parts of the app that have changed relative to their version (i.e. do updates only ship some sort of binary patch)?
The whole app. iTunes actually stores multiple versions of all your apps, and they are submitted to Apple as zipped app bundles.
The whole bundle, as submitted to, tested, approved and codesigned by Apple.
iTunes will delete any previous versions of your app.
If you have very large content that you don't want installed on every update, you might want to consider allowing users to download it from a website for offline use, and have the app store it in the app's sandboxed Documents directory, which should survive app updates (baring weird update bugs).
My experience is that large apps take a while to update. There are many ways Apple could theoretically implement a diff (and it's probably advantageous for them to offer a diff between the two latest versions, since it reduces their bandwidth bill), but as far as I know, they don't.
"Large" apps (>20 MB, currently) can only be downloaded over Wi-Fi. If you make your app big enough, that means users won't download the update until they get connected over Wi-Fi. Also consider that existing users have already paid you — I don't advocate screwing over your users (if only because they'll leave bad reviews), but taking a while to update apps isn't a big deal; that can happen as I sleep.
I'd worry about new users/initial installs:
New users won't be able to download your app unless they're connected over Wi-Fi. I'm not sure what the difference in sales figures is — I can't see it in our graphs (so under 10%?), but it probably depends on the type of app.
A lengthy initial install leaves a bad impression: They've never used your app before. They just found it on the App Store, decided it was worth buying/installing.... and now they have to wait.
If you don't mind running your own servers, then it's definitely worth considering.
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.