Hello, I am exploring an iPadOS product idea for Apple Pencil users and would like to understand the current public API boundary. The user need is a temporary, user-controlled Apple Pencil annotation layer while the user is working in another app or workspace. For example, a student may be reading in Books, Safari, a PDF app, or another educational app and want to write quick Pencil notes directly over the visible material without taking a screenshot or exporting the content first. I understand that PencilKit works inside an app's own UI, and I also understand that iPadOS sandboxing prevents third-party apps from inspecting or modifying other apps. I am not trying to bypass that model. What I am trying to determine is: Is there any current public API, extension point, or entitlement that allows a user-initiated Apple Pencil overlay session across the current iPadOS workspace? If not, is Feedback Assistant the right place to request a new PencilKit / iPadOS entitlement for this use case? Are there existing Apple-recommended patterns for this workflow beyond Quick Note, Screenshot Markup, Split View, Stage Manager, or importing content into the developer's own app? The privacy model I have in mind would be strict: The overlay is user initiated only. A visible system indicator is shown while active. The developer app receives Pencil stroke data only by default. The app cannot inspect the underlying app's view hierarchy, documents, text, or private data. Screen pixels are not captured unless the user grants separate explicit permission. The user can close or clear the overlay at any time. The closest mental model is a system-mediated Pencil annotation layer, not a background screen recorder or a way to control another app. If this is not possible today with public APIs, I would appreciate confirmation so I can file a clear enhancement request through Feedback Assistant. I also filed this as Feedback Assistant report FB23067750. Thank you.

Hi team, We are seeing a high volume of app terminations (uANRs), with most of them sharing the attached stack trace. I’d love to get your input on potential workarounds or fixes we can explore to mitigate this issue. 0 CoreFoundation -[__NSSingleObjectArrayI countByEnumeratingWithState:objects:count:] + 132 1 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 228 2 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 3 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 4 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 5 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 6 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 7 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 8 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 9 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 10 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 11 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 12 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 13 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 14 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 15 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 16 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 17 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 18 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 19 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 20 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 21 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 22 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 23 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 24 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 25 ScreenshotServices +[SSScreenshotMetadataHarvester _contentRectsForMetadata] + 216 26 ScreenshotServices +[SSScreenshotMetadataHarvester harvestScreenshotMetadataAndRespondToAction:] + 628 27 UIKitCore -[UIScreenshotMetadataRequestAction fulfillRequest] + 180 28 UIKitCore -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] + 3432 29 UIKitCore -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 412 30 UIKitCore -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 31 UIKitCore -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 32 FrontBoardServices __76-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.146 (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 252 33 FrontBoardServices -[FBSScene _callOutQueue_coalesceClientSettingsUpdates:] + 68 34 FrontBoardServices -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 712 35 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 148 36 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 37 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 + 252 38 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke + 184 39 libdispatch.dylib _dispatch_client_callout + 16 40 libdispatch.dylib _dispatch_block_invoke_direct + 284 41 FrontBoardServices __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 52 42 FrontBoardServices -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 240 43 FrontBoardServices -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 28 44 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in ae3c9338-0166-397a-9643-356b14f6ee58) + 28 45 CoreFoundation __CFRunLoopDoSource0 (in ae3c9338-0166-397a-9643-356b14f6ee58) + 172 46 CoreFoundation __CFRunLoopDoSources0 (in ae3c9338-0166-397a-9643-356b14f6ee58) + 332 47 CoreFoundation __CFRunLoopRun (in ae3c9338-0166-397a-9643-356b14f6ee58) + 840 48 CoreFoundation CFRunLoopRunSpecific (in ae3c9338-0166-397a-9643-356b14f6ee58) + 572 49 GraphicsServices GSEventRunModal (in d372e13f-7505-3add-ae13-062656f0b1f6) + 168 50 UIKitCore -[UIApplication _run] (in 5e794caa-4162-3ff6-861e-45f29f6b8ac0) + 816 51 UIKitCore UIApplicationMain (in 5e794caa-4162-3ff6-861e-45f29f6b8ac0) + 336

Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRenderer afresh from UIImage(systemName:) — no caching of UIImage across rebuilds Images are baked via withTintColor(_:renderingMode: .alwaysOriginal) then rasterized, so CarPlay receives a finished bitmap rather than a template image relying on its tinting pipeline Same code path renders correctly on launch and for hours afterward — the input bytes are identical before and after the failure boundary Because the failure survives both the app process and the CPTemplateApplicationScene teardown, the corrupted state appears to live in an iOS system process rather than in the app or the CarPlay session. Question for the forum Is there a known workaround on the app side — a different image-supply API, or a way to force the CarPlay rendering pipeline to invalidate its cache without an iPhone reboot?

I am encountering a consistent, reproducible crash in our app when presenting a UIDatePicker configured with the calendar style. The crash triggers every single time the picker is invoked and points directly to the modern date picker's internal UICollectionView. The Exception: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'UICollectionView internal inconsistency: attempted to set layout with the collection view requiring a reload' let datePicker = UIDatePicker() datePicker.datePickerMode = .date datePicker.preferredDatePickerStyle = .compact This crash is occuring in inline style too when I try to open the calendar. I tried this in other apps. It works fine. I didn't override any collectionView layouts

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

I couldn't decide whether to post this question here or in SwiftUI Q&A as there's a lot of overlaps. We're trying to create something similar to UIViewRepresentable for UIKit. This might not work for complicated cases where the View has many pieces but as long as it works for simple cases, we're happy. The only problem right now is figuring out the correct height. Currently, the height anchor is assigned to CGFloat.greatestFiniteMagnitude, which works but when inspecting the layout in View Hierarchy, it appears the wrapped view is getting stretched all the way down. Also, sometimes View Hierarchy isn't able to draw the wrapped View and I'm unsure if it's a problem of View Hierarchy or our implementation. final public class SwiftUIConfigurationContainerView<T: View>: UIView { private var contentView: UIView? public override var intrinsicContentSize: CGSize { contentView?.intrinsicContentSize ?? super.intrinsicContentSize } private var preferredContentSize: CGSize? public init(@ViewBuilder _ content: @escaping () -> T) { super.init(frame: .zero) setUpContentView(content) } @available(*, unavailable) required init?(coder: NSCoder) { return nil } private func setUpContentView(_ content: @escaping () -> T) { let contentView = UIHostingConfiguration { [weak self] in VStack(spacing: .zero) { content() .onGeometryChange(for: CGSize.self, of: \.size) { size in self?.preferredContentSize = size self?.invalidateIntrinsicContentSize() } .frame(maxWidth: .infinity, alignment: .center) Spacer(minLength: .zero) } } .minSize(width: .zero, height: .zero) .margins(.all, .zero) .makeContentView() self.contentView = contentView addSubview(contentView) contentView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ contentView.leadingAnchor.constraint(equalTo: leadingAnchor), contentView.trailingAnchor.constraint(equalTo: trailingAnchor), contentView.topAnchor.constraint(equalTo: topAnchor), contentView.heightAnchor.constraint(equalToConstant: CGFloat.greatestFiniteMagnitude), ]) } }

Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki

See existing post here: https://developer.apple.com/forums/thread/803378 When I add a UIScrollEdgeElementContainerInteraction to a view at the top of a scroll view, the blur effect doesn't always fill the full bounds of the view. The behavior changed a bit from 26.0 to 26.1 and then again in 27.0 seed 1. It depends on what subviews are there, and particularly (at least between 26.1 and 26.5) if there's a UIVisualEffectView with a glass effect. FB20756572

It seems like the automatic edge effect defaults to hard in iOS 27 and soft on iOS 26. Designing for both of these is actually quite difficult - especially since hard edge effects don't work with pinned views in LazyVStack. Is there a way to set the global default to soft for an app?

I've got an iOS app with a custom top toolbar view that uses a UIScrollEdgeElementContainerInteraction to achieve the iOS 26 progressive blur background. It's over top of a web view, and I've set the top edge effect style on its scroll view to .hard so the toolbar's edges are more defined. I'm noticing that the blur doesn't extend fully to the bottom edge of the toolbar, and I'm curious to know if this is a bug or expected behavior. If the latter, what exactly are the details of what's expected? What determines the bottom extent of the blur? I've got this result in a sample project on iOS 26.0. The white border is the label, and the red border is the title bar view itself. Note that the Daring Fireball logo visible inside the bounds of the bar view, and is cut off at the bottom edge of the label. This is the code from the demo app that produced the screenshot. let config = WKWebViewConfiguration() let webView = WKWebView(frame: .zero, configuration: config) self.view.addSubview(webView) webView.translatesAutoresizingMaskIntoConstraints = false webView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; webView.bottomAnchor.constraint(equalTo: self.view.bottomAnchor).isActive = true; webView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true; webView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true; webView.scrollView.topEdgeEffect.style = .hard webView.load(URLRequest(url: URL(string: "https://daringfireball.net")!)) let barView = UIView() self.view.addSubview(barView) barView.translatesAutoresizingMaskIntoConstraints = false barView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; barView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true barView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true let edgeEffect = UIScrollEdgeElementContainerInteraction() edgeEffect.scrollView = webView.scrollView edgeEffect.edge = .top barView.addInteraction(edgeEffect) barView.layer.borderColor = UIColor.red.cgColor barView.layer.borderWidth = 1 let titleLabel = UILabel() barView.addSubview(titleLabel) titleLabel.translatesAutoresizingMaskIntoConstraints = false titleLabel.leftAnchor.constraint(equalTo: barView.leftAnchor).isActive = true titleLabel.rightAnchor.constraint(equalTo: barView.rightAnchor).isActive = true titleLabel.bottomAnchor.constraint(equalTo: barView.bottomAnchor, constant: -20).isActive = true titleLabel.topAnchor.constraint(equalTo: barView.safeAreaLayoutGuide.topAnchor, constant: 8).isActive = true titleLabel.textAlignment = .center titleLabel.text = "Title Here" titleLabel.layer.borderColor = UIColor.green.cgColor titleLabel.layer.borderWidth = 1

There seems to be a regression in the behavior of UIScrollEdgeElementContainerInteraction on iOS 26.1 when it's over a WKWebView. If the web view's scroll view's topEdgeEffect.style is changed to .hard and then back to .soft, it will stop tracking the color of the content underneath it and use the wrong-mix in color in its blur. I've filed this as FB20655398. Here's some sample code to illustrate the issue. The test.html file being loaded is just a bunch of div elements with lorem ipsum. private var webView: WKWebView? = nil override func viewDidLoad() { super.viewDidLoad() let config = WKWebViewConfiguration() let webView = WKWebView(frame: .zero, configuration: config) webView.navigationDelegate = self self.view.addSubview(webView) webView.autoPinEdgesToSuperviewEdges() webView.isInspectable = true self.webView = webView let url = Bundle.main.url(forResource: "test", withExtension: "html")! webView.loadFileURL(url, allowingReadAccessTo: Bundle.main.bundleURL) let blurView = UIView() self.view.addSubview(blurView) blurView.autoPinEdgesToSuperviewEdges(with: .zero, excludingEdge: .bottom) let label = UILabel() label.text = "This is a title bar" blurView.addSubview(label) label.autoAlignAxis(toSuperviewAxis: .vertical) label.autoPinEdge(toSuperviewEdge: .bottom, withInset: 8) label.autoPinEdge(toSuperviewSafeArea: .top, withInset: 8) let interaction = UIScrollEdgeElementContainerInteraction() interaction.scrollView = webView.scrollView interaction.edge = .top blurView.addInteraction(interaction) self.webView?.scrollView.topEdgeEffect.style = .hard DispatchQueue.main.asyncAfterUnsafe(deadline: .now() + .seconds(2)) { self.webView?.scrollView.topEdgeEffect.style = .soft } registerForTraitChanges([UITraitUserInterfaceStyle.self]) { (self: Self, previousTraitCollection: UITraitCollection) in self._updateWebViewColors() } } private func _updateWebViewColors() { let dark = self.traitCollection.userInterfaceStyle == .dark let text = dark ? "#FFFFFF" : "#000000" let bg = dark ? "#000000" : "#FFFFFF" let js = "document.body.style.color = '\(text)';\ndocument.body.style.backgroundColor = '\(bg)';" self.webView?.evaluateJavaScript(js) { res, err in if let err { print("JS error: \(err)") } } } If you run that, then change the system them to dark mode, you get this. Has anyone else seen this before? Know how to work around it?

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

Since iPadOS 26.1 I notice a new annoying bug when changing the dark mode option of the system. The appearance of the UI changes, but no longer for view controllers which are presented as Popover. For these view controllers the method "traitCollectionDidChange()" is still called (though sometimes with a very large delay), but checking the traitCollection property of the view controller in there does no longer return the correct appearance (which is probably why the visual appearance of the popover doesn't change anymore). So if the dark mode was just switched on, traitCollectionDidChange() is called, but the "traitCollection.userInterfaceStyle" property still tells me that the system is in normal mode. More concrete, traitCollection.userInterfaceStyle seems to be set correctly only(!) when opening the popover, and while the popover is open, it is never updated anymore when the dark mode changes. This is also visible in the standard Apps of the iPad, like the Apple Maps App: just tap on the "map" icon at the top right to open the "Map mode" view. While the view is open, change the dark mode. All of the Maps App will change its appearance, with the exception of this "Map mode" view. Does anyone know an easy workaround? Or do I really need to manually change the colors for all popup view controllers whenever the dark mode changes? Using dynamic UIColors won't help, because these rely on the "userInterfaceStyle" property, and this is no longer correct. Bugreport: FB20928471

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

I have an App which supports multiple windows on the iPad. The App can receive URLs from other Apps (via application.openURL()) and also files via "share sheet" (via UIActivityViewController). When receiving a URL from another App the delegate method scene(_ scene: UIScene, openURLContexts URLContexts: Set) will be called on an existing UIScene, however when a file is received through the share sheet from another App, a new UIScene is created and therefore also a new window (eg the delegates application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) and scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) are called). In both cases I do get the URL and file just fine, however I do not want to get new UIScenes and windows created when receiving a file via share sheet. How can I prevent to get a new UIScene or window? The received files should be used in the existing windows and should not create new ones.

Description I'm developing a custom keyboard extension using UIInputViewController and need to set a specific height of 268 points. The keyboard functions correctly, but there's a visible flicker and resize animation during launch that I cannot eliminate. The Problem When the keyboard launches, iOS provides incorrect heights before settling on the correct one. At launch, the view starts at 0×0. Around 295ms later, iOS sets the frame to 440×956 which is full screen height and wrong. Around 373ms, iOS changes it to 440×452 which is still wrong. Finally around 390ms, iOS settles at 440×268 which matches our constraint. This causes visible flicker as the view resizes three times rapidly. The keyboard appears to shrink from full screen down to the correct height, and users can clearly see this animation happening. What I've Tried I've tried adding a height constraint on self.view which gives me the correct height but causes the visible flicker. I created a custom UIInputView subclass and overrode intrinsicContentSize to return my desired height. iOS completely ignores this and gives random heights like 471pt, 680pt, or 956pt instead. I set allowsSelfSizing to true on my UIInputView subclass. iOS ignores this property. I set preferredContentSize on the view controller. iOS ignores this as well. I tried adding the constraint in viewDidAppear instead of viewDidLoad, thinking iOS might have settled by then. It still causes flicker. I overrode the frame and bounds setters on my UIInputView to clamp the height to my desired value. iOS bypasses these overrides somehow. I overrode layoutSubviews to force the correct height after the super call. iOS still applies its own height. Specific Question What is the correct API or technique to specify a keyboard extension's height that iOS will respect immediately upon launch, without triggering the resize animation sequence? Other third-party keyboards like Grammarly and SwiftKey appear to have solved this problem. Their keyboards appear at the correct height without any visible flicker. How do they achieve this? Expected Outcome The keyboard should appear at 268pt height on the first frame with no visible resize animation. Steps to Reproduce Create a new iOS App project in Xcode and add a Keyboard Extension target. In KeyboardViewController.swift, add a height constraint in viewDidLoad: override func viewDidLoad() { super.viewDidLoad() let heightConstraint = view.heightAnchor.constraint(equalToConstant: 268) heightConstraint.priority = .defaultHigh heightConstraint.isActive = true let label = UILabel() label.text = "Demo Keyboard" label.textAlignment = .center label.translatesAutoresizingMaskIntoConstraints = false view.addSubview(label) NSLayoutConstraint.activate([ label.centerXAnchor.constraint(equalTo: view.centerXAnchor), label.centerYAnchor.constraint(equalTo: view.centerYAnchor) ]) } Build and run on a physical device. Enable the keyboard in Settings, then General, then Keyboard, then Keyboards. Open any app with a text field and switch to the custom keyboard using the globe button. Observe the height changing from around 956pt to 452pt to 268pt with visible animation. Environment iOS 17 and iOS 18 and 26.2, Xcode 16 and Xcode 26, affects all iPhone models tested, reproducible on both simulator and physical device.

The view controller stack: UITabBarController ｜__ UINavigationController ｜__ HomeViewController (hidesBottomBarWhenPushed=false) ｜__ DetailViewController (hidesBottomBarWhenPushed=true) The DetailViewController customize the navigation transition via UINavigationControllerDelegate, UIViewControllerAnimatedTransitioning and UIViewControllerInteractiveTransitioning protocols, so that the navigation can be driven by a vertical pan or swipe gesture. Use a real device to : Step 1, drag the DetailViewController down and cancel, the tabBar flashes for a while and keep hidden after dragging. Step 2, repeat the step 1 again, the tabBar remains at the bottom, but without buttons. DetailViewController.swift

My app presents a popover mail controller, which works fine on iPhone and on iPadOS <26.4. However in iPadOS =>26.4, there is no exit or cancel button in the top left corner as usual. The popover can only be closed by tapping the top centre of the view where the 'swipe down bar' is; it cannot be closed by actually swiping down. This is obviously not intuitive for a user. Since the mail controller is not customizable, I'm asking whether this is a bug, a new (unintuitive) design, or if implementations of a mail controller need updating on the new OS.

According to our crash analytics, the application crashes when trying to share a PDF file in the UIDocumentInteractionController. This crash takes place on iOS 26+ only. Based on analytics, user sessions end when the pdf file is opened in the UIDocumentInteractionController. We couldn't reproduce it on a physical device or a simulator. Can you please help with a fix or at least workaround for this issue? What's your opinion for bug localization (application or framework)? Crash log is attached below. CoreFoundation __exceptionPreprocess + 164 libobjc.A.dylib objc_exception_throw + 88 CoreFoundation -[__NSArrayM insertObject:atIndex:] + 1276 ShareSheet __79-[SHSheetActivityItemsManager loadItemProvidersForRequest:activity:completion:]_block_invoke + 972 ShareSheet __79-[_UIShareServiceActivityProxy _loadItemProvidersFromActivityItems:completion:]_block_invoke + 88 ShareSheet __74+[UIActivity _loadItemProvidersFromActivityItems:withCacheURL:completion:]_block_invoke_4 + 352 libdispatch.dylib _dispatch_call_block_and_release + 32 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 libdispatch.dylib _dispatch_main_queue_drain + 180 CoreFoundation __CFRunLoopRun + 1944

Our app supports Full Keyboard Access. We have a scroll view containing content that extends beyond the visible area. When navigating with the keyboard, focusable elements inside the scroll view are reached and the view scrolls to follow focus, but content that has no focusable elements (e.g. long blocks of static text, images, or footer content below the last control) can't be brought into view by the keyboard alone. Is there a supported way for Full Keyboard Access users to scroll a scroll view to see this off-screen, non-focusable content — e.g. a built-in scroll command, or an API to make the scroll view itself focusable/scrollable via the keyboard — without resorting to custom key handling?