There seem to be a few different ways for an app to store data in iCloud (iCloud Drive Documents, Core Data with iCloud Sync, CloudKit Private Databases, Key Value Pairs etc) but I'm not sure if that's all. Which of these different types of iCloud storage appear to the user in the iCloud 'Manage Storage' menu (i.e. some apps don't appear at all whereas others list 'Documents and Data' whereas others list files that can be individually removed but don't appear in iCloud Drive)? I'm trying to figure out but the documentation's a bit vague on this.
Aaron,
There are three "Apple owned" places you can store data for an iOS device, on the device itself, in an iCloud Drive and/or in the iCloudKit database.
The iCloudKit database has within it three more places. Two of those are databases in the true sense of the word, so structured areas you can store information within, namely key/value pairs and CloudKit. A CloudKit database itself breaks down into two more principle divisions, public and private areas.
Their accessibility is governed on a user/app basis. So you as a developer can opt to use or indeed make your files accessible on them or not. The rules governing who can access what can be confusing, especially as they can/have been changing over different iOS releases.
The iCloud Drive is the most and least flexible, you can store everything on it but you cannot share anything within it, except with yourself.
The iCloud key/pair database comes next, except it is used exclusively by an application to store application state/preferences only [it has a very limited space], again you can share it with yourself only.
The CloudKit database comes next, again something that would be used on an application by application basis. So apps do not share databases and cannot access other app databases, unless they come from the same author and sharing is a built in functionality that has been explicitly intended.
That said, the CloudKit database has two distinct areas a private and a public one. The private area can be accessed by a single user of an app, the public area can be accessed by anybody using said app on any iOS device.
CloudKit documents are an area where Apple store documents from its apps principally, so keynotes, pages and numbers; although they have opened it up somewhat in recent years. They can be shared with other users too using on of the apps designed specifically to store data within the iCloudKit documents area. It is the closest you'll get to a dropbox under iOS, short of using dropbox fof course.
Finally you can store data on your iOS device itself and opt in to share that with others on the same device too thru Apple's files app, although that that is a very recent status quo, so only available for apps designed to run under iOS 11 explicitly opted into the new status quo.
All that said, Apple counts all the places as one in the same when it comes to storage limits, be warned if you want design/build an app using cloudKit storage; if Apple deem you did so recklessly, you won't get a foot in on the app store.
As final comment Apple security policies are designed as a general rule to ensure you as a user have quite fine grained control over who accesses their data, it was/is an intentional decision on their part to protect you from yourself. As a general rule, it works well; which is why you see almost no viruses under iOS.
Related
The question might seem weird (and stupid) at first, but keep reading...
I used iCloud Key-Value Storage in one of my apps and now I need to Transfer this app to another Developer Account. But it's, for some reason, impossible to transfer apps if they've used iCloud Entitlements (why no warning?!?!).
So...In other words, I need to remove my original app and create a new one in my new Developer Account. But before that happen, I want my existing users to be able to sync their data to a common iCloud Key-Value Storage, but directed at the new app "container".
If, the "new" app is Live, would it be possible to point at that app Cloud Container (from my old one)? (e.g. my old app saves iCloud data to the new container).
When reading my own question I just think "this sounds like a big security breach if possible", so my guess is, no. But there's nothing in the Apple Documentation that says that this is not possible.
I'm not interested in solutions that involves users saving data on an external db (I know this is possible, but not what I'm looking for right now). Is there some way to save the data locally on disk (without being removed when app is removed) and then read it from the other app?
I am trying to build a mobile monitoring tool/app for iOS without Jailbreak. The only possible way to perfectly access all installed app's content is through iCloudKit.
Also I found Apple's MDM come a little close to this for BYOD devices but yet accessing individual application's data is not possible.
During all this process, I came across some website fonemonitor and phonemonitor (with and without) who claim to do the same without Jail Break.
So here is my question is it possible to take any application's data if we get access to the users iCloud account? Also, are all public, private and shared data accessible via iCloudKit? As the documentation clearly states private data is untouched.
How does app monitoring work for any iOS Devices through these websites. Any lead would actually help!
What is the best way, to share a database between different devices, that are not just the user’s ones, but for example could be his friend’s phone. That means that iCloud is not an option.
Example:
All of my data is app-user specific, so basically:
user logs into my app, do some work
then he can log in with the same acc on his friend phone and data should be the same
Is there an any way to upload the whole user specific database to some online storage provider (like firebase,… ) and then download it on another device and initialise core data stack, when the same user logs in on a different device?
Or is it the only way to sync data with the server and than preload the database?
You could simply upload the whole database file(s) and then download it on another device. The problem though is portability. You need to ensure that both devices support the same version of the database so they are compatible. To port the same thing to another platform is again a different story but doable when not using core data.
Then there is a problem of conflicts. Imagine you forget to log out from the second device and you open it after a week and the database is accidentally synced back to the server. This will make you lose all the data you created on your "main" device.
So in general it is possible to sync the whole thing but you will have loads of issues. You should create a server that supports all entities and works through ids (so you know the object was modified and not created) and date modified to be able to resolve conflicts.
Syncing data between multiple devices is the biggest reason to use something like Firebase. That's one of its primary purposes. You would use Firebase for data storage instead of Core Data, and it would automatically handle syncing between devices. You don't write code to upload or download anything, you just read and write Firebase data and it handles the syncing. It supports user accounts, so if a user logs on on a different device, their data automatically syncs to that device. There are numerous other options besides Firebase, of course.
CloudKit also syncs between different devices, but it's linked to the current iCloud account on the phone. Since you want in-app login, it's not so good.
I'd like to create an iOS app for shopping lists (yeah, one more), allowing synchronization between 2 (or more) iCloud users (like what Apple does with shared calendars).
Any idea how I should structure my data to accomplish that ? Can I do that with the tools iCloud offers at the moment in iOS 8?
EDIT: I'm especially interested in the sharing part of the process: how to "invite" other users (as in the Calendar app to "Add Person" for a shared calendar), or maybe include Family members (as declared in iTunes) in
the app.
Thanks
iCloud app data is sandboxed and not accessible by other users https://developer.apple.com/library/ios/documentation/General/Conceptual/iCloudDesignGuide/Chapters/iCloudFundametals.html
In CloudKit there is a private and a public database. when you write to the public database, then that data could be read by others. https://developer.apple.com/icloud/documentation/cloudkit-storage/
Cloud Kit may be your best option
How can I privately share data between two apps on the same device that have different team IDs? We used to do this via the pasteboard, but with iOS7 to use app-specific pasteboards they now have to have the same team id.
The problem we are trying to solve is the unlocking of features in one app if the user has purchased another app. We'd like this to happen quietly in the background (hence originally using app-specific pasteboards) but having some security to prevent users from spoofing the process and unlocking features.
One approach we are investigating is to use a system pasteboard but to encrypt the data with a device specific key. As long as both apps use the same algorithm to generate the key this should work, but he problem then becomes how to generate an app specific key.
Any advice/guidance on the best way of enabling this sort of feature unlocking scheme would be very helpful.
I use the pasteboard for sending data between applications as well. It's a really useful tool for sending medium size amounts of data between applications. I actually wrote up a blog post on the topic a while back.
Unfortunately, as you've pointed out, private pasteboards are only available to apps that share the same prefix in their app id. This is typically the Team ID, but may be different if you have an app that dates back to when you could use a different bundle seed identifier.
If you have medium sized amounts of private data being shared between apps with different prefixes then a different solution is in order. In this case I would suggest using some form of encryption and using the general pasteboard to shuttle the data around. Depending on the sensitivity of the data, it probably would be a good idea to encrypt the data even when using a private pasteboard. Rob Napier has a nice library for making the encryption and decryption very simple.
Alternatively, if your data is fairly small you might consider encoding the data into a URL and using a URL scheme to move the data into the other app.