MacOS system settings allow the user to select one of a number of number formats. My app behaves differently depending on the format (taken from the system Locale), so I need to test every combination. Thus far I have been successful at creating Locale objects with various identifiers that map to the different formats, like: let westEuropeanLocale = Locale(identifier: "en_DE") However, I can't find a locale that maps to using . as a decimal point, and space as a thousands separator, even though it's a standard option (3rd in this list): Any suggestions on how to create a test for this number format?

It appears that starting with macOS Sequoia, Quick Look Preview extension no longer loads MapKit maps correctly anymore. Map tiles do not appear, leaving users with a beige background. Users report that polylines do render correctly, but annotations appears black. This was previously working fine in prior macOS versions including Sonoma. STEPS TO REPRODUCE Create a macOS app project, with an associated document. Ensure project has a Quick Look preview extension, with necessary basic setups. Ensure that the extension mentioned in (2) must have a MKMapView. Any other cosmetic changes, etc, does not need to be implemented to observe the base issue. Do note that it has been reported that in addition to the map tiles not loading, annotations don't render correctly as well.

UIHostingConfiguration on tvOS: focus permanently broken with multiple focusable SwiftUI views Hi everyone, I'm working on a tvOS app with a UICollectionView. Some cells embed SwiftUI content via UIHostingConfiguration, specifically a row of 3 buttons that should be individually focusable. The cell itself returns canBecomeFocused = false so focus passes through to the SwiftUI buttons. The problem: after navigating focus into that section once, it becomes permanently unfocusable. Focus enters briefly, then immediately exits to nil on its own, without any user input. From that point on, the focus engine completely skips the section. The exact same SwiftUI view works perfectly when embedded via UIHostingController instead. How to reproduce Press DOWN to move focus into the UIHostingConfiguration section Focus lands on a SwiftUI button for a split second Focus exits on its own and bumps to another section The section is now dead, focus skips it on every subsequent navigation What the system logs say (-UIFocusLoggingEnabled YES) Right when focus enters, the system reports the SwiftUI focus items as "disappearing": Ignoring focus update request for disappearing focus environment <UIKitFocusSectionResponderItem> Then when searching for a new focusable item: <SwiftUI._UIInheritedView> → (warning) No focusable items found. <UIHostingContentView> → (warning) No focusable items found. === unable to find focused item in context. retrying with updated request. === The views are still in the hierarchy (verified by pointer), but the UIHostingContentView no longer exposes its virtual focus items. I also see mismatched parentFocusEnvironment on those items, pointing to a _UIHostingView from a completely different cell. What I've tried I've spent a lot of time on this with my colleagues, dug through the very limited documentation available online, and even used AI agents to help brainstorm. We tested 10 different approaches, none worked: Overriding preferredFocusEnvironments to point to the UIHostingContentView setNeedsFocusUpdate() / updateFocusIfNeeded(), rescan finds nothing Forcing UIKit redraws (setNeedsLayout, setNeedsDisplay) Removing .focusSection() Removing all SwiftUI animations, identical behavior Using canFocusItemAt: delegate instead of cell subclass, identical remembersLastFocusedIndexPath = true, causes a separate focus trap configurationUpdateHandler + setNeedsUpdateConfiguration(), config is rebuilt but virtual items stay deregistered Verified the UIHostingContentView never leaves the hierarchy. It doesn't, its internal state is just corrupted My workaround I switched to UIHostingController with proper view controller containment. It works because the hosting controller is a full UIFocusEnvironment, so the focus engine can traverse it and it correctly maintains its virtual items. Has anyone encountered this? Is there a known pattern for using UIHostingConfiguration on tvOS with multiple focusable SwiftUI elements? Or should I just file a Feedback? Thanks for any help! You can find the code here : https://github.com/ThomasDutartre/focus-problem-tvos I recored the problem here : https://youtu.be/yPfM5AvU2ko

UIHostingConfiguration on tvOS: focus permanently broken with multiple focusable SwiftUI views Hi everyone, I'm working on a tvOS app with a UICollectionView. Some cells embed SwiftUI content via UIHostingConfiguration, specifically a row of 3 buttons that should be individually focusable. The cell itself returns canBecomeFocused = false so focus passes through to the SwiftUI buttons. The problem: after navigating focus into that section once, it becomes permanently unfocusable. Focus enters briefly, then immediately exits to nil on its own, without any user input. From that point on, the focus engine completely skips the section. The exact same SwiftUI view works perfectly when embedded via UIHostingController instead. How to reproduce Press DOWN to move focus into the UIHostingConfiguration section Focus lands on a SwiftUI button for a split second Focus exits on its own and bumps to another section The section is now dead, focus skips it on every subsequent navigation What the system logs say (-UIFocusLoggingEnabled YES) Right when focus enters, the system reports the SwiftUI focus items as "disappearing": Ignoring focus update request for disappearing focus environment <UIKitFocusSectionResponderItem> Then when searching for a new focusable item: <SwiftUI._UIInheritedView> → (warning) No focusable items found. <UIHostingContentView> → (warning) No focusable items found. === unable to find focused item in context. retrying with updated request. === The views are still in the hierarchy (verified by pointer), but the UIHostingContentView no longer exposes its virtual focus items. I also see mismatched parentFocusEnvironment on those items, pointing to a _UIHostingView from a completely different cell. What I've tried I've spent a lot of time on this with my colleagues, dug through the very limited documentation available online, and even used AI agents to help brainstorm. We tested 10 different approaches, none worked: Overriding preferredFocusEnvironments to point to the UIHostingContentView setNeedsFocusUpdate() / updateFocusIfNeeded(), rescan finds nothing Forcing UIKit redraws (setNeedsLayout, setNeedsDisplay) Removing .focusSection() Removing all SwiftUI animations, identical behavior Using canFocusItemAt: delegate instead of cell subclass, identical remembersLastFocusedIndexPath = true, causes a separate focus trap configurationUpdateHandler + setNeedsUpdateConfiguration(), config is rebuilt but virtual items stay deregistered Verified the UIHostingContentView never leaves the hierarchy. It doesn't, its internal state is just corrupted My workaround I switched to UIHostingController with proper view controller containment. It works because the hosting controller is a full UIFocusEnvironment, so the focus engine can traverse it and it correctly maintains its virtual items. Has anyone encountered this? Is there a known pattern for using UIHostingConfiguration on tvOS with multiple focusable SwiftUI elements? Or should I just file a Feedback? Thanks for any help!

Memory leak in CarPlay when using CPListImageRowItem. The following behavior was observed in the CPListTemplate class when using CPListImageRowItem: If a CPListImageRowItem cell is inserted into the screen, the screen starts to leak, even if it contains no elements (CPListImageRowItem(titleList: nil, imagesRow: [], titlesRow: []). Replacing CPListImageRowItem with CPListItem stops the leak. Using the new initializer for iOS 26 does not correct the issue; the screen still leaks. Class reference: https://developer.apple.com/documentation/carplay/cplistimagerowitem

It seems to me that NSStagedMigrationManager has algorithmic issues. It doesn't perform staged migration, if all its stages are NSLightweightMigrationStage. You can try it yourself. There is a test project with three model versions V1, V2, V3, V4. Migrating V1->V2 is compatible with lightweight migration, V2->V3, V3->V4 is also compatible, but V1->V3 is not. I have following output: Migrating V1->V2, error: nil Migrating V2->V3, error: nil Migrating V3->V4, error: nil Migrating V1->V3, no manager, error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V3, lightweight[1, 2, 3], error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V3, lightweight[1]->lightweight[2]->lightweight[3], error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V3, custom[1->2]->lightweight[3], error: nil Migrating V1->V3, lightweight[1]->custom[2->3], error: nil Migrating V1->V3, custom[1->2]->custom[2->3], error: nil Migrating V1->V4, error: Optional("Persistent store migration failed, missing mapping model.") Migrating V2->V4, error: nil Migrating V1->V4, custom[1->2]->lightweight[3, 4], error: nil Migrating V1->V4, lightweight[3, 4]->custom[1->2], error: Optional("A store file cannot be migrated backwards with staged migration.") Migrating V1->V4, lightweight[1, 2]->lightweight[3, 4], error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V4, lightweight[1]->custom[2->3]->lightweight[4], error: nil Migrating V1->V4, lightweight[1,4]->custom[2->3], error: nil Migrating V1->V4, custom[2->3]->lightweight[1,4], error: Optional("Persistent store migration failed, missing mapping model.") I think that staged migration should satisfy the following rules for two consecutive stages: Any version of lightweight stage to any version of lightweight stage; Any version of lightweight stage to current version of custom stage; Next version of custom stage to any version of lightweight stage; Next version of custom stage to current version of custom stage. However, rule 1 doesn't work, because migration manager skips intermediate versions if they are inside lightweight stages, even different ones. Note that lightweight[3, 4]->custom[1->2] doesn't work, lightweight[1,4]->custom[2->3] works, but custom[2->3]->lightweight[1,4] doesn't work again. Would like to hear your opinion on that, especially, from Core Data team, if possible. Thanks!

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

Has anyone been able to create a Control Center widget that opens a snippet view? There are stock Control Center widgets that do this, but I haven't been able to get it to work. Here's what I tried: struct SnippetButton: ControlWidget { var body: some ControlWidgetConfiguration { StaticControlConfiguration( kind: "xxx.xxx.snippetWidget" ) { ControlWidgetButton(action: SnippetIntent()) { Label("Show Snippet", systemImage: "map.fill") } } .displayName(LocalizedStringResource("Show Snippet")) .description("Show a snippet.") } } struct SnippetIntent: ControlConfigurationIntent { static var title: LocalizedStringResource = "Show a snippet" static var description = IntentDescription("Show a snippet with some text.") @MainActor func perform() async throws -> some IntentResult & ProvidesDialog & ShowsSnippetView { return .result(dialog: IntentDialog("Hello!"), view: SnippetView()) } } struct SnippetView: View { var body: some View { Text("Hello!") } }

There is a problem with the launchscreen of my application on iPadOS 26. After release of the windowed mode feature the launchscreen of my fullscreen landscape-only application is being cropped and doesn't stretch to screen's size when the device is in the portrait mode. How can I fix this?

Hello, I'm trying to create game in macos with transperent titlebar. The title bar t stay transperent when I click inside, but changed to gray when the window resize or get out of focus. How can I make it stay transperent all the time? I did all of this: window.styleMask.insert(.fullSizeContentView) window.titlebarAppearsTransparent = true window.titlebarSeparatorStyle = .none window.titleVisibility = .hidden window.isMovableByWindowBackground = true window.isOpaque = false window.backgroundColor = .black in the swiftUI view created zstack that start with: var body: some View { ZStack { Color.black.ignoresSafeArea() help please :) Thanks.

When using the Password AutoFill feature, after entering a password and navigating to another page, a system prompt appears asking whether to save the password to the keychain (as shown in the figure). If this prompt is not dismissed and the app is moved to the background, then brought back to the foreground, the prompt automatically disappears. However, after this occurs, all input fields within the app become unresponsive to keyboard input—no keyboard will appear when tapping any text field. The only way to restore keyboard functionality is to force-quit the app and relaunch it. How can this issue be resolved?

Hello， We’re seeing an iPad-specific Launch Screen issue related to multitasking window sizes. Environment Device: iPad (iPadOS 26) Device orientation: Landscape App is launched in a small window where the app window is portrait-shaped (width < height) Issue When the iPad is in landscape but the app is launched as a portrait-shaped small window, the LaunchScreen.storyboard appears to be rendered/layouted as landscape, not matching the actual window geometry. As a result, the Launch Screen content is clipped / partially missing (we see blank/empty area at the bottom during launch). After the app finishes launching, our first view controller uses the correct window size and the UI looks fine — the problem is mainly during the Launch Screen phase. What we checked LaunchScreen.storyboard uses Auto Layout and is expected to adapt to screen/window size. This only reproduces when the device orientation and the app window aspect ratio don’t match (landscape device + portrait-shaped app window, or vice versa). When device orientation and window shape are aligned, the Launch Screen displays correctly. Question Is it expected that iPadOS renders LaunchScreen.storyboard based on the interface orientation / size class rather than the actual window bounds in multitasking scenarios? If not expected, what is the recommended way to ensure the Launch Screen matches the app’s actual window size/aspect ratio at launch (without using code, since Launch Screen is static)? Are there any additional diagnostics or recommended steps to help us investigate and confirm the root cause (e.g., specific logs, APIs/values to capture at launch such as UIWindowScene bounds, interfaceOrientation, size classes, or any guidance on how Launch Screen snapshots are chosen/cached in multitasking)? Thank you.

hello im using the new IOS 26 api for passkey creation ASAuthorizationAccountCreationProvider however it only seems to work with apple's Passwords app. Selecting 3rd party password apps (1Password, google chrome, etc) does not create the passkey. The sign up sheet gives me the option to save in 3rd party apps, but when I select a 3rd party app, I just get the ASAuthorizationError cancelled error? So I dont even know what the problem is? When selecting "Save in Passwords(apple's app)" during the sign up it works fine Has anyone else run into this issue? Is there something I need to do enable 3rd party apps?

Memory leak in CarPlay when using CPTabBarTemplate Reproduced using the code example "Integrating CarPlay with Your Music App" from the official Apple documentation - https://developer.apple.com/documentation/carplay/integrating-carplay-with-your-music-app Steps to reproduce the leak: Download and run the example on CarPlay. Select the Settings tab. Click the first item in the list "Use Apple Music". Click Back button. Repeat steps 3 and 4 several times. Open Debug Memory Graph in xCode and search for "CPGridTemplate" - the count will be greater than 0. Conditions under which the memory leak disappears: If you open and switch to all tabs one by one, the leak disappears.

After reviewing the following Apple Technote, I have confirmed the statement below: https://developer.apple.com/documentation/technotes/tn3187-migrating-to-the-uikit-scene-based-life-cycle In the next major release following iOS 26, UIScene lifecycle will be required when building with the latest SDK; otherwise, your app won’t launch. While supporting multiple scenes is encouraged, only adoption of scene life-cycle is required. Based on the above, I would appreciate it if you could confirm the following points: Is my understanding correct that the term “latest SDK” refers to Xcode 27? Is it correct that an app built with the latest SDK (Xcode 27, assuming the above understanding is correct) will not launch without adopting the UIScene lifecycle, with no exceptions? Is it correct that an app built with Xcode 26 without UIScene lifecycle support will still launch without issues on an iPhone updated to iOS 27?

We're seeing a sharp uptick in BaseBoard/FrontBoardServices crashes since we migrated from UIApplicationDelegate to UIWindowSceneDelegate. Having exhausted everything on my end short of reverse engineering BaseBoard or making changes without being able to know if they work, I need help. I think all I need to get unstuck is an answer to these questions, if possible: What does -[BSSettings initWithSettings:] enumerate over? If I know what's being enumerated, I'll know what to look for in our app. What triggers FrontBoardServices to do this update? If I can reproduce the crash--or at least better understand when it may happen--I will be better able to fix it Here's two similar stack traces: App_(iOS)-crashreport-07-30-2025_1040-0600-redacted.crash App_(iOS)-crashreport-07-30-2025_1045-0600-redacted.crash Since these are private trameworks, there is no documentation or information on their behavior that I can find. There are other forum posts regarding this crash, on here and on other sites. However, I did not find any that shed any insight on the cause or conditions of the crash. Additionally, this is on iPhone, not macOS, and not iPad. This post is different, because I'm asking specific questions that can be answered by someone with familiarity on how these internal frameworks work. I'm not asking for help debugging my application, though I'd gladly take any suggestions/tips! Here's the long version, in case anyone finds it useful: In our application, we have seen a sharp rise in crashes in BaseBoard and FrontBoardServices, which are internal iOS frameworks, since we migrated our app to use UIWindowSceneDelegate. We were using exclusively UIApplicationDelegate before. The stack traces haven't proven very useful yet, because we haven't been able to reproduce the crashes ourselves. Upon searching online, we have learned that Baseboard/Frontsoardservices are probably copying scene settings upon something in the scene changing. Based on our crash reports, we know that most of our users are on an iPhone, not an iPad or macOS, so we can rule out split screen or window resizing. Our app is locked to portrait as well, so we can also rule out orientation changes. And considering the stack trace is in the middle of an objc_retain_x2 call, which is itself inside of a collection enumeration, we are assuming that whatever is being enumerated probably was changed or deallocated during enumeration. Sometimes it's objc_retain_x2, and sometimes it's a release call. And sometimes it's a completely different stack trace, but still within BaseBoard/FrontBoardServices. I suspect these all share the same cause. Because it's thread 0 that crashed, we know that BaseBoard/FrontBoardServices were running on the main thread, which means that for this crash to occur, something might be changing on a background thread. This is what leads me to suspect a race condition. There are many places in our app where we accidentally update the UI from a background thread. We've fixed many of them, but I'm sure there are more. Our app is large. Because of this, I think background UI are the most likely cause. However, since I can't reproduce the crash, and because none of our stack traces clearly show UI updates happening on another thread at the same time, I am not certain. And here's the stack trace inline, in case the attachments expire or search engines can't read them: Thread 0 name: Thread 0 Crashed: objc_retain_x2 (libobjc.A.dylib) BSIntegerMapEnumerateWithBlock (BaseBoard) -[BSSettings initWithSettings:] (BaseBoard) -[BSKeyedSettings initWithSettings:] (BaseBoard) -[FBSSettings _settings:] (FrontBoardServices) -[FBSSettings _settings] (FrontBoardServices) -[FBSSettingsDiff applyToMutableSettings:] (FrontBoardServices) -[FBSSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSSceneSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 (FrontBoardServices) -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke (FrontBoardServices) _dispatch_client_callout (libdispatch.dylib) _dispatch_block_invoke_direct (libdispatch.dylib) __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (FrontBoardServices) -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (FrontBoardServices) -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (FrontBoardServices) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation) __CFRunLoopDoSource0 (CoreFoundation) __CFRunLoopDoSources0 (CoreFoundation) __CFRunLoopRun (CoreFoundation) CFRunLoopRunSpecific (CoreFoundation) GSEventRunModal (GraphicsServices) -[UIApplication _run] (UIKitCore) UIApplicationMain (UIKitCore) (null) (UIKitCore) main (AppDelegate.swift:0) 0x1ab8cbf08 + 0

Hi Everyone We are seeking inputs regarding an issue we are observing with Apple App Site Association (AASA) and Universal Links in our iOS application. In our iOS Mobile App, we have a LogIn button which when clicked , opens a webv view to open a login page using WebView. The login flow follows the OAuth mechanism to get the token after successful login. But despite having a correctly configured AASA file and associated domains setup, our application does not consistently handle Universal Links and we simply end up getting a blank page.So, after successful login the control never gets passed back the iOS Mobile app and flow gets stuck on the browser only that just displays a blank page. Earlier the same OAuth flow was working fine when we were using the 'com.test.app://oauth2redirect' comnvention. Based on our investigation, we suspect this behavior may be related to the use of in-app browsers or embedded webviews, rather than an issue with our app or server-side configuration. From our research and observations, it appears that this may be a known iOS behavior and platform limitation, where Universal Links do not automatically work within third-party in-app browsers or webviews (for example, those embedded in apps such as social media or other container applications). Looks like the Universal Links are primarily designed to work when links are opened from system-level contexts such as Safari, Mail, Messages, or Notes, under specific conditions. Given this, we wanted to confirm with you: If you have developed a mobile app earlier that uses the (AASA) and Universal Links in iOS application. Join us with a quick call and we can walkthrough what we have done and see if there is anything missing. Thanks Rahul

I’m building an iOS SDK that is distributed as a binary XCFramework and consumed via Swift Package Manager using a binaryTarget. What I’ve done so far: Built the SDK using xcodebuild archive for device and simulator Created the XCFramework using xcodebuild -create-xcframework The SDK contains a resource bundle with JSON/config files The XCFramework is wrapped using SPM (code-only wrapper target) Currently, the resource bundle exists outside the XCFramework, and the host app needs to add it manually during integration. I want to avoid this and make the SDK completely self-contained. What I’m trying to achieve: Embed the resource bundle inside the SDK framework so that each XCFramework slice contains it Ensure the SDK can load its assets internally at runtime without any host app changes Questions: What is the correct way to embed a .bundle inside a framework so it gets packaged into each XCFramework slice during archiving? Which Xcode build phases or build settings are required for this (e.g., Copy Bundle Resources, SKIP_INSTALL, etc.)? At runtime, what is the recommended approach for locating and loading this embedded bundle from within the SDK code? Any guidance or best practices for achieving this would be helpful.

I've integrated PencilKit into my app, but I've noticed that shape recognition isn't working during drawing, even though it works perfectly in the Notes app. Is this a bug, or is shape recognition simply not supported in PencilKit for Swift?