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?

Hello, guys. I am going through a situation in which an open validation appears in the system/developer mode and I would like to understand better if this is something normal in this process. Could someone confirm if this type of validation is expected at this stage? I would also like to know what criteria I can observe to be sure that it is legitimate and that I can trust the activation. Thank you in advance for your attention and help. Thank you

Some Apple URL schemes are documented for third-party use. It’s fine to use those URL schemes for their intended purpose. Other Apple URL schemes are not officially documented. Their use is unsupported. If you rely on such implementation details, things might work, or they might not, and that state might change over time. IMPORTANT If you ship via the App Store, pay attention to clause 2.5.1 of the App Review Guidelines. The Apple URL scheme documentation is not always easy to find. I’m aware of the following: Apple URL Scheme Reference QA1924 Opening Keyboard Settings from a Keyboard Extension [This Q&A was retired years ago.] Preparing your app to be the default messaging app The doc comments for es_new_client in <EndpointSecurity/ESClient.h> Developer > Bug Reporting describes the applefeedback scheme Additionally, as questions about this most commonly crop up in the context of opening Settings (System Settings on macOS), I wanted to highlight the following: UIApplication.openSettingsURLString property (in Objective-C this is UIApplicationOpenSettingsURLString) UIApplication.openNotificationSettingsURLString property (in Objective-C this is UIApplicationOpenNotificationSettingsURLString) UIApplication.openDefaultApplicationsSettingsURLString property (in Objective-C this is UIApplicationOpenDefaultApplicationsSettingsURLString) AccessibilitySettings.openSettings(for:) method FIFinderSyncController.showExtensionManagementInterface() class method SMAppService.openSystemSettingsLoginItems() class method VSOpenTVProviderSettingsURLString global CXCallDirectoryManager.openSettings(completionHandler:) method SFSafariSettings.openExportBrowsingDataSettings() method SFSafariSettings.openExtensionsSettings(forIdentifiers:) method If your app needs to perform some action that’s not covered by the above, file an enhancement request for a supported way to do that. Make sure to describes your use case in detail. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2026-01-07 Added a reference to the SFSafariSettings methods. 2025-10-28 Added a reference to UIApplication.openDefaultApplicationsSettingsURLString. Made other minor editorial changes. 2025-04-21 Added a reference to CXCallDirectoryManager.openSettings(completionHandler:). 2024-10-25 Added a reference to UIApplication.openNotificationSettingsURLString and VSOpenTVProviderSettingsURLString. Added a link to Preparing your app to be the default messaging app. 2024-10-01 Added info about the applefeedback URL scheme. 2024-09-29 Added a reference to SMAppService.openSystemSettingsLoginItems(). 2024-09-27 Added a titbit for Finder Sync extension developers. Added an invitation to file feedback. 2024-08-05 First posted.

We have a simple function that retrieves users list via CSIdentityQueryCreate() and CSIdentityQueryExecute(). However, sometimes we get crashes in "com.apple.opendirectory.odxpc.xpc" queue and address sanitizer reports that something inside opendirectory related framework tries to access data that was released: ==327==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000166890010 at pc 0x000109b51f98 bp 0x00016b6f58d0 sp 0x00016b6f5070 READ of size 5 at 0x000166890010 thread T242 #0 0x000109b51f94 in memcpy+0x294 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x85f94) #1 0x000191c08e64 in __CFStringCreateImmutableFunnel3+0x4f8 (CoreFoundation:arm64e+0x2e64) #2 0x000191d2494c in ____CFBinaryPlistCreateObjectFiltered_block_invoke+0xa4 (CoreFoundation:arm64e+0x11e94c) #3 0x000191c39fc8 in __CFBinaryPlistCreateObjectFiltered+0x698 (CoreFoundation:arm64e+0x33fc8) #4 0x000191c3aff0 in __CFBinaryPlistCreateObjectFiltered+0x16c0 (CoreFoundation:arm64e+0x34ff0) #5 0x000191c20b98 in __CFTryParseBinaryPlist+0xe8 (CoreFoundation:arm64e+0x1ab98) #6 0x000191d11e14 in _CFPropertyListCreateWithData+0x98 (CoreFoundation:arm64e+0x10be14) #7 0x000191c20a2c in CFPropertyListCreateWithData+0x38 (CoreFoundation:arm64e+0x1aa2c) #8 0x00019b3a49d0 in ___odxpc_create_connection_block_invoke+0x104 (CFOpenDirectory:arm64e+0x29d0) #9 0x00019189e82c in _xpc_connection_call_event_handler+0x6c (libxpc.dylib:arm64e+0xe82c) #10 0x00019189d128 in _xpc_connection_mach_event+0x4a8 (libxpc.dylib:arm64e+0xd128) #11 0x0001919f98a0 in _dispatch_client_callout4+0xc (libdispatch.dylib:arm64e+0x1b8a0) #12 0x0001919fc10c in _dispatch_mach_msg_invoke+0x1cc (libdispatch.dylib:arm64e+0x1e10c) #13 0x0001919e81b4 in _dispatch_lane_serial_drain+0x148 (libdispatch.dylib:arm64e+0xa1b4) #14 0x0001919fce70 in _dispatch_mach_invoke+0x1d4 (libdispatch.dylib:arm64e+0x1ee70) #15 0x0001919e81b4 in _dispatch_lane_serial_drain+0x148 (libdispatch.dylib:arm64e+0xa1b4) #16 0x0001919e8e28 in _dispatch_lane_invoke+0x180 (libdispatch.dylib:arm64e+0xae28) #17 0x0001919f3260 in _dispatch_root_queue_drain_deferred_wlh+0x120 (libdispatch.dylib:arm64e+0x15260) #18 0x0001919f2ae4 in _dispatch_workloop_worker_thread+0x218 (libdispatch.dylib:arm64e+0x14ae4) #19 0x000191b93e1c in _pthread_wqthread+0x120 (libsystem_pthread.dylib:arm64e+0x2e1c) #20 0x000191b92b70 in start_wqthread+0x4 (libsystem_pthread.dylib:arm64e+0x1b70) 0x000166890010 is located 10946 bytes after 789838-byte region [0x0001667cc800,0x00016688d54e) freed by thread T240 here: #0 0x000109b09480 in free+0x7c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3d480) #1 0x000191c25ca8 in __CFDataDeallocate+0x5c (CoreFoundation:arm64e+0x1fca8) #2 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #3 0x00019f8e4540 in DSIdentity::~DSIdentity()+0x80 (OSServices:arm64e+0xe540) #4 0x00019f8e45ec in DSUserIdentity::~DSUserIdentity()+0xc (OSServices:arm64e+0xe5ec) #5 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #6 0x000191c21b28 in __CFBasicHashDrain+0x1a8 (CoreFoundation:arm64e+0x1bb28) #7 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #8 0x00019f8ec1bc in DSIdentityQuery::~DSIdentityQuery()+0x88 (OSServices:arm64e+0x161bc) #9 0x00019f8ec220 in DSIdentityQuery::~DSIdentityQuery()+0xc (OSServices:arm64e+0x16220) #10 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #11 0x000107eda344 in eka::posix::memory::CFReleaseDeleter<__CSIdentityQuery*>::operator()(__CSIdentityQuery*) const+0x3c (libxxx.dylib:arm64+0x9a344) #12 0x000107eda1c8 (libxxx.dylib:arm64+0x9a1c8) #13 0x000107eda010 (libxxx.dylib:arm64+0x9a010) #14 0x000107e43424 (libx.dylib:axxrm64+0x3424) #15 0x000107e41cc4 in my::helper::EnumerateUsers(std::__1::function<void (my::helper::UserInfo&&, bool&)> const&, unsigned int)+0xf7c (libxxx.dylib:arm64+0x1cc4) ... previously allocated by thread T240 here: #0 0x000109b0938c in malloc+0x78 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3d38c) #1 0x0001919b39d4 in _malloc_type_malloc_outlined+0x60 (libsystem_malloc.dylib:arm64e+0x1d9d4) #2 0x000191d11c34 in __CFDataInit+0x214 (CoreFoundation:arm64e+0x10bc34) #3 0x00019f8e3228 in DSIdentityRecord::addJPEGData(char const*, unsigned int, unsigned int)+0x28 (OSServices:arm64e+0xd228) #4 0x00019f8e627c in DSIdentity::CreateIdentityFromDSAttributeList(__CFAllocator const*, unsigned int, tDataBuffer*, unsigned int, long, bool, DSIdentityAuthority&, tDirStatus*)+0x1c8 (OSServices:arm64e+0x1027c) #5 0x00019f8ecb64 in DSIdentityQuery::consumeRecordData(unsigned int, tDataBuffer*, long)+0xb4 (OSServices:arm64e+0x16b64) #6 0x00019f900e2c in findRecordsWithNames+0xd0 (OSServices:arm64e+0x2ae2c) #7 0x00019f8ec49c in DSIdentityQuery::performQuery(__CFError**)+0x1c4 (OSServices:arm64e+0x1649c) #8 0x00019f8ec5c4 in DSIdentityQuery::execute(unsigned long, __CFError**)+0x40 (OSServices:arm64e+0x165c4) #9 0x00019f8e06f4 in CSIdentityQueryExecute+0x2c (OSServices:arm64e+0xa6f4) #10 0x000107e4144c in my::helper::EnumerateUsers(std::__1::function<void (my::helper::UserInfo&&, bool&)> const&, unsigned int)+0x704 (libxxx.dylib:arm64+0x144c) EnumerateUsers is our function which basically does this (simplified, error checking skipped): unique_cfref<CSIdentityQueryRef> query(CSIdentityQueryCreate(kCFAllocatorDefault, kCSIdentityClassUser, CSGetLocalIdentityAuthority())); CSIdentityQueryExecute(query.get(), 0, &error); unique_cfref<CFArrayRef> userIdentities(CSIdentityQueryCopyResults(query.get())); auto userIdentitiesCount = CFArrayGetCount(userIdentities.get()); for (CFIndex i = 0; i < userIdentitiesCount; ++i) { // do something including calling getpwuid() } unique_cfref is just a std::unique_ptr wrapper that calls CFRelease when we goes out of scope. Looks like something in OpenDirectory tries to access released data (weak references and delayed processing?). The problem seems to occur on macOS 15. Is there any bug/regression, should we file a feedback? Or maybe we do something wrong?

Ok so for some background, our app has a keyboard extension where we run a dictation service. Due to iOS limitations, this requires the user to press a button on the keyboard which will then bring the user to our app to activate an audio session. Once the audio session has been activated, it takes the user back to the original app it came from to continue using the keyboard + dictation service. The problem we're running into involves iOS 26.0 and the iMessages app. Whenever our app tries to switch back to the iMessages app using Deep Link (specifically the messages:// URL), the iMessages app opens up a new message compose sheet. This compose sheet replaces the view or message thread that the user was previously looking at which we don't want. This behavior appears to be only happening in iOS 26 and not in any of the previous iOS versions (tested up to iOS 18.6). We know that it should be possible to bring the user back to the messages app without opening up this new compose sheet, because similar apps do the same thing and these apps have been verified to work on iOS 26. We've tried also using the sms:// URL but that always opens a new message compose sheet regardless of whether or not it's iOS 26.0.

My app is a VoIP softphone for Mac that allows people to make phone calls to a regular phone numbers. The app exists since before Mac App Store. The app declares itself to the system as capable of handling tel: URLs. Until now, people could change the default handler for tel URLs in FaceTime settings (Default for calls). In macOS Tahoe 26, this doesn't seem to be possible any more. That option is gone from the FaceTime settings. Is it completely gone or has it been moved somewhere else? If there is no UI control for this any more, is it possible to change it programmatically?

Hi, I’m trying to open a GPX file (route.gpx) from the Files app on my iPhone using my app (e.g., Aqua Map). Since the latest iOS update (iOS 26), when I long-press the file and tap “Open with…”, my app does not appear in the list anymore. I’ve checked that my app has the correct permissions for Files and Folders. I’m wondering: Is this a user-side issue (Settings on iPhone)? Or does it require developer-side changes in the app (Info.plist / UTI declarations) to make .gpx files appear in “Open with…” or “Share” menus? What is the proper way to make my app appear as an option to open GPX files in Files.app on iOS 26? Thanks in advance!

On macOS, one can set the "Open With ..." application in the information panel of a file without changing the default for this file type. However, doing this for a number of files is very tedious. A simple case is to change all .txt files in a directory to a special editor, but leave the system wide default (usually TextEdit). I have tried AppleScript, command line tools as well as a minimal GUI app (using LSSetItemAttribute), but all fail because of a lack of permission. Is there any way to achieve this?

Hi All, I am facing one problem in my app. That is open battery settings from my app. It is working fine in iOS 16.0.0 and it's not working in iOS 18.6.1 is it possible to make it workable in iOS 18.6.1? If so How to do that? Please help me over this to resolve the problem. Thanks, Nguyen Quang Minh

A user of my AppKit, document-based app brought to my attention that when setting it as the default app to open a certain file with extension .md (by choosing in the Finder "File &gt; Open With &gt; Other", then selecting my app and enabling "Always open with"), trying to open it with a double-click displays the warning "Apple could not verify [file] is free of malware that may harm your mac or compromise your privacy". This is what happens for me: When keeping the default app for a .md file (Xcode in my case), the file opens just fine. When choosing my app in the "File &gt; Open With" menu, the file opens just fine in my app. But when setting my app as the default app (see above), the warning is displayed. From that moment on, choosing my app in the "File &gt; Open With" menu doesn't work anymore. Selecting Xcode doesn't work either. Only setting Xcode again as the default app allows me to open it in Xcode, but my app still isn't allowed to open it. Is this a macOS issue, or can I do anything in my app to prevent it? Where should I start looking for the issue in my code?

I am trying to add custom scheme (CFBundleURLSchemes) to my App Clip. I launch the app clip via TestFlight to cache it to the device then i try to access the custom scheme URL to launch App Clip but nothing happened. May I know if it is something I did wrongly or just App Clip does not support Custom Scheme?