2

I'm working on an iOS app that will need to save data onto files. I chose to go for a Document Based app, precisely an app based on a UIDocumentBrowserViewController so that I can easily save and load files from the system's Files app.

Since the data I need to save/load on a file is quite complex: big hierarchy of different objects, with meta-data, image files, etc. I'm wondering what is the best technology to use going forward. I came across NSFileWrapperand its ability to save different files as one. And I could definitely use that. But I also saw UIManagedDocument and the ability to use Core Data in my project while maybe saving the content of the Core Data database (I know it's not quite a database, but you know what I mean) into a file that I could write somewhere in the File App.

Is this a behavior I can expect?

To reformulate: I'm wondering if I can read/write files through a UIDocumentBrowserViewController, with data described by a UIManagedDocument that works with Core Data.

Thank you in advance.

Clément Cardonnel
  • 4,232
  • 3
  • 29
  • 36
  • Thats a bit of a broad question. UIManagedDocument already uses coredata on its own, and since they are UIDocuments, they can be accessed through UIDocumentBrowserViewController ... – MartinM Apr 03 '19 at 13:38
  • I've been playing with this class this week. My finding is that it works and will do what you want it to. However, it's not easily apparent where the boundaries exist between the 2 technologies. For example, saving the document's context directly will post a `NSManagedObjectContextDidSave` notification, but this does not save the document, instead marking it as `hasChanges` for the next save pass. Once the document does save you will get both a notification of document state change as well as another contextDidSave notification. This could lead to unnecessary redraws. PM me if needed. – MH175 Jan 01 '22 at 05:47

1 Answers1

2

As you have discovered, UIManagedDocument is there for your kind of application. And it does feature methods to write and read additional content like the metadata or image files you have, within the document package.

That being said, I have never used UIManagedDocument, and have never seen it used by others. A quick search of GitHub finds only this one project with two contributors who wrote a wrapper around it in 2013. Also, there does not seem to be any sample code from Apple, and the remark in the the writeAdditionalContent(_:to:originalContentsURL:) documentation that Additional content is not supported on iCloud leaves me a little concerned, but maybe it's a good sign that the Core Data team knows where to draw the line.

I have used the macOS counterpart of UIManagedDocument, NSPersistentDocument. It is in a similar situation of not being used very much, but with many more known technical issues. So a few years ago I switched to BSManagedDocument, which purportedly mimics UIManagedDocument to support Core Data in all its modern glory. I have been happy with BSManagedDocument.

In summary, if I was in your situation, yes I would give UIManagedDocument a try. But don't be surprised if you need to use a DTS support incident or two during your development.

Jerry Krinock
  • 4,860
  • 33
  • 39
  • Thank you very much! Yes, it feels like being a pioneer of a half a decade old technology. But I'm happy to see that it might be feasible. I'm currently learning Core Data and will try to use it with UIManagedDocument in a small project. I think that it can work, we'll see! – Clément Cardonnel Apr 04 '19 at 07:52