I have read so many blogs but still its not clear to me that whether iCloud backs up the keychain data which are stored programmatically using SecItemAdd or not ?
iCloud Keychain is a feature introduced with iOS 7.0.3 / OS X Mavericks 10.9.
In order to take advantage of this for data stored programmatically using SecItemAdd, you have to update the item with the key kSecAttrSynchronizable.
This key is not added by default so items without it will not be backed up to iCloud.
Also, even with kSecAttrSynchronizable properly set, bear in mind that users might not have enabled the iCloud Keychain feature from their point of view, meaning that they wouldn't be synced either.
Related
I have an iOS 7 app, that is using Core Data. Some of the Core Data objects has a related (one to one relationship) images that are > 1MB & < 4MB and are stored in the app’s Document folder. Core Data objects only stores image names as string.
I want to integrate iCloud support for the app so I can sync data between devices. I am planning to use iCloud Core Data storage to sync Core Data objects. But what to do with the images?! After reading different posts, I found a couple of options that are highlighted underneath. I am struggling to pick one, that would suit me best. It would be nice to know someones experience/recommendations. What I should be careful with, or what didn't I think of? I also need to consider migration of the existing data to the option I will pick.
OPTION 1. Store UIImage in the Core Data as Binary Data with External Binary Data option (read here). At this moment is seems to be the easiest solution, but I guess not the best. From Documentation:
It is better, however, if you are able to store BLOBs as resources on
the filesystem, and to maintain links (such as URLs or paths) to those
resources.
Also will the external files be synced? If so, how reliable the sync would be if the user quits on minimises the app, will the sync process resume? From objc.io about External File References:
In our testing, when this occurs, iCloud does not always know how to
resolve the relationship and can throw exceptions. If you plan to use
iCloud syncing, consider unchecking this box in your iCloud entities
OPTION 2. Store images using UIDocument (good tutorial here) and somehow track relation between Core Data entry and UIDocument. From what I understand whatever I put in this directory will be automatically synchronised to the iCloud by a system daemon. So if the user quits the app, the images will still be synced to the iCloud, right?
OPTION 3. Using FileManager(more info here). I haven’t read a lot about this approach, but I think it can also work.
OPTION 4. Any other?
There are similar posts (e.g. Core Data with iCloud design), but unfortunately they don't fully answer my question.
Seems Apple will reject application because of large database iCloud synchronization.
I think the best solution is to store images on a remote host, and keep Image URL in CoreData.
And also Local path of image should be resolvable from remote URL.
So the algorithm will look like this ->
1) Getting Remote URL from CoreData.
2) Resolve local path of image.
3) If local image exists retrieve it, otherwise read it from remote and save it to local storage.
You can have a look to Amazon S3 server here.
I've created an app that uses the Alloy framework to store data. I've found that the default Alloy database that gets created is called _alloy_.sql and is stored in the app's [APP_ID]/Library/Private Documents in the iPhone Simulator.
I was looking around on how to get this database backed up on iCloud, so that the users data would stay with them from device to device. But all the questions I found online where about turning this feature off, please see Support turning off iCloud backup for auto-generated model databases.
I have a few questions around this:
Does this mean that the default Alloy database is already backed up on iCloud?
Is there a way to confirm that this is the case?
How do I test that it is successful?
Should my app appear inside the iCloud settings section of the iPhone settings?
The Alloy database is exactly the same as every other database that you can create using
Ti.Database.open("db_name"); // _alloy_
or
Ti.Database.install("db_name"); // _alloy_
And it should be backed up by default ,so yes you are right it is already backed up.
You can find out more here https://developer.appcelerator.com/question/163013/icloud-backup-and-restore
I am using phonegap for IOS app development. Now, phonegap tries to find the db by default in 'NSCachesDirectory', but whenever IOS runs into memory problems, it tries to delete data from 'NSCachesDirectory', so, the data is not secured. If i am not mistaken, this problem was solved in cordova 2.1.0, where the back-up of data is taken and then restored afterwards. So, just wanted to confirm if i am heading in the right direction or data itself can be stored in 'NSDocumentDirectory' so that data is secured and somehow phonegap looks for db in 'NSDocumentDirectory' and not Caches direcory. Thanks.
Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the /Documents directory(You can store DB in Documents directory)
Data that can be downloaded again or regenerated should be stored in the /Library/Caches directory.
I'm just getting into saving data from my game into a .plist, but I'm a bit unclear on how secure that is.
I'll be saving the players entire game state (including tile map data) in a plist(s). As I understand it you can't modify a plist in the bundle, but all the example code i've seen creates a new dynamic plist which is stored in the documents? is this easily changeable by the player from their phone?
is this easily changeable by the player from their phone?
Only if they have access to it - a fact of which the prerequisite is the phone being jailbroken. But in this case, yes they can modify it easily.
The plist files can be easily modified even without a jailbreak -
iExplorer allows to browse the iPhone application folders over an USB connection. In this case, the plist file can be copied from the iPhone to a computer, modified and loaded into iPhone.
Plist files are stored unencrypted on the backup. So the file can be modified in the backup and restored into iPhone.
Use keychain for better security. To make it more secure, use custom crypto and encrypt the game state before storing it on the device.
I have an iOS application that currently manages a small bunch of settings (via NSUserDefaults, I know how to sync these via iCloud) and some list data.
Let's say as an example I want to store a list of <color name / color / comment>. So I create a custom type, that is called ColorInfo. In my app I need to store multiple values of ColorInfo, I'd try and achieve that using an NSMutableArray or a database, but both are not easily synchronizable via the iCloud.
What ways to manage lists of data do you prefer in your iOS apps to meet the following two requirements?
You should be able to easily store the data persistently on the local phone.
You should be able to easily sync the data via the iCloud.
You want to use UIDocument its designed for local archiving and iCloud persistence.
Developer Doc
Do not use the key value storage. It is very.. weird.
I would make my own version of the key value storage by creating a local file and a remote file of the same name. To sync, you have to download the remote file and combine its contents with the local data. Write it to the file and upload the file.