Filed as FB24092251. On macOS 27.0 beta (26A5388g), clicking into any text input inside a WKWebView in a Mac Catalyst app makes focus oscillate forever and typing does nothing. CPU pegs at 100% while the editor is focused. The same binary works fine on macOS 26. The DOM element never actually loses focus. Only the window does: window focus -> activeElement=TEXTAREA.inputarea JS focus -> activeElement=TEXTAREA.inputarea window blur -> activeElement=TEXTAREA.inputarea <- window loses key status JS blur -> activeElement=TEXTAREA.inputarea <- element did not ...repeats indefinitely... Pausing during the loop shows why. Focusing the element sends WebKit into UIKit's software-keyboard machinery, on a platform that has no software keyboard: -[UIKeyboardSceneDelegate containerWindowForViewService:] -[UIKeyboardSceneDelegate _setKeyWindowSceneInputViews:animationStyle:] -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] -[WKContentView(WKInteraction) _continueElementDidFocus:...] -[WKContentView(WKInteraction) _elementDidFocus:...] WebKit::WebPageProxy::elementDidFocus(...) Building that container steals key status from the web view. First responder ends up on the enclosing _UIHostingView, so key presses are delivered there and immediately cancelled: pressesBegan: [...], focusedItem: monacoEditor firstResponder at keypress: _UIHostingView<...> pressesCancelled: [...] The catch: -becomeFirstResponder cannot be used to recover, because it is the trigger. Calling it re-enters _elementDidFocus and re-arms the loop permanently. So there is no app-side way back — the only API that reclaims the keyboard is the one that breaks it. Minimal repro is just a WKWebView in a UIViewRepresentable inside a SwiftUI hierarchy, with any focusable . No Monaco needed. Partial mitigation, if you hit this: do not echo focus/blur commands back at the web view in response to its own focus events, and treat a blur where document.hasFocus() is false but activeElement is unchanged as a window-level blur rather than an editing-ended event. That stops the runaway loop and keeps your focus state correct — but it does not restore typing. Has anyone found a way to get first responder back to the web view without calling -becomeFirstResponder? Or a way to stop the keyboard scene delegate engaging on Catalyst in the first place? If you can reproduce on 27 beta, please file a duplicate referencing FB24092251.

After updating the application following an upgrade from a previous macOS version to macOS Tahoe 26.5.1 (25F80), the sandboxed app immediately crashes on launch. The crash occurs during dyld library initialization, before any application code (including main()) is executed. The crash report identifies that libsystem_secinit.dylib rejects the existing app sandbox container with the following signature: "failed integrity checks for container at /Users/apptest/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data: Invalid argumen" Clearing out the old sandbox container data (e.g., rm -rf ~/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data) resolves the crash. Please help analyze the possible causes of this issue: 1.Could this be a compatibility issue between the new macOS 26.5.1 system and Mac Catalyst apps? 2.Could this be caused by certain APIs used by the app or specific project configuration settings? If so, please provide some relevant hints to help narrow down the scope of analysis. Crash Log excerpt.txt

My Mac Catalyst app (distributed via TestFlight) crashes instantly at launch — before main() — on macOS 26.5.1 (25F80) when archived with Xcode 27 beta 3. The same code archived with Xcode 26.5 (GA) launches fine. Crash excerpt: Termination Reason: Namespace DYLD, Code 4, Symbol missing Symbol not found: _UIFontTextStyleBody Referenced from: <...> /Applications/Paku.app/Contents/MacOS/Paku Expected in: <...> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (terminated at launch; ignore backtrace) What appears to be happening The symbol comes from completely ordinary UIKit code — e.g. UIFont.preferredFont(forTextStyle: .body). When linking with the Xcode 27 beta 3 SDK, the two-level namespace bind for _UIFontTextStyleBody in my binary points at AppKit, i.e. the beta SDK's AppKit.tbd declares (re-exports) the UIKit text-style constants for Catalyst. But the shipping OS doesn't provide that: on macOS 26.5.1, _UIFontTextStyleBody is absent from both the installed AppKit binary (checked with dyld_info -exports /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) and the Xcode 26.5 GA SDK's AppKit.tbd. So any binary linked against the beta SDK hard-binds the symbol to AppKit and then fatally fails to bind on current GA macOS — a 100%-reproducible launch crash for every user not on the macOS 27 beta. Steps to reproduce Mac Catalyst target that uses any UIFont.TextStyle constant (e.g. .preferredFont(forTextStyle: .body)). Archive with Xcode 27 beta 3 and distribute via TestFlight. Launch on macOS 26.5.1 → immediate dyld abort with the report above. Questions Is this a known issue with the macOS 27 beta SDK's AppKit re-export list? It looks like these UIKit constants are being moved/re-exported through AppKit in the 27 cycle, but without availability/weak-linking info that would let binaries back-deploy to macOS 26. Is the intended behavior that Catalyst apps built with the 27 beta SDK simply can't run on macOS 26? If so, should App Store Connect / TestFlight have rejected or flagged the upload?

Mac Store search results now default to IOS Apps, devastating Mac Catalyst sales. To compound this issue, there is no way for Mac Catalyst developers to remove their Mac Catalyst version so that their IOS app (for iPad) will appear. They are invisible. I've contacted Apple but no reply yet. Any thoughts?

I have an iOS app that I want to publish to the Mac App Store as a Catalyst app, but I noticed a situation where the app can't be closed and has to be force quit. The problem happens if the user has 0 photos in their Photo Library, and hits "Limited Access" on the request authorization prompt (In my case PHPhotoLibrary.requestAuthorization(for: .readWrite). Since the popup is a system prompt, I can't manually add a close button to it. I tried wrapping it in a view with a close button but the popup always shows up over any view I'm presenting within my app. If anyone has a workaround that would be greatly appreciated!

So I am adding Catalyst support to my iOS app. I went through and updated my code and Build Settings to add Catalyst support. I can build for any iOS build or macOS build. I went into App Store Connect and then added a macOS build. I am not able to do a single build and archive that uploads a build for both macOS and iOS. I can do a build and archive for "Any iOS Device (arm64)" and it shows up in the iOS test flight. I can do a build and archive for "Any Mac (Mac Catalyst, arm64, x86_64) and it shows in the macOS test flight. Maybe I'm making a bad assumption ( I could not find any documentation on it) but I assumed Catalyst was a single build and archive that showed up in BOTH macOS and iOS sections. The build settings seem to imply the build is good for a single build and archive process. I want this to be a universal app and my assumption doing it that way would keep everything in sync when you push to the App Store. You can already download the app through the App Store but it is a version of the iPad app. I was hoping to make it more native and available in the Mac App Store without the iPhone/iPad app option. Am I making bad assumptions? Will I just have to do two Build and Archives for every build? I just want to make sure I'm doing this correctly and the best way.

When building our project for Mac Catalyst with Xcode 26.2, we get this warning almost a hundred times, once for every object file: directory not found for option '-L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' Somehow, every Link <FileName>.o build step got the following parameter, regardless if the target contained Metal files or not: -L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst The toolchain is mounted at this point, but the directory usr/lib/swift/maccatalyst doesn't exist. When building the project for iOS, the option doesn't exist and the warning is not shown. We already check the build settings, but we couldn't find a reason why the linker is trying to link against the toolchain here. Even for targets that do contain Metal files, we get the following linker warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Is this a known issue? Is there a way to get rid of these warnings?

Hi everyone! Adam here, the developer of Albums. Bummed not to get to have our yearly WebEx reunion where I beg y’all to add an endpoint to the Apple Music API to allow deleting items from a user’s library. But that’s not what this thread is about. Back in October, thanks to your team’s multi-year efforts, I was finally able to ship Albums for macOS. It’s been a genuine dream come true to use it on the platform I always envisioned it on, and I hear from users all the time who feel the same way. I know it was a significant engineering effort, and I’m genuinely very grateful. I’ll be judicious with my time here (I’d love to chat in more detail about my adventures in MusicKit on the Mac somehow, sometime). These are the main things on my wishlist for MusicKit on the Mac. There are three main things I hear from users that my app “can’t do” that can be dealbreakers for them. The first two are AirPlay support and a volume slider. Users are only able to AirPlay using the control center utility, because AVRoutePickerView does not work with ApplicationMusicPlayer (FB13934910). Relatedly, the MPVolumeView does not work with ApplicationMusicPlayer (FB21042385), so I can’t allow users app-specific volume control for my app. The lack of those two things is a real detriment to my app being able to be taken seriously alongside all of the other music player apps on the platform for which those features are table stakes. I know there’s a challenge here given the playback actually happens in the subprocess, but hoping some progress can be made here. The other issue is that library tracks played in ApplicationMusicPlayer do not update the last played date or play count in Music.app or in the user’s iCloud Music Library (FB17675148). Some people refuse to use the app for that reason, and I can’t say I blame them. I’ve only been able to test this briefly in Golden Gate, but it seems like this is still the case. Are you able to share anything about your work on the music library in macOS this year? Thank you again for all your work on MusicKit! I’m planning to get the last of the load-bearing MediaPlayer code out of my codebase later this year. Hooray!

My latest app version may have a bug that happens very rarely when opening/closing the app and AVAudioPlayer.init(contentsOf:fileTypeHint:) is called (note that everything related to audio player is protected inside try/catch blocks). But the app does start again. I tested on my Intel Mac and Mac mini 2024 without any problems. In fact we have more than 2000 Mac users that use our app daily without any problems. But we have 3 customers that have a serious problems. They have apple silicon Macs with macOS 15.7.7 and 26.5. So the app does not ever start again, after working for years. Uninstalling and deleting all hidden files over the entire hard drive related to our app and reinstalling it from the store. Does not make it start again. I saw many macOS bugs happening. Killing/Closing the app then rebooting the Mac without the option to reopen the apps. When the reboot is done our app is opened, we see a little dot underneath (nothing exists to start it on boot). I saw display problems in Monitor app. For one customer, after uninstalling our app, it does appear in App Store, but the "get" button is grey and cannot be clicked. Our app is not on the SSD and not in the garbage bin. I compiled a special version of my app with no sound, all the code related to the possible crash completely commented. I gave it to 2 users and the app does not start. After cleaning everything, rebooting and reinstalling the app, I have one customer that gets a message that the previous opening of the app crashed. But the 2 choices (do not open or reopen) don't work. It juste either do nothing or crash again and again. My Theory is that there is an old bug in macOS that my app triggered. And from that moment on, macOS will stop behaving properly. My app was compiled with the lasted Xcode and apple libraries (I only use the basic Apple libraries, no 3rd party stuff) as of last month. My customers are angry and I tell them to get help from Apple customer service. The problem is not in my app, but something get stuck in macOS that makes the app never start again. The app was working, even my latest update, then after 1 crash it never start again, even after cleaning, rebooting and reinstalling the app. I can't fix this on my side, an app that crashes should not ever break the entire OS. I want to reiterate that my app does work for me an thousands of people and that even a new version without any possible problem manually put on desktop does not start either. When we uninstall and reinstall an app, it should work as it did, not leave behind some hidden crap that makes it never start again.

Why is the WiFiAware framework not importable in Mac Catalyst? Are there any plans to support Wi-Fi Aware technology on Mac Catalyst in the future?

Hi everyone, I’ve encountered an issue where using a popover inside the toolbar of a Catalyst app causes a crash on macOS 26 beta 5 with Xcode 26 beta 5. Here’s a simplified code snippet: import SwiftUI struct ContentView: View { @State private var isPresentingPopover = false var body: some View { NavigationStack { VStack { } .padding() .toolbar { ToolbarItem { Button(action: { isPresentingPopover.toggle() }) { Image(systemName: "bubble") } .popover(isPresented: $isPresentingPopover) { Text("Hello") .font(.largeTitle) .padding() } } } } } } Steps to reproduce: Create a new iOS app using Xcode 26 beta 5. Enable Mac Catalyst (Match iPad). Add the above code to show a Popover from a toolbar button. Run the app on macOS 26, then click the toolbar button. The app crashes immediately upon clicking the toolbar button. Has anyone else run into this? Any workarounds or suggestions would be appreciated! Thanks!

I have an application that is a VOIP application of sorts that needs access to the microphone. I am using the Mac (Designed for iPad) support to not have to do huge amounts of conditional building and support for all the many iOS specific things my app includes. I never get prompted to allow microphone permissions and I never see my app name appear in Privacy & Security -> Microphone permissions setup. So is it that Mac is just a dead end for any form of an application that needs a microphone and is running under Mac (Designed for iPad) compatibility mode? Why doesn't TCC have some mechanism to notice and grant access to mic use?

Please show me where I’ve gone amiss in MacCatalyst and UIScenes with regard to the macOS green zoom/fullscreen button. Originally the MacCatalyst App used a secondary AppKit bundle for its NSWindow work, but at some point in time AppStore Connect complained about this secondary bundle which prevented new App uploads. To continue receiving green button notifications I switched to UINSWindow. That worked. Now that I’m forced to use UIScenes I’m in a pickle: a click on the green button forces an automatic jump to fullscreen, nothing I can do about it AFAIK. A poor, poor compromise would be to disable the green button but I have no idea how even to do that. I’d like my App to exist in two states, any suggestions? Thanks.

On Mac Catalyst 26, a Button bar item in a bottom toolbar look squished. This happens only when the "Mac Catalyst Interface" option is set to "Optimize for Mac". When it is set to "Scale to match iPad", the buttons look fine. For example, in the screenshots below, the text button should say "Press Me", instead of "…" A simple reproducible snippet and a screenshot below. The toolbar button comparison between "Scale to match iPad" and "Optimize for Mac" are shown. Optimize for Mac Scale to match iPad import SwiftUI struct ContentView: View { @State private var selectedItem: String? = "Item 1" let items = ["Item 1", "Item 2"] var body: some View { NavigationSplitView { List(items, id: \.self, selection: $selectedItem) { item in Text(item) } .navigationTitle("Items") } detail: { if let selectedItem = selectedItem { Text("Detail view for \(selectedItem)") .toolbar { ToolbarItemGroup(placement: .bottomBar) { Text("Hello world") Spacer() Button("Press Me") { } Spacer() Button { } label: { Image(systemName: "plus") .imageScale(.large) } } } } else { Text("Select an item") } } } }

I just submitted FB22318443. In Mac Catalyst apps running on macOS 26.4, if you choose to limit the app's access to specific photos (as opposed to granting full access), the photos do not appear in the app. 💀 This issue does not occur on iPadOS. It is a macOS 26.4 regression. It occurs even with apps built using a previous version of the SDK such as 26.2. A sample of the console logs: [RM]: 4-1-1 failed to decode for asset: 9290CC20-B85D-47B5-BDBE-D330FE61773D, error code: 3303, description: Error Domain=PHPhotosErrorDomain Code=3303 "(null)" Failed to get sandbox extension for url: file:///Users/Jordan/Pictures/Photos%20Library.photoslibrary/resources/derivatives/masters/9/9290CC20-B85D-47B5-BDBE-D330FE61773D_4_5005_c.jpeg, error: Error Domain=com.apple.photos.error Code=44001 "sandbox extension not in the cache after requesting them for path: /Users/Jordan/Pictures/Photos Library.photoslibrary/resources/derivatives/masters/9/9290CC20-B85D-47B5-BDBE-D330FE61773D_4_5005_c.jpeg" UserInfo={NSDebugDescription=sandbox extension not in the cache after requesting them for path: /Users/Jordan/Pictures/Photos Library.photoslibrary/resources/derivatives/masters/9/9290CC20-B85D-47B5-BDBE-D330FE61773D_4_5005_c.jpeg} [RM]: 1-1-1 Image request failed with error: Error Domain=PHPhotosErrorDomain Code=3303 "(null)"

Hello, I have a iOS app I was looking at porting to Mac. I'm having an issue with both the Mac (Designed for iPad) and Mac Catalyst Destinations. I can't test Mac due to too many build issues. I'm trying to assign a new NSManagedObject into a NSPersistentStore. let object = MyObject(context: context) context.assign(object, to: nsPersistentStore) This works fine for iOS/iOS Simulator/iPhone/iPad. But on the Mac it's crashing with FAULT: NSInvalidArgumentException: Can't assign an object to a store that does not contain the object's entity.; { Thread 1: "Can't assign an object to a store that does not contain the object's entity."

In iOS 18, TabView with .tabViewStyle(.sidebarAdaptable) introduced a powerful adaptive pattern — tabs in compact, sidebar in regular. However, the current Tab API only supports a title and an image (icon). There is no way to provide a trailing accessory view (e.g., a secondary icon or indicator) for sidebar rows. This is a meaningful gap in the API, because trailing accessories are a well-established pattern throughout UIKit and SwiftUI. Precedent in Apple's own design language Apple already supports trailing accessories in many analogous contexts: UITableViewCell / UICollectionViewListCell — support accessories (disclosure indicators, checkmarks, custom views) via UICellAccessory. UIListContentConfiguration — allows leading and trailing content in list rows. SwiftUI List rows — support Label, HStack with trailing elements, .badge(), and swipeActions. NavigationLink — automatically renders a disclosure chevron as a trailing accessory. UITabSidebarItem (UIKit, iOS 18) — supports configurationUpdateHandler and cell accessories at the UIKit level. The sidebar of a .sidebarAdaptable TabView is visually identical to a List — yet its rows lack the accessory support that List rows have had for years. Real-world example: Photos app Apple's own Photos app (iPadOS 18+) demonstrates this exact need. In its sidebar, the "Recently Deleted" row displays a trailing lock icon to indicate that authentication is required to view the album. This is a meaningful UX element — it communicates state at a glance, without requiring the user to tap into the item. Third-party developers building with TabView(.sidebarAdaptable) have no public API to replicate this pattern. The Tab view builder's label closure is decomposed into a discrete title and image; any additional views (including Spacer() and trailing Image views within an HStack) are silently discarded by the system. What we've tried Custom label closure with HStack — trailing views are ignored. The system extracts only the first Image and Text. .badge() modifier — only supports Int or Text, not custom views such as icons. Label with complex content — the system normalizes it to icon + title. The only viable path today is to bridge to UIKit's UITabBarController and customize UITabSidebarItem directly, which defeats the purpose of using SwiftUI's declarative TabView API. Proposed API A trailing accessory modifier on Tab, consistent with existing SwiftUI patterns: Tab("Recently Deleted", systemImage: "trash", value: "deleted") { RecentlyDeletedView() } .tabSidebarAccessory { Image(systemName: "lock.fill") .foregroundStyle(.secondary) } // Option B: Text accessory (e.g., counts, status labels) Tab("Inbox", systemImage: "tray", value: "inbox") { InboxView() } .tabSidebarAccessory { Text("12") .font(.subheadline) .foregroundStyle(.secondary) } // Option C: Combined text + image accessory Tab("Shared Albums", systemImage: "rectangle.stack", value: "shared") { SharedAlbumsView() } .tabSidebarAccessory { HStack(spacing: 4) { Text("3 new") .font(.caption) .foregroundStyle(.secondary) Image(systemName: "person.2.fill") .foregroundStyle(.blue) } } Environment Platform: iPadOS / macOS Catalyst iOS version: 18.0+ Xcode: 16.0+ Component: SwiftUI TabView with .tabViewStyle(.sidebarAdaptable) Summary The Tab API should support trailing accessory content for sidebar rows, bringing it in line with the accessory support already available in UITableViewCell, UICollectionViewListCell, UIListContentConfiguration, and SwiftUI List. Apple's own Photos app demonstrates the need for this capability, yet no public API exists for third-party developers to achieve it.

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is "Open In Place" compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the "In Place" capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider supports .openInPlace before the performDrop delegate method is called?

Updated version of this post My HomePod mini is now on version 16.4, so the the temperature and humidity sensors are enabled. The data properly shows up in the Home app on my various devices. In my HomeKit iPad app running on Mac Catalyst, however, the data does not show up. I would expect the HomePod mini to show up in HMHome.accessories with a service of type HMServiceTypeTempatureSensor. I see all of my other HomeKit accessories, just not the HomePod mini. I have tried with the latest Xcode (14.3) and highest available iOS Target and Minimum Deployment (16.4), macOS version 13.3. I have not, as of this writing, upgraded my HomeKit architecture, however. Note that I haven't tried the app on an actual iPad (and the iOS simulator doesn't expose my HomeKit environment.)

When I've tried to use UIDevice on my Mac running my Catalyst application, testing code UIDevice *d=UIDevice.currentDevice; for (NSString *k in @[@"name", @"systemName", @"systemVersion", @"model", @"localizedModel"]) NSLog(@"%@ -> %@", k, [d valueForKey:k]); to my great surprise I am getting name -> iPad systemName -> iPadOS systemVersion -> 26.3 model -> iPad localizedModel -> iPad What the. How do I determine the real values? Thanks!