We have been struggling to get support and answeres regarding this roadblock : Request in whitelisting of the NFC Tag Reading and Writing (NDEF) entitlement for our iOS application Our application utilizes Core NFC to enable reading and writing of NFC tags, simplifying user interactions with NFC-enabled devices and services. The NDEF entitlement is essential for our app to deliver its core functionality effectively. Build Environment: Our app is developed and built using Xcode 16.4 on Codemagic’s cloud-based CI/CD platform, which utilizes a compatible macOS version (e.g., macOS Sonoma 14.4 or later). The app targets iOS 18 and uses Core NFC APIs for NDEF tag reading and writing. so far we cant get it to read or write as ios is restricking us

I've faced with some performance issues developing my readonly filesystem using fskit. For below screenshot: enumerateDirectory returns two hardcoded items, compiled with release config 3000 readdirsync are done from nodejs. macos 15.5 (24F74) I see that getdirentries syscall takes avg 121us. Because all other variables are minimised, it seems like it's fskit<->kernel overhead. This itself seems like a big number. I need to compare it with fuse though to be sure. But what fuse has and fskit seams don't (I checked every page in fskit docs) is kernel caching. Fuse supports: caching lookups (entry_timeout) negative lookups (entry_timeout) attributes (attr_timeout) readdir (via opendir cache_readdir and keep_cache) read and write ops but thats another topic. And afaik it works for both readonly and read-write file systems, because kernel can assume (if client is providing this) that cache is valid until kernel do write operations on corresponding inodes (create, setattr, write, etc). Questions are: is 100+us reasonable overhead for fskit? is there any way to do caching by kernel. If not currently, any plans to implement? Also, additional performance optimisation could be done by providing lower level api when we can operate with raw inodes (Uint64), this will eliminate overhead from storing, removing and retrieving FSItems in hashmap.

Hi there, I am in the process of writing a macOS app using NSFileProviderExtension so that I can map my customer's data in Finder. I am in the process of building it out. But one thing I notice is that once the file is downloaded and I save it to the cache folder, I see it disappear from the folder. It looks like the system removed the downloaded file a few seconds later. How do I go about tracking this? I have added the log stream messages from the point where it is downloaded to the point where it is gone missing. Any pointers greatly appreciated. 2025-07-15 16:10:41.989915-0700 0x138326 Default 0x0 989 0 filecoordinationd: (Foundation) [com.apple.foundation.filecoordination:provider] Provider radwar.Drive.DriveFileProviderExtension finished providing for 44FB3A4A-CA50-4EE2-9DC8-1C96FE584DF5 2025-07-15 16:10:41.989974-0700 0x138326 Default 0x0 989 0 filecoordinationd: (Foundation) [com.apple.foundation.filecoordination:claims] Provider radwar.Drive.DriveFileProviderExtension finished, unblocking claimer for 44FB3A4A-CA50-4EE2-9DC8-1C96FE584DF5 2025-07-15 16:10:41.987613-0700 0x138bb6 Default 0x0 990 0 fileproviderd: (Foundation) [com.apple.foundation.filecoordination:provider] radwar.Drive.DriveFileProviderExtension finished providing 2025-07-15 16:10:42.034144-0700 0x138905 Default 0x71f4b8 624 7 runningboardd: (RunningBoard) [com.apple.runningboard:ttl] Invalidating assertion 624-44341-46806 (target:[xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:5AABEA5E-ACAD-428B-A6DD-F2EFF14CEE99]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44341]) from originator [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:5AABEA5E-ACAD-428B-A6DD-F2EFF14CEE99]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44341] 2025-07-15 16:10:44.185866-0700 0x138906 Default 0x0 624 7 runningboardd: (RunningBoard) [com.apple.runningboard:ttl] [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] termination reported by launchd (0, 0, 0) 2025-07-15 16:10:44.186166-0700 0x138906 Default 0x0 624 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] Removing process: [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] 2025-07-15 16:10:44.186424-0700 0x138906 Default 0x0 624 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] Removing assertions for terminated process: [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] 2025-07-15 16:10:44.189939-0700 0x138c30 Default 0x71f4e4 976 0 gamepolicyd: (RunningBoardServices) [com.apple.runningboard:monitor] Received state update for 44328 (xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}, none-NotVisible 2025-07-15 16:10:44.190503-0700 0x138c8f Default 0x0 624 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] XPC connection invalidated: [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] 2025-07-15 16:10:46.294619-0700 0x13904a Default 0x0 44341 0 DriveFileProviderExtension: 🔥FileProviderExtension: 🔥FileProviderExtension: ❌ CRITICAL: File disappeared after 5 seconds! /Users/radwar/Library/Containers/radwar.Drive.DriveFileProviderExtension/Data/Library/Caches/FileCache/README.md (item: 19105790787)```

is it possible for the IOS 26 to make the chat bubbles different colors than blue? kinda tired of the same blue color. is it possible to get that version for the new update?

I have a simple impossible task, to restore /var/root/Library/Application Support/multipassd/qemu/vault/instances/gcc-cobol/ubuntu-22.04-server-cloudimg-arm64.img as of 8:02 Saturday morning. Because /var/root is owned by, well, root, the usual techniques don't work. This is a VM image hosted by qemu via Canonical's Multipass. ISTM the strategy would be to first mount the NAS filesystem and then use tmutil(8) to list the backups and recover the file. But $ sudo mount -v -o rdonly -t smb //nasa.local/TimeMachine /usr/local/mnt/ mount: exec /Library/Filesystems/smb.fs/Contents/Resources/mount_smb for /usr/local/mnt: No such file or directory mount: /usr/local/mnt failed with 72 Must I defeat SIP to do this?

The online documentation for fs_snapshot_create, which is on a website which apparently I'm not allowed to link to on this forum, mentions that some entitlement is necessary, but doesn't specify which one. Searching online I found someone mentioning com.apple.developer.vfs.snapshot, but when adding this to my entitlement file and building my Xcode project, I get the error Provisioning profile "Mac Team Provisioning Profile: com.example.myApp" doesn't include the com.apple.developer.vfs.snapshot entitlement. Searching some more online, I found someone mentioning that one has to request this entitlement from DTS. Is this true? I couldn't find any official documentation. I actually want to make a snapshot of a user-selected directory so that my app can sync it to another volume while avoiding that the user makes changes during the sync process that would make the copy inconsistent. Would fs_snapshot_create be faster than traversing the chosen directory and creating clones of each nested file with filecopy and the flag COPYFILE_CLONE? Although I have the impression that only fs_snapshot_create could make a truly consistent snapshot.

During EEPROM reading or writing on some appliance devices, the app encounters an error after 6 steps. This issue occurs only on iPhone 14 Pro Max, 15 Pro Max, and 16 Pro models, while all other iPhone models function correctly. Any one with this problem?

I am trying to disable certain paths from Endpoint Security Events using es_mute_path, but this seems to be returning with ES_RETURN_ERROR. I am currently not having 'com.apple.developer.endpoint-security.client' but is disabling SIP to check the same. What is the reason for this behavior ?

Hi there, I have discovered that the behavior of file copying has changed starting from iOS 18.4. When using FileManager.copyItem(atPath:toPath:) to copy a directory specified as an argument, whether or not there is a trailing slash ('/') affects whether the copy process works correctly. The same process operates as expected in the iOS 18.3.1 Simulator. Is this the correct behavior, or could it be a bug? The application's build environment is Xcode 16.2. Below is an example of the code. In practice, the file copying is performed within the application's folder. // Both iOS 18.3.1 and iOS 18.4 successfully complete the copy process. FileManager.default.copyItem(atPath: "/path/from/dirA", toPath: "/path/to/dirB") FileManager.default.copyItem(atPath: "/path/from/dirA/", toPath: "/path/to/dirB/") // iOS 18.3.1 successfully complete the copy process, but iOS 18.4 fails. FileManager.default.copyItem(atPath: "/path/from/dirA/", toPath: "/path/to/dirB") I hope this helps Apple engineers and other developers experiencing the same issue. Feedback or additional insights would be appreciated.

When I connect to another Mac via Finder (using SMB), creating a hard link with FileManager.linkItem(atPath:toPath:) fails (both source and destination are on the remote Mac). I read online that SMB itself supports creating hard links, so is this a macOS limitation or bug?

Hello! I am running into a crash at AbstractCombineLatest.request(_:) (), BUG IN CLIENT OF LIBMALLOC: memory corruption of free block. The crash is Crashed: com.apple.NSURLSession-delegate EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000, or Crashed: com.apple.NSURLSession-delegate EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x446d4644951e0518 This has only been reported in production, for a small percentage of users. It has been present in our application for a while, but has become much more prevalent in the past few weeks, coinciding with the iOS 18.5 release. The crash occurs when sending a value fetched from a network to a CurrentValueSubject, which is done on a Timer. A skeleton of the timer creation function: private func newTimer(for url: URL) { timerCancellable?.cancel() timerCancellable = Timer .publish(every: interval, on: .current, in: .common) .autoconnect() .flatMap({ [weak self] _ -> AnyPublisher<Response?, Never> in guard let self = self else { return Just(nil).eraseToAnyPublisher() } return self.fetch(from: url) }) .sink(receiveValue: { response in self.subject.send(response) // Crash occurs here }) } and the network request: private func fetch(from url: URL) -> AnyPublisher<Response?, Never> { return session .dataTaskPublisher(for: url) .map { (data, response) in let response = try? JSONDecoder().decode(Response.self, from: data) return response } .replaceError(with: nil) .eraseToAnyPublisher() } Timer creation itself is triggered by a separate publisher: otherPublisher .map({ item in guard let url = item?.url else { self.timerCancellable?.cancel() return nil } self.newTimer(for: url) return url }) ... Our crash reporting system has indicated the majority of these occur in the background, so I am curious if something could have changed in iOS 18.5 with background execution? Our app is registered with the audio background mode.

General: Forums subtopic: App & System Services > Core OS Forums tags: Files and Storage, Foundation, FSKit, File Provider, Finder Sync, Disk Arbitration, APFS Foundation > Files and Data Persistence documentation Low-level file system APIs are documented in UNIX manual pages File System Programming Guide archived documentation About Apple File System documentation Apple File System Guide archived documentation File system changes introduced in iOS 17 forums post On File System Permissions forums post Extended Attributes and Zip Archives forums post Unpacking Apple Archives forums post Creating new file systems: FSKit framework documentation File Provider framework documentation Finder Sync framework documentation App Extension Programming Guide > App Extension Types > Finder Sync archived documentation Managing storage: Disk Arbitration framework documentation Disk Arbitration Programming Guide archived documentation Mass Storage Device Driver Programming Guide archived documentation Device File Access Guide for Storage Devices archived documentation BlockStorageDeviceDriverKit framework documentation Volume format references: Apple File System Reference TN1150 HFS Plus Volume Format Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

The root issues is a missing entitlement error. I've jumped through countless hoops of checking/rechecking .entitlement file/plist file, creating new credentials, creating new projects, creating new provisioning profiles with no luck, manual signing, automatic signing. Any suggestions appreciated. Looking at the Provisioning Profile Info shows NFC Tag capabilities is included and NFC Entitlements are included. I'm at a loss... I am including the following: Pertinent output from console Current Info.Plist Current .entitlement file Here are the pertinent sectsis the Console Log for reference: ... NFCConnectionManager[0x074d6e40].tagReaderSessionDidBecomeActive(:): NFCTagReaderSessionDelegate: Session did become active NFCConnectionManager[0x074d6e40].tagReaderSession(:didDetect:): NFCTagReaderSessionDelegate: Session didDetectTags – 1 tags NFCConnectionManager[0x074d6e40].connected(session:tag:): Manager.connected(session:tag:) - tag: 7 bytes NFCConnection.Type.connection(): NFCConnection.connection() – connection established DEBUG: Successfully established YubiKit NFCConnection. DEBUG: UI updated: 'YubiKey connected... Performing challenge-response...' DEBUG: Sending APDU to select OATH applet: 00a4040008a000000527210101 NFCConnection[0x04575e00].send(data:): NFCConnection.send(data:) – 13 bytes NFCConnectionManager[0x074d6e40].transmit(request:for:): Manager.transmit – 13 bytes to tag ISO7816Identifier(data: 7 bytes) Here is the dreaded error: -[NFCTagReaderSession transceive:tagUpdate:error:]:897 Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement} ERROR: Operation failed: Missing required entitlement DEBUG: Unexpected error: Missing required entitlement Here is the info.plist Here is the entitlements file:

I stumbled across the "Apple NFC &amp; SE Platform" while searching for the cause to a persistent missing entitlement error. I am curious if not having this entitlement could be the root cause to my issues? Specifically, I am trying to perform an HMAC-SHA1 challenge-response via NFC on a YubiKey. Part of this entails low level APDU Send commands via NFC. The missing entitlement occurs right after the APDU Send. Per my separate post, I believe I have exhausted all other possible causes to no avail. For reference and details, this is the other post: [https://developer.apple.com/forums/thread/791995)

We are experiencing abnormal battery drain during sleep on several machines that installed our product. The affected devices appear to enter and exit sleep repeatedly every few seconds, even though the system logs show no new wake request reasons or changes in wake timers. Symptoms: Battery drops ~1% every ~15–20 minutes overnight. pmset -g log shows repeated "Entering Sleep" and "Wake Requests" events every few seconds. Wake requests remain unchanged between cycles and are scheduled far into the future (i.e. 20+ minutes later), yet the log lines keep repeating. On healthy machines, the same wake request entries appear only once every 20–30 minutes as expected, with minimal battery drop during sleep (~1% in 9 hours). What we've checked: No user activity (system lid closed, device idle). No significant pmset -g assertions; only powerd and bluetoothd are holding expected PreventUserIdleSystemSleep. pmset -g on affected machines shows sleep set to 0, likely due to sleep prevented by powerd, bluetoothd. No third-party daemons are holding assertions or logging excessive activity. Sample Logs from Affected Machine: 2025-06-28 21:57:29 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:76%) 3 secs 2025-06-28 21:57:31 Wake Requests [process=mDNSResponder request=Maintenance deltaSecs=7198 wakeAt=2025-06-28 23:57:29 ...] 2025-06-28 21:57:38 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:76%) 3 secs 2025-06-28 21:57:40 Wake Requests [process=mDNSResponder request=Maintenance deltaSecs=7198 wakeAt=2025-06-28 23:57:38 ...] 2025-06-28 21:57:47 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:75%) 3 secs 2025-06-28 21:57:49 Wake Requests [process=mDNSResponder request=Maintenance deltaSecs=7198 wakeAt=2025-06-28 23:57:47 ...] The only change in logs is the wakeAt timestamp being slightly updated . The wake requests themselves (process, type, deltaSecs) remain identical. Yet, the system keeps entering/exiting sleep every few seconds, which leads to power drain. We would appreciate your help in identifying: Why the sleep/wake cycles are repeating every few seconds on these machines. Whether this behavior is expected under certain conditions or indicates a regression or misbehavior in power management. How we can trace what exactly is triggering the repeated wake (e.g., a subsystem, implicit assertion, etc.). Whether there are unified log predicates or private logging options to further trace the root cause (e.g., process holding IO or waking CPU without explicit assertion). We can provide access to full logs, configuration profiles, and system diagnostics if needed.

My team has an app that uses BTLE heavily, and has been doing so successfully, including no issues continuing to receive data in the background and updating things in the app (for recording workouts). We have a BTLE write queue that only tries to write when the CBPeripheral.canSendWriteWithoutResponse property is true, or when we get the notification from the system in peripheralIsReady(toSendWriteWithoutResponse:). This is used as a means to rate limit data transfer, as we transfer files, as well as require that packets always arrive in the correct order due to blob encoding. However, we had a new requirement come in to periodically write data out to a connected peripheral. I noticed that as soon as the app was in the background, despite other delegate callbacks coming in, like didRecieveUpdatedValue:, neither the property canSendWriteWithoutResponse nor the delegate callback were called any longer. This meant our write queue didn't think it had permission to write, and packets would just stack up. The failure to deliver these updates didn't occur immediately after backgrounding, but did within 2-5s of backgrounding. If, when in the background, I ignore the changing of that property, and instead just write the data to the peripheral, it works! Can anyone explain why, despite other CBPeripheral callbacks happening when in the background, this one does not?

I have this very simple PersistenceController setup. It's used in both the main app and widget target. struct PersistenceController { static let shared = PersistenceController() @MainActor static let preview: PersistenceController = { let result = PersistenceController(inMemory: true) let viewContext = result.container.viewContext return result }() let container: NSPersistentContainer /// The main context. var context: NSManagedObjectContext { return container.viewContext } init(inMemory: Bool = false) { container = NSPersistentContainer(name: "Gamery") if inMemory { container.persistentStoreDescriptions.first!.url = URL(fileURLWithPath: "/dev/null") } else { do { let storeURL = try URL.storeURL(forAppGroup: "XXXXXXXXXX", databaseName: "Gamery") let storeDescription = NSPersistentStoreDescription(url: storeURL) /// Enable history tracking for cloud syncing purposes. storeDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) print("### Persistent container location: \(storeURL)") container.persistentStoreDescriptions = [storeDescription] } catch { print("Failed to retrieve store URL for app group: \(error)") } } container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { Crashlytics.crashlytics().record(error: error) fatalError("Unresolved error \(error), \(error.userInfo)") } }) container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergePolicy.mergeByPropertyObjectTrump #if !WIDGET if !inMemory { do { try container.viewContext.setQueryGenerationFrom(.current) } catch { fatalError("###\(#function): Failed to pin viewContext to the current generation: \(error)") } } PersistentHistoryToken.loadToken() #endif } } I regularly receive crash logs from the widget. I never experienced crashes myself and the widgets work fine. GameryWidgetExtension/PersistenceController.swift:35: Fatal error: Unresolved error Error Domain=NSCocoaErrorDomain Code=256 "The file “Gamery.sqlite” couldn’t be opened." UserInfo={NSFilePath=/private/var/mobile/Containers/Shared/AppGroup/B6A63FE1-ADDC-4A4C-A065-163507E991C6/Gamery.sqlite, NSSQLiteErrorDomain=23}, ["NSSQLiteErrorDomain": 23, "NSFilePath": /private/var/mobile/Containers/Shared/AppGroup/B6A63FE1-ADDC-4A4C-A065-163507E991C6/Gamery.sqlite] I have absolutely no idea what's going on here. Anyone who can help with this?

Hi everyone! I've considered this — what if Apple added a native system-wide feature in all of iOS, iPadOS, and macOS called “CrossRun” where you can natively execute non-App Store software like Windows or Linux apps natively on your device? But not in a sluggish emulator—this would use intelligent Apple-signed Just-In-Time (JIT) compilation inside the virtual containers, and the experience would actually perform fast and feel natural. This is my vision for CrossRun: Every developer, student, creative professional, and enterprise user who relies on specialized software—whether it’s legacy Windows tools, Linux-only applications, or vintage DOS and Classic Mac utilities—feels the pain of platform lock‑in. Artists can’t run niche Linux‑based graphics programs on their iPads. Engineers can’t test x64‑only binaries on Apple Silicon without juggling emulators. Retro‑gaming fans miss their favorite DOS titles. Even enterprises struggle to standardize on Apple hardware because critical Windows‑only applications won’t run seamlessly. If we don’t push for CrossRun now, the Apple ecosystem remains siloed: iPads and iPhones will continue limited to App Store apps, Macs will still need multiple third‑party VM tools, and countless workflows stay fragmented across devices. That means slower development cycles, extra licensing costs for virtualization software, and lost opportunities for education, creativity, and business efficiency. Without CrossRun’s universal runtime, we’ll still be rebooting into different environments or paying for separate virtualization apps—year after year. Apple already provides the building blocks: Rosetta 2, Virtualization.framework, Apple Silicon—and QEMU thrives as open‑source, battle‑tested code. With the next wave of Apple Silicon devices on the horizon, demand for cross‑architecture support, legacy‑app compatibility, and enterprise containerization is only growing. Delaying another year will cost developers, businesses, and users real time and money. Let’s show Apple that the community is ready for a truly universal, system‑integrated solution—right now. Key features we should demand in CrossRun: Built‑in Apple‑signed QEMU for all ISAs (x86, ARM, RISC‑V, PowerPC, 68k, MIPS, etc.) Rosetta 2 JIT for seamless macOS and Windows x64 support Metal‑backed 3D GPU passthrough and Vulkan→Metal / Direct3D→Metal translation Downloadable OS and app containers via the App Store or verified repositories (Ubuntu, Windows ARM/x64, Android, Haiku, ReactOS, FreeBSD, retro OSes) Predictive ML pre‑warm cache to speed cold starts Dynamic resource scaling (CPU, GPU, RAM) per container iCloud‑synced snapshots and shareable VM links for cross‑device continuity Customizable on‑screen controls (D‑pad, virtual buttons, trackpad, keyboard) on iPhone, iPad, and macOS Secure sandboxing via Virtualization.framework with VM disk encryption and MDM policy enforcement Virtual LAN and VPN passthrough for container networking Developer tooling (crossrunctl CLI, Xcode debugger integration, CI/CD support) Plugin ecosystem and container SDK for community‑published templates and translation layers Let Apple know it’s time to bake CrossRun into the system and unlock a universal runtime for every app, past and future, across iOS, iPadOS, and macOS.

The objective C code using the kernel API ‘sysctlbyname’ for ‘kern.osproductversion’ returns 16.0 instead of 26.0 on macOS Tahoe. sysctlbyname("kern.osproductversion", version, &size, NULL, 0) The command ‘sysctl kern.osproductversion’ returns ‘kern.osproductversion: 26.0’ on same macOS Tahoe. Note: The objective C code was built using Xcode 16.3.

Until now I was using FileManager.contentsEqual(atPath:andPath:) to compare file contents in my App Store app, but then a user reported that this operation is way slower than just copying the files (which I made faster a while ago, as explained in Making filecopy faster by changing block size). I thought that maybe the FileManager implementation reads the two files with a small block size, so I implemented a custom comparison with the same block size I use for filecopy (as explained in the linked post), and it runs much faster. When using the code for testing repeatedly also found on that other post, this new implementation is about the same speed as FileManager for 1KB files, but runs 10-20x faster for 1MB files or bigger. Feel free to comment on my implementation below. extension FileManager { func fastContentsEqual(atPath path1: String, andPath path2: String, progress: (_ delta: Int) -> Bool) -> Bool { do { let bufferSize = 16_777_216 let sourceDescriptor = open(path1, O_RDONLY | O_NOFOLLOW, 0) if sourceDescriptor < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } let sourceFile = FileHandle(fileDescriptor: sourceDescriptor) let destinationDescriptor = open(path2, O_RDONLY | O_NOFOLLOW, 0) if destinationDescriptor < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } let destinationFile = FileHandle(fileDescriptor: destinationDescriptor) var equal = true while autoreleasepool(invoking: { let sourceData = sourceFile.readData(ofLength: bufferSize) let destinationData = destinationFile.readData(ofLength: bufferSize) equal = sourceData == destinationData return sourceData.count > 0 && progress(sourceData.count) && equal }) { } if close(sourceDescriptor) < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } if close(destinationDescriptor) < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } return equal } catch { return contentsEqual(atPath: path1, andPath: path2) // use this as a fallback for unsupported files (like symbolic links) } } }