I'm building a macOS app using SwiftUI and I recently updated to xcode 14.3. Since then I've been debugging why none of my animations were working, it turned out that the NavigationSplitView or NavigationStack are somehow interfering with all the animations from withAnimation to .transition() and everything in between. Is anyone else experiencing this, knows a work around or knows why this is happening?

I'm being faced with an issue when using SwiftUI's WebView on iOS 26. In many websites, the top/bottom content is unaccessible due to being under the app's toolbars. It feels like the WebView doesn't really understand the safe areas where it's being shown, because the content should start right below the navigation bar, and only when the user scrolls down, the content should move under the bar (but it's always reachable if the users scroll back up). Here's a demo of the issue: Here's a 'fix' by ensuring that the content of the WebView never leaves its bounds. But as you can see, it feels out of place on iOS 26 (would be fine on previous OS versions if you had a fully opaque toolbar): Code: struct ContentView: View { var body: some View { NavigationStack { WebView(url: URL(string: "https://apple.com")).toolbar { ToolbarItem(placement: .primaryAction) { Button("Top content covered, unaccessible.") {} } } } } } Does anyone know if there's a way to fix it using some sort of view modifier combination or it's just broken as-is?

Basic Information Please provide a descriptive title for your feedback: Sheet presentationDetents breaks after rapid open/dismiss cycles Which platform is most relevant for your report? iOS Description Steps to Reproduce: Create a sheet with presentationDetents([.medium]) Rapidly perform these actions multiple times (usually 3-4 times): a. Open the sheet b. Immediately scroll down to dismiss Open the sheet again Observe that the sheet now appears at .large size, ignoring the .medium detent Expected Result: Sheet should consistently maintain .medium size regardless of how quickly it is opened and dismissed. Actual Result: After rapid open/dismiss cycles, the sheet ignores .medium detent and appears at .large size. Reproduction Rate: Occurs consistently after 3-4 rapid open/dismiss cycles More likely to occur with faster open/dismiss actions Configuration: iOS 18 Xcode 16.0 (16A242d) SwiftUI Device: iPhone 14

Hi, I am in need of a solution that takes data from SwiftData classes and generates a PDF with the given data. Any guidance would be greatly appreciated.

I have an app with a TabView containing a view representable containing a SwiftUI View with a toolbar. The representable is providing the toolbar while the .toolbar modifier provides the content. Everything works normally on iOS 17, but on iOS 18 the toolbar contents are not showing. Is this a iOS 18 bug? See the code below for a simplified example. import SwiftUI @main struct TestApp: App { @State var selection: String = "one" var body: some Scene { WindowGroup { TabView(selection: $selection) { Representable() .tabItem { Text("One") } .tag("one") } } } } struct Representable: UIViewControllerRepresentable { let navigationController = UINavigationController() func makeUIViewController(context: Context) -> UINavigationController { navigationController.pushViewController(UIHostingController(rootView: ToolbarView()), animated: false) return navigationController } func updateUIViewController(_ uiViewController: UINavigationController, context: Context) {} } struct ToolbarView: View { var body: some View { NavigationLink("Navigate") { ToolbarView() } .toolbar { ToolbarItem(placement: .principal) { Text("Top") } } } }

I'm receiving reports from users that my app is crashing immediately after being opened on the Apple Watch Series 10 using watchOS 11. I've updated my personal Apple Watch Series 8 to watchOS 11 and I'm unable to reproduce this crash using the same release build from the App Store. The version currently on the App Store was built using Xcode 15.4 (22622). I'm preparing an update that is built using Xcode 16.0 (23051) and have asked one of the users reporting the crash to try a TestFlight build built using Xcode 16.0 and they are no longer experiencing this crash. As far as I can tell, the only difference between the version on the App Store and the TestFlight build is that it is built with the watchOS 11 SDK included with Xcode 16.0. I don't think any of my app's dependencies (all managed by Swift Package Manager) have been updated in the TestFlight build. I'm attaching a crash report submitted by one of the users. I believe this is a partially symbolicated crash report and have tried opening it in Xcode in an attempt to make it fully symbolicated without success. I've also received a video recording of the app crashing. I'm also not able to see any crashes occurring with an Apple Watch Series 10 in the Xcode Organizer, which leads me to believe this crash may be occurring at the Springboard level. Any help to further diagnose this issue would be much appreciated.

Is it possible to specify a default window size for a 2D window in visionOS? I know this is normally achieved by modifying the WindowGroup with .defaultSize(width:height:), but I get an error that this was not included in "xrOS". I am able to specify .defaultSize(width:height:depth:) for a volumetric window, but this doesn't have any effect when applied to a 2D one.

NavigationTitle does not change when the app language changes. It works well in iOS 17.5 but does not in iOS 18.x

In this app, I set the preferredColorScheme in main @main struct TheApp: App { @AppStorage("isDarkMode") private var isDarkMode = false var body: some Scene { WindowGroup { ContentView() .preferredColorScheme(isDarkMode ? .dark : .light) } } } isDarkMode is changed dynamically in code. When code is compiled with Xcode 15.3, the background of ContentView changes from light to dark or vice versa. When compiled with Xcode 16, no more change. However, direct changes to objects do work, such as: TextField("N", value: $t, format: .number) .frame(width: 40) .background(isDarkMode ? .gray : .white) What has changed in Xcode 16 ? Is it documented somewhere ? I saw this SO thread which describe similar problem. https://www.reddit.com/r/swift/comments/upkprg/preferredcolorscheme_toggle_not_working/

How can we performantly scroll to a target location using TextKit 2? Hi everyone, I'm building a custom text editor using TextKit 2 and would like to scroll to a target location efficiently. For instance, I would like to move to the end of a document seamlessly, similar to how users can do in standard text editors by using CMD + Down. Background: NSTextView and TextEdit on macOS can navigate to the end of large documents in milliseconds. However, after reading the documentation and experimenting with various ideas using TextKit 2's APIs, it's not clear how third-party developers are supposed to achieve this. My Code: Here's the code I use to move the selection to the end of the document and scroll the viewport to reveal the selection. override func moveToEndOfDocument(_ sender: Any?) { textLayoutManager.ensureLayout(for: textLayoutManager.documentRange) let targetLocation = textLayoutManager.documentRange.endLocation let beforeTargetLocation = textLayoutManager.location(targetLocation, offsetBy: -1)! textLayoutManager.textViewportLayoutController.layoutViewport() guard let textLayoutFragment = textLayoutManager.textLayoutFragment(for: beforeTargetLocation) else { return } guard let textLineFragment = textLayoutFragment.textLineFragment(for: targetLocation, isUpstreamAffinity: true) else { return } let lineFrame = textLayoutFragment.layoutFragmentFrame let lineFragmentFrame = textLineFragment.typographicBounds.offsetBy(dx: 0, dy: lineFrame.minY) scrollToVisible(lineFragmentFrame) } While this code works as intended, it is very inefficient because ensureLayout(_:) is incredibly expensive and can take seconds for large documents. Issues Encountered: In my attempts, I have come across the following two issues. Estimated Frames: The frames of NSTextLayoutFragment and NSTextLineFragment are approximate and not precise enough for scrolling unless the text layout fragment has been fully laid out. Laying out all text is expensive: The frames become accurate once NSTextLayoutManager's ensureLayout(for:) method has been called with a range covering the entire document. However, ensureLayout(for:) is resource-intensive and can take seconds for large documents. NSTextView, on the other hand, accomplishes the same scrolling to the end of a document in milliseconds. I've tried using NSTextViewportLayoutController's relocateViewport(to:) without success. It's unclear to me whether this function is intended for a use case like mine. If it is, I would appreciate some guidance on its proper usage. Configuration: I'm testing on macOS Sonoma 14.5 (23F79), Swift (AppKit), Xcode 15.4 (15F31d). I'm working on a multi-platform project written in AppKit and UIKit, so I'm looking for either a single solution that works in both AppKit and UIKit or two solutions, one for each UI framework. Question: How can third-party developers scroll to a target location, specifically the end of a document, performantly using TextKit 2? Steps to Reproduce: The issue can be reproduced using the example project (download from link below) by following these steps: Open the example project. Run the example app on a Mac. The example app shows an uneditable text view in a scroll view. The text view displays a long text. Press the "Move to End of Document" toolbar item. Notice that the text view has scrolled to the bottom, but this took several seconds (~3 seconds on my MacBook Pro 16-inch, 2021). The duration will be shown in Xcode's log. You can open the ExampleTextView.swift file and find the implementation of moveToEndOfDocument(_:). Comment out line 84 where the ensureLayout(_:) is called, rerun the app, and then select "Move to End of Document" again. This time, you will notice that the text view moves fast but does not end up at the bottom of the document. You may also open the large-file.json in the project, the same file that the example app displays, in TextEdit, and press CMD+Down to move to the end of the document. Notice that TextEdit does this in mere milliseconds. Example Project: The example project is located on GitHub: https://github.com/simonbs/apple-developer-forums/tree/main/how-can-we-performantly-scroll-to-a-target-location-using-textkit-2 Any advice or guidance on how to achieve this with TextKit 2 would be greatly appreciated. Thanks in advance! Best regards, Simon

How can I put navigation into an existing program?

I'm working on a NavigationStack based app. Somewhere I'm using: @Environment(\.dismiss) private var dismiss and when trying to navigate to that view it gets stuck. I used Self._printChanges() and discovered the environment variable dismiss is changing repeatedly. Obviously I am not changing that variable explicitly. I wasn't able to reproduce this in a small project so far, but does anybody have any idea what kind of thing I could be doing that might be causing this issue? iOS 17.0.3

When I build my app for iPad OS, either 26, or 18.5, as well as iOS on 16.5 from Xcode 26 with UIDesignRequiresCompatibility enabled my app is crashing as it loads the main UIViewController, a subclassed UITabBarController which is being loaded programatically from a Storyboard from another SplashScreen ViewController. On i(Pad)OS 18.5 I get this error: Thread 1: "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)" On iPadOS 26 I get this error: UIKitCore/UICoreHostingView.swift:54: Fatal error: init(coder:) has not been implemented There is no issue building from Xcode 16.4, regardless of targeted i(Pad)OS.

Our app was just rejected by Apple because they say the subscription management sheet never loads. It just spins indefinitely. We're using StoreKit's manageSubscriptionsSheet view modifier to present the sheet, and it's always worked for us when testing in SandBox. Has anyone else had this problem? Given that it's Apple's own code that got us rejected, what's our path forward?

SwiftUI Popover Crash on iPad During Resizing in Stage Manager with Exception. *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Trying to layout popover in the delegate callback popoverPresentationController:willRepositionPopoverToRect:inView: will lead to recursion. Do not force the popover's container view or an ancestor to layout in this callback.' (Occurred from iPadOS 18.1) struct ContentView: View { @State var showPopover: Bool = false var body: some View { VStack { Text("Hello, world!") Button(action: { showPopover = true }, label: { Text("Open Popover") }) } .padding() .popover(isPresented: $showPopover, attachmentAnchor: .point(.trailing), content: { VStack { Text("Popover Content") } }) } }

I would like to include the bottom sheet from the iPhone "find my" and "maps" app in my app. During my research I came across the new modifier .presentationDetents for sheets. The only problem here is that you can no longer interact with the main screen when the sheet is active. In my app, however, I would like the sheet to be active all the time like in the iPhone apps mentioned and that you can still interact with the main screen like in the iPhone apps with the map. I would be very happy about help. Greetings

After updating to Mac OS Sonoma, we have encountered compatibility issues with our iPad-designed application, specifically with the AirPrint functionality, when it is run on MacOS. The AirPrint feature stopped working properly through UIPrintInteractionController.shared. We have noticed that when we compile the application using Catalyst, the AirPrint functionality is restored and works as expected. However, this solution is not viable for us due to the restrictions associated with the frameworks we are utilizing. We are seeking alternative solutions, and any help or guidance would be highly appreciated to resolve this issue and ensure a seamless and uninterrupted user experience in our application. STEPS TO REPRODUCE Create an app for ipad with just a button and this code var str = "TEST" let printInfo = UIPrintInfo(dictionary:nil) printInfo.outputType = .general printInfo.jobName = "Report" printInfo.orientation = .portrait let printController = UIPrintInteractionController.shared printController.printInfo = printInfo printController.showsNumberOfCopies = false printController.showsPageRange = false printController.showsNumberOfCopies = false let formatter = UIMarkupTextPrintFormatter(markupText: str) formatter.contentInsets = UIEdgeInsets(top: 72, left: 72, bottom: 72, right: 72) printController.printFormatter = formatter printController.present(animated: true, completionHandler: nil) 2.Run it on a MacOS with Sonoma, there is no error on console or anything but it don't work. -If you run it with Catalyst it just works when adding the Printing permission of App Sandbox in Signing & Capabilities.

Apple docs for RealityView state: You can also use the optional update closure on your RealityView to update your RealityKit content in response to changes in your view’s state." Unfortunately, I've not been able to get this to work. All of my 3D content is programmatically generated - I'm not using any external 3D modeling tools. I have an object that conforms to @ObservableObject. Its @Published variables define the size of a programmatically created Entity. Using the initializer values of these @Published variables, the 1st rendering of the RealityView { content in } works like a charm. Basic structure is this: var body: some View { RealityView { content in // create original 3D content using initial values of @Published variables - works perfect } update: { content in // modify 3D content in response to changes of @Published variables - never works } Debug statements show that the update: closure gets called as expected - based upon changes in the viewModel's @Published variables. However, the 3D content never changes - even though the 3D content is based upon the @Published variables. Obviously, if the @Published variables are used in the 1st rendering, and the update: closure is called whenever changes occur to these @Published variables, then why isn't the update: closure updating the RealityKit content as described in the Apple docs? I've tried everything I can think of - including removing all objects in the update: closure and replacing them with the same call that populated them in the 1st rendering. Debug statements show that the new @Published values are correct as expected when the update: closure is called, but the RealityView never changes. Known limitation of the beta? Programmer error? Thoughts?

Is there a way to access an Icon Composer .icon file in Swift or Objective-C? Any way to get this in an NSImage object that I can display in an image view? Thanks.

Making the call as: UIApplication.shared.open(websiteURL) doesn't open the browser and gives the following in the console: BUG IN CLIENT OF UIKIT: The caller of UIApplication.openURL(:) needs to migrate to the non-deprecated UIApplication.open(:options:completionHandler:). Force returning false (NO). However, making the call as: UIApplication.shared.open(websiteURL) { _ in } opens the browser and there is nothing in the cosole. Does someone understand why is this or if it's Apple's iOS 18 bug? In the iOS & iPadOS 18 RC Release Notes | Apple Developer Documentation there is a section around resolving this or something similar, unsure.