My iPadOS app can open .xml files. In my XMLApp.swift, I hooked up a: var body: some Scene { WindowGroup(id: "main") { .commands CommandGroup(replacing: .newItem) { ... Button(.openDot) { openXMLFile() } ... Next, I entered a new UTImportedTypeDeclarations / UTExportedTypeDeclarations in Project Settings -> Target -> Info -> Document Types, Exported Type Identifiers, Imported Type Identifiers, for the XML file-type: ... <key>UTImportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.data</string> <string>public.xml</string> <string>public.content</string> </array> ... As soon as I do that, Xcode creates an additional Open... menu entry all the way at the bottom of the File menu. I cannot get rid of this additional menu entry. Its state is disabled (grayed out). I have my own Open (per the code above), which also responds to ⌘ - O. My menu entry works fine, as long as I disable the same keyboard shortcut so they don't collide. The extra Open entry is also displayed on the matching iPadOS simulator. From the same codebase, the Open is not displayed on the Mac (targeting macOS, not Catalyst). On macOS, only my Open is in the File menu, as expected. Why is there a duplicate Open menu entry and how do I get rid of it?

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?

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'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") } }

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) {