Hi, i'm using the PasteButton component to paste content from clipboard. On the docs it says that the PasteButton will handle internally permissions and will not present the prompt. But in my case seems to be not true. I removed all the occurrencies of UIPasteboard.general.string since i read that this will cause the prompt to appear. Also as you can see on the code below i'm not doing fancy or weird things, even with the base component this behaviour is still there. PasteButton(payloadType: String.self) { strings in if let first = strings.first { print("clipboard text: \(first)") } } I can see other apps using this paste button without asking for permissions every time, but i cannot see any issue in my code.

Hello, I am experiencing a crash in a SwiftUI app. It happens when I place multiple views inside a ScrollView. The crash occurs only on a physical device (it does not reproduce in the Simulator). It happens during runtime, seemingly while SwiftUI is updating or laying out the view hierarchy. I have not been able to determine the exact cause. I am attaching a text file with the entire backtrace from LLDB. swiftui_crash_backtrace Is this a known SwiftUI issue? Any recommendations on how to further investigate or work around it? Any help or suggestions would be appreciated. Xcode 16.3 / iOS 18.6.2 Thank you!

Hello, I’ve encountered what seems to be a bug with the keyboard dismissal animation on iOS 26.0 Beta (25A5349a), Xcode Version 26.0 beta 5 (17A5295f). When dismissing the keyboard from a SwiftUI TextField using @FocusState, the keyboard does not animate downward as expected. Instead, it instantly disappears, which feels jarring and inconsistent with system behavior. I am attaching a short video demonstrating the issue. Below is the minimal reproducible code sample: // // ContentView.swift // TestingKeyboardDismissal // // Created by Sasha Morozov on 27/08/25. // import SwiftUI struct ContentView: View { @State private var text: String = "" @FocusState private var isFocused: Bool var body: some View { ZStack { Color.clear.ignoresSafeArea() VStack(spacing: 20) { TextField("Enter text here...", text: $text) .textFieldStyle(.roundedBorder) .focused($isFocused) .padding(.horizontal) HStack { Button("Focus") { isFocused = true } .buttonStyle(.borderedProminent) Button("Unfocus") { isFocused = false } .buttonStyle(.bordered) } } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) .padding() } .ignoresSafeArea(.keyboard, edges: .bottom) } } #Preview { ContentView() } Steps to reproduce: Run** the app on iOS 26.0 beta 5 (17A5295f). Tap Focus → keyboard appears as expected. Tap Unfocus → keyboard disappears instantly without the usual slide-down animation. Expected result: Keyboard should animate smoothly downwards when dismissed. Actual result: Keyboard instantly vanishes without animation. p.s. we should be really able to upload videos here for demostration

Description: 1. When initiating the print flow via UIPrintInteractionController, and no printer is initially connected, iOS displays all possible paper sizes in the paper selection UI. However, if a printer connects in the background after this view is shown, the list of paper sizes does not automatically refresh to reflect only the options supported by the connected printer. 2. If the user selects an incompatible paper size (one not supported by the printer that has just connected), the app crashes due to an invalid configuration. Steps to Reproduce: Launch the app and navigate to the print functionality. Tap the Print button to invoke UIPrintInteractionController. At this point, no printer is yet connected. iOS displays all available paper sizes. While the paper selection UI is visible, the AirPrint-compatible printer connects in the background. Without dismissing the controller, the user selects a paper size (e.g., one that is not supported by the printer). The app crashes. Expected Result: App should not crash Once the printer becomes available (connected in the background), the paper size options should refresh automatically. The list should be filtered to only include sizes that are compatible with the connected printer. This prevents the user from selecting an invalid option, avoiding crashes. Actual Result: App crashes The paper size list remains unfiltered. The user can still select unsupported paper sizes. Selecting an incompatible option causes the app to crash, due to a mismatch between UI selection and printer capability. Demo App Crash : https://drive.google.com/file/d/19PV02wzOJhc2DYI6kAe-uxHuR1Qg15Bu/view?usp=sharing Apple Files App Crash: https://drive.google.com/file/d/1flHKuU_xaxHSzRun1dYlh8w7nBPJZeRb/view?usp=sharing

I’m trying to understand the exact role of the return value in the UITextFieldDelegate method textFieldShouldReturn(_:). From my experiments in Xcode, I observed: Returning true vs false does not seem to cause any visible difference (e.g., the keyboard does not automatically dismiss either way). I know that in shouldChangeCharactersIn returning true allows the system to insert the character, and returning false prevents it. That’s clear. For textFieldShouldReturn, my current understanding is that returning true means “let the OS handle the Return press,” and returning false means “I’ll handle it myself.” My confusion: what is it that the OS actually does when it “handles” the Return press? Does UIKit do anything beyond calling this delegate method? If the system is supposed to dismiss the keyboard when returning true, why doesn’t it happen automatically? I’d appreciate clarification on the expected use of this return value — specifically, what default behavior the system performs (if any) when we return true. Thanks!

On testing my app with tvOS 18, I have noticed the Siri Remote back button no longer provides system-provided behavior when interacting with tab bar controller pages. Instead of moving focus back to the tab bar when pressed, the back button will close the app, as if the Home button was pressed. This occurs both on device and in the Simulator. Create tvOS project with a tab bar controller. Create pages/tabs which contain focusable items (ie. buttons) Scroll down to any focusable item (ie. a button or UICollectionView cell) Hit the Siri Remote back button. See expect behavior below: Expected behavior: System-provided behavior should move focus back to the tab bar at the top of the screen. Actual results: App is closed and user is taken back to the Home Screen. Has anyone else noticed this behavior?

(NSString*)getClienttime { NSDate* currentDate = [NSDate date]; NSDateFormatter* dateformatter = [[NSDateFormatter alloc] init]; dateformatter.timeZone = [NSTimeZone timeZoneForSecondsFromGMT:8*3600]; dateformatter.locale= [NSLocale systemLocale]; [dateformatter setDateFormat:@"yyyy-MM-dd HH:mm:ss"]; return [dateformatter stringFromDate:currentDate]?:@""; } the info of crash 1 libicucore.A.dylib icu::UnicodeString::copyFrom(icu::UnicodeString const&, signed char) (in libicucore.A.dylib) + 36 2 libicucore.A.dylib icu::DecimalFormatSymbols::operator=(icu::DecimalFormatSymbols const&) (in libicucore.A.dylib) + 64 3 libicucore.A.dylib icu::DecimalFormatSymbols::operator=(icu::DecimalFormatSymbols const&) (in libicucore.A.dylib) + 64 4 libicucore.A.dylib icu::DecimalFormat::DecimalFormat(icu::DecimalFormat const&) (in libicucore.A.dylib) + 188 5 libicucore.A.dylib icu::DecimalFormat::clone() const (in libicucore.A.dylib) + 48 6 libicucore.A.dylib icu::NumberFormat::createInstance(icu::Locale const&, UNumberFormatStyle, UErrorCode&) (in libicucore.A.dylib) + 188 7 libicucore.A.dylib icu::SimpleDateFormat::initialize(icu::Locale const&, UErrorCode&) (in libicucore.A.dylib) + 580 8 libicucore.A.dylib icu::SimpleDateFormat::SimpleDateFormat(icu::Locale const&, UErrorCode&) (in libicucore.A.dylib) + 332 9 libicucore.A.dylib icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) (in libicucore.A.dylib) + 264 10 libicucore.A.dylib udat_open (in libicucore.A.dylib) + 396 11 CoreFoundation __cficu_udat_open (in CoreFoundation) + 72 12 CoreFoundation __ResetUDateFormat (in CoreFoundation) + 508 13 CoreFoundation __CreateCFDateFormatter (in CoreFoundation) + 324 14 Foundation -[NSDateFormatter _regenerateFormatter] (in Foundation) + 204 15 Foundation -[NSDateFormatter stringForObjectValue:] (in Foundation) + 104 16 ABC +[JMAContext getClienttime] (in DadaStaff) (JMAContext.m:73)

Note: in this post I discuss sceneDidEnterBackground/WillResignActive but I assume any guidance provided would also apply to the now deprecated applicationDidEnterBackground/applicationWillResignActive and SwiftUI's ScenePhase (please call out if that's not the case!). A common pattern for applications with sensitive user data (banking, health, private journals, etc.) is to obsurce content in the app switcher. Different apps appear to implement this in two common patterns. Either immediately upon becoming inactive (near immediately upon moving to task switcher) or only upon becoming backgrounded (not until you've gone to another app or back to the home screen). I’d like to make sure we’re aligned with Apple’s intended best practices and am wondering if an anti-pattern of using sceneWillResignActive(_:) may be becoming popularized and has minor user experience inconviences (jarring transitions to the App Switcher/Control Center/Notification Center and when the system presents alerts.) Our applications current implementation uses sceneDidEnterBackground(_:) to obscure sensitive elements instead of sceneWillResignActive(_:), based on the recomendations from tech note QA1838 and the documentation in sceneDidEnterBackground(_:) ... Shortly after this method [sceneWillEnterBackground] returns, UIKit takes a snapshot of your scene’s interface for display in the app switcher. Make sure your interface doesn’t contain sensitive user information. Both QA1838 and the sceneDidEnterBackground documentation seem to indicate backgrounding is the appropriate event to respond to for this pattern but I am wondering if "to display in the app switcher" may be causing confusion since your app can also display in the app switcher upon becoming inactive and if some guidance could be added to sceneWillResignActive that it is not nesscary to obsure content during this state (if that is true). In our testing, apps seems to continue to play any in-progress animations when entering the app switcher from the application (inactive state), suggesting no snapshot capture. We also discovered that it appears sceneWillResignActive not always be called (it usually is) but occasionally you can swipe into the app switcher without it being called but that sceneDidEnterBackground is triggered more consistently. It appears the Wallet app behaves as I'd expect with sceneDidEnterBackground on card details screens as well (ejecting you to the card preview if you switch apps) but will keep you on the card details screen upon becoming inactive. Questions: Is sceneDidEnterBackground(_:) still Apple’s recommended place to obscure sensitive content, or should apps handle this earlier (e.g. on inactive)? Would it actually be recommended against using sceneWillResignActive active given it seems to not be gauranteed to be called? Ask: Provide an updated version of QA1838 to solidfy the extrapolation of applicationDidEnterBackground -> sceneDidEnterBackground Consider adding explicit guidance to sceneWillResignActive documentation

I have a document-based macOS app written in Objective-C, and each document window contains a scrollable NSTextView. I know that printing can get complicated if you want to do nice pagination, but is there a quick and dirty way to get basic printing working? As it is, the print panel shows up, but its preview area is totally blank. Here's the current printing part of my NSDocument subclass. - (NSPrintInfo *)printInfo { NSPrintInfo *printInfo = [super printInfo]; [printInfo setHorizontalPagination: NSPrintingPaginationModeFit]; [printInfo setHorizontallyCentered: NO]; [printInfo setVerticallyCentered: NO]; [printInfo setLeftMargin: 72.0]; [printInfo setRightMargin: 72.0]; [printInfo setTopMargin: 72.0]; [printInfo setBottomMargin: 72.0]; return printInfo; } - (void)printDocumentWithSettings:(NSDictionary<NSPrintInfoAttributeKey, id> *)printSettings showPrintPanel:(BOOL)showPrintPanel delegate:(id)delegate didPrintSelector:(SEL)didPrintSelector contextInfo:(void *)contextInfo { NSPrintInfo* thePrintInfo = [self printInfo]; [thePrintInfo setVerticallyCentered: NO ]; NSPrintOperation *op = [NSPrintOperation printOperationWithView: _textView printInfo: thePrintInfo ]; [op runOperationModalForWindow: _docWindow delegate: delegate didRunSelector: didPrintSelector contextInfo: contextInfo]; }

I have a strange issue for iOS26. I have a UITabBarController at the root view of the app, but on certain actions, I want to hide it temporarily, and then have some options where the user can press a button which display some options using UIAlertController. It used to work fine before, but with iOS26, when the UIAlertController is presented, the tab bar (which is hidden by setting the ‘frame’) suddenly pops back into view automatically, when I don't want it to. Here's an example that reproduces the issue: class TestTableViewController: UITableViewController { private var isEditMode: Bool = false override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. self.navigationItem.leftBarButtonItem = UIBarButtonItem(title: "Change", style: .plain, target: self, action: #selector(changeMode)) } @objc func changeMode() { print("change mode called") if isEditMode == false { isEditMode = true // hide tab bar setEditingBarVisible(true, animated: true) self.navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Action", style: .plain, target: self, action: #selector(showActionsList)) } else { isEditMode = false // show tab bar setEditingBarVisible(false, animated: true) self.navigationItem.rightBarButtonItem = nil } } @objc func showActionsList() { let alert = UIAlertController(title: "Action", message: "showing message", preferredStyle: .actionSheet) alert.addAction(UIAlertAction.init(title: "Cancel", style: .cancel, handler: nil)) self.present(alert, animated: true, completion: nil) } @objc func setEditingBarVisible(_ visible: Bool, animated: Bool) { guard let tabBar = tabBarController?.tabBar else { return } let performChanges = { // Slide the tab bar off/on screen by adjusting its frame’s y. // This is safe because UITabBar is frame-managed, not Auto Layout constrained. var frame = tabBar.frame let height = frame.size.height if visible { // push it down if not already if frame.origin.y < self.view.bounds.height { frame.origin.y = self.view.bounds.height + self.view.safeAreaInsets.bottom } // Give our content its full height back (remove bottom safe-area padding that tab bar created) self.additionalSafeAreaInsets.bottom = 0 } else { // bring it back to its normal spot frame.origin.y = self.view.bounds.height - height // Re-apply bottom safe-area so content clears the tab bar again self.additionalSafeAreaInsets.bottom = height } tabBar.frame = frame // Ensure layout updates during animation self.tabBarController?.view.layoutIfNeeded() self.view.layoutIfNeeded() } if animated { UIView.animate(withDuration: 0.28, delay: 0, options: [.curveEaseInOut]) { performChanges() } } else { performChanges() } } } I have a bar button called 'Change', and selecting it should hide/show the UITabBar at the bottom, and show/hide a different bar button called 'Action'. Selecting the 'Action' button shows an alert. With iOS26, with the tab bar moved out of view, when the 'Action' button is called, the alert shows but the tab bar automatically moves into view as well. Is this a known issue? Any workaround for it? I filed FB19954757 just in case.

When building with the iOS 26 SDK (currently beta 4), the navigation title is often illegible when rendering a Map view. For example, note how the title "Choose Location" is obscured by the map's text ("South America") in the screenshot below: This screenshot is the result of the following view code: import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } I tried using the scrollEdgeEffectStyle(_:for:) modifier to apply a scroll edge effect to the top of the screen, in hopes of making the title legible, but that doesn't seem to have any effect. Specifically, the following code seems to produce the exact same result shown in the screenshot above. import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .scrollEdgeEffectStyle(.hard, for: .top) // ⬅️ no apparent effect .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } Is there a recommended way to resolve this issue so that the navigation title is always readable?

This is probably abusing the system more than it should be but maybe it is somehow possible. I have: An objective-C based storyboard iPad OS app. I'm beginning to adopt SwiftUI. I have a hosting controller with a content view that has a lazygrid of cards, which have an NSManagedObject for data. On tapping a card, a detail view opens, if in multi-tasking, a new window, if not, pushing the navigation controller (this detail view still exists in UIKit/ObjC, and is handled by sending a notification with the ObjectID, which then triggers a storyboard segue to the detail.) I have zoom transitions on all my things. They work great in Obj.C, especially now with the bar button source. On my iPhone target, I still have an old tableview, and I'm able to zoom properly - if someone changes the detail view's managed object (through a history menu), the zoom context looks up where the tableview is, and scrolls to it while popping. I'd like to somehow do this on the lazygrid - first) to just have an individual card be the zoom source, it should be able to know what the source view is to say in the prepareForSegue method just to zoom at all. and second) if the detail has changed the current ObjectID (which gets passed around as a notification), to somehow scroll the lazygrid to the right object before popping. I've looked at https://developer.apple.com/tutorials/SwiftUI/interfacing-with-uikit but this seems like swiftUI is the host. I have it the other way around, uikit hosting swiftUI pushing uikit. TIA for any pointers

I need more time to adapt to the new iOS 26 UI, so I set the "UIDesignRequiresCompatibility" attribute to "Yes." This works, but now all large titles are not aligned with the content. Below you can see an example, but I have the issue with all large titles. All good on iOS 18. Does anyone have an idea why and how can i fix it?

Hello! I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators. When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar. On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator. Here's a clip from a simulator: Here's the code that reproduced the bug I experienced in our app. #Preview { NavigationStack { ScrollView { TextField("", text: .constant("")) .padding() .background(Color.secondary) TextField("", text: .constant("")) .padding() .background(Color.green) } .padding() .safeAreaInset(edge: .bottom, content: { Color.red .frame(maxWidth: .infinity) .frame(height: 40) }) .toolbar { ToolbarItem(placement: .keyboard) { Button {} label: { Text("test") } } } } }

NavigationLinks do not display correctly in tvOS 26. When using a Button, the correct behavior of vertically placing an Image or AsyncImage above one or two Text fields occurs. However, when using NavigationLink the image and text(s) are laid out horizontally. Attempting to fix this using a VStack prevents the text from sliding down as the NavigationLink receives focus. Using the hoverEffect modifier does not help. Using a Button (correct behavior): Using a NavigationLink without VStack: Using a NavigationLink with VStack:

I have a custom list and I want to make the names in the list editable through double tap. I know how to solve this hacky ways. But are there no solid way to achieve this? like having .disabled without graying it out?

When building with iOS 26 SDK beta 5 (23A5308f), onTapGesture is no longer being triggered on Map views. This appears to be a regression in beta 5 specifically, as this issue was not present in beta 4. How to reproduce Code The following code demonstrates the issue, as seen in the videos below. import MapKit import SwiftUI struct ContentView: View { @State private var location = CGPoint.zero var body: some View { Map() .onTapGesture { location in self.location = location } .safeAreaInset(edge: .bottom) { VStack(alignment: .center) { Text("iOS \(UIDevice.current.systemVersion)") .font(.largeTitle) Text("Tapped Location") Text("\(location.x), \(location.y)") } .frame(maxWidth: .infinity, alignment: .center) .background(.background) } } } Demo The gifs below show the behavior in iOS 18.5 (in which the tap gestures are recognized and tapped coordinate is displayed in the safe area inset) and iOS 26 beta 5 (in which the tap gestures have no effect): iOS 18 iOS 26 Next steps? Is there a recommended workaround for this issue?

Observed on iPadOS 26 b8 in apps built with current SDK: Floating keyboard lacks corner mask Floating key blue highlight not aligned with its background Invoking floating keyboard can result in “ghost” full-sized keyboard appearing at bottom of screen Swipe-dismissing floating keyboard can result in it bouncing back up, again with ghost keyboard appearing Touching globe key can produce menus truncated/obscured by ghost keyboard Ghost keyboard can remain visible even after backgrounding the app (Some of these issues may be limited to non-English keyboards) FB19951605

On iPhone, I would like to have a more button at the top right of the navigation bar, a search field in the bottom toolbar, and a plus button to the right of the search field. I've achieved this via the code below. But on iPad they should be in the navigation bar at the trailing edge from left to right: plus, more, search field. Just like the Shortcuts app, if there's not enough horizontal space, the search field should collapse into a button, and with even smaller space the search bar should become full-width under the navigation bar. Right now on iPad the search bar is full width under the navigation bar, more at top right, plus at bottom middle, no matter how big the window is. How can I achieve that? Any way to specify them for the system to more automatically do the right thing, or would I need to check specifically for iPhone vs iPad UIDevice to change the code? struct ContentView: View { @State private var searchText = "" var body: some View { NavigationStack { VStack { Text("Hello, world!") } .navigationTitle("Test App") .searchable(text: $searchText) .toolbar { ToolbarItem { Menu { //... } label: { Label("More", systemImage: "ellipsis") } } DefaultToolbarItem(kind: .search, placement: .bottomBar) ToolbarSpacer(.fixed, placement: .bottomBar) ToolbarItem(placement: .bottomBar) { Button { print("Add tapped") } label: { Label("Add", systemImage: "plus") } } } } } }

Is it possible at all to programmatically change visible rect / map region programmatically? Otherwise, how can we make sure user sees anythng just after starting the app, if nearest POIs are far away?