App Directories And Data

Hello everyone,

I hope you’ll all bear with me as I get up to speed. My background is in Unix, procedural languages, mission critical databases and enterprise applications.

I’ve just started heading a team with an iOS app used in healthcare that contains confidential patient information (PHI) that's governed by HIPAA and FDA cybersecurity, etc.

It seems there’s some contention in the team over whether the app, SQLite db, and medical images belong in the Documents or an Application Support directory in the Library.

From everything I’ve read, it seems that Apple’s intent is Library/Application Support.

Two questions:

  1. Which is the correct location? And hopefully, a few compelling justifications.
  2. On one of our iPads, the app stopped displaying what was two years of data in SQLite. I haven’t yet tested for index corruption, however one of the programmers believes this resulted from an iOS update that needed space and cleared data in the cache (but that makes no sense to myself).

Feedback highly appreciated. Many thanks,

David Why, because somebody has to

From everything I’ve read, it seems that Apple’s intent is Library/Application Support.

Have you read About the iOS File System?

I'm not sure what you mean about storing "the app".

Which is the correct location? And hopefully, a few compelling justifications.

It depends on the data. See the above link. If you want the user to access it, use Documents. If you want to keep the user out, use Application Support.

On one of our iPads, the app stopped displaying what was two years of data in SQLite. I haven’t yet tested for index corruption, however one of the programmers believes this resulted from an iOS update that needed space and cleared data in the cache (but that makes no sense to myself).

That is the behaviour of the Caches folder. You probably shouldn't save databases in the caches folder. That is reserved for cache files that can be easily re-created, if necessary.

Documents or an Application Support directory in the Library. From everything I’ve read, it seems that Apple’s intent is Library/Application Support. Which is the correct location?

Application Support - though it doesn’t really matter except in the case where you have a mixture of “documents” that the user needs to have access to via e.g. the Files app and “non-documents” that they shouldn’t.

the app stopped displaying what was two years of data in SQLite. I haven’t yet tested for index corruption, however one of the programmers believes this resulted from an iOS update that needed space and cleared data in the cache (but that makes no sense to myself).

You weren’t storing it in the Caches directory, or using the “don’t backup” xattr, were you?

OS updates can “offload” apps, but I’ve not seen any reports of that causing problems.

Do you vacuum your sqlite db?

  1. Which is the correct location? And hopefully, a few compelling justifications.

As far as the system is concerned, it doesn't really matter. More specifically:

  • "Documents" is intended to be used for "user data" but the definition of "user data" is largely up to your app. At a technical level, there are several mechanisms in place that make the contents of "Documents" directly accessible to the user, which is different than other directories. However, all of those mechanisms are also "opt in", so storing data in Documents doesn't make that data inherently more accessible than any other location.

  • "Library/Application Support" is one of the directories we create and which is in "common" usage. However, strictly speaking, there isn't any difference in how the system treats "Library/Application Support" and how it would treat a directory you directly created in Library.

  • If you're not storing data in "Documents", my one suggestion would be that you create your own directory using reverse DNS naming ("com.kevine.myapp.stuff") instead of directly using one of our directories. SO, store the data in "Library/Application Support/com.kevine.myapp.stuff/", not "Library/Application Support/". This is not required, but it's a simple way to remove the risk of name collisions if we decided to store data in that directory.

For complicated historical reasons, directory location choices and backup behavior tend to "entangled" in our documentation. SO, stating the systems behavior for the record:

  • The system does not backup the contents of "tmp" or "Caches".

  • The system does backup the contents of "Library", "Documents", as well as other "data" directories (like shared app group directories).

  • As special side note, data shared through iCloud isn't "backed up" through the normal backup process, but is instead preserved by the iCloud itself. In concrete terms, when an app is restored from backup that apps local data is restored with the backup data and the app can then retrieve it's iCloud data through the iCloud APIs.

Finally, on this point:

And hopefully, a few compelling justifications.

The "right" choice between those directories really depends on what your app/user thinks of as "user data" and if/how you want the users to be able to access it. If you want the user to be able to access it, then you need to user Documents. If you don't... then you don't need to.

The main thing I'd note on that point is that "user data" doesn't necessarily mean "data the user expects/needs to directly interact with on a regular bases". I know of several smaller/niche apps that intentionally store their data in "Documents" and set UIFileSharingEnabled = true not because the user will interact with that data directly, but because the data is "valuable" to the user and they want the user to have access to it JUST in case "something" goes wrong.

On one of our iPads, the app stopped displaying what was two years of data in SQLite. I haven’t yet tested for index corruption, however one of the programmers believes this resulted from an iOS update that needed space and cleared data in the cache (but that makes no sense to myself).

This sounds like a problem in your app but there isn't enough information here to really speculate beyond that.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

App Directories And Data
 
 
Q