iOS18.0以前では発生していなかったアプリのレイアウト崩れが発生しており、これはOS起因のバグなのか否かをご教示いただきたいです。 【事象】 iOS18.0以前では発生していなかった、右上に表示していたアイコンが真ん中に来ているといったアプリのレイアウト崩れが発生しております。 【原因調査】 ソースを確認したところ、 親要素のCSS内にあるui-btn-textのdisplayが、上記事象が発生しているOS(現在で確認できているのは18.4.1と18.5)だと 「display: block」もしくは「display: inline-block」となっていない場合横幅がない状態として判定されています。 その為「position:absolute」かつ、「right: XXpx」という指定を行った場合、iOS18.0以前では親要素の右端から「XXpx」ずれた位置に配置される形となりますが、事象が発生しているOSでは（横幅が0として判定されるため）親要素の左端から「XXpx」ずれた位置に配置される形となっております。 【質問】 これはOS起因のバグなのか仕様変更なのか確認いただきたいです。

My assumption has always been that [NSApp runModalForWindow:] runs a modal window in NSModalPanelRunLoopMode. However, while -[NSApplication _doModalLoop:peek:] seems to use NSModalPanelRunLoopMode when pulling out the next event to process via nextEventMatchingMask:untilDate:inMode:dequeue:, the current runloop doesn't seem to be running in that mode, so during -[NSApplication(NSEventRouting) sendEvent:] of the modal-specific event, NSRunLoop.currentRunLoop.currentMode returns kCFRunLoopDefaultMode. From what I can tell, this means that any event processing code that e.g. uses [NSTimer addTimer:forMode:] based on the current mode will register a timer that will not fire until the modal session ends. Is this a bug? Or if not, is the correct way to run a modal session something like this? [NSRunLoop.currentRunLoop performInModes:@[NSModalPanelRunLoopMode] block:^{ [NSApp runModalForWindow:window]; }]; [NSRunLoop.currentRunLoop limitDateForMode:NSModalPanelRunLoopMode]; Alternatively, if the mode of the runloop should stay the same, I've seen suggestions to run modal sessions like this: NSModalSession session = [NSApp beginModalSessionForWindow:theWindow]; for (;;) { if ([NSApp runModalSession:session] != NSModalResponseContinue) break; [NSRunLoop.currentRunLoop limitDateForMode:NSModalPanelRunLoopMode]; } [NSApp endModalSession:session]; Which would work around the fact that the timer/callbacks were scheduled in the "wrong" mode. But running NSModalPanelRunLoopMode during a modal session seems a bit scary. Won't that potentially break the modality?

Hi Team! Has anyone found a reliable way to detect CarPlay connection without the app needing to be in the foreground? I’m exploring a concept where, for example, as someone nears home while driving, a prompt appears on the CarPlay screen asking “Would you like to turn on the lights / open garage?” triggered by proximity and CarPlay connection. Would be cool to have it work automatically, but knowing you're in the car is kind of important. From what I can see, apps can’t reliably detect CarPlay connection unless they’re actively open on the CarPlay screen. Most background detection methods (like external screen connect notifications) appear deprecated. That is, unless you're specifically approved as a "messaging" or "navigation" app that appear to get special privilages to send alerts from the background. If I send an alert (or poll Carplay periodically) it just gives silent/dead response. Is there any approach, framework, entitlement, or UI pattern that could allow a passive trigger or background detection while driving with CarPlay connected? I can't see any way to bring an app to the foreground either. Not looking to abuse any rules... just want to understand if anyone’s found a clean, approved workaround. Thanks in advance!

We recently migrated our app to use NavigationSplitView on iPad with a sidebar and detail setup, and we got reports that the navigation buttons on the sidebar disappear when returning to our app after using a different app. I reproduced the issue from a new empty project with the following code (issue tested on iOS 17.4 and iOS 18.3, was not able to reproduce on iOS 16.4): import SwiftUI @main struct TestApp: App { var body: some Scene { WindowGroup { NavigationSplitView { Text("sidebar") .toolbar { ToolbarItem(placement: .topBarLeading) { Button(action: {}) { Image(systemName: "square.and.arrow.down") } } ToolbarItem(placement: .topBarTrailing) { Button(action: {}) { Image(systemName: "square.and.arrow.up") } } } } detail: { Text("detail") .toolbar { ToolbarItem(placement: .topBarLeading) { Button(action: {}) { Image(systemName: "eraser") } } ToolbarItem(placement: .topBarTrailing) { Button(action: {}) { Image(systemName: "pencil") } } } } } } } Please check the following GIF for the simple steps, notice how the navbar buttons in the detail view do not disappear: Here's the console output, it shows that the constraints break internally:

In UIKit, UIButton provides a configuration property which allows us to create and customize a UIButton.Configuration instance independently (on a background thread or elsewhere) and later assign it to a UIButton instance. This separation of configuration and assignment is very useful for clean architecture and performance optimization. Questions: Is this configuration-style pattern (creating a configuration object separately and assigning it later) available or planned for other UIKit components such as UILabel, UITextField, UISlider, etc.? Similarly, in AppKit on macOS, are there any components (e.g. NSButton, NSTextField) that support a comparable configuration object mechanism that can be used the same way — constructed separately and assigned to the view later? This would help in building consistent configuration-driven UI frameworks across Apple platforms. Any insight or official guidance would be appreciated.

So I am looking to use a custom NSWindow application (so I can implement some enhanced resizing/dragging behavior which is only possible overriding NSWindow). The problem is my whole application is currently SwiftUI-based (see the project here: https://github.com/msdrigg/Roam/blob/50a2a641aa5f2fccb4382e14dbb410c1679d8b0c/Roam/RoamApp.swift). I know there is a way to make this work by dropping my @main SwiftUI app and replacing it with a SwiftUI root view hosted in a standard AppKit root app, but that feels like I'm going backwards. Is there another way to get access (and override) the root NSWindow for a SwiftUI app?

@Observable seems not to work well with generic typed throw. The following code using @Observable with non-generic typed throw builds good: @Observable class ThrowsLoadingViewModel<R, E: Error> { private(set) var isLoading = true private(set) var error: E? = nil private(set) var data: R? = nil private var task: () throws(Error) -> R init(task: @escaping () throws(E) -> R) { self.task = task } func load() { do throws(Error) { self.data = try task() } catch { // self.error = error } self.isLoading = false } } But if I change Line 7 and 14 to generic, it'll breaks the build with a "Command SwiftCompile failed with a nonzero exit code" message : @Observable class ThrowsLoadingViewModel<R, E: Error> { private(set) var isLoading = true private(set) var error: E? = nil private(set) var data: R? = nil private var task: () throws(E) -> R init(task: @escaping () throws(E) -> R) { self.task = task } func load() { do throws(E) { self.data = try task() } catch { // self.error = error } self.isLoading = false } } A the same time, if I remove @Observable, the generic typed throw works again: class ThrowsLoadingViewModel<R, E: Error> { private(set) var isLoading = true private(set) var error: E? = nil private(set) var data: R? = nil private var task: () throws(E) -> R init(task: @escaping () throws(E) -> R) { self.task = task } func load() { do throws(E) { self.data = try task() } catch { // self.error = error } self.isLoading = false } } Currently the possible solution seems to fall back to use ObservableObject...

When I run my iOS app on a Mac using Mac Catalyst, several sharing options that show up on an iOS device in a share sheet are absent on the Mac. Clicking on Edit Extensions, I see Mail, Message and AirDrop, their switches are on and disabled. All three items show up when I share from Safari or Notes. How can I make Mail, Message and AirDrop available? For example, when sharing data, no share extensions are shown. For text, only Simulator, Shortcuts and Copy are shown.

I'm using SwiftUI's TextEditor. I'd like to include an undo button in my UI that operates on the TextEditor. I don't see a way to hook this up. You can get the UndoManager from the environment, but this is not the undo manager the TextEditor is using. I know that UITextView uses an undocumented UndoManager (_UITextUndoManager) and I've accessed that before when using a UIViewRepresentable wrapper around UITextView. I'd like to achieve the same with TextEditor.

I’m having a weird UIKit problem. I have a bunch of views in a UIScrollView and I add a UIContextMenuInteraction to all of them when the view is first loaded. Because they're in a scroll view, only some of the views are initially visible. The interaction works great for any of the views that are initially on-screen, but if I scroll to reveal new subviews, the context menu interaction has no effect for those. I used Xcode's View Debugger to confirm that my interaction is still saved in the view's interactions property, even for views that were initially off-screen and were then scrolled in. What could be happening here?

I would like to have different fill colors in my chart. What I want to achieve is that if the values drop below 0 the fill color should be red. If they are above the fill color should be red. My code looks as follows: import SwiftUI import Charts struct DataPoint: Identifiable {     let id: UUID = UUID()     let x: Int     let y: Int } struct AlternatingChartView: View {          enum Gradients {         static let greenGradient = LinearGradient(gradient: Gradient(colors: [.green, .white]), startPoint: .top, endPoint: .bottom)         static let blueGradient = LinearGradient(gradient: Gradient(colors: [.white, .blue]), startPoint: .top, endPoint: .bottom)     }          let data: [DataPoint] = [         DataPoint(x: 1, y: 10),         DataPoint(x: 2, y: -5),         DataPoint(x: 3, y: 20),         DataPoint(x: 4, y: -8),         DataPoint(x: 5, y: 15),     ]               var body: some View {         Chart {             ForEach(data) { data in                 AreaMark(                     x: .value("Data Point", data.x),                     y: .value("amount", data.y))                 .interpolationMethod(.catmullRom)                 .foregroundStyle(data.y < 0 ? Color.red : Color.green)                                  LineMark(                 x: .value("Data Point", data.x),                 y: .value("amount", data.y))                 .interpolationMethod(.catmullRom)                 .foregroundStyle(Color.black)                 .lineStyle(StrokeStyle.init(lineWidth: 4))                              }         }         .frame(height: 200)     } } #Preview {     AlternatingChartView() } The result looks like this: I also tried using foregroundStyle(by:) and chartForegroundStyleScale(_:) but the result was, that two separate areas had been drawn. One for the below and one for the above zero datapoints. So, what would be the right approach to have two different fill colors?

I have created an AppIntent and added it to shortcuts to be able to read by Siri. When I say the phrase, the Siri intent dialog appears just fine. I have added a custom SwiftUI View inside Siri dialog box with 2 buttons with intents. The callback or handling of those buttons is not working when initiated via Siri. It works fine when I initiate it in shortcuts. I tried using the UIButton without the intent action as well but it did not work. Here is the code. static let title: LocalizedStringResource = "My Custom Intent" static var openAppWhenRun: Bool = false @MainActor func perform() async throws -> some ShowsSnippetView & ProvidesDialog { return .result(dialog: "Here are the details of your order"), content: { OrderDetailsView() } } struct OrderDetailsView { var body: some View { HStack { if #available(iOS 17.0, *) { Button(intent: ModifyOrderIntent(), label : { Text("Modify Order") }) Button(intent: CancelOrderIntent(), label : { Text("Cancel Order") }) } } } } struct ModifyOrderIntent: AppIntent { static let title: LocalizedStringResource = "Modify Order" static var openAppWhenRun: Bool = true @MainActor func perform() async throws -> some OpensIntent { // performs the deeplinking to app to a certain page to modify the order } } struct CancelOrderIntent: AppIntent { static let title: LocalizedStringResource = "Cancel Order" static var openAppWhenRun: Bool = true @MainActor func perform() async throws -> some OpensIntent { // performs the deeplinking to app to a certain page to cancel the order } } Button(action: { if let url = URL(string: "myap://open-order") { UIApplication.shared.open(url) } }

Hey! Our team is experiencing some issue in a large SwiftUI application. When loading large views, the app crashes with a EXC_BAD_ACCESS signal. This signal can be reported by Xcode either on the @main attribute, inside a view hierarchy, or any order property that is accessed in the view hierarchy. After some investigation we found several possible workarounds: Splitting up the view into smaller subviews Wrapping parts of the view into an AnyView, which isn't ideal. However, this only temporarily solved the issue. As the app becomes bigger, we run into this problem more frequently. When trying to reproduce this issue in a clean Xcode project, I came up with the following: struct ContentView: View { var body: some View { Text("Hello") .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} .task {} } } When running this, the app immediately crashes on an iPhone 14 (YMMV on different (newer) devices). Of course such a view is not very likely to occur, but in total a view hierarchy could have this many view modifiers. Is there some limit we should we aware of? How can we circumvent this? Thanks!

Description When using UIDocumentPickerViewController with allowsMultipleSelection = false, I expect that selecting a file will dismiss only the document picker. However, if a user quickly taps the same file multiple times, the picker dismisses both itself and the presenting view controller (i.e., it pops two levels from the view controller stack), which leads to unintended behavior and breaks presentation flow. Expected Behavior Only UIDocumentPickerViewController should be dismissed when a file is selected—even if the user taps quickly or multiple times on the same file. Actual Behavior When tapping the same file multiple times quickly, the picker dismisses not only itself but also the parent view controller it was presented from. Steps to Reproduce Create a simple view controller and present another one modally over it. From that presented view controller, present a UIDocumentPickerViewController with allowsMultipleSelection = false. Tap quickly on the same file in the picker 2 times. Result: Both the document picker and the presenting view controller are dismissed. Reproducible Code Snippet class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .green addLabel("Parent View Controller") DispatchQueue.main.async { [unowned self] in let child = UIViewController() child.view.backgroundColor = .yellow present(child, animated: true) child.addLabel("Child View Controller") let vc = UIDocumentPickerViewController( forOpeningContentTypes: [.pdf, .jpeg, .png], asCopy: true ) vc.allowsMultipleSelection = false child.present(vc, animated: true) } } } extension UIViewController { func addLabel(_ text: String) { let label = UILabel(frame: CGRect(x: 0, y: 50, width: view.bounds.width, height: 30)) label.text = text view.addSubview(label) } } Environment Device: iPhone 15 Pro and others iOS version: 18.2 (reproduces on multiple iOS versions) Occurs with: .pdf, .jpeg, .png file types Mode: Both simulator and real device Notes Happens consistently with fast multiple taps on the same file. This breaks expected view controller stack behavior.

Hi, I've got an app that displays markdown in UITextView / NSTextView. I would like it to behave like Notes app does, that is if user types the line start modifier, e.g: "# " or "> " I would like the keyboard to show a capitalized letters. I've tried looking into overriding insertText - and it breaks the predictive text (can not insert white space). I've tried implementing UITextInputTokenizer but no luck either. Like I said, I see the Notes app does it perfectly, so maybe I'm missing something obvious or there is a way to do it without interrupting the auto-correction and predictive text. Ideally same thing can be applied to the NSTextView as the app support both platforms.

I am currently developing an AR experience using ARKit with SceneKit and am looking to implement functionality that enables: Zooming into the AR camera feed, ideally leveraging the ultra-wide or telephoto lenses available on supported devices. Macro-style focus capabilities, allowing users to view and interact with virtual content closely aligned with small or nearby real-world objects (within a few centimeters). My objective is to ensure that ARKit continues to render the scene accurately while enabling a zoomed-in view or macro-level focus for better detail visibility and alignment. Could you please advise on: Whether ARKit currently supports camera zoom or allows access to macro or ultra-wide cameras within an ARSession. Limitations or considerations when using multi-camera setups in conjunction with ARKit. Any guidance or references to documentation or sample code would be greatly appreciated. Best regards, Ayush

So I'm dealing with a really obtuse crash that appears to be a stack overflow in an internal SwiftUI code path creating a Color.Resolved. I haven't found anyone one else with this issue online, and I cannot get it to reproduce on my own device. Interestingly enough, it is only happening on 1 device in the field (according to XCode crash logs). Here are some lines from the crashed thread. You can see that my code is never called, and it appears to be starting in some Array equality check checking the equality of colors (which I can't think of anywhere in my app I am doing anyway). You can see from this trace here that it appears to be a recursive call through Color.Resolved and NSColor.withColorAppearance. I don't have any idea how to solve this, but it keeps happening with at least one in-the-field device across multiple app updates. So my whole app is open source on github at https://github.com/msdrigg/roam, but I don't even use NSColor explicitly anywhere except for here which doesn't match the stack trace. I also tried changing the accent color of the app with defaults write com.msdrigg.roam AppleAccentColor -integer 1 to see if that somehow caused the crash, but my app opened up totally fine (and respected the change). Besides this, the only places I think I could be using dynamic colors is I when define an AccentColor and a WidgetBackground color for my app using xcassets, and then I use these colors from SwiftUI. In most of my app I stick to the system colors (Color.gray and such). Thread 0 Crashed: 0 libsystem_pthread.dylib 0x000000018601213c ___chkstk_darwin + 60 1 CoreFoundation 0x0000000186108434 -[NSArray isEqualToArray:] + 52 (NSArray.m:454) 2 AppKit 0x000000018a21fcd4 -[NSCoreUICatalogColor resolvedCUINamedColorForAppearance:] + 164 (NSColor.m:5057) 3 AppKit 0x0000000189c32cd4 -[NSCoreUICatalogColor resolvedColor] + 48 (NSColor.m:5148) 4 AppKit 0x0000000189c31e74 -[NSDynamicNamedColor colorUsingColorSpace:] + 32 (NSColor.m:4410) 5 SwiftUICore 0x0000000221ca9fd8 CoreColorPlatformColorGetComponents + 116 (CoreColorFunctions.m:149) 6 SwiftUICore 0x0000000221faaf28 specialized Color.Resolved.init(platformColor:) + 92 (CoreColor.swift:14) 7 SwiftUICore 0x0000000221faa5b0 Color.Resolved.init(platformColor:) + 16 (<compiler-generated>:0) 8 SwiftUI 0x00000001b53b1dc4 closure #1 in NSColor.resolve(in:) + 20 (AppKitColorConversions.swift:156) 9 SwiftUI 0x00000001b53b222c partial apply for closure #1 in static NSColor.withColorAppearance(in:_:) + 32 (<compiler-generated>:0) 10 SwiftUI 0x00000001b46b1e54 closure #1 in SubmitTriggerSource.dispatchUpdate(_:) + 28 (PlatformViewCoordinator.swift:12) 11 SwiftUI 0x00000001b5484488 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0) 12 AppKit 0x0000000189c174a4 +[NSAppearance _performWithCurrentAppearance:usingBlock:] + 72 (NSAppearance.m:2408) 13 SwiftUI 0x00000001b53b2088 specialized static NSColor.withColorAppearance(in:_:) + 324 (AppKitColorConversions.swift:142) 14 SwiftUI 0x00000001b53b1e7c protocol witness for ColorProvider.resolve(in:) in conformance NSColor + 68 (<compiler-generated>:151) 15 SwiftUICore 0x0000000222436e6c ColorBox.resolve(in:) + 124 (Color.swift:288) 16 SwiftUICore 0x0000000222435e30 Color.resolve(in:) + 72 (Color.swift:87) 17 SwiftUI 0x00000001b53b1c88 closure #1 in NSColor.init(_:) + 196 (AppKitColorConversions.swift:124) 18 SwiftUI 0x00000001b4542714 thunk for @escaping @callee_guaranteed (@guaranteed NSAppearance) -> (@owned NSColor) + 56 (<compiler-generated>:0) 19 AppKit 0x0000000189c31e74 -[NSDynamicNamedColor colorUsingColorSpace:] + 32 (NSColor.m:4410) //// ... Repeating for 500 lines 500 SwiftUICore 0x0000000221ca9fd8 CoreColorPlatformColorGetComponents + 116 (CoreColorFunctions.m:149) 501 SwiftUICore 0x0000000221faaf28 specialized Color.Resolved.init(platformColor:) + 92 (CoreColor.swift:14) 502 SwiftUICore 0x0000000221faa5b0 Color.Resolved.init(platformColor:) + 16 (<compiler-generated>:0) 503 SwiftUI 0x00000001b53b1dc4 closure #1 in NSColor.resolve(in:) + 20 (AppKitColorConversions.swift:156) 504 SwiftUI 0x00000001b53b222c partial apply for closure #1 in static NSColor.withColorAppearance(in:_:) + 32 (<compiler-generated>:0) 505 SwiftUI 0x00000001b46b1e54 closure #1 in SubmitTriggerSource.dispatchUpdate(_:) + 28 (PlatformViewCoordinator.swift:12) 506 SwiftUI 0x00000001b5484488 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0) 507 AppKit 0x0000000189c174a4 +[NSAppearance _performWithCurrentAppearance:usingBlock:] + 72 (NSAppearance.m:2408) 508 SwiftUI 0x00000001b53b2088 specialized static NSColor.withColorAppearance(in:_:) + 324 (AppKitColorConversions.swift:142) 509 SwiftUI 0x00000001b53b1e7c protocol witness for ColorProvider.resolve(in:) in conformance NSColor + 68 (<compiler-generated>:151) 510 SwiftUICore 0x0000000222436e6c ColorBox.resolve(in:) + 124 (Color.swift:288) full-log.crash

We are experiencing an issue with session sharing on iOS and would appreciate your guidance. We operate and control our own OpenID Connect (OIDC) server. Our iOS application uses ASWebAuthenticationSession to authenticate users. We're unable to get the authentication session to be shared between the Safari app and the app's ASWebAuthenticationSession. This results in users having to re-authenticate despite being logged in via Safari. We've attempted various configurations related to cookie SameSite settings. These adjustments resolved the session sharing issue on Android using Chrome Custom Tabs. However, no changes we've tried have enabled session sharing to work as expected on iOS. According to documentation from Apple, Microsoft, Okta, and Auth0, session sharing between Safari and ASWebAuthenticationSession should work. Question: Are there any additional settings, configurations, or platform limitations we should be aware of that could impact session sharing on iOS? Where else can we look to resolve this issue?

There has been a long lasting UIStackView bug dating back to 2016 that still exists in the latest Xcode 16.3 and SDKs, where calling setHidden:true multiple times (lets say twice) on a subview of that stack view requires calling setHidden:false twice before the subview shows up again. This was originally documented via Radar #25087688. Hopefully a Frameworks Engineer here on the forums can raise it to the attention of the appropriate engineers. It would be really nice if this eventually gets fixed, because it's one of those odd issues where you end up wasting a lot of time trying to debug because everything looks correct.

Xcode 16 iOS18 WKWebView里包含http图片时无法显示