Allows external storage and iOS 12

Anybody facing issues with saving binary data with "Allows external storage" checked in your property? I am just now facing some customer queries why their saved images are disappearing after a while in my app. This used to work just fine in iOS 11.

I have been debugging this issue with simMagnifier tool for viewing the Core Data content as well as just checking the contents of iOS 12 simulator directory on macOS.

Now I am seeing in simulator that when I set the image property and save the context, image file gets written to _EXTERNAL_DATA -directory but the image field in Core Data stays nil. My app shows the image cause it is saved to managed object context in memory. But once app gets killed and user reopens, the image is not there - cause apparently it was not saved properly in the first place. What on earth is going on and can I do something to make this work or is this just a serious bug on iOS 12?

Post not yet marked as solved Up vote post of Petri T Down vote post of Petri T


Wow, we had issues with people reporting nil images, but it turns out now that when restarting the app, the images to external data are indeed empty.....!!!

Major bug. What can we do to get these images back??

Also reproducible in iOS 12.1 beta

Sad news is that I have no solution on how to get the images back. I have now ended up on rolling out an update which does two things:
1. Does not save or read images from the Core Data database anymore, instead saves the images to file system and reads them from there. My record has an UUID so I will just have an image with that UUID as its filename to reference, pretty simple. And now I am in full control of saving and deleting those files.

2. At first launch of the next version, all existing images (if there are still any 🙂) are copied to this directory.

I realized that the bug for me was also worse because I did an extra context save when saving the image, that extra save caused the image to disappear always. Like discussed in that SO post and bug report, this nilling seems to happen with every other save call.

I have been testing this as well and added some crude debugging. I can see that after several saves, my external data folder keeps increasing. But my data model has nil fields for these binary objects. My app uses app groups to share data, so that is the reason for the "forSecurityApplicationGroupIdentifier". But I'm not sure where the relationship exists between the filename and the core data object.

So while I can fix this to store the data myself, seems like some care should be taken with this old data.

let externalStorage = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.countdownwithme.coredata")?.appendingPathComponent(".CountdownModel_SUPPORT/_EXTERNAL_DATA") as! URL

do {

let filePaths = try FileManager.default.contentsOfDirectory(at: externalStorage, includingPropertiesForKeys: nil

, options: [])


for filePath in filePaths {


do {

let data = try Data(contentsOf: filePath)


} catch {




} catch let error as NSError {

print("Could not view temp folder: \(error.debugDescription)")











FWIW, I created a verion of the sample app that exposes the issue reported in the radar. It seems to be resolved with iOS 12.1 beta 3 released earlier today. There are no notes to confirm this. I was wondering if anyone else has tried and can confirm this?

Glad i found this thread, thought i was going mad.

Same issue for our app, bit of a major disaster, eventually had to switch off external storage as quick fix.

Will test iOS12.1 beta 3 later, but too many unrecoverable hours lost debuggin this problem, thinking it was in the code.

I tried to fix it by creating a new model version where "Allows external storage" was unchecked but i have got an error:

Thread 1: Fatal error: 'try!' expression unexpectedly raised an error: Error Domain=NSCocoaErrorDomain Code=134140 "Persistent store migration failed, missing mapping model."

FYI, this issue appears to be resolved in iOS 12.1 (verified in beta 4 on iPad).

I can confirm that it is most certainly NOT fixed in iOS 12.1.1

Not from where I'm standing with iOS 12.1.1

The problem is still well & truly alive & kicking!