I'm trying to do something so seemingly basic, yet I can't get it to work and I'm flummoxed. In a basic, vanilla SwiftUI app for tvOS, embed a single Text element with a very long string (hundreds of lines) in it: struct ContentView: View { var body: some View { ScrollView(.vertical) { Text(veryLargeString) .focusable() } } } Then fire up the app on tvOS, and it will not scroll. No matter what I do. Pressing arrow keys, swiping fast with my thumb, and nothing. It will not move. Ironically, in the Xcode SwiftUI Preview window—it does scroll, so that's always a fun tease. What I do know is that the focus engine is throwing a few errors, so it's leading me to believe the issue is with how I have the focusable element attached. I'm using a combination of -UIFocusLoggingEnabled YES as well as listening for UIFocusSystem.movementDidFailNotification. Unfortunately since this is SwiftUI, the notification failure and debugging logs aren't really all that actionable. Help appreciated!

I have some really straight forward code in a sample project. For some reason when the app launches the title is blurred obscured by scrolledgeeffect blur. If I scroll down the title goes small as it should do and all looks fine. If I scroll back to the top, just before it reaches the top the title goes large and it looks correct, but once it actually reaches/snaps to the top, is then incorrectly blurs again. Is there anything obvious I'm doing wrong? Is this a bug? struct ContentView: View { var body: some View { NavigationStack { ScrollView { VStack { Rectangle().fill(Color.red.opacity(0.2)).frame(height: 200) Rectangle().frame(height: 200) Rectangle().frame(height: 200) Rectangle().frame(height: 200) Rectangle().frame(height: 200) } } .safeAreaBar(edge: .top) { Text("Test") } .navigationTitle(Title") } } }

When I dismiss a view presented with .navigationTransition(.zoom), the source view gets a weird background (black or white depending on the appearance) for a couple of seconds, and then it disappears. Here’s a simple code example. import SwiftUI struct NavigationTransition: View { @Namespace private var namespace @State private var isSecondViewPresented = false var body: some View { NavigationStack { ZStack { DetailView(namespace: namespace) .onTapGesture { isSecondViewPresented = true } } .fullScreenCover(isPresented: $isSecondViewPresented) { SecondView() .navigationTransition(.zoom(sourceID: "world", in: namespace)) } } } } struct DetailView: View { var namespace: Namespace.ID var body: some View { ZStack { Color.blue Text("Hello World!") .foregroundStyle(.white) .matchedTransitionSource(id: "world", in: namespace) } .ignoresSafeArea() } } struct SecondView: View { var body: some View { ZStack { Color.green Image(systemName: "globe") .foregroundStyle(Color.red) } .ignoresSafeArea() } } #Preview { NavigationTransition() }

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

Summary As presented in the SwiftUI WWDC video, the new tabViewBottomAccessory should allow for unique contents for .inline. This is what was presented as being used for the Apple Music miniplayer. However, the functionality seems to be either missing or unintuitive. As seen in the photos attached, not only does .inline functionality not seem to do anything, but the inline accessory also has misaligned elements that cannot be fixed by conditionally modifying the contents. Build Target iOS 26.0 Details This problem recurs on physical devices, simulators, and Xcode previews. Here is a view I've constructed for use as a tabViewBottomAccessory: struct FitnessToolbarAccessory: View { @Environment(\.tabViewBottomAccessoryPlacement) var placement var body: some View { if (placement == .inline) { Text("hello") } else { HStack { HStack { Image(systemName: "dumbbell.fill") VStack(alignment: .leading) { Text("Active Workout") Text("Push Day - Chest") .font(.system(size: 13)) } Spacer() Image(systemName: "pause.fill") } .padding() } } } } Here is the result, working as expected in expanded mode: And here is the result in inline mode after minimizing the tabViewBottomAccessory: The content of this inline accessory is clearly incorrect, as it was specified to contain a Text view containing "hello". Additionally, the contents seem to have some incorrect alignment. This occurs regardless of the contents of the accessory, even plain text.

Right now, the traffic light buttons overlapped on my iPad app top corner on windows mode (full screen is fine). How do I properly design my app to avoid the traffic light buttons? Detect that it is iPadOS 26?

Using an App Clip link encoded into a QR Code shows an error when scanning the encoded QR Code on an iPhone or iPad. After being scanned, the App Clip's banner is visible, but a message says: "App Clip Unavailable". Accessing the same App Clip URL via Safari works as expected. I've filed a feedback with more details and screenshots of the issue here: FB17891015 Thanks!

Hello, I'm using LongPressGesture to provide haptic & color change feedback on a long press action. This fails to call the .updating(_:body:) method on every iOS 18.0 beta. It works fine on iOS 17. The following code, taken directly from Apple's documentation illustrates the problem. The .updating() closure is never called, while the .onEnded() closure is called correctly. Instead of a gradual color transition the example code generates a delayed sharp switch from Red to Blue, preventing interactive user feedback. struct LongPressGestureView: View { @GestureState private var isDetectingLongPress = false @State private var completedLongPress = false var longPress: some Gesture { LongPressGesture(minimumDuration: 3) .updating($isDetectingLongPress) { currentState, gestureState, transaction in gestureState = currentState transaction.animation = Animation.easeIn(duration: 2.0) } .onEnded { finished in self.completedLongPress = finished } } var body: some View { Circle() .fill(self.isDetectingLongPress ? Color.red : (self.completedLongPress ? Color.green : Color.blue)) .frame(width: 100, height: 100, alignment: .center) .gesture(longPress) } } Can anyone share tips on a workaround or potential fix application-side?

I have installed the iOS 26 Beta on my device and conducted a comprehensive functionality test of my iOS application, which I designed and developed. The application includes a feature that allows users to share images directly to X (formerly Twitter) and Facebook. During testing, I encountered an issue where the icons for X (formerly Twitter) and Facebook do not appear in the share dialog, despite both apps being installed on the device. This issue prevents users from sharing images to these platforms directly from the app. Steps to Reproduce: 1.Install iOS 26 Beta on a compatible device. 2.Ensure that both the X (formerly Twitter) and Facebook apps are installed and logged in on the device. 3.Open the iOS application and navigate to the image sharing feature. 4.Attempt to share an image using the share dialog. 5.Observe that the icons for X (formerly Twitter) and Facebook are missing from the share options. Expected Behavior: The share dialog should display icons for X (formerly Twitter) and Facebook, allowing users to share images directly to these platforms. Actual Behavior: The icons for X (formerly Twitter) and Facebook do not appear in the share dialog, preventing direct sharing to these platforms. Code Implementation: I have not implemented any code to exclude X (formerly Twitter) and Facebook from the share options. Below is the relevant code for controlling the share screen: let activityViewController = UIActivityViewController(activityItems: activityItems, applicationActivities: applicationActivities) let excludedTypes = [ UIActivity.ActivityType.assignToContact, UIActivity.ActivityType.print, ] activityViewController.excludedActivityTypes = excludedTypes activityViewController.completionWithItemsHandler = completion self.present(activityViewController, animated: true, completion: nil) As shown in the implementation, there is no exclusion of X (formerly Twitter) and Facebook, yet their icons do not appear in the share dialog.

I am trying to learn Xcode and swift ui for a class project but the attribute inspector just does not show up, I can have the simulator open or closed I click on it nothing works. I feel so stupid. I suppose you don't need it but it helps a lot. anyone have any trouble shooting that could help?

The sample code provided in "Building a document-based app with SwiftUI" (https://developer.apple.com/documentation/swiftui/building-a-document-based-app-with-swiftui) does not work as expected. The DocumentGroup/StoryView toolbar does not appear for documents opened in the App. By removing the DocumentGroupLaunchScene block from the App the toolbar does appear and works as expected - but of course the App's DocumentGroupLaunchScene customizations are lost. I've tested this on 18.0 devices, as well as production 18.0 and 18.1 beta 6 simulators. If I modify the StoryView by wrapping the content in a NavigationStack I can make some progress - but the results are unstable and hard to pin down - with this change the first time a document is opened in the WritingApp the toolbar appears as expected. When opening a document subsequently the toolbar is corrupted. Please is this a bug or is there a good example of incorporate both DocumentGroupLaunchScene customizations at the App level and retina the toolbar in documents presented via DocumentGroup?

When you touch down on a button in a scroll view, you can cancel the tap by scrolling. In SwiftUI, this works correctly when the scroll view is not inside a dismissible sheet. However, if the scroll view is inside a sheet that can be dismissed with a drag gesture, scrolling does not cancel the button touch, and after scrolling, the button tap is activated. This happens whether the modal is presented from SwiftUI using the sheet modifier, or wrapped in a UIHostingController and presented from UIKit. This is a huge usability issue for modals with scrollable content that have buttons inside of them. Video of behavior: https://youtube.com/shorts/w6eqsmTrYiU Easily reproducible with this code: import SwiftUI struct ContentView: View { @State private var isPresentingSheet = false var body: some View { ScrollView { LazyVStack { ForEach(0..<100, id: \.self) { index in Button { isPresentingSheet = true } label: { Text("Button \(index)") .padding(.horizontal) .padding(.vertical, 5) .frame(maxWidth: .infinity, alignment: .leading) } } } .padding() } .sheet(isPresented: $isPresentingSheet) { ContentView() } } }

While testing my application on iOS beta 26, I am experiencing issues with the native UISegmentedControl component from UIKit. After implementing the control, I noticed that I am unable to switch to the second segment option—the selection remains fixed on the first segment regardless of user interaction. I have already reviewed the initial configuration of the control, the addition of the segments, and the implementation of the target-action, but the issue persists. I would like to understand what could be causing this behavior and if there are any specific adjustments or workarounds for iOS 26. I created a minimal application containing only a UISegmentedControl to clearly demonstrate the issue.

We have encountered a problem on iOS 26. When switching to dark mode, the color of all subviews (font color, background color, etc.) of the Sidebar (Primary View) of UISplitViewController will not change. For example, if it is set to the color of UIColor.label, it will always be black and will not be white in dark mode. On Xcode, just create a UISplitViewController in Storyboard without changing any settings, and run it directly to see the following: The title of the Navigation Bar defaults to the label color, and it is still black after switching to dark mode. There is no such problem in the Secondary View or other places. This problem has occurred since iOS 26 beta 3, and iOS 26 beta 4 is now the same. But beta 1 and beta 2 have no problem. I'm not sure if this is a bug, or if there is something that needs to be changed to adapt to iOS 26?

It looks like we're encountering a similar hitTest issue to what we had with iOS Xcode 16 + iOS 18. When running Xcode 26 + iOS 26, rootViewController?.view.subviews is returning an empty array, even though the views are clearly present in the hierarchy. Last year, we "fixed" this issue using the code attached, but it doesn't seem to work anymore with iOS 26. Any suggestions would be greatly appreciated! private class PassthroughWindow: UIWindow { override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? { guard let hitView = super.hitTest(point, with: event), let rootView = rootViewController?.view else { return nil } if #available(iOS 18, *) { for subview in rootView.subviews.reversed() { let convertedPoint = subview.convert(point, from: rootView) if subview.hitTest(convertedPoint, with: event) != nil { return hitView } } return nil } else { return hitView == rootView ? nil : hitView } } }

My app uses the SwiftUI Map control to display annotations. When annotations contain buttons AND the map has an .onTapGesture modifier, annotation button taps aren’t always recognized. Given the following ContentView, run it on an iOS device or simulator. Tap the buttons. Since iOS 18.0, some of the buttons won't respond to tap. I've also tried using the onTapGesture instead of a button, and that shows the same issue. This was not a problem under iOS 17.x: it has only shown up for my users since updating to iOS 18. Additionally, this issue does not occur when running on either macOS 15.0 or visionOS 2.0 when running in "designed for iPad" mode. Note that there was previously a tap issue on VisionOS 1.x (designed for iPad), where no tap gestures were received by annotations. I'm curious if this issue could be related. I have filed a report in Feedback Assistant (FB15273909). struct ContentView: View { private let center = CLLocationCoordinate2D(latitude: 37.77925, longitude: -122.41924) @State private var label: String = "tap a button" @State private var locations: [Location] = [] var body: some View { Map { ForEach(locations) { location in Annotation(location.name, coordinate: location.coordinate) { Button(location.name) { print("\(location.name) tapped") label = "\(location.name) tapped" } .buttonStyle(.borderedProminent) } .annotationTitles(.hidden) } } .onTapGesture { point in print("Map tapped") label = "map tapped" } .safeAreaInset(edge: .top) { Text(label) .padding() .background(.thinMaterial) .clipShape(.rect(cornerRadius: 10)) } .navigationTitle("Test Page") .navigationBarTitleDisplayMode(.inline) .task { for index in 1...16 { locations.append(Location(name: "location \(index)", coordinate: CLLocationCoordinate2D(latitude: center.latitude + Double.random(in: -0.02...0.02), longitude: center.longitude + Double.random(in: -0.02...0.02)))) } } } private struct Location: Identifiable { let id: UUID = UUID() let name: String let coordinate: CLLocationCoordinate2D } } #Preview { ContentView() }

I'm running into a persistent problem with the iOS 18.5 simulator in Xcode 26 beta 2. I have built a very simple test app with a storyboard that includes only a toolbar added to the ViewController scene in the storyboard. The test app runs fine in iOS 26 simulators.When I try to run it in the iOS 18.5 simulator for iPhone Pro or iPad (16), it fails while unarchiving the storyboard (as far as I can tell) with this error message in the Xcode console: *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' terminating due to uncaught exception of type NSException CoreSimulator 1043 - Device: iPad (A16) (3E70E25F-8434-4541-960D-1B58EB4037F3) - Runtime: iOS 18.5 (22F77) - DeviceType: iPad (A16) I'd love a simple workaround for this.

When displaying a view with a Button inside a ScrollView using the sheet modifier, if you try to close the sheet by swiping and your finger is touching the Button, the touch is not canceled. This issue occurs when building with Xcode 16 but does not occur when building with Xcode 15. Here is screen cast. https://drive.google.com/file/d/1GaOjggWxvjDY38My4JEl-URyik928iBT/view?usp=sharing Code struct ContentView: View { @State var isModalPresented: Bool = false var body: some View { ScrollView { Button { debugPrint("Hello") isModalPresented.toggle() } label: { Text("Hello") .frame(height: 44) } Button { debugPrint("World") } label: { Text("World") .frame(height: 44) } Text("Hoge") .frame(height: 44) .contentShape(Rectangle()) .onTapGesture { debugPrint("Hoge") } } .sheet(isPresented: $isModalPresented) { ContentView() } } }

Hi, I'm seeing an issue in iOS 26 beta related to UINavigationBar rendering in landscape. When a background color is set for the navigation bar and the device is rotated to landscape, an unexpected gap appears above the navigation bar. This also happens in the official sample project provided in Apple’s documentation: https://developer.apple.com/documentation/uikit/customizing-your-app-s-navigation-bar Is this a bug in the beta, or is there a workaround to avoid this behavior? Thanks in advance!

Hello Apple Developer Community: I have a problem with the fullscreencover. I can see the Things, that shouldn’t be visible behind it. I’m currently developing with iOS 26 and only there it happens. I hope you can help me :) Have a nice day