Summary: When running our iPad app on macOS (“Designed for iPad”), invoking UIPrintInteractionController intermittently fails to show a working print sheet. The same code works reliably on iPad or iOS devices and also on macOS pre 26. This regression started after updating to macOS Tahoe Version 26.0 (25A354) Steps to Reproduce: Launch the attached minimal sample on macOS (Designed for iPad). Tap “Print plain text” Expected Results: The print panel should appear and discover AirPrint printers reliably, as on iPad/iOS or previous mac versions. Actual Results: On macOS, the panel fails to appear. Mac version: macOS Tahoe 26.0 (25A354) xCode version: 26.0 (17A324) Sample Reproduction Code: struct ContentView: View { var body: some View { Button("Print plain text") { printPlainText() } .buttonStyle(.borderedProminent) .padding() } func printPlainText() { let text = "This is just a sample print" guard UIPrintInteractionController.isPrintingAvailable else { NSLog("Printing not available on this device") return } let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "Plain Text" let formatter = UISimpleTextPrintFormatter(text: text) formatter.perPageContentInsets = UIEdgeInsets(top: 36, left: 36, bottom: 36, right: 36) let ctrl = UIPrintInteractionController.shared ctrl.printInfo = info ctrl.printFormatter = formatter DispatchQueue.main.async { ctrl.present(animated: true) { _, completed, error in if let error { NSLog("Print error: \(error.localizedDescription)") } else { NSLog(completed ? "Print completed" : "Print cancelled") } } } } } Also I have added the following values to info.plist: <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover AirPrint printers.</string> <key>NSBonjourServices</key> <array> <string>_ipp._tcp.</string> <string>_ipps._tcp.</string> <string>_printer._tcp.</string> </array>

‏‏‏آلَحـ🇾🇪‏ᬼ⃝⃡Wٌـّاج this string cause a crash on iOS 26 when sett label.text Crashed: com.apple.main-thread 0 CoreText 0xf720c std::__1::__hash_table<std::__1::__hash_value_type<long, CGPoint>, std::__1::__unordered_map_hasher<long, std::__1::__hash_value_type<long, CGPoint>, std::__1::hash, std::__1::equal_to, true>, std::__1::__unordered_map_equal<long, std::__1::__hash_value_type<long, CGPoint>, std::__1::equal_to, std::__1::hash, true>, std::__1::allocator<std::__1::__hash_value_type<long, CGPoint>>>::erase(std::__1::__hash_const_iterator<std::__1::__hash_node<std::__1::__hash_value_type<long, CGPoint>, void*>>) + 300 1 CoreText 0xf63d4 TGlyphComposer::ComposeGlyphs(long, TInlineVector<unsigned short, 30ul> const&, TInlineVector<long, 30ul> const&) + 2896 2 CoreText 0x8b018 TCombiningEngine::ResolveCombiningMarks(TCombiningEngine::CombiningFlag, bool, bool*) + 2232 3 CoreText 0x4edf0 TKerningEngine::PositionGlyphs(TRunGlue&, TCharStream const&, signed char) + 1108 4 CoreText 0x4eee8 TTypesetter::FinishLayout(std::__1::tuple<TLine const*, TCharStream const*, void const* ()(__CTRun const, __CFString const*, void*), void*, std::__1::shared_ptr, unsigned int, unsigned char, bool, long> const&, TRunGlue&, signed char, SyncState) + 64 5 CoreText 0x34608 TTypesetterAttrString::Initialize(__CFAttributedString const*, bool) + 3300 6 CoreText 0x34d88 TTypesetterAttrString::TTypesetterAttrString(__CFAttributedString const*, __CFDictionary const*, bool) + 160 7 CoreText 0x34c38 CTLineCreateWithAttributedString + 84 8 UIFoundation 0x6204 __NSCoreTypesetterCreateBaseLineFromAttributedString + 704 9 UIFoundation 0xafd38 -[NSCoreTypesetter _stringDrawingCoreTextEngineWithOriginalString:rect:padding:graphicsContext:forceClipping:attributes:stringDrawingOptions:drawingContext:stringDrawingInterface:] + 2652 10 UIFoundation 0x26bc __NSStringDrawingEngine + 1592 11 UIFoundation 0xab308 -[NSString(NSExtendedStringDrawing) boundingRectWithSize:options:attributes:context:] + 164 12 UIKitCore 0x186a978 + 132 13 UIKitCore 0x48a7c + 668 14 UIKitCore 0x186b35c + 444 15 UIKitCore 0x186eb30 + 408 16 UIKitCore 0x486d4 + 136 17 UIKitCore 0x47c1c + 80 18 UIKitCore 0x1b68e4 + 80 19 UIKitCore 0x1867c08 + 760 20 UIKitCore 0x18678ec + 72 21 UIKitCore 0x186be30 + 104 ....... 28 UIKitCore 0xa894e0 + 52 29 UIKitCore 0x19047fc + 76 30 UIKitCore 0xa88b0c + 1196 31 UIKitCore 0xa91ce0 + 524 32 UIKitCore 0xa9222c + 280 33 UIKitCore 0xa90550 + 3036 34 UIKitCore 0x1e1604 + 280 35 UIKitCore 0x27078 + 912 36 UIKitCore 0x27b38 + 40 37 UIKitCore 0x190df68 + 2532 38 QuartzCore 0xac8bc + 116 39 QuartzCore 0x8f2fc + 600 40 QuartzCore 0xadf84 + 200 41 QuartzCore 0x6ef78 + 536 42 QuartzCore 0x9bab0 + 644 43 QuartzCore 0xa93c0 + 88 44 UIKitCore 0x780f0 + 52 45 UIKitCore 0x78024 + 352 46 UIKitCore 0x85ee8 + 128 47 UIKitCore 0x85378 + 60 48 UpdateCycle 0x15f8 UC::DriverCore::continueProcessing() + 84 49 CoreFoundation 0x6a230 + 28 50 CoreFoundation 0x6a1a4 + 172 51 CoreFoundation 0x47c6c + 232 52 CoreFoundation 0x1d8b0 + 820 53 CoreFoundation 0x1cc44 + 532 54 GraphicsServices 0x1498 GSEventRunModal + 120 55 UIKitCore 0xa9ddc + 792 56 UIKitCore 0x4eb0c UIApplicationMain + 336 57 UIKitCore 0x18a860 + 588 59 ??? 0x18c7cae28 (缺少)

We’ve recently updated our app to adopt the native iOS 26 tab bar. Since then, we’ve started seeing crashes on iOS 26 devices with swift_getObjectType appearing in the stack. I’ve reviewed the logs in Organizer but couldn’t find anything conclusive. The issue seems isolated to iOS 26 and doesn’t reproduce on earlier versions. com.grofers.consumer_issue_2cc3a4a209ab2b47bfbdab919a320fa7_crash_session_68148be54ef5441fac56d3138d055bac_DNE_5_v2_stacktrace.txt

Dear Apple Support, We are encountering an issue with deep linking on iOS 26 when using Safari and App Store redirection. Below are the detailed steps to reproduce the problem: The app is not installed on the device. User clicks on a Branch link: For example:- https://qewed.app.link/99u88ef9f?uuid=88dbwh5ubd4b Safari opens and displays the fallback page. User taps on “Get the App”, which navigates to the App Store. User installs and opens the app. Expected Behavior:
The app should receive the Branch link parameters (in this case, uuid=88dbwh5ubd4b) upon first open. Actual Behavior:
The app opens successfully, but the uuid parameter is not passed to the app. This issue seems specific to the Safari → App Store → App flow on iOS 26, as other flows behave correctly. Could you please advise whether this is a known issue or if there are recommended adjustments on our side to ensure parameters are consistently delivered after App Store redirection? Note: We are using Branch SDK version 3.11.0 (Cocoapods dependency) Thank you for your assistance.

When preparing the app for the new iOS 26, I came across an unpleasant design decision. Specifically, in the new design, the keyboard has rounded corners, under which the system background is visible. And here we have only two options, a light/dark background, which breaks all keyboard calls in the application. Can you tell me if there is any way around this problem?

Scenario: Typing Chinese Zhuyin “ㄨㄤ” and then selecting the candidate word “王”. On iOS 18, the delegate (textField:shouldChangeCharactersInRange:replacementString:) is called with: range: {0, 2} replacementString: "王" On iOS 26, the delegate (textField:shouldChangeCharactersInRanges:replacementString:) instead provides: ranges: [{2, 0}] replacementString: "王" This results in inconsistent text input handling compared to earlier system versions. Implement: Limit user input to a maximum of 100 Chinese characters. - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if ([textField markedTextRange]) { return YES; } NSString *changedString = [textField.text stringByReplacingCharactersInRange:range withString:string]; if (changedString.length > 100) { return NO; } return YES; } Questions: Is this an intentional change in iOS 26? If intentional, what is the recommended way to handle such cases in order to support both iOS 18 and iOS 26 consistently?

Hello, I’m seeing a layout issue where the system window controls overlap the navigation bar’s right-side buttons when the app window is resized on iPadOS 26. Environment Xcode: 16.4 Simulator: iPadOS 26.0, device profile iPad Pro 13-inch Physical device: iPad updated to iPadOS 26 (same behavior) UI stack: UIKit + Storyboards (no SwiftUI) App structure: Root UINavigationController Summary Since iPadOS 26 introduced freely resizable app windows, the system’s window management controls (close/minimize/resize at the top-right) begin to overlap the navigation bar buttons as the window size becomes smaller. At maximum window size there’s no issue. Additionally, the navigation bar buttons themselves appear to scale down visually when the window gets smaller. Steps to Reproduce Build with Xcode 16.4 and run on iPadOS 26.0 (simulator or device). Open a screen embedded in a UINavigationController with right-side bar button items. Resize the app window to a smaller size. Observe the top-right system window controls overlapping the navigation bar buttons. Expected Result System window controls should not overlap app content; the navigation bar should remain usable and properly spaced at all supported window sizes. Actual Result When the window is small, the system window controls overlap the right-side navigation bar buttons. The bar button items also appear to shrink as the window size decreases. Notes Reproducible on both simulator and a real device updated to iPadOS 26. Project uses UIKit + Storyboards only (no SwiftUI). Safe areas and basic constraints look fine, so the root cause is unclear. Questions Is this a known issue with iPadOS 26 resizable windows? Any recommended workaround (e.g., API to reserve space near the window controls, UINavigationBar configuration, or trait/size-class handling)? I can provide a minimal sample project and screenshots if helpful. Thank you!

Hey there, Link to the sample project: https://github.com/dev-loic/AppleSampleScrolling Context We are working on creating a feed of posts in SwiftUI. So far, we have successfully implemented a classic feed that opens from the top, with bottom pagination — a standard use case. Our goal, however, is to allow the feed to open from any post, not just the first one. For example, we would like to open the feed directly at the 3rd post and then trigger a network call to load elements both above and below it. Our main focus here is on preserving the scroll position while opening the screen and waiting for the network call to complete. To illustrate the issue, I created a sample project (attached) with two screens: MainView, which contains buttons to open the feed in different states. ScrollingView, which initially shows a single element, simulates a 3-second network call, and then populates with new data depending on which button was tapped. I am currently using Xcode 26 beta 6, but I can also reproduce this issue on Xcode 16.3. Tests on sample project I click on a button and just wait the 3 seconds for the call. In this scenario, I expect that the “focused item” stays at the exact same place on the screen. I also expect to see items below and above being added. Simulator iPhone 16 / iOS 18.4 with itemsHeight = 100 position = 0, 1, 2, 3 ⇒ works as expected position = 4, 5, 6, 7, 8, 9 ⇒ scroll is reset to the top and we loose the focused item Simulator iPhone 16 / iOS 18.4 with itemsHeight = 500 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible position = 8, 9 ⇒ scroll is reset to the top and we loose the focused item Simulator iPhone 16 / iOS 26 with itemsHeight = 100 or 500 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Device iPhone 15 / iOS 26 with itemsHeight = 100 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Device iPhone 15 / iOS 26 with itemsHeight = 500 position = 0, 1, 2, 3 ⇒ works as expected position = 4, 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Not any user interaction Moreover, in this scenario, the user does not interact with the screen during the simulated network call. Regardless of the situation, if the ScrollView is in motion, its position always resets to the top. This behavior prevents us from implementing automatic pagination when scrolling upward, which is ultimately our goal. My conclusion so far As far as I know it seems not possible to have both keeping scroll possible and upward automatic pagination using a SwiftUI LazyVStack inside a ScrollView. This appears to be standard behavior in messaging apps or other feed-based apps, and I’m wondering if I might be missing something. Thank you in advance for any guidance you can provide on this topic. Cheers

Platform: iOS 26 RC / Xcode 26 RC Component: UIKit - UITextField Description: When typing a Japanese character (or other IME input) as the first character in a UITextField and then losing focus (by pressing Enter or tapping elsewhere), the character is incorrectly duplicated. This issue only happens in iOS26 beta. Steps to Reproduce: Create a UITextField with shouldChangeCharactersIn delegate Switch to Japanese keyboard Type "あ" (or any hiragana character) Press Enter or tap outside the text field Observe the character count becomes 2 instead of 1 Expected Result: Character count should remain 1 Actual Result: Character is duplicated, count becomes 2 Sample Code: func shouldChangeText( in range: NSRange, replacementText string: String, maximumNumberOfCharacters: Int, regexValidation: String? = nil) -> (String, Bool) { guard let stringRange = Range(range, in: currentText) else { return (currentText, false) } if let regex = regexValidation, string != "", // delete key !string.room.checkPattern(regex) { return (currentText, false) } let changedText = currentText.replacingCharacters(in: stringRange, with: string) let allowChange = changedText.utf16.count <= maximumNumberOfCharacters print("=== stringRange: \(stringRange), currentText: \(currentText), replacementText: \(string) changedText: \(changedText), allowChange: \(allowChange) ===") guard !allowChange else { return (changedText, allowChange) } // Accept text deletion even if changedText count is more than maximumNumberCharacters guard !string.isEmpty else { return (changedText, true) } insert(text: string, maximumNumberOfCharacters: maximumNumberOfCharacters) return (currentText, allowChange) }

I’m creating a UITabBarController with a simple array of UITab instances. I’m setting the mode to .tabSideBar. How do I prevent editing? I don’t want the Edit button to appear at all. I’ve tried setting the tab controller’s customizableViewControllers property to both nil and an empty array but neither is preventing the Edit button from appearing. I scanned the various delegates and I don‘t see any relevant methods. So far I’ve tested this on a simulated iPad running iPadOS 26 using Xcode 26 RC.

Looking to see if anyone has experienced this issue, and is aware of any workarounds. With an app migrating towards SwiftUI Views but still using UIKit for primary navigation, my app makes use of UIHostingController to push SwiftUI Views onto a UINavigationController stack in a lot of areas. With iOS 26, I notice that SwiftUI's Menu view really struggles to present when contained in a UIHostingController. An error is logged to the console on presentation, and depending on the UI, the Menu won't present inside of it's container, or will jump around the screen. The bug, it seems is based in a private class UIReparentingView and I am curious if anyone has found a work around for this issue. The error reported is: Adding '_UIReparentingView' as a subview of UIHostingController.view is not supported and may result in a broken view hierarchy. Add your view above UIHostingController.view in a common superview or insert it into your SwiftUI content in a UIViewRepresentable instead. The simplest way to see this issue is to create a new storyboard based project. From the ViewController present a UIHostingController with a SwiftUI view that has a Menu and then simply tap to open the Menu. Thanks for any input!

After updating to iPad OS 26, when moving around the app, I can not see the back button, title, and the right menu button on the navigation bar unless I scroll down, then everything is fine. Any advice ? Thanks

Hi, I have an app that displays tens of short (<1mb) mp4 videos stored in a remote server in a vertical UICollectionView that has horizontally scrollable sections. I'm caching all mp4 files on disk after downloading, and I also have a in-memory cache that holds a limited number (around 30) of players. The players I'm using are simple views that wrap an AVPlayerLayer and its AVPlayerItem, along with a few additional UI components. The scrolling performance was good before iOS 26, but with the release of iOS 26, I noticed that there is significant stuttering during scrolling while creating players with a fileUrl. It happens even if use the same video file cached on disk for each cell for testing. I also started getting this kind of log messages after the players are deinitialized: <<<< PlayerRemoteXPC >>>> signalled err=-12785 at <>:1107 <<<< PlayerRemoteXPC >>>> signalled err=-12785 at <>:1095 <<<< PlayerRemoteXPC >>>> signalled err=-12785 at <>:1095 There's also another log message that I see occasionally, but I don't know what triggers it. << FigXPC >> signalled err=-16152 at <>:1683 Is there anyone else that experienced this kind of problem with the latest release? Also, I'm wondering what's the best way to resolve the issue. I could increase the size of the memory cache to something large like 100, but I'm not sure if it is an acceptable solution because: 1- There will be 100 player instance in memory at all times. 2- There will still be stuttering during the initial loading of the videos from the web. Any help is appreciated!

Hello, I have been receiving crash reports on iOS 26 related to a view containing a UITextField. Although I have not been able to reproduce the issue locally and the exact reproduction steps are unknown, the call stack suggests the crash may be related to language or input method changes. If anyone has encountered a similar crash on iOS 26 or has any insights regarding language/input-related issues impacting UITextField behavior, your help would be greatly appreciated. The call stack from the reports is attached below. Exception NSInvalidArgumentException -[__NSPlaceholderArray initWithObjects:count:] attempt to insert nil object from objects[1] Fatal Exception: NSInvalidArgumentException 0 CoreFoundation 0xc98c8 __exceptionPreprocess 1 libobjc.A.dylib 0x317c4 objc_exception_throw 2 CoreFoundation 0xe1d7c -[__NSPlaceholderArray initWithObjects:count:] 3 CoreFoundation 0x1485d0 +[NSArray arrayWithObjects:count:] 4 UIKitCore 0xfc4d44 -[UIInlineInputSwitcher updateInputModes:withHUD:] 5 UIKitCore 0xfc4fe0 -[UIIndicatorInputSwitcher switchMode:withHUD:withDelay:] 6 UIKitCore 0xfc31d4 -[UIInputSwitcher showsLanguageIndicator:] 7 UIKitCore 0xa16dc8 __140-[_UIKeyboardStateManager _setupDelegate:delegateSame:hardwareKeyboardStateChanged:endingInputSessionIdentifier:force:delayEndInputSession:]_block_invoke_4 8 libdispatch.dylib 0x1abc _dispatch_call_block_and_release 9 libdispatch.dylib 0x1b7cc _dispatch_client_callout 10 libdispatch.dylib 0x38af0 _dispatch_main_queue_drain.cold.5 11 libdispatch.dylib 0x10ea8 _dispatch_main_queue_drain 12 libdispatch.dylib 0x10de4 _dispatch_main_queue_callback_4CF 13 CoreFoundation 0x6b520 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ 14 CoreFoundation 0x1dd14 __CFRunLoopRun 15 CoreFoundation 0x1cc44 _CFRunLoopRunSpecificWithOptions 16 GraphicsServices 0x1498 GSEventRunModal 17 UIKitCore 0xaa6d8 -[UIApplication _run] 18 UIKitCore 0x4ec24 UIApplicationMain Thank you!

Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?

Code that disables a tab bar item via UITabBarItem.isEnabled = false used to both grey out the item and block taps on iOS 18. On iOS 26, the item often remains tappable and selectable, even though isEnabled is set to false. This looks like a behavior change or regression. func disableTabbarItems(tabbar: UITabBarController, isEnable: Bool, index: Int) { if let tabItems = tabbar.tabBar.items, index < tabItems.count { let tabItem = tabItems[index] tabItem.isEnabled = isEnable } } iOS 18 iOS 26

Code that disables a tab bar item via UITabBarItem.isEnabled = false used to both grey out the item and block taps on iOS 18. On iOS 26, the item often remains tappable and selectable, even though isEnabled is set to false. This looks like a behavior change or regression. func disableTabbarItems(tabbar: UITabBarController, isEnable: Bool, index: Int) { if let tabItems = tabbar.tabBar.items { let tabItem = tabItems[index] tabItem.isEnabled = isEnable } ![]("https://developer.apple.com/forums/content/attachment/a3c0bafb-2b10-44c3-8d76-d31bd83f30f7" "title=iOS 18.jpg;width=1179;height=279") } ![]("https://developer.apple.com/forums/content/attachment/4bbaccf3-292b-4790-b272-0d9809ba2949" "title=iOS 26.jpg;width=828;height=196")

Hi all, I’m subclassing UITextView and overriding insertText(_:) to intercept and log input: class TWTextView: UITextView { override func insertText(_ text: String) { print("insertText() : \(text)") super.insertText(text) } } This works fine, but I’ve noticed that insertText(_:) is invoked both when: The user types something in the text view (via hardware/software keyboard). I programmatically call myTextView.insertText("Hello") from my own code. I’d like to be able to distinguish between these two cases — i.e., know whether the call was triggered by the user or by my own programmatic insert. Is there any recommended way or system-provided signal to differentiate this? Thanks in advance!

I have a simple task, to measure the height of the overlapping area occupied by the keyboard in the current view. In the attached images, I use it to position a UITextView (red) above the keyboard, as a test. The keyboard displays an inputAccessoryView (yellow) when editing a text view, but it’s also summoned by a UIFindInteraction, which shows a search bar above the keyboard. When measuring the keyboard, I need to account for either the accessory view or the search bar, basically, the total keyboard height including any extra views above it. I use the usual algorithm: the keyboard frame from UIResponder.keyboardWillShowNotification (documented as being in screen coordinates) is converted to my view’s coordinates and intersected with the view’s bounds to get the overlapping height. The first issue: in windowed mode, the keyboard frame reports a negative origin.x (e.g. -247), even though in screen coordinates it should start at 0. I display the raw frame in the navbar, as shown in the first screenshot. I then suspected the frame might be in window coordinates on iOS 26, but repositioning the window a few times, and switching between find interaction keyboard and text editing keyboard, sometimes yields a positive origin.x instead, as if the keyboard starts from the middle of the screen!? (see the second screenshot). And in some cases, the raw keyboard height is even 0, despite the keyboard clearly being visible and taking space (third screenshot). Interestingly, the reported frame for the search keyboard is always consistent and in screen coordinates, but the default keyboard frame just doesn’t make sense.

I currently have a SwiftUI TabView that has 5 Tab's. The first tab has a UIScrollView in a UIViewRepresentible with scrollView.scrollsToTop = false and that works fine for when the user hits the navigation bar, however if the user taps the first tab when it is already selected my UIScrollView scrolls to top. My UIScrollView is essentially 5 views, a center view, top, bottom, right, and left view. All views except for the center are offscreen but available for the user to scroll horizontal or vertical (and the respective views get updated based on the new center view). The issue I have is that clicking the first tab when its already selected, sets the content offset (for the y axis) to 0, which messes me up 2x, first it scrolls up but since its not really scrolling the right, left, and upper views dont exist, which makes the user think it can't be scrolled or it's broken. For now I subclassed UIScrollView like this class NoScrollToTopScrollView: UIScrollView { override func setContentOffset(_ contentOffset: CGPoint, animated: Bool) { if contentOffset.y == .zero { // Ignore SwiftUI’s re-tap scroll-to-top return } super.setContentOffset(contentOffset, animated: animated) } } which seems to work, but I'm just wondering if there is a better way to do this, or maybe a way to disable SwiftUI Tab from doing its default action which can help with a SwiftUI ScrollView as well?