Modern versions of macOS use a file system permission model that’s far more complex than the traditional BSD rwx model, and this post is my attempt at explaining that model. If you have a question about this, post it here on DevForums. Put your thread in the App & System Services > Core OS topic area and tag it with Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" On File System Permissions Modern versions of macOS have four different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) The first two were introduced a long time ago and rarely trip folks up. The second two are newer, more complex, and specific to macOS, and thus are the source of some confusion. This post is my attempt to clear that up. Error Codes App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure. When a file system operation fails, check the error to see whether it was blocked by this sandboxing infrastructure. If an operation was blocked by BSD permissions or ACLs, it fails with EACCES (Permission denied, 13). If it was blocked by something else, it’ll fail with EPERM (Operation not permitted, 1). If you’re using Foundation’s FileManager, these error are both reported as Foundation errors, for example, the NSFileReadNoPermissionError error. To recover the underlying error, get the NSUnderlyingErrorKey property from the info dictionary. App Sandbox File system access within the App Sandbox is controlled by two factors. The first is the entitlements on the main executable. There are three relevant groups of entitlements: The com.apple.security.app-sandbox entitlement enables the App Sandbox. This denies access to all file system locations except those on a built-in allowlist (things like /System) or within the app’s containers. The various “standard location” entitlements extend the sandbox to include their corresponding locations. The various “file access temporary exceptions” entitlements extend the sandbox to include the items listed in the entitlement. Collectively this is known as your static sandbox. The second factor is dynamic sandbox extensions. The system issues these extensions to your sandbox based on user behaviour. For example, if the user selects a file in the open panel, the system issues a sandbox extension to your process so that it can access that file. The type of extension is determined by the main executable’s entitlements: com.apple.security.files.user-selected.read-only results in an extension that grants read-only access. com.apple.security.files.user-selected.read-write results in an extension that grants read/write access. Note There’s currently no way to get a dynamic sandbox extension that grants executable access. For all the gory details, see this post. These dynamic sandbox extensions are tied to your process; they go away when your process terminates. To maintain persistent access to an item, use a security-scoped bookmark. See Accessing files from the macOS App Sandbox. To pass access between processes, use an implicit security scoped bookmark, that is, a bookmark that was created without an explicit security scope (no .withSecurityScope flag) and without disabling the implicit security scope (no .withoutImplicitSecurityScope flag)). If you have access to a directory — regardless of whether that’s via an entitlement or a dynamic sandbox extension — then, in general, you have access to all items in the hierarchy rooted at that directory. This does not overrule the MAC protection discussed below. For example, if the user grants you access to ~/Library, that does not give you access to ~/Library/Mail because the latter is protected by MAC. Finally, the discussion above is focused on a new sandbox, the thing you get when you launch a sandboxed app from the Finder. If a sandboxed process starts a child process, that child process inherits its sandbox from its parent. For information on what happens in that case, see the Note box in Enabling App Sandbox Inheritance. IMPORTANT The child process inherits its parent process’s sandbox regardless of whether it has the com.apple.security.inherit entitlement. That entitlement exists primarily to act as a marker for App Review. App Review requires that all main executables have the com.apple.security.app-sandbox entitlement, and that entitlements starts a new sandbox by default. Thus, any helper tool inside your app needs the com.apple.security.inherit entitlement to trigger inheritance. However, if you’re not shipping on the Mac App Store you can leave off both of these entitlement and the helper process will inherit its parent’s sandbox just fine. The same applies if you run a built-in executable, like /bin/sh, as a child process. When the App Sandbox blocks something, it typically generates a sandbox violation report. For information on how to view these reports, see Discovering and diagnosing App Sandbox violations. To learn more about the App Sandbox, see the various links in App Sandbox Resources. For information about how to embed a helper tool in a sandboxed app, see Embedding a Command-Line Tool in a Sandboxed App. Mandatory Access Control Mandatory access control (MAC) has been a feature of macOS for many releases, but it’s become a lot more prominent since macOS 10.14. There are many flavours of MAC but the ones you’re most likely to encounter are: Full Disk Access (macOS 10.14 and later) Files and Folders (macOS 10.15 and later) App container protection (macOS 14 and later) App group container protection (macOS 15 and later) Data Vaults (see below) and other internal techniques used by various macOS subsystems Mandatory access control, as the name suggests, is mandatory; it’s not an opt-in like the App Sandbox. Rather, all processes on the system, including those running as root, as subject to MAC. Data Vaults are not a third-party developer opportunity. See this post if you’re curious. In the Full Disk Access and Files and Folders cases, users grant a program a MAC privilege using System Settings > Privacy & Security. Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access). If you’re not sure, run this simple test: On a Mac with two users, log in as user A and enable the MAC privilege for a program. Now log in as user B. Does the program have the privilege? If a process tries to access an item restricted by MAC, the system may prompt the user to grant it access there and then. For example, if an app tries to access the desktop, you’ll see an alert like this: “AAA” would like to access files in your Desktop folder. [Don’t Allow] [OK] To customise this message, set Files and Folders properties in your Info.plist. This system only displays this alert once. It remembers the user’s initial choice and returns the same result thereafter. This relies on your code having a stable code signing identity. If your code is unsigned, or signed ad hoc (“Signed to Run Locally” in Xcode parlance), the system can’t tell that version N+1 of your code is the same as version N, and thus you’ll encounter excessive prompts. Note For information about how that works, see TN3127 Inside Code Signing: Requirements. The Files and Folders prompts only show up if the process is running in a GUI login session. If not, the operation is allowed or denied based on existing information. If there’s no existing information, the operation is denied by default. For more information about app and app group container protection, see the links in Trusted Execution Resources. For more information about app groups in general, see App Groups: macOS vs iOS: Fight! On managed systems the site admin can use the com.apple.TCC.configuration-profile-policy payload to assign MAC privileges. For testing purposes you can reset parts of TCC using the tccutil command-line tool. For general information about that tool, see its man page. For a list of TCC service names, see the posts on this thread. Note TCC stands for transparency, consent, and control. It’s the subsystem within macOS that manages most of the privileges visible in System Settings > Privacy & Security. TCC has no API surface, but you see its name in various places, including the above-mentioned configuration profile payload and command-line tool, and the name of its accompanying daemon, tccd. While tccutil is an easy way to do basic TCC testing, the most reliable way to test TCC is in a VM, restoring to a fresh snapshot between each test. If you want to try this out, crib ideas from Testing a Notarised Product. The MAC privilege mechanism is heavily dependent on the concept of responsible code. For example, if an app contains a helper tool and the helper tool triggers a MAC prompt, we want: The app’s name and usage description to appear in the alert. The user’s decision to be recorded for the whole app, not that specific helper tool. That decision to show up in System Settings under the app’s name. For this to work the system must be able to tell that the app is the responsible code for the helper tool. The system has various heuristics to determine this and it works reasonably well in most cases. However, it’s possible to break this link. I haven’t fully research this but my experience is that this most often breaks when the child process does something ‘odd’ to break the link, such as trying to daemonise itself. If you’re building a launchd daemon or agent and you find that it’s not correctly attributed to your app, add the AssociatedBundleIdentifiers property to your launchd property list. See the launchd.plist man page for the details. Scripting MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that. The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts. TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you’re likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. For an example of how you might do that, see this post. Revision History 2024-11-08 Added info about app group container protection. Clarified that Data Vaults are just one example of the techniques used internally by macOS. Made other editorial changes. 2023-06-13 Replaced two obsolete links with links to shiny new official documentation: Accessing files from the macOS App Sandbox and Discovering and diagnosing App Sandbox violations. Added a short discussion of app container protection and a link to WWDC 2023 Session 10053 What’s new in privacy. 2023-04-07 Added a link to my post about executable permissions. Fixed a broken link. 2023-02-10 In TCC and Main Executables, added a link to my native trampoline code. Introduced the concept of an implicit security scoped bookmark. Introduced AssociatedBundleIdentifiers. Made other minor editorial changes. 2022-04-26 Added an explanation of the TCC initialism. Added a link to Viewing Sandbox Violation Reports.  Added the TCC and Main Executables section. Made significant editorial changes. 2022-01-10 Added a discussion of the file system hierarchy. 2021-04-26 First posted.

General: DevForums tags: Files and Storage, Finder Sync, File Provider, Disk Arbitration, APFS File System Programming Guide On File System Permissions DevForums post File Provider framework Finder Sync framework App Extension Programming Guide > App Extension Types > Finder Sync Disk Arbitration Programming Guide Mass Storage Device Driver Programming Guide Device File Access Guide for Storage Devices Apple File System Guide TN1150 HFS Plus Volume Format Extended Attributes and Zip Archives File system changes introduced in iOS 17 DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

File system changes introduced in iOS 17 As part of iOS 17, tvOS 17, and watchOS 10, the system has reorganized where applications and their data containers are stored. In previous systems, both lived within the same volume but, starting in iOS 17, they will be stored on different volumes. What does this mean for you? Copying large amounts of data from the app bundle to a data container will take longer than in previous versions of iOS. Previously that copy would have occurred as an APFS file clone, but now the operation will occur as a standard copy, which may take much significantly longer. Because the data will need to be fully duplicated, storage usage will increase more than was the case in previous versions. You should minimize the data they copy out of their app bundle and avoid any unnecessary duplication of data between the app bundle and data container. When upgrading from previous system version, splitting the data into separate volumes may mean that there is insufficient space for all existing apps and their data. If this occurs, the app's data container will remain on the device, preserving the user's data, while the app bundle itself is removed using the same mechanism as "Offload Unused Apps". The user can then restore the app once they've freed sufficient space for the app to install. Revision History 2023-07-11 First posted

I was able to confirm with a customer of mine that calling copyfile with a source file that is a symbolic link on a NTFS partition always causes the error NSPOSIXErrorDomain 12 Cannot allocate memory They use NTFS drivers from Paragon. They tried copying a symbolic link from NTFS to both APFS and NTFS with the same result. Is this an issue with macOS, or with the NTFS driver? Copying regular files on the other hand always works. Copying manually from the Finder also seems to always work, both with regular files and symbolic links, so I'm wondering how the Finder does it. Here is the sample app that they used to reproduce the issue. The first open panel allows to select the source directory and the second one the destination directory. The variable filename holds the name of the symbolic link to be copied from the source to the destination. Apparently it's not possible to select a symbolic link directly in NSOpenPanel, as it always resolves to the linked file. @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ notification: Notification) { let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.canChooseFiles = false openPanel.runModal() let filename = "Modules" let source = openPanel.urls[0].appendingPathComponent(filename) openPanel.runModal() let destination = openPanel.urls[0].appendingPathComponent(filename) do { let state = copyfile_state_alloc() defer { copyfile_state_free(state) } var bsize = UInt32(16_777_216) if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } if copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CB), unsafeBitCast(copyfileCallback, to: UnsafeRawPointer.self)) != 0 || copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CTX), unsafeBitCast(self, to: UnsafeRawPointer.self)) != 0 || copyfile(source.path, destination.path, state, copyfile_flags_t(COPYFILE_NOFOLLOW)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } } catch { let error = error as NSError let alert = NSAlert() alert.messageText = "\(error.localizedDescription)\n\(error.domain) \(error.code)" alert.runModal() } } private let copyfileCallback: copyfile_callback_t = { what, stage, state, src, dst, ctx in if what == COPYFILE_COPY_DATA { if stage == COPYFILE_ERR { return COPYFILE_QUIT } var size: off_t = 0 copyfile_state_get(state, UInt32(COPYFILE_STATE_COPIED), &size) } return COPYFILE_CONTINUE } }

iPhone 15pro iOS 18.2 Downloaded files cannot be located anywhere in Files, only by accessing Downloads in Safari. I have tried setting download folder to various locations, iCloud, Phone, Google Disk, but nothing is stored. Has an invisible cache or temp folder been introduced? If so, it is a total fail: When press-holding any file in Safari download, the normal file action options (Quick Look, share, store to Files, etc) are not available. When clicking any file it opens any of several apps that has this file type associated with it, and there is no way to change the default app or disable the forced opening of an app. I tried deleting the app opening .csv (in this case OneDrive), and another irrelevant app opened. There seems to be a hierarchy of apps-file types, and it has no logic to it. in Chrome behaviour is as expected. Chrome vs. Safari screen recordings: https://shorturl.at/my3Oy

iPhone 15pro iOS 18.2 Downloaded files cannot be located anywhere in Files, only by accessing Downloads in Safari. I have tried setting download folder to various locations, iCloud, Phone, Google Disk, but nothing is stored. Has an invisible cache or temp folder been introduced? If so, it is a total fail: When press-holding any file in Safari download, the normal file action options (Quick Look, share, store to Files, etc) are not available. When clicking any file it opens any of several apps that has this file type associated with it, and there is no way to change the default app or disable the forced opening of an app. I tried deleting the app opening .csv (in this case OneDrive), and another irrelevant app opened. There seems to be a hierarchy of apps-file types, and it has no logic to it. Tips?

Accessing a directory on my custom distributed filesystem results in a kernel panic. According to the backtrace, the last function called before the panic is triggered is mac_label_verify(). See the backtrace file attached. mac_label_verify-panic.txt The panic manifests itself given the following conditions: Machine-a: make a directory in Finder. Machine-b: remove the directory created on machine-a in Finder. Machine-a: access the directory removed on machine-b in Finder. Kernel panic ensues. The panic is reproducible on both Apple Silicon and x86-64. The backtrace is for x86-64 as I wasn't able to symbolicate it on Apple Silicon. Not sure how to tackle this one. Any pointers would be much appreciated.

Capability to read and write ofd HFS disks on Mac has been removed since a long time. Capability to simply read was also removed since Catalina I think. That is surprising and sometimes frustrating. I still use a 90's MacBook for a few tasks and need from time to time to transfer files to newer Mac or read some old files stored on 3.5" disks. Solution I use is to read the disk on an old Mac with MacOS 10.6 (I'm lucky enough to have kept one) and transfer to USB stick or airdrop… As there is no USB port on the Macbook of course (and I have no more a working 56k modem to transfer by mail), only option if not 3,5" disk is using PCMCIA port on the MacBook for writing to an SD Card to be read in Mac Sonoma. But reading directly 3.5" disk would be great. Hence my questions for the forum: how hard would it be to write such a driver for READING only HFS on Mac Sonoma? There are some software like FuseHFS. Did anyone experience it ? Did anyone have a look at the source code (said to be open source). does anyone know why Apple removed such capability (I thought it was a tiny piece of code compared to the GB of present MacOS)? Thanks for any insights on the matter.

I am getting recurring errors running code on macOS 15.1 on arm that is using a volume mounted from a machine running macOS 14.7.1 on x86. The code I am running copies files to the remote volume and deletes files and directories on the remote volume. The files and directories it deletes are typically files it previously had copied. The problem is that I get permission failures trying to delete certain directories. After this happens, if I try to list the directory using Terminal on the 15.1 system, I get a strange error: ls -lA TestVAppearances.app/Contents/runtime-arm/Contents total 0 ls: fts_read: Permission denied If I try to list the directory on the target (14.7.1) system, there is no error: TestVAppearances.app/Contents/runtime-arm/Contents: total 0

We run simple iOS Swift code triggered by a remote notification: UserDefaults.standard.set("key", forKey: "value") It runs fine when the app is active or inactive, but when the device is closed/locked and the code is triggered, we see a warning in Xcode: Couldn't write values for keys ( key ) in CFPrefsPlistSource<0x3018802d0> (Domain: com.example, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): Path not accessible Not updating lastKnownShmemState in CFPrefsPlistSource<0x3018802d0> (Domain: com.example, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): 767 -> 767 The issue is that there seems to be no way to catch that warning. The value is set, when it's re-read the value is correct. But the value is never written to disk, so after an app restart/update the value is gone, potentially has an old wrong value. This code runs without any interruption, it's just showing the warning on iOS 17.7.1 on iPad: UserDefaults.standard.set("key", forKey: "value") UserDefaults.standard.synchronize() print("value: \(UserDefaults.standard.string(forKey: "key"))") Should there not be a way to catch this, so the code can act accordingly to the circumstances? It would be good to know inside the code that the value is not persisted. I would expect that an exception is generated somewhere which can be caught. It seems .completeFileProtectionUntilFirstUserAuthentication enables files to be written to disk while the device is closed/locked, can something similar be used for UserDefaults.standard?

Dear Apple engineers, Is it possible to make a fileprovider cloud volume mount path independent of the user's home folder in order to have constant path across desktop clients when files are referenced / placed by applications like Adobe Creative Cloud ? Ideally mount or link the fileprovider cloud volume under /Volumes Thanks,

I would like to replace the deprecated method FSMountServerVolumeSync with the newer one NetFSMountURLSync. I can properly mount my FTP volume using "Connect to Server" in the Finder and with FSMountServerVolumeSync (the volume comes as read only, but it's ok). When I try to mount the FTP volume with NetFSMountURLSync I get this error message: "The share does not exist on the server. Please check the share name and then try again". But as I know I can't define the share on a FTP server. How can I fix this issue?

Hi all, I found an issue by chance where, when we copy an .app bundle (a large one), Gatekeeper can choose to try to scan the app before the file copying finishes (without the app having been launched). This of course fails, and then the app can't open because "it's damaged", even though spctl and codesign checks of the completed copied app come out fine. Then Gatekeeper remembers this setting forever, not rescanning the app. I'm wondering if anyone else has seen this happen and if so, if there's a best practice for keeping Gatekeeper's hands off until the copy is done? I imagine copying into a folder not named .app, then renaming it might work, or maybe saving the plist or main binary copy until last, although both require a more complex copy operation. Maybe there's a more elegant way? Thanks!

I ran out of disk space and I think I've come to the point that I need to delete files used by Xcode. Can I delete Simulator altogether? It doesn't look like I can run the latest Xcode without iOS 18 installed with it on my Mac Pro. Is there any way I can exclude iOS 18 support using the current Xcode? Would it be a good option to uninstall the latest Xcode and use a previous version of Xcode instead, since I'm not developing for iOS 18? Since I've been working on only macOS apps, is it possible for me to delete anything that has to do with developing for iOS?

I am working on a personal use app, to transcribe audio files. I have over 1000 Voice Memos of ideas for a dog training app and book, recorded while... walking dogs, of course. I seem to not have the built in transcription option, either because Sonoma doesn't support it or my region doesn't, but I have learned a lot of Swift building an app that works great fort files in a folder in Documents. I have also found the path to to all the Voice Memo recordings. But when I try to read the contents of the folder to build the queue for transcription I get The file “Recordings” couldn’t be opened because you don’t have permission to view it. I expected this to be locked down, and some searching brought me to this and I have added Access User Selected Files (Read Only) = YES to the entitlements file, but I am not seeing where in the TARGETS editor I would assign com.apple.security.files.user-selected.read-only. If I add it as a key under info I don't get a popup to select, either in Xcode or when running the app. If I try to add that key to the entitlements file it doesn't allow for selection either. I am sure I am just missing something in the documentation, likely as a result of being an Xcode & Swift noob. So, if I CAN do this and I am just missing something, can someone point the way? And if a folder inside another app is just verboten, manually copying those files to a documents folder for processing won't be the end of the world.

Codesigned and notarized app cannot directly write files inside the app bundle (neither in my.app/Contents/Resources/ nor my.app/Contents/MacOS/). Are there any restrictions regarding this? Is there a way to bypass these restrictions? Here is the situation I encountered: The main app contains several sub-apps and sub-executables. When the main app calls the sub-apps or sub-executables, it can write files within the app bundle, but when executed directly, it cannot write files. The app is usually opened using the GUI, and when using the command line, neither the main app nor the sub-apps/sub-executables can write files within the app bundle. My codesigning environment is: Sonoma 14.0 on mac mini M1. I manually sign the app directly using the codesign command in CI instead of using Xcode. The process will traverse all of the files and sub-apps in the app folder and sign them from the deepest paths to the shallowest paths. I also tried applying this process to other applications, but all of them encountered the same issue of failing to write files. The app should not be sandboxed (I did not add sandbox entitlements). I have tried adding the entitlement com.apple.security.files.user-selected.read-write, but this has not resolved the issue.

You'll have to forgive me, I am still pretty new to Swift, but I'm really struggling to figure out what I'm doing wrong or how I can fix it. I'm working on an app that generates an image from some views and then exports that image, but it always returns this very vague error: The operation couldn’t be completed. (SwiftUI.FileExportOperation.Error error 0.) Here's most of the program: import SwiftUI import UniformTypeIdentifiers struct ContentView: View { @State private var backgroundColor = Color.black @State private var fileExporterIsPresented = false @State private var image: NSImage? @State private var fileExporterErrorAlertIsPresented = false @State private var fileExporterErrorDescription: String? var body: some View { let wallpaper = Rectangle() .foregroundStyle(backgroundColor) .aspectRatio(16 / 9, contentMode: .fit) VStack { wallpaper .clipShape(.rect(cornerRadius: 10)) .overlay { RoundedRectangle(cornerRadius: 10) .strokeBorder(.separator, lineWidth: 5) } ColorPicker("Background Color", selection: $backgroundColor, supportsOpacity: false) Button("Generate Wallpaper") { let renderer = ImageRenderer(content: wallpaper.frame(width: 3840, height: 2160)) image = renderer.nsImage fileExporterIsPresented = true } .fileExporter( isPresented: $fileExporterIsPresented, item: image, contentTypes: [UTType.heic, UTType.png] ) { result in if case .failure(let error) = result { fileExporterErrorDescription = error.localizedDescription fileExporterErrorAlertIsPresented = true } } .alert("File Exporter Failure", isPresented: $fileExporterErrorAlertIsPresented, actions: { Button("OK") {} }, message: { if let fileExporterErrorDescription { Text(fileExporterErrorDescription) } }) .dialogSeverity(.critical) } .padding() } } #Preview { ContentView() }

Hello, I'm seeing a strange error on another user's device where the SwiftUI file importer doesn't do anything at all. When selecting multiple files and hitting "open", the importer just freezes. Here's a video showing the problem: https://streamable.com/u5grgy I'm unable to replicate on my own device, so I'm not sure what could be going on. I have startAccessingSecurityScopedResource and stopAccessingSecurityResource everywhere I access a file from fileImporter as well.

Hey, I am fairly new to working with AVFoundation etc. As far as I could research on my own, if I want to get metadata from let's say a .m4a audio file, I have to get the data and then create an AVAsset. My files are all on local servers and therefore I would not be able to just pass in the URL. The extraction of the metadata works fine - however those AVAssets create a huge overhead in storage consumption. To my knowledge the data instances of each audio file and AVAsset should only live inside the function I call to extract the metadata, however those data/AVAsset instances still live on on storage as I can clearly see that the app's file size increases by multiple Gigabytes (equal to the library size I test with). However, the only data that I purposefully save with SwiftData is the album artwork. Is this normal behavior for AVAssets or am I missing some detail? PS. If I forgot to mention something important, please ask. This is my first ever post, so I'm not too sure what is worth mentioning. Thank you in advance! Denis

Hi everyone! I’m fairly new to Swift and currently working on a small iOS app in SwiftUI. The app is able to load a CSV file embedded in the Xcode project (using Bundle.main.path(forResource:)), and everything works well with that. Now, I want to take it a step further by allowing the app to load an external CSV file located in the iPhone’s directories (like “Documents” or “Downloads”). However, I’m struggling to make it work. I tried using a DocumentPicker to select the CSV file, and I believe I’m passing the file URL correctly, but the app keeps reading only the embedded file instead of the one selected by the user. Could anyone offer guidance on how to properly set up loading an external CSV file? I’m still learning, so any suggestions or examples would be really appreciated! Thanks a lot in advance for the help! Here’s the code that isn’t working as expected: import Foundation struct Product: Identifiable { let id = UUID() var codice: String var descrizione: String var prezzo: Double var installazione: Double var trasporto: Double } class ProductViewModel: ObservableObject { @Published var products: [Product] = [] @Published var filteredProducts: [Product] = [] func loadCSV(from url: URL) { products = [] do { let data = try String(contentsOf: url) let lines = data.components(separatedBy: "\n") // Legge e processa ogni riga del CSV (saltando la prima riga se è l'intestazione) for line in lines.dropFirst() { let values = line.components(separatedBy: ";") // Assicurati che ci siano abbastanza colonne e gestisci i valori mancanti if values.count >= 5 { let codice = values[0].trimmingCharacters(in: .whitespaces) let descrizione = values[1].trimmingCharacters(in: .whitespaces) let prezzo = parseEuropeanDouble(values[2]) ?? 0.0 let installazione = parseEuropeanDouble(values[3].isEmpty ? "0,00" : values[3]) ?? 0.0 let trasporto = parseEuropeanDouble(values[4].isEmpty ? "0,00" : values[4]) ?? 0.0 let product = Product( codice: codice, descrizione: descrizione, prezzo: prezzo, installazione: installazione, trasporto: trasporto ) products.append(product) } } filteredProducts = products } catch { print("Errore nel caricamento del CSV: \(error)") } } private func parseEuropeanDouble(_ value: String) -> Double? { let formatter = NumberFormatter() formatter.locale = Locale(identifier: "it_IT") formatter.numberStyle = .decimal return formatter.number(from: value)?.doubleValue } } struct ContentView: View { @StateObject var viewModel = ProductViewModel() @State private var showFilePicker = false var body: some View { VStack { Button("Carica file CSV") { showFilePicker = true } .fileImporter(isPresented: $showFilePicker, allowedContentTypes: [.commaSeparatedText]) { result in switch result { case .success(let url): viewModel.loadCSV(from: url) case .failure(let error): print("Errore nel caricamento del file: \(error.localizedDescription)") } } List(viewModel.filteredProducts) { product in VStack(alignment: .leading) { Text("Codice: \(product.codice)") Text("Descrizione: \(product.descrizione)") Text("Prezzo Lordo: €\(String(format: "%.2f", product.prezzo))") Text("Installazione: €\(String(format: "%.2f", product.installazione))") Text("Trasporto: €\(String(format: "%.2f", product.trasporto))") } } } .padding() } }

Hi. I am having trouble with the issue where the media name and storage information name, which matched in MacOS 14 and earlier, are now inconsistent with the volume label and "NO NAME" in MacOS 15. The problem is that while changing the name on macos 15 will temporarily unify the names, if you overwrite them on Windows they revert to "NO NAME". At first I thought it was reflecting BS_VolLab in the boot sector, but that doesn't seem to be the case. Do you have any ideas for writing a program for Windows to solve this problem?

Extracting an archive into the same directory on my custom filesystem more than once fails with the following message: Unable to finish expanding 'misc.tar.xz' into 'extractme'. Could not move 'misc' into destination directory. I.e. initial extraction succeeds with archive contents extracted into extractme/misc. Subsequent extraction fails to rename extractme.sb-db71cd27-lFjN1f/misc to extractme/misc 2. This behaviour is observed on macOS Monterey and Ventura. It does work as expected on macOS Sonoma though. Dtrace(1)-ing the archive being extracted over smbfs results in the following sequence of calls being made: 2 -> smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 nameiop:0 2 <- smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 -> 2 ;ENOENT 2 -> smbfs_vnop_lookup AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc nameiop:0x2 ;DELETE 2 <- smbfs_vnop_lookup AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc -> 0 2 -> smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 nameiop:0x3 ;RENAME 2 <- smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 -> EJUSTRETURN 1 -> smbfs_vnop_rename AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc -> extractme/nil 2 <- smbfs_vnop_rename AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc -> extractme/nil -> 0 2 -> smbfs_vnop_lookup AUHelperService-2163 -> TheRooT/extractme/misc 2 nameiop:0 3 <- smbfs_vnop_lookup AUHelperService-2163 -> TheRooT/extractme/misc 2 -> 0 ;Successful lookup What I don't understand is what causes vnop_lookup to be called for misc to be removed from the temporary directory and renamed into 'misc 2' and placed in the destination directory, 'extractme' via vnop_rename? I had a look at smbfs_vnop_lookup and rename and didn't see anything that would cause 'misc 2' to come into being. Based on the output of the dtrace(1) script running on my custom filesystem, there are no vnop_lookup and vnop_rename calls being made to remove the 'misc' directory from the temporary directory and to rename it to 'misc 2' and place it in the destination directory at extractme. Archive extraction proceeds no further after extracting the archive contents into the temporary directory. What am I missing?

I want to use ShareLink+FileRepresentation to save a small text file to my iPhone with the steps below. Tap [Share...] to display the share sheet. This sheet contains [Save to Files]. Tap [Save to Files]. A black sheet is displayed, but it disappears instantly. In step 3, I was expecting a browser to be displayed to select the location where the file will be saved. But in fact, a black sheet appears, which quickly disappears. The implemented code is as follows. import SwiftUI @main struct SLSandboxApp: App { var body: some Scene { WindowGroup { let title = Text("File Output") let numListString = "123,456,789" let numListFileName = "numlist.csv" let tagListFile = TextFile(content: numListString, filename: numListFileName) ShareView(title: title, fileToShare: tagListFile, messageToPreview: numListFileName) } } } struct ShareView: View { let title: Text let fileToShare: TextFile let messageToPreview: String var body: some View { ShareLink(item: self.fileToShare, preview: SharePreview(self.messageToPreview)) } } struct TextFile: Transferable { let content: String let filename: String static var transferRepresentation: some TransferRepresentation { FileRepresentation(exportedContentType: .data) { textFile in let data = textFile.content.data(using: .utf8) ?? Data() let tempDirectory = FileManager.default.temporaryDirectory let fileURL = tempDirectory.appendingPathComponent(textFile.filename) try data.write(to: fileURL) return SentTransferredFile(fileURL) } } } The development environment is as follows. Xcode 15.4 (Deployment Target = iOS Deployment Target 17.5) macOS 14.6.1 The execution environment is as follows. iPhone SE Gen3 17.7 The following is a console log from the time the application was launched to the time when the share sheet was displayed by tapping [Share...]. Error acquiring assertion: &lt;Error Domain=RBSServiceErrorDomain Code=1 "(originator doesn't have entitlement com.apple.runningboard.primitiveattribute AND originator doesn't have entitlement com.apple.runningboard.assertions.frontboard AND target is not running or doesn't have entitlement com.apple.runningboard.trustedtarget AND Target not hosted by originator)" UserInfo={NSLocalizedFailureReason=(originator doesn't have entitlement com.apple.runningboard.primitiveattribute AND originator doesn't have entitlement com.apple.runningboard.assertions.frontboard AND target is not running or doesn't have entitlement com.apple.runningboard.trustedtarget AND Target not hosted by originator)}&gt; (501) personaAttributesForPersonaType for type:0 failed with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: failed at lookup with error 159 - Sandbox restriction.} Received port for identifier response: &lt;(null)&gt; with error:Error Domain=RBSServiceErrorDomain Code=1 "Client not entitled" UserInfo={RBSEntitlement=com.apple.runningboard.process-state, NSLocalizedFailureReason=Client not entitled, RBSPermanent=false} elapsedCPUTimeForFrontBoard couldn't generate a task port Received port for identifier response: &lt;(null)&gt; with error:Error Domain=RBSServiceErrorDomain Code=1 "Client not entitled" UserInfo={RBSEntitlement=com.apple.runningboard.process-state, NSLocalizedFailureReason=Client not entitled, RBSPermanent=false} elapsedCPUTimeForFrontBoard couldn't generate a task port Received port for identifier response: &lt;(null)&gt; with error:Error Domain=RBSServiceErrorDomain Code=1 "Client not entitled" UserInfo={RBSEntitlement=com.apple.runningboard.process-state, NSLocalizedFailureReason=Client not entitled, RBSPermanent=false} elapsedCPUTimeForFrontBoard couldn't generate a task port The following is the console log that was written when I tapped [Save to file] on the share sheet. cancelled request - error: The operation couldn’t be completed. Invalid argument What modifications should I make to the code to get the expected result?