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") } } } } }

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?

We are encountering an issue with noticeable lag when interacting with objects in Unity using the XR Interaction Toolkit. Even with the Movement Type set to Instantaneous, interactable objects still show a delay when following hand movements, especially at higher speeds. Is there additional configuration required, or any recommended steps to eliminate this latency? https://wifi4compressed.com/

Hi, In the WWDC25 session Elevate an app with Swift concurrency (timestamps: 8:04 and later), the StickerViewModel is shown annotated with @Observable but not @MainActor. The narration mentions that updates happen on the main thread, but that guarantee is left implicit in the calling code. In Swift 6, though, one of the major benefits is stronger compiler enforcement against data races and isolation rules. If a view model were also annotated with @MainActor, then the compiler could enforce that observable state is only updated on the main actor, preventing accidental background mutations or updates that can cause data races between nonisolated and main actor-isolated uses. Since @Observable already signals that state changes are intended to be observed (and in practice, usually by views), it seems natural that such types should also be main-actor isolated. Otherwise, we’re left with an implicit expectation that updates will always come from the main thread, but without the compiler’s help in enforcing that rule. This also ties into the concept of local reasoning that was emphasized in other Swift 6 talks (e.g. Beyond the basics of structured concurrency). With @MainActor, I can look at a view model and immediately know that all of its state is main-actor isolated. With only @Observable, that guarantee is left out, which feels like it weakens the clarity that Swift 6 is trying to promote. Would it be considered a best practice in Swift 6 to use both @Observable and @MainActor for UI-facing view models? Or is the intention that SwiftUI developers should rely on calling context to ensure main-thread updates, even if that means the compiler cannot enforce isolation? Thanks!

The following is verbatim of a feedback report (FB19809442) I submitted, shared here as someone else might be interested to see it (I hate the fact that we can't see each other's feedbacks). On iOS 16, TextKit 2 calls NSTextLayoutFragment's draw(at:in:) method once for the first paragraph, but for every other paragraph, it calls it continuously on every scroll step in the UITextView. (The first paragraph is not cached; its draw is called again when it is about to be displayed again, but then it is again called only once per its lifecycle.) On iOS 17, the behavior is similar; the draw method gets called once for the 1st and 2nd paragraph, and for every other paragraph it again gets called continuously as a user scrolls a UITextView. On iOS 18 (and iOS 26 beta 4), TextKit 2 calls the layout fragment's draw(at:in:) on every scroll step in the UITextView, for all paragraphs. This results in terrible performance. TextKit 2 is promised to bring many performance benefits by utilizing the viewport - a new concept that represents the visible area of a text view, along with a small overscroll. However, having the draw method being constantly called almost negates all the performance benefits that viewport brings. Imagine what could happen if someone needs to add just a bit of logic to that draw method. FPS drops significantly and UX is terribly degraded. I tried optimizing this by only rendering those text line fragments which are in the viewport, by using NSTextViewportLayoutController.viewportBounds and converting NSTextLineFragment.typographicBounds to the viewport-relative coordinate space (i.e. the coordinate space of the UITextView itself). However, this patch only works on iOS 18 where the draw method is called too many times, as the viewport changes. (I may have some other problems in my implementation, but I gave up on improving those, as this can't work reliably on all OS versions since the underlying framework isn't calling the method consistently.) Is this expected? What are our options for improving performance in these areas?

I really enjoyed using SwiftData for persistence until I found out that the CloudKit integration ensures changes are only eventually consistent, and that changes can propagate to other devices after as long as minutes, making it useless for any feature that involves handoff between devices. Devastating news but I guess it’s on me for nrtfm. I may try my hand at a custom model context DataStore integrating Powersync, but that’s a whole trip and before I embark on it I was wondering if anyone had suggestions for resolving this problem in a simple and elegant manager that allows me to keep as much of the machinery within Apple’s ecosystem as possible, while ensure reliable “live” updates to SwiftData stores on all eligible devices.

I am trying out iOS26 with my existing app. I have a UITabBarController which is set to the main window's rootViewController, and I setup my UITabBar viewControllers programmatically. The first tab's root view has a UITableView with 100s of rows. When I build and run with the new Xcode, the app has the iOS26 look, but the table view doesn't seem to scroll behind the tab bar. The tab bar seems to have a hard edge and the content doesn't show through behind that. I have tried setting up the UITabBarController with the UITab items from iOS18 as well, but that doesn't help either. If I build a new project using the Xcode template, with storyboards, it works as expected and table view content shows through the UITabBar. What could be causing this? Is there something I need to configure to get the correct effect in iOS26? -- Figure it out: I needed to pin the bottomAnchor of the view controller to view's bottomAnchor (not safeAreaLayoutGuide.bottomAnchor)

We have an app that uses a NSProgressIndicator indeterminate and it no longer animates on Tahoe (currently beta 8). I did a empty swift app using storyboards and added this to the view controller: override func viewDidLoad() { super.viewDidLoad() let progressIndicator=NSProgressIndicator.init(frame: NSMakeRect(0, 300, 400,20)) progressIndicator.style = .bar progressIndicator.isIndeterminate = true progressIndicator.isDisplayedWhenStopped=true self.view.addSubview(progressIndicator) progressIndicator.startAnimation(self) } Works fine in macOS 15, no animation in macOS 26. If I switch to the style to spinner, it animates fine. Filed feedback FB19933934

In the current beta of iPadOS 26.0 (23A5297m), the camera does not function properly when the following conditions are met: The device is set to Windowed Apps mode in the Settings app. Multiple application windows are present on one screen. Using AVCaptureVideoPreviewLayer. On the other hand, UIImagePicker works properly. Is this a specification of iPadOS 26 that cannot be avoided? Or is there an official solution or workaround available?

I've been exploring the resources from WWDC25 Session 280: "Code-along: Cook up a rich text experience in SwiftUI with AttributedString" and the SwiftUI documentation on "Building rich SwiftUI text experiences." After spending some time experimenting and trying to implement these features with these APIs on iOS26 , I’ve run into a specific question. Is there a way to programmatically trigger the Format Sheet directly—for example, from a custom button—rather than requiring the user to go through the multi-step process of selecting text, opening the context menu, tapping "Format," and then selecting "More"? I’d like to provide a more streamlined editing experience in my app. Any guidance would be greatly appreciated!