Hello! The minimize behavior was working correctly while I was using Xcode 26 beta 4 with iOS 26 beta 4 simulator — when scrolling down, the Tab Bar would minimize as expected. However, after upgrading both Xcode and iOS simulator to beta 5, the tabBarMinimizeBehavior setting no longer has any visible effect — the Tab Bar stays fixed in place. Code snippet: if #available(iOS 26.0, *) { self.tabBarMinimizeBehavior = .onScrollDown } Steps to reproduce: 1. Create a UITabBarController with at least one tab containing a scrollable view (e.g., UITableView). 2. In viewDidLoad, set tabBarMinimizeBehavior to .onScrollDown. 3. Run on iOS 26 beta 5 simulator. Expected behavior (beta 4): Scrolling down hides/minimizes the Tab Bar with animation. Actual behavior (beta 5): Tab Bar remains fixed; no minimize animation is triggered. Environment: • Xcode 26 beta 5 (Build: 17A5295f) • iOS 26 beta 5 simulator (Build: 1055) – iPhone 16 Pro • Also tested on iPhone 13 mini – iOS 26 (Build: 23A5308g)

Issue Description: When toggling between the system keyboard and a custom input view, the keyboard height reported in subsequent keyboard notifications becomes incorrect!!! specifically missing the predictive text/suggestion bar height. Environment: Device: iPhone 11 Expected keyboard height: 346pt Actual reported height: 301pt (missing 45pt suggestion bar) Reproduction Steps: Present system keyboard → Height correctly reported as 346pt Switch to custom input view → Custom view displayed Switch back to system keyboard(no suggestion bar) → Height correctly reported as 301pt Trigger keyboard frame change → Height still incorrectly reported as 301pt despite suggestion bar being visible Expected Behavior: Keyboard height should consistently include the suggestion bar height (346pt total). Actual Behavior: After switching from custom input view, keyboard height excludes suggestion bar height (301pt instead of 346pt). key code private func bindEvents() { customTextField.toggleInputViewSubject.sink { [weak self] isShowingCustomInput in guard let strongSelf = self else { return } if isShowingCustomInput { strongSelf.customTextField.inputView = strongSelf.customInputView strongSelf.customInputView.frame = CGRect(x: 0, y: 0, width: strongSelf.view.frame.size.width, height: strongSelf.storedKeyboardHeight) } else { strongSelf.cusTextField.inputView = nil } strongSelf.customTextField.reloadInputViews() strongSelf.customTextField.becomeFirstResponder() }.store(in: &cancellables) }

We're seeing sporadic crashes on devices running iOS 18.1 - both beta and release builds (22B83). The stack trace is always identical, a snippet of it below. As you can tell from the trace, it's happening in places we embed SwiftUI into UIKit via UIHostingController. Anyone else seeing this? 4 libobjc.A.dylib 0xbe2c _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 30 5 libobjc.A.dylib 0xb040 weak_register_no_lock + 396 6 libobjc.A.dylib 0xac50 objc_storeWeak + 472 7 libswiftCore.dylib 0x43ac34 swift_unknownObjectWeakAssign + 24 8 SwiftUI 0xeb74c8 _UIHostingView.base.getter + 160 9 SwiftUI 0x92124 _UIHostingView.layoutSubviews() + 112 10 SwiftUI 0x47860 @objc _UIHostingView.layoutSubviews() + 36

An app with a UIToolbar pinned to the bottom of a view controllers view extends to the screen edge (behind the safe area) when run on iOS 18.X but not iOS 26. This UIToolbar is set as constrained to the safeAreaLayoutGuide with the following constraints. self.view.addConstraints([ bottomToolbar.leadingAnchor.constraint(equalTo: self.view.leadingAnchor), bottomToolbar.trailingAnchor.constraint(equalTo: self.view.trailingAnchor), bottomToolbar.bottomAnchor.constraint(equalTo: self.view.safeAreaLayoutGuide.bottomAnchor), bottomToolbar.heightAnchor.constraint(greaterThanOrEqualToConstant: 44.0) ]) This is especially noticeable when the UIToolbar background color differs from the view background color. This occurs on iOS 26 beta 6, app built with Xcode 26 beta 5. I've posted a Feedback FB19664903 including a minimal Xcode workspace that reproduces this issue. Anyone suggestions would be appreciated ... this definitely seems like a regression.

This line in the WWDC25: Build a SwiftUI app with the new design talk, Doesn't work. no .rect is not member and neither corner a parameter or containerConcentric listed. Help .background(.tint, in: .rect(corner: .containerConcentric))

I'd like to investigate creating a safety feature for Type 1 Diabetics driving a car. Allowing HealthKit glucose data (read from a Dexcom G7 or similar) to be displayed as part of the CarPlay UI background or show an icon/button with the number visible. I'd also like to include a warning system for glucose low's that alerts the driver audibly. Has anyone looked into that before?

Dear random Apple UIKit engineer. This is a question for you. Today let's speak about keyboard notifications. In particular, UIResponder.keyboardWillShowNotification and UIResponder.keyboardWillHideNotification. While working with those, I noticed some undocumented behaviour. First, let me give you some context: extension UIViewController { func registerForKeyboardNotifications() { NotificationCenter.default.addObserver(self, selector: #selector(keyboardNotification), name: UIResponder.keyboardWillShowNotification, object: nil) NotificationCenter.default.addObserver(self, selector: #selector(keyboardNotification), name: UIResponder.keyboardWillHideNotification, object: nil) } /// Override this method to handle keyboard notifications. @objc func keyboardNotification(_ notification: Notification) { ... } } Eventually, I found that latter method with 3 dots has an implicit animation inside it's scope. Here is the [proof.](https://medium.com /uptech-team/why-does-uiresponder-keyboard-notification-handler-animate-10cc96bce372) Another thing I noticed, is that this property definition is perfectly valid let curve = UIView.AnimationCurve(rawValue: 7)!. The 7 btw comes from UIResponder.keyboardAnimationCurveUserInfoKey as a default value during my tests. So, the enum with 4 possible values (0...3) can be initialized with a value out of enum's cases range. Also, how can I initialize UIView.AnimationOption from 7? I will pollute my OptionSet which I feed to options parameter on UIView.animate(...) My questions: Why implicit animation is not documented and can I trust it or it's a subject to change. Why UIView.AnimationCurve(rawValue: 7)! does not crash. How can I convert UIResponder.keyboardAnimationCurveUserInfoKey's value into UIView.AnimationOption properly if I don't want to use implicit value. I don't encroach on UIKit secrets. I just need to know how to work with the API. Thank you!

Is the Cancel button intentionally removed from UISearchBar (right side)? Even when using searchController with navigationItem also. showsCancelButton = true doesn’t display the cancel button. Also: When tapping the clear ("x") button inside the search field, the search is getting canceled, and searchBarCancelButtonClicked(_:) is triggered (Generally it should only clear text, not cancel search). If the search text is empty and I tap outside the search bar, the search is canceled. Also when I have tableview in my controller(like recent searches) below search bar and if I try to tap when editing started, action is not triggered(verified in sample too). Just cancellation is happening. In a split view controller, if the search is on the right side and I try to open the side panel, the search also gets canceled. Are these behaviors intentional changes, beta issues, or are we missing something in implementation?

is there anything I can do about this? It's in a navigation controller, and I get a lot of these when I pop and push. eventually it causes glitches with zoom animations making for some really loopy zooms. I posted a movie to FB20439774. If there's anything I can do to fix it would be great. Unable to simultaneously satisfy constraints. ( "<NSAutoresizingMaskLayoutConstraint:0x600002149680 h=-&- v=-&- TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106b0e700.minX == 0 (active, names: '|':TtGC5UIKit22UICorePlatformViewHostGVS_32PlatformViewRepresentableAdaptorVS_P10$186c5d1b020ButtonRepresentation:0x106b08ef0 )>", "<NSAutoresizingMaskLayoutConstraint:0x600002149590 h=-&- v=-&- H:[TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106b0e700]-(0)-| (active, names: '|':TtGC5UIKit22UICorePlatformViewHostGVS_32PlatformViewRepresentableAdaptorVS_P10$186c5d1b020ButtonRepresentation:0x106b08ef0 )>", "<NSLayoutConstraint:0x600002142b20 _TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106b0e700.width == _UIButtonBarButton:0x106b16ef0.width (active)>", "<NSLayoutConstraint:0x60000214a4e0 'UITemporaryLayoutWidth' TtGC5UIKit22UICorePlatformViewHostGVS_32PlatformViewRepresentableAdaptorVS_P10$186c5d1b020ButtonRepresentation:0x106b08ef0.width == 0 (active)>", "<NSLayoutConstraint:0x600002143200 'IB_Leading_Leading' H:|-(1)-[_UIModernBarButton:0x106b09810] (active, names: '|':_UIButtonBarButton:0x106b16ef0 )>", "<NSLayoutConstraint:0x6000021434d0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106b09810]-(1)-| (active, names: '|':_UIButtonBarButton:0x106b16ef0 )>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x6000021434d0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106b09810]-(1)-| (active, names: '|':_UIButtonBarButton:0x106b16ef0 )>

Just posted this feedback regarding macOS 26 "Tahoe" (FB19853155) - please support with additional submissions if you share my view. I will miss the beautiful and individual designed icons of the past! "macOS 26 is enforcing squicles for app icons, falling back to a grey background for 3rd party apps without a compliant AppIcon asset. As a result many original app icons are reduced in size and hard to distinguish because they share the same background color. Although I respect Apple's strive for an iOS-like UI on Macs, a smooth transition path would be more user- and developer-friendly ... e.g. with some info.plist property to opt-out icon migration, potentially ignored by a future macOS version. The current solution causes a bad usability, and makes the system look inconsistent as many - especially free - software will not be updated with new icon designs. Please reconsider this bad design decision!"

Hi, I have a List and I want to limit the dynamic text size for some of the elements in the list's row item view. I created a test view below. The ".dynamicTypeSize(.large)" restriction only works if it's applied to the List view, not if it's set for the the ContentItemView in the ForEach below. Is there a reason for this? Do I need to do something else to limit a list row to a certain size? The example only has a text field, but I want to do this for a Image with some text inside it, and I wanted to restrict that text field, but it doesn't seem to work when the view is inside a List row. Please let me know if there's a workaround for it. import SwiftUI import CoreData struct ContentView: View { @FetchRequest( sortDescriptors: [NSSortDescriptor(keyPath: \Item.timestamp, ascending: true)], animation: .default) private var items: FetchedResults<Item> @State private var multiSelectedContacts = Set<Item.ID>() var body: some View { NavigationStack { List (selection: $multiSelectedContacts) { ForEach(items) { item in ContentItemView(item: item) } .dynamicTypeSize(.large) // <-- doesn't works } .dynamicTypeSize(.large) // <-- THIS WORKS } } } struct ContentItemView: View { @Environment(\.managedObjectContext) private var viewContext @ObservedObject var item: Item @State var presentConfirmation = false var body: some View { HStack { if let timestamp = item.timestamp, let itemNumber = item.itemNumber { Text("\(itemNumber) - \(timestamp, formatter: itemFormatter)") } } .popover(isPresented: $item.canShowPopover, content: { Text("Test Item Label") .frame(width: 100, height: 150) }) } } private let itemFormatter: DateFormatter = { let formatter = DateFormatter() formatter.dateStyle = .short formatter.timeStyle = .long return formatter }() #Preview { ContentView().environment(\.managedObjectContext, PersistenceController.preview.container.viewContext) }

Hello! I'm creating a settings page for my app and I want it to look as native as possible. I want to know if it's possible to add constraints that make the second label go to the bottom when the text size gets really large (see Picture1) instead of having to force it to be on the right (see Picture 2). I've left my constraint code for this cell down below, too. I'm still learning constraints and best practices, so if there's any feedback, I'd love to hear it. Thank you! Picture 1 Picture 2 - (void) setConstraints { [NSLayoutConstraint activateConstraints:@[ // Cell Title Label [self.themeColorLabel.leadingAnchor constraintEqualToAnchor:self.contentView.layoutMarginsGuide.leadingAnchor], [self.themeColorLabel.trailingAnchor constraintEqualToAnchor:self.contentView.layoutMarginsGuide.trailingAnchor], [self.themeColorLabel.topAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.topAnchor], [self.themeColorLabel.bottomAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.bottomAnchor], // Selected Theme Color Label [self.selectedColorLabel.trailingAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.trailingAnchor], [self.selectedColorLabel.topAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.topAnchor], [self.selectedColorLabel.bottomAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.bottomAnchor], ]]; }

Hello, I have a number of UIViewControllers that are presented as follows: vc.modalPresentationStyle = UIModalPresentationStyle.popover vc.modalTransitionStyle = UIModalTransitionStyle.coverVertical self.present(vc, animated: true, completion: nil) The VC is designed from a Storyboard where I set the 'view' of the VC to have a .clear 'backgroundColor', I have a smaller 'Alert View' added as a subview which is what the user interacts with. In iOS 13 - iOS 18 this would present modally, not take up the entire screen and allow the user to see relevant context from the screen underneath. In iOS 26 Beta 5 and every beta prior the system injects a 'UIDropShadowView' in the View Hierarchy, this view has a solid color backdrop, either white/black depending on light/dark mode. This causes all underlying content to be blocked and essentially forces a full screen modal presentation despite the existing design. I am looking for a way to remove this solid color. I'm not sure if it's intentional or a bug / oversight. I have been able to remove it in a hacky way, I cycle the view hierarchy to find 'UIDropShadowView' and set it's backdrop to transparent. However when you swipe down to partially dismiss the view it turns to Liquid Glass when it is around 75% dismissed and then resets the background color to white/black. I tried creating a custom UIViewControllerTransitioningDelegate so that I could re-implement the existing behaviour but it's incredibly difficult to mimic the partial dismiss swipe down effect on the VC. I have also tried changing my presentation to: vc.modalPresentationStyle = UIModalPresentationStyle.overFullScreen vc.modalTransitionStyle = UIModalTransitionStyle.crossDissolve This works but then the user loses the ability to interactively swipe to dismiss. Any help would be appreciated. Thank you!

In a UIKit-based project, I am attempting to integrate SwiftUI components. However, I encounter a persistent issue that hinders this integration. This problem arises when pushing a SwiftUI view using UIHostingController and subsequently attempting to push a UIKit view controller using UIViewControllerRepresentable. Not only are the navigation items and title from the view controller disregarded, but more concerningly, my tab bar item title is set to nil. This renders it impossible for me to utilize SwiftUI within my application when I wish to present older UIKit view controllers from there. This feedback has all the details and a sample project. FB18956999

On MacOS Tahoe (26.0 26.1 or 26.2), when loading an application that was built with an SDK older than version SDK 14.5, all CGContextDrawShading calls to draw onto the screen (inside of NSView drawRect:) fail silently, filling the path with a single color instead of a gradient. If rendering into a local CGBitmapContext instead of the NSView context on Tahoe, CGShading works as expected. On MacOS 15 and earlier, CGShading works as expected too. If the app is built with SDK version 14.5 or newer, CGShading works normally on MacOS Tahoe. For recent applications, they can of course be rebuilt with a more recent version of the SDK, which fixes the problem. However for Audio Units or any other type of plug-in, even if they are built with the "appropriate" SDK, if they are loaded inside of a legacy application that was built with an older SDK, the problem arises, which customers complain about and do not understand. I have noticed that there had been a few changes in MacOS Tahoe regarding the CGShading APIs, could this problem be related? If this issue cannot be fixed in an upcoming MacOS update, is there maybe a "defaults" value that can be changed? (since this behaviour is specific to a sdk version, I guess that it is triggered by a version check in the Frameworks and that there is a "defaults" value that can be changed to avoid this specific behaviour, as it is usually the case via a DefaultValueFunction)? I have already opened a feedback regarding this issue, but maybe someone already has a solution for this problem?

What is the correct way to implement scrolling in a looong list that uses ScrollView and LazyVstack Imagine I have some api that returns a longs list of comments with replies The basic usecase is to scroll to the bottom(to the last comment) Most of the time this works fine But, imagine some of the comments have many replies like 35 or more (or even 300) User expands replies for the first post, then presses scroll to bottom. The scrollbar reaches the bottom and I see the blank screen. Sometimes the scrollbar may jump for a while before lazyvstack finishes loading or until I manually scroll up a bit or all the way up and down What should I do in this case? Is this the swiftui performance problem that has no cure? Abstract example: ScrollViewReader { proxy in ScrollView { LazyVStack { ForEach(comments) { comment in CommentView(comment: comment) .id("comment-\(comment.id)") } } } } struct CommentView: View { let comment: Comment @State var isExpanded = false var body: some View { VStack { Text(comment.text) if isExpanded { RepliesView(replies: comment.replies) // 35-300+ replies } } } } ... scroll proxy.scrollTo("comment-\(lastComment.id)", anchor: .bottom)

I was trying to figure out why my bottom sheet looks weird and doesn't have the "proper glass" look. I found that this issue seems to be new to iOS 26.1. See the images below, they show the same view hierarchy (in this case UIHostingController configured as bottom sheet that has NavigationStack and content. On iOS 26.1 there seems to be extra two layers of background - even though I am no adding any. iOS 26: iOS 26.1 Has anyone experienced something similar? Any workarounds? I am happy to completely disable the glass effect for this bottom sheet if it helps. The screenshots show one sheet, but the same thing happens for another ones.

An iOS app has a UINavigationController with a UINavigationBar that is non-translucent (e.g. black). When performing a push (or pop) to navigate to or from another UIViewController the UIBarButtonItems on the navigation bar are flashing a white background. With a dark navigation bar this is very noticeable and not desirable. This only occurs when run on iOS 26 and is related to Liquid Glass I've created FB19660024 with a minimal Xcode workspace to reproduce, along with a video showing the behavior. This is a cosmetic bug, not affecting functionality, but is a very undesirable effect on apps with dark and non-translucent navigation bars. Has anyone else seen this and found a workaround?

I know iPhone Cannot prohibit screenshots, but I have seen someone else's solution, which is to capture a white page instead of the current design page when taking screenshots. I want to use swift implement iPhone The photo generated when taking a screenshot is a white screen, and I don't want my page to be seen by others

We have encountered a consistent problem with OTP (One Time Password) autofill on iOS versions 26.0.1 through 26.3. The issue pertains to apps implementing OTP input using multiple UITextFields (often 6 or 7 separate text boxes for each digit). Problem Details: When tapping the OTP autofill suggestion from Messages or supported third-party apps, iOS autofill pastes the entire OTP string into just one UITextField (commonly the second or focused field) rather than distributing digits across the individual text fields. The delegated UITextField methods such as textField:shouldChangeCharactersInRange:replacementString: receive an entire OTP string at once, but the usual event handlers like UIControlEventEditingChanged do not always trigger, breaking existing logic relying on those. This results in the OTP input UI showing incorrect or partial OTP, confusing users and forcing manual re-entry. Many popular apps employing multi-field OTP input UIs face similar autofill malfunctions on iOS 26.x, impacting user experience negatively. Setting textContentType = .oneTimeCode on the first text field alone is insufficient to restore the intended autofill behavior on iOS 26.x. This represents a regression or functional deficiency compared to iOS 15-18 autofill handling patterns, which worked reliably for these multi-field OTP UIs.| Expected Behavior: OTP autofill should either automatically split the filled code into each UITextField or trigger consistent delegate/callback events to enable developers to replicate this behavior manually. textDidChange or equivalent events should fire on autofill updates to reflect text changes correctly in multi-field OTP input. Apple’s OTP autofill system should transparently support or provide clear guidelines for handling multi-field OTP input on iOS 26+. What We’ve Tried: Setting .oneTimeCode content type on only the first UITextField. Handling OTP autofill in delegate methods including shouldChangeCharactersInRange. Manual distribution and custom logic triggered by textDidChange and other callbacks. Confirming all relevant system autofill settings are enabled. Testing on multiple devices and iOS versions (26.0.1 through 26.3). Note: its happen for may apps which have text field with 6 box otp fill