FileAttributeKey.protectionKey's value is always nil in Simulator

It seems like this is not supported in the Simulator because when I run my Unit tests and I try to read protection key-value the value is always nil, even if I set the data protection level when I write the file.

On device this key returns the expected value.

Is it possible to have the simulator support the data protection classes to run my unit tests?

FYI Im testing on iOS

Answered by DTS Engineer in 834970022

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

Could you try setting something else in your test code?

Oh, hey, would you look at that. I switched to .completeFileProtection and that reproduced the problem.

I then put the same code in a Mac app and that worked.

I believe this a special case within the simulator. Because macOS previously didn’t support data protection, FileManager avoids getting and setting these attributes [1].

As to whether this should change, I’m in two minds about that:

  • On the one hand, changes like this often break working code.

  • And it’ll be of limited utility because data protection is primarily relevant when the device is locked, and the simulator doesn’t really support that.

  • OTOH, it’d help folks, like yourself, who are writing new code.

If you have a strong opinion about this, feel free to register it in Feedback Assistant. And if you do file a bug, please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Some spelunking in the Foundation open source reveals evidence for my theory. See here.

Hmmm, this is working for me. Specifically:

  1. Using Xcode 16.3 on macOS 15.3.2, I created a small test app from the iOS > App template.

  2. I added a button and set it up to call the test code below.

  3. I ran it on the iOS 18.4 simulator.

It printed:

will write, to: /Users/quinn/…/tmp/2025-04-11 09:15:12 +0000.txt
did write, will read
did read, prot: NSURLFileProtectionCompleteUntilFirstUserAuthentication

The one potential gotcha here is your CPU architecture. I’m testing on an Apple silicon Mac. Intel Macs don’t support data protection, and that’s true both inside and outside of the simulator.

Oh, and I’m using the modern URL-based file system API. You should to, but I don’t think it’ll materially affect this test.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"


do {
    let name = "\(Date.now).txt"
    var url = FileManager.default.temporaryDirectory.appendingPathComponent(name)
    print("will write, to: \(url.path)")
    let content = Data(UUID().uuidString.utf8)
    try content.write(to: url, options: [.completeFileProtectionUntilFirstUserAuthentication])
    print("did write, will read")
    url.removeAllCachedResourceValues()
    let rv = try url.resourceValues(forKeys: [.fileProtectionKey])
    print("did read, prot: \(rv.fileProtection.map { $0.rawValue } ?? "-")")
} catch {
    print("did not write, error: \(error)")
}

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

Could you try setting something else in your test code?

Oh, hey, would you look at that. I switched to .completeFileProtection and that reproduced the problem.

I then put the same code in a Mac app and that worked.

I believe this a special case within the simulator. Because macOS previously didn’t support data protection, FileManager avoids getting and setting these attributes [1].

As to whether this should change, I’m in two minds about that:

  • On the one hand, changes like this often break working code.

  • And it’ll be of limited utility because data protection is primarily relevant when the device is locked, and the simulator doesn’t really support that.

  • OTOH, it’d help folks, like yourself, who are writing new code.

If you have a strong opinion about this, feel free to register it in Feedback Assistant. And if you do file a bug, please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Some spelunking in the Foundation open source reveals evidence for my theory. See here.

FileAttributeKey.protectionKey's value is always nil in Simulator
 
 
Q