Is this the case? Do NSUserDefaults get reset when you submit an update to an app on the App Store, or are they reset?
My app is crashing when updated but not crashing when downloaded fully - so I'm trying to determine what could possibly be different in the updated session to the freshly downloaded session.
Cheers,
Nick.
They are usually not reset unless the user deletes the app. For basic data, NSUserDefaults is the best way to save data such as preferences, dates, strings etc. If you are looking to save images and files, the file system is a better bet.
I beleive the answer is YES, it will persist. This also fully documented under the Application Directory chapter in the Apple iPhone OS Programming Guide.
Direct answer to the posted question: YES.
Your problem:
Your app gets crashed due to logic issues. Suppose you store an object in defaults and the app checks it's value on launch (or elsewhere). In you update you could change the way it is checked or used, e.g. you expect a value, but the object is nil, or vice versa. This may cause a SIGABRT or EXC_BAD_ACCESS.
If you had CoreData model and you changed something in your model and update, without managing migration, thats probably reason why your app crashes on update...
I have a similar experience. Our app stores a version number in Settings.Bundle/Root.Plist. This gets displayed through the iPhone Settings app. What we find is that on an Install the version number gets loaded from the app bundle - therefore the version number is correct. On an update however the version number doesn't change. This gives the impression the user is running a previous version of the app. We don't have any logic linked to the version number, it's just for display (it could be used by contact centre staff when diagnosing faults).
Our experience is NSUserDefaults doesn't get cleared when a user updates our app, but the Settings display doesn't get updated either.
Be aware of this case, when your app is running in background and you cannot access your stored values in NSUserDefaults:
Eric:
There have been many threads and bugs about this, but it's happening to me again in ios 9. I have an app that launches in the background in response to NSURLSession tasks and content-available pushes. Reproducibly, if I reboot my phone and wait for a background launch of my app to happen, then when I open the app I find that [[NSUserDefaults standardUserDefaults] dictionaryRepresentation] contains all the system values, e.g. AppleITunesStoreItemKinds, etc. but does not contain any of the values I have set. If I force-quit and relaunch the app all of my values come back. Is there any way to avoid it caching the "empty" standardUserDefaults from before the phone is unlocked, or at least to determine when they are messed up and fix them without having to force-quit the app?
Eskimo (eskimo1#apple.com):
The problem here is that NSUserDefaults is ultimately backed by a file in your app’s container and your app’s container is subject to data protection. If you do nothing special then, on iOS 7 and later, your container uses NSFileProtectionCompleteUntilFirstUserAuthentication, a value that’s inherited by the NSUserDefaults backing store, and so you can’t access it prior to first unlock.
IMO the best way around this is to avoid NSUserDefaults for stuff that you rely on in code paths that can execute in the background. Instead store those settings in your own preferences file, one whose data protection you can explicitly manage (in this case that means ‘set to NSFileProtectionNone’).
There are two problems with NSUserDefaults in a data protection context:
Its a fully abstract API: the presence and location of its backing store is not considered part of that API, so you can’t explicitly manage its data protection.
Note On recent versions of OS X NSUserDefaults is managed by a daemon and folks who try to manipulate its backing store directly have run into problems. It’s easy to imagine the same sort of thing coming to iOS at some point.
Even if changing the data protection were possible, NSUserDefaults has no mechanism to classify data based on the context in which you’re using it; it’s an ‘all or nothing’ API. In your case you don’t want to remove protection from all of your user defaults, just those that you need to access in the background before first unlock.
Finally, if any of this data is truly sensitive, you should put it in the keychain. Notably, the keychain does have the ability to set data protection on an item-by-item basis.
Source:
https://webcache.googleusercontent.com/search?q=cache:sR9eZNHpZtwJ:https://forums.developer.apple.com/thread/15685
Related
The answer to this question may be iCloud storage, but I am using this for a very light-weight piece of data and think it may be extreme to use iCloud for this one purpose. We have an in-app subscription app. Before we provided the app for free but would not deliver any content to it until the user subscribed to content through the in-app subscription.
Some reviews indicate people think that we are trying to trick them by saying free and then saying they have to subscribe. We want the app to be listed as the price of the subscription to avoid this misunderstanding but after the first year has elapsed offer them the in-app subscription to continue. We plan to store the initial launch date in persistent storage so that we can determine when to begin requiring a subscription receipt.
1) We wanted to use the keychain storage since this information will persist even if a user removes the app from his/her device and then re-installs. The problem is if the user gets a new device and does not restore it from an encrypted backup, then the initialized value will be lost.
2) If we use our servers to store this value for them, then there seems to be no way to tie it to that appleID; so that is ruled out as a possibility.
3) Back to iCloud, it just seems like a lot to add iCloud support just for this, and I believe the user still has to have iCloud enabled for this to work.
Does anyone know the solution to this data persistence problem? Help is appreciated!
Yes, nsubiquitouskeyvaluestore is the way to get it synched with new devices. Using this in conjunction with both keychain for storing on a device after app as been removed and nsuserdefaults for quick and easy unconstrained access is the way to go. Apple also has a way to read receipts for the actual app purchase now, but it only works for iOS 7. Solutions should conditionally rely on receipt data from nsbundle.mainbundle url if it is available.
Switching to custom generated device UUID's is turning out to truly be a nightmare! I am hoping someone has come across this before and might know a way to deal with it.
Assume a user has an application with a data set of 500,000 (small) records, its not feasible to simply copy the entire db of a device and merge them. A user has this application installed on an:
iPhone,
MacBook
Android tablet.
When connected to the same physical network, each device can see each other and can initiate a synchronisation.
To achieve three way data synchronisation (that does not depend on a central server or an internet connection).
Each device keeps a list of timestamped changes.
Each device knows the last time it synchronised with each of the other two devices.
When a device sees another device, it sends through all known changes since the last time they spoke to that device.
If a new device is discovered, no problem just send through all data ever entered.
The problem comes along if a user backs up their iphone or ipad, and restores it onto another iphone or ipad. Under this scenario we are ending up with a user that has two devices on the local network with the same UUID. Updates end up (randomly) going to one or the other identically identified devices.
I know we can continue to use the device unique identifier for now, but I am worried whats going to happen once its gone!
On application start you search for a file in the applications documents folder called udid.txt. If this file is not available create it and generate your custom UDID, save it to this file. Use the following function to add a flag to this file, to exclude it from the backup and sync routines.
#include <sys/xattr.h>
- (void) AddSkipBackupAttributeToFile: (NSURL*) url
{
u_int8_t b = 1;
setxattr([[url path] fileSystemRepresentation], "com.apple.MobileBackup", &b, 1, 0, 0);
}
The problem with this solution is that a user might use iPhoneExplorer or something similar to change the UDID. Try to encrypt or hide the file to prevent him from doing this.
Note: Works only since iOS 5.0.1.
You can instead store your generated device UDID in a file in the Caches directory, where it will not be backed up. When a backup is restored onto a new device, the database will be present but there will be no UDID file. In this case create a new UDID; the other instances will see this as a new instance and can push any recent changes across. You might want to change the logic so the other instances will query the timestamp on a new UDID instead of assuming the new instance is totally empty.
Before iOS 5.0, your UDID file will not be automatically deleted by the system. However in iOS 5.0 you will need to put up with the fact that it may get purged in low disk space situations. If that happens, just follow the same procedure as when restored onto a new device: create a new UDID; the other instances will see this as a new instance and push recent changes across.
As Floix said, there is a new mechanism in iOS 5.0.1 (yet to be released) which will let you specify that the file should be neither backed up nor purged.
i have an iphone app that uses coredata to store its contents. users often ask me if i could provide a way to sync data between their mobile devices (ipod/iphone/ipad). as of now, i have no idea on how to achieve this.
i found zsync, but this seems to depend on a osx version of the app (which i dont have). i also read about upcoming iclouds sync features, and it seems to be what i need - however i think its not possible to sync coredata contents, but text-based contents only (e.g. xml storage files). is this true?
another way i was thinking of was to abuse the eventkit api to sync via a user-provided calendar. since my app is mainly managing events, which can optionally be stored in a user-calendar (in addition to coredata storage), syncing through a calendar would seem good to me. however i think syncing might break, e.g. when the user chooses not to syncronize the whole calendar but only like 3 months in the devices settings/account settings.
anyone got an idea of how my approach should be like? any tips?
Syncing device to device (if that is what you are trying to achieve) can be quite tricky. You could implement your own discovery and data-transfer protocol and work something out that way, but it could be quite a bit of work.
Syncing device to server to device is a bit more straightforward, assuming that you already have a server with some form of registration/login system. Then you just need a way of communicating your current database state up to the server, and then back down again from the server to other devices. Again there is a fair bit of work involved in doing this, but at least the logic of working out which devices sync with which other devices and how they transfer data from one to the other is all implicit in the workings of the server.
As for iCloud, the programmatic content that you sync through it needs to be derived from UIDocument, so it will not help you with generic Core Data entities.
If you're looking for an out-of-the-box solution that will sync all of your Core Data content from one device to another with no custom code, then there really isn't one. The closest you can reasonably get would be to ship the entire .sqlite file that your app uses from one device to another, overwriting the target devices .sqlite file. That works fine if your sync only needs to be unidirectional, but obviously is not appropriate for other use-cases. Perhaps you could use this model with iCloud, if you can get it to sync your app's entire .sqlite file as an atomic entity.
I know with ios 4 it is possible to run application in background as per this documentation
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html
this documents states that if application updates user's current location in background continuously then it is possible to run it in background.but is it necessary that we have to use only CLLocationManager for updating current location?can we user other apis like google latitude apis for updating current location?then also it is possible that application is able to run in the background forever?
As far as I understand from the document you posted, if you define the UIBackgroundModes with a value of location in your info.plist, "the system should allow the application to run as needed in the background". So, the first answer is yes, the application can run in the background and it will run indefinitely (up to battery life). This could be easily checked, actually.
Anyway, it seems to me that this kind of functionality is "reserved" to GPS-like apps and that Apple is really concerned about its usage:
For applications that require more precise location data at regular intervals, such as navigation applications, you need to declare the application as a continuous background application. This option is available for applications that truly need it, but it is the least desirable option because it increases power usage considerably.
so, I understand that Apple will screen really thoroughly all apps that activate this mode in order to assess if they really need the continuous update or do not (and in this case, possibly, the app would not be let in into the App Store).
Now, to answer the second part of your question, I think that one way that Apple will know if your app really complies with the rules, is its usage of CLLocationManager. The risk is that if you use another service, then Apple could think when reviewing your app that you just need background time without needing to constantly update the location.
But this is just a guess...
Is it possible to assign different identifiers to copies of an app downloaded from the app store that is hard coded into the application? Or is their anyway of permanently storing an identifier in the application bundle such that when it is copied, the key remains within the bundle?
EDIT: Ok, how about iTunes reciepts, can they be used to verify when it was downloaded as the user has to register their app with the server within say 5 hours of them downloading it.
thanks in advance
I'm assuming your goal here is to disable part of the functionality of your app by having a master list of bogus serial numbers somewhere. Unfortunately there is no per-copy serial number available, and if there were it would be the first thing the bad guys would change before posting your app for download.
Instead you'll need to detect whether your app bundle has been tampered with from within the app. See this question:
Reducing piracy of iPhone applications
You'll then need to decide how subtly or obviously you want to limit functionality. Probably the best solution would be to do something innocuous but slightly annoying that generates a specific kind of support request, at which point you can gently prod the deadbeat into considering buying a legit copy.
An approach with more false positives but potentially fewer false negatives would be to check if the app is running on a jailbroken device. The downside there is that jailbreakers may well have legitimately purchased your app, so you're alienating honest customers for little to no extra benefit.
For the app I'm working on, which has a big social/viral aspect (I hope), I've decided that potential deadbeats probably have enough honest friends to pay for the server cycles that they're stealing, and it's just not worth worrying about.
No, there's no way to do either of these. The closest you could come would be to store device IDs on a central server.