The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories" COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories. P.S. - Forgive me if I posting this in the wrong category, I couldn't find a "category" in the list of available categories on these forums that seems appropriate for this question.

I am developing an iOS/iPadOS application and have encountered some behavior regarding Files App and security-scoped bookmarks that I would like to clarify. Additionally, I would like to report some behavior which might include a potential issue. Question1: Accessing deleted files via bookmark (Specification clarification) Our app saves file URLs as bookmarks, which file that user has selected on Files App or app-created so to open a file which user has modified previously in the next launch. When a user deletes a file in Files App (moves a file to Recently Deleted), the app can still resolve the bookmark and access the file for read/write operations. Is this behavior intended? In other words, is it correct that a bookmark can access a file that has been deleted in Files App but not permanently removed? Question2: Overwriting a file in Recently Deleted (Potential bug) We noticed that overwriting a file in Recently Deleted behaves differently depending on the method used. Current implementation 1.Create a temporary file in the same directory 2.Write content to the temporary file 3.Delete the original file ([NSFileManager removeItemAtURL:error:]) 4.Move the temporary file to the original file path ([NSFileManager moveItemAtURL:toURL:error:]) Result: The file disappears from Files App Recently Deleted. In contrast, using [NSFileManager replaceItemAtURL:withItemAtURL:] keeps the file visible in Recently Deleted. Is this difference designed behavior? If not, this may be a bug. Question3: Detecting files in Recently Deleted We want to detect whether a file resides in Recently Deleted, but we cannot find a reliable and officially supported method. Recently Deleted files appear under .Trash, but using the path alone is not a reliable method. We have tried the following APIs without success: [NSURL getResourceValue:forKey:NSURLIsHiddenKey error:] [NSURL checkResourceIsReachableAndReturnError:] [NSFileManager fileExistsAtPath:] [NSFileManager isReadableFileAtPath:] [NSFileManager getRelationship:ofDirectory:NSTrashDirectory inDomain:NSUserDomainMask toItemAtURL:error:] We could not obtain the Recently Deleted folder URL using standard APIs. [NSFileManager URLsForDirectory:NSTrashDirectory inDomains:NSUserDomainMask] [NSFileManager URLForDirectory:NSTrashDirectory inDomain:NSUserDomainMask appropriateForURL:url create:error:] Could you advise a safe and supported way to detect Recently Deleted files properly by the app?

I am referencing: https://developer.apple.com/documentation/foundation/pausing-and-resuming-uploads Specifically: You can’t resume all uploads. The server must support the latest resumable upload protocol draft from the HTTP Working Group at the IETF. Also, uploads that use a background configuration handle resumption automatically, so manual resuming is only needed for non-background uploads. I have control over both the app and the server, and can't seem to get it to work automatically with a background url session. In other words, making multiple requests to get the offset then upload, easy but I am trying to leverage this background configuration resume OS magic. So anyone know what spec version does the server/client need to implement? The docs reference version 3, however the standard is now at like 11. Of course, I am trying out 3. Does anyone know how exactly this resume is implemented in iOS, and what exactly it takes care of? I assumed that I can just POST to a generic end point, say /files, then the OS receives a 104 Location, and saves that. If the upload is interrupted, when the OS resumes the upload, it has enough information to figure out how to resume from the exact offset, either by making a HEAD request to get the offset, or handle a 409. I am assuming it does this, as if it doesn't, the 'uploads that use a background configuration handle resumption automatically' is useless, if it just restarts from 0. Note, of course making individual POST/HEAD/PATCH requests manually works, but at that point I'm not really leveraging any OS auto-magic, and am just consuming an API that could really implement any spec. This won't work in the background, as the OS seems to disallow random HTTP requests when it wakes the app for URLSession background resumes. As of right now, I have it 'partially' working, insofar as the app does receive the 104 didReceiveInformationalResponse url delegate call, however it seems to then hang; it stops sending bytes, seemingly when the 104 is received. However, the request does not complete. In other words, it doesn't seem to receive a client timeout or otherwise indicate the request has finished. Right now, I am starting a single request, POSTing to a /files end point, i.e. I am not getting the location first, then PATCHing to that, as if I do that, the OS 'automatic' resuming fails with a 409, i.e. it doesn't seem to make a HEAD request and/or use the 409 offset correction then continue with the PATCH. Any idea what could be going on?

So if I create an Alias of a folder in Finder and hand the alias to my app (I also moved the alias file to a new folder, but I did not move the original folder)...so then my app resolves the alias using: NSURL +URLByResolvingAliasFileAtURL: What happens? The resolved URL points to a completely different folder. Well not completely different. It resolves to a folder that happens to share same last path component as the original folder...but this folder is inside the same parent folder the alias file is in. It does not resolve to the original folder I created the alias of. So then once my app touches the alias with +URLByResolvingAliasFileAtURL: the alias now resolves to this new (wrong) location (even in Finder). Couple details: My app is not sandboxed. I have permission to access the original folder in my app (but even if I didn't the alias shouldn't be mutated just by merely resolving it). Only seems to happen if the folder I move the alias to happens to contain a sibling folder that has the same title as the original folder. Like it's just deleting the last path component of the alias and then appending the last path component of the original filename and just going with that. I hope that makes sense. I tried creating the alias myself using -bookmarkDataWithOptions: and going the other way (to Finder) but Finder must be resolving the alias using a different API because it resolves to the original location as expected.

Environment: Hardware: Mac M4 OS: macOS Sequoia 15.7.4 TensorFlow-macOS Version: 2.16.2 TensorFlow-metal Version: 1.2.0 Description: When using the tensorflow-metal plug-in for GPU acceleration on M4, the ReLU activation function (both as a layer and as an activation argument) fails to correctly clip negative values to zero. The same code works correctly when forced to run on the CPU. Reproduction Script: import os import numpy as np import tensorflow as tf # weights and biases = -1 weights = [np.ones((10, 5)) * -1, np.ones(5) * -1] # input = 1 data = np.ones((1, 10)) # comment this line => GPU => get negative values # uncomment this line => CPU => no negative values # tf.config.set_visible_devices([], 'GPU') # create model model = tf.keras.Sequential([ tf.keras.layers.Input(shape=(10,)), tf.keras.layers.Dense(5, activation='relu') ]) # set weights model.layers[0].set_weights(weights) # get output output = model.predict(data) # check if negative is present print(f"min value: {output.min()}") print(f"is negative present? {np.any(output < 0)}")

I have an iOS app that runs on Mac, in iPad mode. In the menubar, some subitems are improperly labelled, featuring NSMENUITEMTITLEABOUT or NSMENUITEMHIDE or NSMENUITEMTITLE instead. Looks like it cannot find the name of the app. I have tried to set display name to no avail. Or is it a localisation issue ? How to correct this ?

Hi, I’m looking for clarification on what concurrency and consistency guarantees Apple provides when multiple targets (main app + Widget extensions) access shared storage. Specifically: 1. UserDefaults (App Group / suiteName:) • If multiple processes (app + multiple widget instances) read and write the same shared UserDefaults, what guarantees are provided? • Is access serialized internally to prevent corruption? • Are read–modify–write operations safe across processes, or can lost updates occur? 2. Core Data (shared SQLite store in App Group container) • Is it officially supported for multiple processes to open and write to the same Core Data SQLite store? • Are there recommended configurations (e.g. WAL mode) for safe multi-process access? • Is Apple’s recommendation to have a single writer process? 3. FileManager (shared container files) • If two processes write to the same file in an App Group container, what guarantees are provided by the system? • Is atomic replaceItemAt the recommended pattern for safe cross-process updates? Additionally: • Do multiple widget instances count as separate processes with respect to these guarantees? • Is there official guidance on best practices for shared persistence between app and widget extensions? I want to ensure I’m following the correct architecture and not relying on undefined behavior. Thanks.

I set the value of NSURLHasHiddenExtensionKey. I provide a textfield to rename a file and I set this flag based on whether the user has deleted or left on the path extension. So -setResourceValue:forKey:error: returns YES, does not populate the error, but does not honor the value I just set it to. I'm always setting it off the main thread on the same serial queue. Works the first time I rename the file then it just starts failing (silently). For example: NSError *setError = nil; if ([theURL setResourceValue:@(NO) forKey:NSURLHasHiddenExtensionKey error:&setError]) { [theURL removeAllCachedResourceValues]; NSNumber *freshRead = nil; NSError *getError = nil; if ([theURL getResourceValue:&freshRead forKey:NSURLHasHiddenExtensionKey error:&getError]) { if (freshRead.boolValue) { NSLog(@"it is yes when it should be NO."); } } if (getError != nil) { NSLog(@"Get error: %@",getError); } } if (setError != nil) { NSLog(@"Set error: %@",setError); } While I get that it is possible for there to be other apps setting this value at the same time as my app, doesn't really seem possible in my local environment right now. No errors log out but "it is yes when it should be NO." does log out.

In this code, I use in some places required init?(coder: (NSCoder?)) { // Init some properties super.init(coder: coder!) } And in other places required init?(coder: NSCoder) { super.init(coder: coder) // Init some properties } Both seem to work. Is there a preferred one ? In which cases ? Or should I always use the second one ? And can super be called at anytime ?

In this Mac App, I have an IBOutlet (which is defined as instance of a subclass of NSView). When I connect the IBOutlet to the code, referencing as file's owner, it works OK. But if I reference to the class, it crashes, when I access a specific IBOutlet (but other IBOutlets are accessed just before it without crashing).. The IBOutlet turnPageControl is defined as instance of subclass of NSView. Note: I have implemented several init methods: override init(window: NSWindow!) { } required init?(coder: (NSCoder?)) { } // Yes, (NSCoder?) convenience init(parameters) { // loading from nib } override func windowDidLoad() { super.windowDidLoad() // Access turnpageControl I get those calls before crash: init(window:) init(parameters:) init(window:) windowDidLoad() -> crash inside on accessing the IBOutlet for turnPageControl.isHidden = true Is there any reason to this ?

So I'm reworking couple things in my app. And I noticed I had this old code that does the following: Creates a temporary directory. Writes a file in the temporary directory. After the file is written moves the file out of the temporary location and places it in its final destination. Okay so I was not creating the temporary directory using the recommended API. I was simply doing something like this: NSURL *tempDirectory = [NSURL fileURLWithPath:[NSTemporaryDirectory() stringByAppendingPathComponent:[NSProcessInfo processInfo].globallyUniqueString]]; // Create tempDirectory and write files inside it. Now I just changed the code to use the recommended API which takes the the volume of the target destination into account: -URLForDirectory:inDomain:appropriateForURL:create:error:) and I pass in NSItemReplacementDirectory and a url to appropriateForURL so the destination volume is taken into account. Now I have external storage mounted and I use the recommended approach. I discovered NSFileManager simply writes a directory right in a user facing location titled: **(A Document Being Saved By App Name) ** and the folder is not hidden. Is this intended behavior for this API? Are temporary files supposed to be user facing? I know it is good practice to clean up temporary stuff when you are done but in crashes or just forgetting to clean up will leave these behind which isn't the behavior I expect for "temporary files." Also if the user is viewing the folder in Finder they'll see these A Document Being Saved By App Name folders appear and disappear in the window as my app does this work.

MacOS system settings allow the user to select one of a number of number formats. My app behaves differently depending on the format (taken from the system Locale), so I need to test every combination. Thus far I have been successful at creating Locale objects with various identifiers that map to the different formats, like: let westEuropeanLocale = Locale(identifier: "en_DE") However, I can't find a locale that maps to using . as a decimal point, and space as a thousands separator, even though it's a standard option (3rd in this list): Any suggestions on how to create a test for this number format?

macOS 26 "Tahoe" is allocating much more memory for apps than former macOS versions: A customer contacted me with my app's Thumbnail extension allocating so much memory that her 48 GB RAM Mac Mini ran into "out of application memory" state. I couldn't identify any memory leak in my extension's code nor reproduce the issue, but found the main app allocating as much as 5 times the memory compared to running on macOS 15 or lower. This productive app is explicitly using "Liquid Glass" views as well as implicitly e.g. for an inspector pane. So I created a sample app, just based on Xcode's template of a document-based app, and the issue is still showing (although less dramatically): This sample app allocates 22 MB according to Tahoe's Activity Monitor, while Sequoia only requires 16 MB: macOS 15.6.1 macOS 26.2 Is anyone experiencing similar issues? I suspect some massive leak in Tahoe's memory management, and just filed a corresponding feedback (FB21967167).

Hey, I am just about to prepare my app for Swift 6, and facing the issue that UserDefaults is not Sendable. The documentation states that its thread safe, so I am wondering, why is it not marked as Sendable? Was it just forgotten? Is it safe to mark it as nonisolated(unsafe) or @unchecked Sendable?

Hello. We are facing very silent and hardly replicable issue. All UserDefaults.standard data the application saved and was using to determine the state of app is lost and app behaves as if it was freshly installed. The issue always occurs only if we leave app on background for long time or if we manually swipe the app from the background apps. In case we swipe, this issue can occur in minutes, hours or up to 2 days by our latest testing. One important factor is that the app was developed using iOS18 in which issue never occured. Next it was being tested on iOS26 and it did everytime. Any currently available version of iOS26 reported this issue, all the way up to 26.2.1 (23C71). Our application is going through major upgrade of its whole lifecycle and services so it is possible this issue is caused by a bug in development as the production version does not report this issue neither on iOS26 of any version. The following list contains how we tried to fix this issue but none of which helped. App prewarming in the background (postpone all initialization including searching UserDefaults.standard for when isProtectedDataAvailable) Calling UserDefaults.standard.synchronize() everytime after saving data despite it is not recomended Built app using different SDK's (tested on iOS18 and iOS26 SDK) Distributed the app from local machine aswell as on TestFlight itself We searched through currently opened and closed issues for third-party libraries app uses regarding 'iOS26' and 'UserDefaults', especially those who were added recently with no success. The structure using which we save data into UserDefaults.standard did not change, we have only added few more settings to save through the lifecycle of the app after update. We estimate the overall increase is merely 30% more of what it used to be in previous version. Any ideas are much appreciated. We are considering to use different or fully custom ways to store app's settings.

I'm importing SwiftUI, Foundation and Charts into an iOS app I'm writing in Swift in Xcode Playgrounds and am getting this error: error: Couldn't look up symbols: protocol witness table for Foundation.Date : Charts.Plottable in Charts the code looks like this in just two example files: file 1, the view import Foundation import SwiftUI import Charts import PlaygroundSupport struct FirstChart_WithDates: View { private let data = ChartDateAndDoubleModel.mockData(months: 3) var body: some View { Chart(data) { item in BarMark( x: .value("Label", item.date, unit: .month), y: .value("Value", item.value) ) } .padding() .aspectRatio(1, contentMode: .fit) .dynamicTypeSize(.accessibility1) ChartDateAndDoubleModelView(data: data) } } struct ChartDateAndDoubleModelView: View { var data: [ChartDateAndDoubleModel] var body: some View { VStack { HeaderRowView(texts: ["date", "value"]) ForEach(data) { datum in HStack { Text(datum.date.formatted(date: .abbreviated, time: .omitted)) .frame(maxWidth: .infinity) // TODO: Format for 2 decimal places. Text(datum.value, format: .number.precision(.fractionLength(2))) .frame(maxWidth: .infinity) } } } .padding(.bottom, 8) .overlay(.quaternary, in: .rect(cornerRadius: 8).stroke()) .padding() } } struct HeaderRowView: View { var texts: [String] var body: some View { HStack(spacing: 2.0) { ForEach(texts, id: \.self) { text in Text(text) .padding(4) .frame(maxWidth: .infinity) .background(.quaternary) } } .font(.headline) .mask(UnevenRoundedRectangle(topLeadingRadius: 8, topTrailingRadius: 8)) } } and file 2, the model: import Foundation import SwiftUI import Charts // ChartDateAndDoubleModel.swift // // // Created by Michael Isbell on 2/10/26. // public struct ChartDateAndDoubleModel: Identifiable { public let id = UUID() public let date: Date public let value: Double } public extension ChartDateAndDoubleModel { static func mockData(months: Int = 5) -> [ChartDateAndDoubleModel] { var data: [ChartDateAndDoubleModel] = [] let calendar = Calendar(identifier: .gregorian) let currentDate = Date() for month in 0..<months { //add month to current date and append to data data.append( ChartDateAndDoubleModel( date: calendar.date(byAdding: .month, value: month, to: currentDate)!, value: Double.random(in: 0...1000) ) ) } return data } }

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is "Open In Place" compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the "In Place" capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider supports .openInPlace before the performDrop delegate method is called?

Hello, I have a .app NSApplication which is ran as a LaunchDaemon, in it's lifecycle I never call any AppKit functions (I start it with CFRunLoopRun). (mentioned on this post as well). I intercept a couple of signals using signal(s) in order to trigger CFRunLoopStop(CFRunLoopGetCurrent()) to do some cleanup. This LaunchDaemon has the purpose of providing VPN connectivity, as such I call connect functions that trigger the "Add VPN configuration" dialog (I can't provide extra details about this, as I integrate another SDK so I'm not sure what happens under the hood) and I noticed that whenever it is displayed, after allowing it, during the lifecycle of the application when it's time to send the signal, the signal isn't received. I tried re-adding the NSApp callbacks in order to investigate, but it looks like those aren't called as well. I'm interested in knowing more about this scenario and what happens... I couldn't really find information about this dialog... Thanks!

Environment: Xcode 26 iOS 26 Also tested on iOS 18 (working correctly) Description: I'm experiencing a behavior change with URL(fileURLWithPath:) when the filename starts with a tilde (~) character. On iOS 18, passing a filename like ~MyFile.txt to URL(fileURLWithPath:) treats the tilde as a literal character. However, on iOS 26, the same code resolves the tilde as the home directory, resulting in unexpected output. Minimal Example: let filename = "~MyFile.txt" let url = URL(fileURLWithPath: filename) print(url.lastPathComponent) Expected Result (iOS 18): ~MyFile.txt Actual Result (iOS 26): 924AF0C4-C3CD-417A-9D5F-733FBB8FCF29 The tilde is being resolved to the app's container directory, and lastPathComponent returns the container UUID instead of the filename. Questions: 1. Is this an intentional behavior change in iOS 26? 2. Is there documentation about this change? 3. What is the recommended approach for extracting filename components when the filename may contain special characters like ~? Workaround: Using NSString.lastPathComponent works correctly on both iOS versions: let filename = "~MyFile.txt" let result = (filename as NSString).lastPathComponent // Returns: "~MyFile.txt" ✅ Is this the recommended approach going forward?

I've implemented func urlSession(_ session: URLSession, task: URLSessionTask, willPerformHTTPRedirection response: HTTPURLResponse, newRequest request: URLRequest, completionHandler: @escaping (URLRequest?) -> Void) and func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) I've put a breakpoint in each but the BP in willPerformHTTPRedirection never fires. When the didWriteData fires and I inspect downloadTask.originalRequest I see my original request URL When I inspect downloadTask.currentRequest the returned request contains a different URL. I'm the farthest thing from an HTTP wizard, but I had thought when originalRequest differs from currentRequest there had been some sort of server-side 'redirection'. Is there a way for my code to receive a callback when something like this happens? NOTE: my download code works fine, I'm just hoping to detect the case when currentRequest changes. any/all guidance greatly appreciated on the off chance it helps, are are my original and current request values: (lldb) po downloadTask.originalRequest ▿ Optional<URLRequest> ▿ some : https://audio.listennotes.com/e/p/c524803c1a90412f922948274ecc3625/ (lldb) po downloadTask.currentRequest ▿ Optional<URLRequest> ▿ some : https://26973.mc.tritondigital.com:443/OMNY_HAPPIERWITHGRETCHENRUBIN_PODCAST_P/media-session/76cfceb2-1801-4570-b830-ded57611a9cf/d/clips/796469f9-ea34-46a2-8776-ad0f015d6beb/e1b22d0b-6974-4bb8-81ba-b2480119983c/2f35a8ca-b982-44e9-8122-b3dc000ae0e1/audio/direct/t1769587393/Ep_571_Want_to_Join_Us_for_a_No-Spend_February_Plus_a_Better_Word_for_Squats.mp3?t=1769587393&in_playlist=751ada7f-ded3-44b9-bfb8-b2480119985b&utm_source=Podcast