“swiftui”

I have an app with a Widget Extension. Both the main app and the widget extension link against the same Swift Package, which contains a localization bundle (String Catalog) used by SwiftUI views inside the package. To make the package's views follow the app's configured language (rather than the system language), I set CFBundleAllowMixedLocalizations to NO in the Info.plist of each target (main app and widget extension). Behavior in the main app: This works as expected. If the app only supports Korean, the package's views display Korean text even when the system language is set to English. Behavior in the widget: The same views (from the same package) display English instead of Korean, even though the widget extension has the identical CFBundleAllowMixedLocalizations = NO setting and the widget's view code lives entirely in the package — not in the widget extension target itself. Question: As far as I understand, widgets are supposed to follow the host app's language setting. Given that both targets

Our app is being killed by the watchdog on iPadOS 26 (iPad Pro 11, 3rd gen) when navigating between tabs after using search. The crash only occurs when AssistiveTouch is enabled — disabling it prevents the issue entirely. The crash stack shows the main thread blocked in CoreUI vector glyph rasterization (CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition:) triggered during a UINavigationController transition while the keyboard is being dismissed: UINavigationController _startCustomTransition → UIKeyboardSceneDelegate _restoreInputViewsWithId → UITextField resignFirstResponder → SwiftUI ViewGraphRootValueUpdater.render → UIButton layoutSubviews → UIImageView _setImage → CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition: The termination reason: FRONTBOARD domain:10 code:0x8BADF00D Failed to terminate gracefully after 5.0s WatchdogEvent: process-exit WatchdogVisibility: Foreground Key observations: Only reproduces with AssistiveTouch enabled iPad Pro 11 (3rd gen), iPadOS 26 Our code i

I am building an iOS text composer with an attachment panel. When its UITextField is first responder and the system keyboard is visible, tapping the attachment button should present a panel that can extend into the region occupied by the keyboard. When the panel closes, the user should return to the same keyboard state without a visible dismissal and re-presentation. The required continuity is: The same UITextField remains first responder. The active input mode remains alphabet, 123, or Emoji. Emoji preserves its selected category, search state, and scroll position. The composer remains positioned above the keyboard throughout the transition. I have investigated the public UIKit approaches: A normal app-window overlay cannot render above the remotely hosted system keyboard. inputAccessoryView remains in the accessory region and cannot cover the keycaps. Resigning first responder visibly dismisses the keyboard and loses continuity. Assigning a custom inputView to the same UITextField and calling reloadInputVie

I have a few crashes on my project that happen in the wild, and the stack trace looks like this, from a thread that is not the main thread: Crashed: com.apple.SwiftUI.AsyncRenderer 0 libdispatch.dylib 0x36f1c _dispatch_assert_queue_fail + 120 1 libdispatch.dylib 0x37988 dispatch_assert_queue$V2.cold.2 + 114 2 libdispatch.dylib 0x5094 dispatch_assert_queue + 108 3 libdispatch.dylib 0x5094 dispatch_assert_queue$V2 + 108 4 libswift_Concurrency.dylib 0xedfc _swift_task_checkIsolatedSwift + 48 5 libswift_Concurrency.dylib 0x6fc4 swift_task_isCurrentExecutorWithFlagsImpl(swift::SerialExecutorRef, swift::swift_task_is_current_executor_flag) + 356 6 Xogot 0x2585a78 closure #1 in Toolbar3D.dockedBody.getter + 195 (Toolbar3D.swift:195) 7 SwiftUI 0xeae60 ScrollView.init(_:showsIndicators:content:) + 136 8 Xogot 0x2585798 Toolbar3D.body.getter + 207 (Toolbar3D.swift:207) 9 SwiftUICore 0x31614 closure #1 in ViewBodyAccessor.updateBody(of:changed:) + 1068 10 SwiftUICore 0x311b0 ViewBodyAccessor.updateBody(of:chang

Hello! We are seeing a problem with a SwiftUI view that wraps an MTKView and that MTKView uses gesture recognizers from UIKit. One of those gestures we are using is UIPinchGestureRecognizer. And that gesture isn’t recognized at all when the SwiftUI view is attached to a RealityView using the ViewAttachmentComponent AND the RealityView is being shown in an ImmersiveSpace. If the SwiftUI view is attached to the RealityView using the init that has an attachment closure then pinching works fine there. So this definitely seems like a bug. Here is some code to help you reproduce the problem. Run this on a Vision Pro device. A simple red square will be rendered and if a single tap or pinch gesture is recognized on the red square, it will print to the console. App Code: import SwiftUI @main struct VisionPinchProblemsApp: App { var body: some Scene { WindowGroup { MenuView() } ImmersiveSpace(id: RedSquare) { RedSquareView() } } } View code: import MetalKit import RealityKit import SwiftUI

For GNU Taler, we defined a custom URL scheme: taler://. We want to have a SwiftUI PasteButton in our app which is only active/enabled when the user copied a talerURI, but not for other URIs (such as https:// or mailto://). Currently we use PasteButton(supportedContentTypes: [.url]) { providers in which works, but is also enabled when the copied text is some other URI, not only for taler://. Can we define a UTType .taler for PasteButton to check whether the pasteBoard has indeed a talerURI? How?

Hi everyone In SwiftUI, are there any good solutions to achieve a layout similar to Android's StaggeredGridLayoutManager for displaying a large amount of data?

On iPadOS 27.0 beta 4, SwiftUI views hosted inside UIKit-managed containers/overlays can be laid out incorrectly. The same app and same code work correctly on iPadOS 26.x release versions. One visible example is the app’s About dialog. The dialog is implemented as a UIKit UIViewController presented with UIModalPresentationFormSheet. Inside that controller, a UIHostingController is added as a child view controller, and the hosting controller’s view is constrained to all four edges of the parent view. The SwiftUI root view is a VStack containing the app icon, app name, version, text, links, and buttons. Expected behavior: The SwiftUI content should be vertically centered inside the form sheet. The app icon should appear above the app title, followed by the version, text, links, and buttons. This is the behavior on iPadOS 26.x. Actual behavior on iPadOS 27.0 beta 4: When the About dialog is opened immediately after launching the app, this issue occurs intermittently. The form sheet its