Hello, I don't understand what is /System/Applications/ folder (macOS Sonoma). It is not an (hard)link to /Applications/. /Applications/ is not a (hard)link to /System/Applications/ Can anyone explain me what is /System/Applications/ ? Isn't it redundant to /Applications/ ? Thanks

Our updating process is a launchd daemon that will download zipped bundle directories that contain resources to be used for updating. One of the bundles is an app that has a tool that is executed to perform the updating after all of the bundles have been downloaded. We are finding that on Sonoma starting in version 14.1 the zip extraction of the bundle containing the executable now is blocked on about 1 in 7 computers when the bundle directory itself is being created. <redacted>Updater <subsystem> Error during Extract state: Error Domain=<our error domain> Code=2001 "filesystem error: in create_directories: Operation not permitted ["/Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle"]" UserInfo={NSLocalizedDescription=filesystem error: in create_directories: Operation not permitted ["/Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle"]} We have seen the following error just preceding the above on some of these failures: <date> Error 0x45c755 184 0 sandboxd: tcc_server_message_request_authorization(kTCCServiceSystemPolicyAppBundles) failed: Error Domain=kTCCErrorDomain Code=2 "missing 'auth_value' in reply message" UserInfo={NSDescription=missing 'auth_value' in reply message} <date> Error 0x0 184 0 sandboxd: [com.apple.sandbox.reporting:violation] System Policy: <redacted>Updater(1431) deny(1) file-write-create /Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle Violation: deny(1) file-write-create /Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle I believe that the kTCCServiceSystemPolicyAppBundles failure occurs because TCC has determined that our Updater does not have permission to modify the Installer.bundle. Both the Updater and Installer.bundle have been signed by the same Apple Developer certificate (with the same team id). The Updater has been using this same procedure successfully but starts failing after the update to Sonoma v14.1. When this failure occurs, the updater has been able to extract the other resource-only bundles (no executables) that precede it. Computers that have this failure show the updater in the System Settings > Privacy & Security > Full Disk Access list as disabled. The computers that do not see this failure, do not have the updater listed in Full Disk Access. This has been raised as Feedback #FB13359407 What is the recommended way that an updater is supposed to create a new copy of an application without running into these TCC errors? Would extracting the app bundle as a directory without the .bundle extension and then renaming the directory to add the .bundle extension be a reasonable approach? BTW: The above approach does seem to work on Sonoma v 14.1 At what point does an app become subject to kTCCServiceSystemPolicyAppBundles? Is it is just a directory with a .app or .bundle extension or when a bundle structure exists that a signing check can validate?

Hello, I know this is not a good practice but i want to make a test. I would like to write a file into /System folder on macOS Sonoma. I have tried to reboot in recovery mode. I have disabled SIP. But i can't write into /System. This folder is mounted as read only. How can i write into this folder ? I know there is a kind of checksum mechanism to check if something has been modified in /System folder and i want to see what happens if this checksum does not match. Thanks

On a real iOS device, I am unable to write data to overwrite a file in my bundle. I am getting an error You don't have permission to save the file "CU_config.js" in folder "2023". Here is the code that tries to write the file. func configure() { let picker = UIDocumentPickerViewController(forOpeningContentTypes: [.javaScript], asCopy: true) picker.delegate = self present(picker, animated: true) } func documentPicker(_ controller: UIDocumentPickerViewController, didPickDocumentsAt urls: [URL]) { controller.dismiss(animated: true, completion: nil) urls.forEach { url in let sourceURL:URL if(isMatch){ sourceURL = Bundle.main.bundleURL.appendingPathComponent("www/2023/CU_config").appendingPathExtension("js") }else{ sourceURL = Bundle.main.bundleURL.appendingPathComponent("www/2023/CU_Pit_config").appendingPathExtension("js") } let destURL = url let incoming:Data? do { incoming = try Data(contentsOf: destURL) }catch{ incoming = nil print("Unable to find file") let alert = UIAlertController(title: "Error", message: "Unable to find file", preferredStyle: UIAlertController.Style.alert) alert.addAction(UIAlertAction(title: "Ok", style: UIAlertAction.Style.default, handler: nil)) self.present(alert, animated: true, completion: nil) } do { sourceURL.startAccessingSecurityScopedResource() try incoming!.write(to: sourceURL) sourceURL.stopAccessingSecurityScopedResource() }catch{ let alert = UIAlertController(title: "Error", message: "Unable to write file"+error.localizedDescription, preferredStyle: UIAlertController.Style.alert) alert.addAction(UIAlertAction(title: "Ok", style: UIAlertAction.Style.default, handler: nil)) self.present(alert, animated: true, completion: nil) print("Unable to write file") } webview.reload() } } I tried giving it permission in the info.plist by using "Application supports iTunes file sharing" but that didn't work. It works perfectly in simulation.

Hello! I'm in the process of creating an app for iOS. A part of the app relies on data that is collected as the user uses the app. This data is then stored in a .CSV file for easy storage, retrieval, and a small size even if it grows larger than expected. The data is really simple and easy to traverse, however it won't be stored on a remote database, and only locally on the user's device. I've read that updating the app doesn't overwrite the data of the current version, but instead places the new version of the app in a new directory entirely while the other, older version is then deleted. Is it possible to mark certain files to be transferred and not replaced entirely? I'd like to know if it's possible or not before I make the mistake and learn the hard way 😅 Also I'm open to any alternative ways to store such data that people may suggest! Thanks a lot in advance! Help is much appreciated Jack

hi,i want to create a NSFileProviderExtension , need add file for storage, but, i create a folder, xocde show a error : [ERROR] List of user interactions is not an array

I am using UIDocumentPickerViewController for transferring folder in export mode. The transferring of folder is working on selected folders. Now I want to restrict some target folders. But didPickDocumentsAtURLs is getting called after actual transfer. Any idea how can we restrict it?

I have a problem with Xcode version 15.0.1: I have programmed a DocumentPicker in Swift UI to load a document from my own cloud into the app. When I run the app, it works fantastic with the simulator, but it doesn't work with my device. I always get the following error message: file is not reachable. Ensure file URL is not a directory, symbolic link, or invalid url. As I said, when I run the code in the simulator, it works fine. I am using IOS 17.2 Here is the code. import SwiftUI import MobileCoreServices import Firebase import FirebaseStorage import CoreData import UniformTypeIdentifiers struct DocumentPickerView: UIViewControllerRepresentable { @Binding var fileContent : String @Binding var nameContent : String @Binding var showqr : Bool @Binding var documentURL: URL? @Binding var alert: Bool // @Binding var webViewURL : URL func makeCoordinator() -> Coordinator { Coordinator(self) } func makeUIViewController(context: Context) -> UIDocumentPickerViewController { // let picker = UIDocumentPickerViewController(documentTypes: ["public.item"], in: .import) let types: [UTType] = [UTType.content] let picker = UIDocumentPickerViewController(forOpeningContentTypes:types) picker.allowsMultipleSelection = false picker.delegate = context.coordinator return picker } func updateUIViewController(_ uiViewController: UIDocumentPickerViewController, context: Context) {} class Coordinator: NSObject, UIDocumentPickerDelegate { var parent: DocumentPickerView init(_ parent: DocumentPickerView) { self.parent = parent } func documentPicker(_ controller: UIDocumentPickerViewController, didPickDocumentsAt urls: [URL]) { if let selectedURL = urls.first { parent.documentURL = selectedURL parent.uploadToFirebase(selectedURL) } } } func uploadToFirebase(_ fileURL: URL) { let storage = Storage.storage() let storageRef = storage.reference() let fileRef = storageRef.child(fileURL.lastPathComponent) // if FileManager.default.fileExists(atPath: fileURL.path){ // print("File Existiert:\(fileURL)") // } else { // print("File Existiert nicht") // } _ = fileRef.putFile(from: fileURL, metadata: nil){ (metadata, error) in if let error = error { print("Fehler beim Hochladen der Datei: \(error.localizedDescription)") } else { print("Datei erfolgreich hochgeladen!") // Rufen Sie die Download-URL für die hochgeladene Datei ab fileRef.downloadURL { (url, error) in if let error = error { alert = true print("Fehler beim Abrufen der Download-URL: \(error.localizedDescription)") } else { if let downloadURL = url { print("Download-URL: \(downloadURL)") self.fileContent = "\(downloadURL)" self.showqr = true } } } } } } }

It seems that whenever I scan the contents of ~/Library/Containers with my app, I get the warning [App] would like to access data from other apps, regardless of how often I have already allowed it. When the warning appears, the last scanned file is ~/Library/Containers/com.apple.CloudPhotosConfiguration/Data. My sample code: let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.runModal() let url = openPanel.urls[0] let enumerator = FileManager.default.enumerator(at: url, includingPropertiesForKeys: nil) while let url = enumerator?.nextObject() as? URL { print(url.path) } Is it expected that one has to allow this warning every time the app is run?

Why is it that I can open a symbolic link, but can't read it? I am aware that I can get the contents of a symlink file using the readlink function, but still, it seems like this ought to work. Here's example code: #include <iostream> #include <unistd.h> #include <fcntl.h> int main(int argc, const char * argv[]) { // Make sure there is not already a file where we will create the link unlink( "/tmp/ReadSymLink-test" ); // Create a symlink int result = symlink( "../usr", "/tmp/ReadSymLink-test"); int err; if (result == 0) { std::cout << "created file /tmp/ReadSymLink-test\n"; } else { err = errno; std::cerr << "symlink failed with error " << err << "\n"; return 1; } // Open it for reading int fd = open( "/tmp/ReadSymLink-test", O_RDONLY | O_SYMLINK ); if (fd < 0) { err = errno; std::cerr << "open failed with error " << err << "\n"; return 2; } std::cout << "open succeeded\n"; // and read it char buffer[200]; ssize_t bytesRead = read( fd, buffer, sizeof(buffer) ); if (bytesRead < 0) { err = errno; std::cerr << "read failed with error " << err << "\n"; return 2; } else { buffer[ bytesRead ] = '\0'; std::cout << "read of symlink result: " << buffer << "\n"; } return 0; } The result, running under Sonoma 14.2 (beta) is created file /tmp/ReadSymLink-test open succeeded read failed with error 1

After updating from MacOS 14.0 to 14.1 we got permission errors within an app we developed. We got an "operation not permitted" error if the app tries to access files on a samba network share which is mounted by another tool. Additionally, we got a "Permission denied" if the app tries to run programs outside the app, for example /usr/local/bin/ip. The app works fine on Catalina, Big Sur, Monterey, Ventura and Sonoma 14.0. The app and its components are codesigned and the app is notarized, no entitlements. In the Info.plist the NSNetworkVolumesUsageDescription key is set. Any ideas? Could it be that the app is sandboxed by default on MacOS 14.1? And we have to disable sandboxing via entitlement? Thanks for any input!

Context I'm using https://github.com/stephencelis/SQLite.swift as the access layer for interacting with SQLite databases. For each database I maintain a long running connection. As reading the schema is done lazily on each connection and can be expensive I prefer to open the connection once, do a number of operations and then close the connection when it is not needed any more (and given that the app is a GUI for working with SQLite databases, long running means long running). E.g. func open(url: URL, options: ...) func commitCurrentTransaction() throws func rollbackCurrentTransaction() throws func executeStatements(rawSQL: RawSQL, executeMode: ExecuteMode) async throws -&gt; SQLOperationResult ... func close() To be a good citizen on the Mac I'm looking to use the NSFileCoordinator to indicate read and write operations on the SQLite database files the application is using. I'm thinking of wrapping each operation that might result in a file access with the corresponding coordinate(readingItemAt: ... and coordinate(writingItemAt: ... calls. But the API documentation states that the last argument, the block byAccessor should use the given URL: A Block object containing the file operations you want to perform in a coordinated manner. This block receives an NSURL object containing the URL of the item and returns no value. Always use the URL passed into the block instead of the value in the url parameter. In my case, the URL is used once when opening the connection but not afterwards so I'd be ignoring the URL passed to the block. The examples I have found for using the NSFileCoordinator seem to follow a different pattern, where the entire operation on the file happens within the block of the coordinate method. Questions What is the correct way of using NSFileCoordinator in a case like this where there essentially is a long live file handle in use? The application does work without using the NSFileCoordinator. What is the ramification of not using the NSFileCoordinator in this case?

Context I'm using the NSFileCoordinator &amp; NSFilePresenter in a sandboxed application to access SQLite database files and their secondary files (e.g. WAL or journal files) as per https://developer.apple.com/documentation/foundation/nsfilepresenter/1415415-primarypresenteditemurl E.g. something similar to this: var presenters: [NSFilePresenter] = ["wal", "journal", "shm"].map { ext in let presenter = SQLiteTempFilePresenter(databaseId: databaseContext.id, sqliteMainFile: url, newExt: ext) // addFilePresenter needs to be balanced with a `removeFilePresenter`. See SQLiteTempFilePresenter#deinit NSFileCoordinator.addFilePresenter(presenter) return presenter } That way there will be a NSFilePresenter for each possible secondary SQLite file (e.g. with the main file being foo/bar/database.sqlite there will be presenter for each of the secondary files foo/bar/database.sqlite-shm and foo/bar/database.sqlite-wal) Using NSFilePresenter to work with SQLite files within the Sandbox environment works as expected. Desired change I'd like to expand the usage of NSFileCoordinator to react to changes to the SQLite files that happen outside of the application. To achieve that I added an additional NSFilePresenter for the main file (e.g. foo/bar/database.sqlite) that has a func presentedItemDidChange() method. That method does get called when I change the corresponding SQLite file (e.g. by using the sqlite3 command line tool). So far so good. But in WAL mode (https://www.sqlite.org/wal.html), changes to the SQLite file don't immediately change the file itself but get written to the write-ahead-log first (e.g. foo/bar/database.sqlite-wal in this example). Only when the outside connection is closed, will the changes be committed to the main SQLite file itself. At which point the NSFilePresenter#presentedItemDidChange() method will be called. So I also like to be notified when the secondary files change. Adding a presentedItemDidChange() callback method to the SQLiteTempFilePresenter instances for the secondary files does not seem to work, the method never gets called even though the corresponding secondary files change. Questions If I add another instance of the NSFilePresenter for each of the secondary files, the callback presentedItemDidChange() gets called for the secondary files as well. Having two different instance of the NSFilePresenter for a single URL (one for sandboxing purposes, the other for being notified of file changes) seems a bit fishy though. Is that the intended (or at least an acceptable) way of using NSFilePresenter? The documentation for NSFilePresenter states that "If another process uses a file coordinator for the same file or directory, your presenter objects are similarly notified whenever the other process makes its changes." I do get notified though when using the sqlite3 command line tool which does not use a NSFileCoordinator. Is there any documentation that explains that behaviour? I mean it's great that it seems to work but I'd like to understand why.

How often/ under what circumstances are users sandbox directory URL's changed? So I tried to save a URL to a document in @AppStorage @AppStorage(DefaultsKey.userActiveBook.rawValue) var activeBook : URL = Bundle.main.url(forResource: "BookPlaceHolder", withExtension: "pdf")! When user selects a new document activeBook is updated with the new URL. Issue is when the app relaunches from xCode the path to whatever is stored in activeBook changes. My work around so far is to just access the users Documents Directory via FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!. Then appending the last path component of activeBook. sidebar: obviously this doesn't work if the saved URL in activeBook is still the default from Bundle.main.url. I haven't written that workaround as yet. Am I only seeing issues in development due to a fresh relaunch via xCode? If the user only ever terminates the app on their device are the .documentDirectory URL's changing on each launch or do the remain constant? I don't want to write a workaround to ensure the correct URL for whats stored in @AppStorage, if the changing URL's only occurs due to launching from xCode which the end user wont ever encounter that edge case.

2 versions 1 works 1 doesn't. UIViewRepresentable to show a PDF @AppStorage(DefaultsKey.userActiveBook.rawValue) var activeBook : URL = Bundle.main.url(forResource: "BookPlaceHolder", withExtension: "pdf")! func makeUIView(context: Context) -&gt; PDFView { do { let pdfData = try Data(contentsOf: activeBook) pdfView.document = PDFDocument(data: pdfData) //&lt;---- is nil ... } catch let Error { print(Error) } } fails with Error Domain=NSCocoaErrorDomain Code=260 "The file “BookPlaceHolder.pdf” couldn’t be opened because there is no such file." func makeUIView(context: Context) -&gt; PDFView { do { let pdfData = try Data(contentsOf: Bundle.main.url(forResource: "BookPlaceHolder", withExtension: "pdf")!) pdfView.document = PDFDocument(data: pdfData) ... } catch let Error { print(Error) } } Works perfectly. What is it with using @AppStorage to access the exact same URL causing the discrepancies ?

Hello. I'm experiencing some issues with my iOS application. We distribute our app through an enterprise plan, and our app is almost 8 years old. We've noticed that on iOS 17 devices, our UserDefaults files are not being saved in the Preferences folder. I've conducted research on this issue, and everywhere I looked, it indicated that the system should handle this saving process. Does anyone know what changes have been made in iOS 17 that prevent us from saving data in UserDefaults? I've tested it with a new app, and it worked perfectly fine. Below are screenshots of the 'Preferences' folder on iOS 17 and 16.

Hello, I am trying to create a dmg file by launching hdiutil through my swift program. This swift program is sandboxed. Here is what i've done: let hdd_file:String = NSHomeDirectory() + "hdd.dmg.sparseimage" let process = Process() process.launchPath = "/usr/bin/hdiutil" process.arguments = ["create", "-size", "30g", "-fs", "'APFS'", "-volname", "myvolume", "-type", "SPARSE", hdd_file] let pipe = Pipe() process.standardOutput = pipe process.launch() let data = try pipe.fileHandleForReading.readToEnd() print(data) I get this error: hdiutil: create failed - Device not configured I don't understand why i get this error because the dmg file is created in application's sandbox home directory. Or maybe hdiutil is forbidden but i am just creating a dmg file. I am not trying to mount a device. Do you have any idea of how i can create a dmg file from my sandboxed application ? Thanks

I can't anymore check SMB credentials on macOS. Sonoma stops checking them after first successful validation. No matter which way to go, it could be smbutil, mount_smbfs, or even the NetFSMountURLSync function from the NetFS framework. Below is a script that works fine on Ventura, but would fail on Sonoma. There are three smbutil calls. The first call includes the correct username and password, the second omits the password, the third goes with an incorrect password. On Ventura and earlier the second and third calls fail, but Sonoma feels okay. The same could be seen with mount_smb. Is it a normal behavior? Is there a way to check credentials on Sonoma? #!/bin/bash # SMB server or its ip address SERVER="127.0.0.1" RESOURCE="Test" # username and password to authenticate on the server USER_NAME="username" USER_PASSWORD="password" # path to mount server resource MOUNT_POINT="/tmp/1" function Raise { echo "!!! ERROR: $1" exit 1 } /usr/bin/smbutil view -ANf "//${USER_NAME}:${USER_PASSWORD}@${SERVER}" || Raise "Unable to browse shares with credentials" /usr/bin/smbutil view -ANf "//${USER_NAME}:@${SERVER}" &amp;&amp; Raise "Successfully browsed shares without password" /usr/bin/smbutil view -ANf "//${USER_NAME}:foobar@${SERVER}" &amp;&amp; Raise "Successfully browsed shares with incorrect password" mkdir -p "/tmp/1" mount_smbfs -s "//${USER_NAME}:${USER_PASSWORD}@${SERVER}/${RESOURCE}" "/tmp/1" || Raise "Unable to mount share with credentials" diskutil unmount "/tmp/1" mkdir -p "/tmp/1" mount_smbfs -s "//${USER_NAME}:foobar@${SERVER}/${RESOURCE}" "/tmp/1" &amp;&amp; Raise "Successfully mounted with incorrect password" diskutil unmount "/tmp/1"

I'm converting some code that reads a file's ACLs and I'm having a hard time with acl_free crashing. There is clearly something that I am not understanding. // --- Do we have access control lists? let fileSecurity = properties.fileSecurity var accessList: acl_t? if CFFileSecurityCopyAccessControlList( fileSecurity, &amp;accessList ) { print( "We have access control lists" ) acl_free( &amp;accessList ) } The line acl_free( &amp;accessList ) crashes with the following. malloc: *** error for object 0x16d28ac40: pointer being freed was not allocated In the debugger I can see that accessList points to an object. "accessList = acl_t? 0x000000015b00ea00" I notice that the crash report ptr ref is different to what Xcode is showing in the debugger. Also worth noting, is CFFileSecurityCopyAccessControlList takes a "UnsafeMutablePointer&lt;acl_t?&gt;!" While acl_free takes a "void *obj_p" Can anyone please give me a ptr as to what I am doing wrong? 16" MacBook Pro M2 Pro with Ventura 13.5 running Xcode 15.0

I am trying to open a document from inside my application with word using the UIDocumentInteractionController. The document opens but the document opens in Read/Only. It provides me with an option to "Save Copy" . This is only happening in iOS 17. iPadOS and iOS. This works 100% on iOS 16 so the issue was introduced with the new version of ios 17. `documentController = UIDocumentInteractionController.FromUrl(NSUrl.FromFilename(filePath)); string fileExtension = Path.GetExtension(sharedPath.FileName).Substring(1); string uti = MobileCoreServices.UTType.CreatePreferredIdentifier(MobileCoreServices.UTType.TagClassFilenameExtension.ToString(), fileExtension, null); documentController.Uti = uti; UIView presentingView = UIApplication.SharedApplication.KeyWindow.RootViewController.View; documentController.PresentOpenInMenu(CGRect.Empty, presentingView, true);` info.Plist UIFileSharingEnabled LSSupportsOpeningDocumentsInPlace UISupportsDocumentBrowser Is there perhaps something that changed that is not documented. It seems that some sort of security issue that has changed with how my app and word is allowed to access the file inside my app folder. I have logged multiple questions on other platforms but no luck.