They may rely on a credential provider or even a keychain entry tied to an auth context - I can't be sure. However, my question isn't about keychain; it is specifically about the differences between the two approaches. When is it appropriate to use the second approach?

At runtime. For example, if I set test.shouldSkipPartTwo = true test.partThree() // partThree, shouldSkipPartTwo, credits Otherwise test.partThree() // partThree, shouldSkipPartTwo, partTwo, partOne, intro, credits

I've noticed that I can supply a fraction of the requestedLength and still make the video play. Not sure if this will work with other types of media.

Right. MapKit does this work in a separate process that’s not affected by your sandbox configuration. I would assume that MapKit is an exception. Or is it indeed possible to spawn a child process that exceeds the permissions of its sandboxed parent process?

You could implement the same sort of thing in a third-party product. For example, if your app used XPC to talk to your non-sandboxed daemon. Will this product be (Mac) App Store compliant? As in, can you potentially ship a non-sandboxed daemon along with your app and establish an XPC communication like MapKit does?

Thanks for taking the time to respond. I should have been clearer - the questions were specifically about apps going to the App Store. These apps (and any extension, XPC, etc) are sandboxed. I expected that com.apple.security.network.client = false would restrict all outgoing connections. But that doesn't work with MapKit - it still is able to make outgoing connections. Is MapKit the only exception - as in, is there any other way (or any other system framework) that is expected to bypass this entitlement? Is this list already documented? Besides this entitlement, is there any other way to restrict outgoing connections?

Can you, as the app developer, control which servers are contacted by the map view? No. No. I’m sure there are many. Thanks. That certainly helps with understanding the scope of com.apple.security.network.client.

[quote='756183021, on-d-go, /thread/756183, /profile/on-d-go'] Is there a way to ensure that fileDescriptor is writing the content in the expected filePath? [/quote] This can be done by comparing their inodes. var fdStat = stat() var fpStat = stat() let isValid = fstat(fileDescriptor.rawValue, &fdStat) == 0 && stat(filePath.string, &fpStat) == 0 && fdStat.st_ino == fpStat.st_ino If it's not pointing to filePath, recreate the file descriptor. if !isValid { fileDescriptor = try FileDescriptor.open(filePath, .readWrite) } This works, but is there a better way? Also, is there a high-level API in FileManager that does fstat and stat?

Here's another example where the System.FileDescriptor doesn't read from the desired FilePath let dataWrittenInFile1 = Data([1,1,1,1]) let file1 = URL(fileURLWithPath: "/path/to/file1") try FileManager.default.removeItem(at: file1) FileManager.default.createFile(atPath: file1.path, contents: dataWrittenInFile1) let fileDescriptor1 = try FileDescriptor.open(file1.path, .readWrite) try fileDescriptor1.close() let dataWrittenInFile2 = Data([2,2,2,2]) let file2 = URL(fileURLWithPath: "/path/to/file2") try FileManager.default.removeItem(at: file2) FileManager.default.createFile(atPath: file2.path, contents: dataWrittenInFile2) try FileDescriptor.open(file2.path, .readWrite) var dataInFile1 = Data(count: 4) try dataInFile1.withUnsafeMutableBytes({try fileDescriptor1.read(into: $0)}) print(dataInFile1 == dataWrittenInFile1) // false print(dataInFile1 == dataWrittenInFile2) // true I would expect fileDescriptor1 to read from file1. Instead, it reads from file2. In my view, reading from a closed file descriptor should have resulted in an error. This problem extends to Foundation.FileHandle as well. Do you know if there's a high-level API, included with iOS, macOS, and tvOS that does: func fileDescriptor(_ fileDescriptor: System.FileDescriptor, pointsTo filePath: System.FilePath) -> Bool { // }

[quote='789284022, endecotp, /thread/756183?answerId=789284022#789284022, /profile/endecotp'] What’s actually happening is that the kernel is allocating the same FD for the second open as for the first, which it can do because you closed the first one. So when you read, you read from the second file. [/quote] I was (and still am) hesitant to make that assumption because the actual implementation is behind these APIs. System.FileDescriptor: write(_:retryoninterrupt:) System.FileDescriptor: read(fromabsoluteoffset:into:retryoninterrupt:) Foundation.FileHandle: read Foundation.FileHandle: write However, I see your point; these APIs don't necessarily need to read/write from the filePath, likely because they are eventually backed by the posix’s filedescriptor. My use case requires that I read/write to a pre-defined filepath. If I've opened a file descriptor with a filepath, I need to know if or when it's not reading/writing from/to that filepath. My question still is: [quote='789258022, on-d-go, /thread/756183?answerId=789258022#789258022, /profile/on-d-go'] Do you know if there's a high-level API, included with iOS, macOS, and tvOS that does: func fileDescriptor(_ fileDescriptor: System.FileDescriptor, pointsTo filePath: System.FilePath) -> Bool { // } [/quote]