These days I've observed a strange behavior in my document-based app on macOS: Its NSDocument class implementation is overwriting "saveToURL:ofType:forSaveOperation:completionHandler:", performing some additional checks and calling super by passing the original parameters. As my app is supporting various file formats for writing (and exporting those UTIs) the user can open a file in one format and save it to another. NSDocument is calling the mentioned methods implicitly after completing the "Save as..." dialog. If this happens, the passed-on fileType is still the one of format #1, although the file is saved with the file name extension of format #2. This hick-up is not directly obvious to the user. But if the file is re-saved (e.g. after modifications), Cocoa is trying to extend the sandbox for the URL of type #1, and fails with the following error message at the Xcode console: -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 521] typeName: com.janome.jef -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 523] targetTypeUTI: com.tajima.dst NSFileSandboxingRequestRelatedItemExtension: Failed to issue extension for /Users/matthias/Desktop/Ohne Titel.jef because: Error Domain=NSPOSIXErrorDomain Code=3 "No such process" -[NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/matthias/Desktop/Ohne%20Titel.dst, newURL: file:///Users/matthias/Desktop/Ohne%20Titel.jef I'm currently fixing this issue by determining the UTType for the new file name extension and passing it to super. Unfortunately I have no idea how long this issue was already present, and cannot replicate it with a sample app based on Apple's Xcode 26 template (too many differences to my >15 years old app) - so I won't file a bug report. Take this post just for information in case someone else is facing a similar situation...

I need to open p12 file from other iOS applications to import private key to my application. My app is set up to be able to open nay file with following plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeName</key> <string>Files</string> <key>LSHandlerRank</key> <string>Default</string> <key>LSItemContentTypes</key> <array> <string>public.item</string> <string>public.data</string> <string>public.content</string> </array> </dict> </array> </dict> </plist> But my don't appear in share dialog from Files or Mail app for example. There are however other third party apps that can accept this file. Some of them use Share extension which I don't have, but some of them don't have it as far as I can understand. At least they don't present any UI and open apps directly. Also I've tried to specify com.rsa.pkcs-12 UTI directly but it didn't help. Also noticed that *.crt files have similar behaviour. Am I missing something about this specific file type?

I have a minimal macOS document based app written in SwiftUI in Xcode 16.3. It is created from the standard template replacing all occurences of 'com.example.plain-text' with 'com.topografix.gpx' and changing the file extension in info.plist from 'exampletext' to 'gpx'. Those changes are sufficient to allow opening, editing and saving of .gpx files. However, when opening, editing or saving, the following message is written to the console 6 times. Unexpected bundle class 16 declaring type public.gpx While this is not preventing the app from working, I would like to understand the origin of the message and fix the underlying problem.

Hello, I have an existing AUv3 instrument plugin. In the plug in, users can access files (audio files, song projects) via a UIDocumentPickerViewController In Logic Pro, (and some other hosts, but not all), the document picker is unable to receive touches, while a keyboard case is attached to the iPad. Removing the case (this is an Apple brand iPad case) allows the interactions to resume and allows me to pick files in the usual way. One of my users reports this non-responsive behavior occurs even after disconnecting their keyboard. I have fiddled with entitlements all day, and have determined that is not the issue, since the keyboard disconnection appears to fix it every time for me. Here is my, very boilerplate, presentation code : guard let type = UTType("com.my.type") else { return } let fileBrowser = UIDocumentPickerViewController(forOpeningContentTypes: [type]) fileBrowser.overrideUserInterfaceStyle = .dark fileBrowser.delegate = self fileBrowser.directoryURL = myFileFolderURL() self.present(fileBrowser, animated: true) {

I'm working on an iOS document-based app. It uses ReferenceFileDocument and custom creation of documents via DocumentGroupLaunchScene + NewDocumentButton. It works fine when I use the plain NewDocumentButton("Whatever") (without any more arguments), but when I want to perform additional setup via preapreDocumentURL or even just add a contentType it gives such output in the console when I hit it: Content serialization failed, document won't be saved. UTType.replayable is correctly wired up in the plist. It looks like a bug in the SDK, but maybe there is a chance that I'm doing something wrong? Here's a code: import SwiftUI import UniformTypeIdentifiers import Combine @main struct MyApp: App { var body: some Scene { DocumentGroup { Document() } editor: { documentConfiguration in EmptyView() } DocumentGroupLaunchScene("Yoyo") { NewDocumentButton(contentType: .replayable) { return URL(string: "whatever, it doesnt even go there...")! } } } } final class Document: ReferenceFileDocument { static var readableContentTypes: [UTType] { [.replayable] } @Published var x = 0 init() {} init(configuration: ReadConfiguration) throws {} func snapshot(contentType: UTType) throws -> Data { Data() } func fileWrapper(snapshot: Data, configuration: WriteConfiguration) throws -> FileWrapper { .init(regularFileWithContents: snapshot) } } extension UTType { static var replayable: UTType { UTType(exportedAs: "com.whatever.yo") } }

Logic Pro recently changed the way it accepts drag and drop. If the ItemProvider contains UTType.midi, then Logic Pro shows visual feedback for the drop operation, but when the item is dropped, nothing happens. In the past, drag-and-drop used to work. With today's version (Logic Pro 11.2), the only way I was able to successfully drop MIDI was to provide UTType.fileURL and no other data types. But that's not a viable solution; I need other data types to be included too. As a side note, I tested with Ableton Live 12 and it works with no issue. Is this a bug in Logic Pro? What ItemProvider structure does Logic Pro expect to correctly receive the MIDI data?

On iOS:When one receives a file of type .pages by email, Mail displays a large Pages icon and tapping on it opens Pages. (A long-press brings up the more complicated Actions screen).When one receives a file of type .vcf by email, Mail displays a large Contacts icon and tapping on it opens Contacts. (A long-press brings up the more complicated Actions screen).I have my own custom file type, .ripf, and I want to have the same behaviour because that is what my users will expect. Accordingly, in my app's Info.plist I have a CFBundleDocumentTypes dictionary providing a one-element LSItemContentTypes array referring to the name 'com.universalis.ripcard', and a UTExportedTypeDeclarations dictionary associating the UTTypeIdentifier 'com.universalis.ripcard' with a public.filename-extension 'ripf' and a public.mime-type 'text/vnd.universalis.ripcard'. All the other entries in those two dictionaries are present and correct as far as I can tell. Both CFBundleDocumentTypes[0].CFBundleTypeIconFiles and UTExportedTypeDeclarations[0].UTTypeIconFiles contain a list of icon files for the file type.(That rather long paragraph is to avoid boring people by including the entire Info.plist!)Some things do work..ripf files received via AirDrop bring up a suitable "Open with..." message which mentions my app, and tapping the message opens the app..ripf files received as an email attachment display as an icon. But it is the app's icon and not the icon of the file type.BUTTapping on a received file's icon does not open the app, but only opens the generic Actions screen, offering Message, Mail, WhatsApp, Notes, and only then (after the user has scrolled sideways) "Copy to..." my app.Now, the whole apparatus of CFBundleDocumentTypes and UTExportedTypeDeclarations is obscure and under-documented, and indeed the main documenation for the latter has a big warning at the top saying that it is obsolete and not being updated. That doesn't matter so much. What I need to know is:(Less important): How do I get the right file icon?(More important): How do I get my app to open when the icon is tapped, as Pages and Contacts do? There must be a way – unless special cases for those two apps are wired into iOS itself.