Apps that try to access the contents of the pasteboard cause a system prompt to appear asking the user "AppName" would like to paste from "OtherAppName" Do you want to allow this? Don't Allow Paste Allow Paste This prompt does not appear if you implement a UIPasteControl and the user taps it to signal intent to paste, but this control cannot be placed into a UIMenu. I read this could be achieved with UIAction.Identifiers like .paste or .newFromPasteboard but the prompt still appears with the following code. What's the trick? override func viewDidLoad() { super.viewDidLoad() title = "TestPaste" view.backgroundColor = .systemBackground let imageView = UIImageView() imageView.translatesAutoresizingMaskIntoConstraints = false imageView.contentMode = .scaleAspectFit imageView.clipsToBounds = true view.addSubview(imageView) NSLayoutConstraint.activate([ imageView.topAnchor.constraint(equalTo: view.topAnchor), imageView.leadingAnchor.constraint(equalTo: view.leadingAnchor), imageView.trailingAnchor.constraint(equalTo: view.trailingAnchor), imageView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Add", image: UIImage(systemName: "plus"), menu: UIMenu(children: [ UIAction(identifier: .paste) { _ in imageView.image = UIPasteboard.general.image } ])) }

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

My app start up has became horrid. It takes 1 minute to open SQLlite database for my rust core. Impossible to work... I have Address Sanitizer, Thread Perf Checker and Thread Sanitizer disabled...

After updating to Xcode 26 my XCUITests are now failing as during execution exceptions are being raised and caught by my catch all breakpoint These exceptions are only raised during testing, and seem to be referencing some private internal property. It happens when trying to tap a button based off an accessibilityIdentifier e.g. accessibilityIdentifier = "tertiary-button" ... ... app.buttons["tertiary-button"].tap() The full error is: Thread 1: "[<UIKit.ButtonBarButtonVisualProvider 0x600003b4aa00> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _titleButton." Anyone found any workarounds or solutions? I need to get my tests running on the liquid glass UI

[Submitted as FB21958289] A minimal SwiftUI app logs framework warnings when a bottom bar Menu is used with the system search toolbar item. The most severe issue is logged as a console Fault (full logs below): Adding 'UIKitToolbar' as a subview of UIHostingController.view is not supported and may result in a broken view hierarchy. Add your view above UIHostingController.view in a common superview or insert it into your SwiftUI content in a UIViewRepresentable instead. This appears to be a framework-level SwiftUI/UIKit integration issue, not custom UIKit embedding in app code. The UI may still render, but the warnings indicate an internal hierarchy/layout conflict. This occurs in simulator and physical device. REPRO STEPS Create a new project then replace ContentView with the code below. Run the app. The view uses NavigationStack + .searchable + .toolbar with: ToolbarItem(placement: .bottomBar) containing a Menu DefaultToolbarItem(kind: .search, placement: .bottomBar) EXPECTED RESULT No view hierarchy or Auto Layout warnings in the console. ACTUAL RESULT Console logs warnings such as: "Adding 'UIKitToolbar' as a subview of UIHostingController.view is not supported..." "Ignoring searchBarPlacementBarButtonItem because its vending navigation item does not match the view controller's..." "Unable to simultaneously satisfy constraints..." (ButtonWrapper/UIButtonBarButton width and trailing constraints) MINIMAL REPRO CODE import SwiftUI struct ContentView: View { @State private var searchText = "" @State private var isSearchPresented = false var body: some View { NavigationStack { List(0..<30, id: \.self) { index in Text("Row \(index)") } .navigationTitle("Toolbar Repro") .searchable(text: $searchText, isPresented: $isSearchPresented) .toolbar { ToolbarItem(placement: .bottomBar) { Menu { Button("Action 1") { } Button("Action 2") { } } label: { Label("Actions", systemImage: "ellipsis.circle") } } DefaultToolbarItem(kind: .search, placement: .bottomBar) } } } } CONSOLE LOG Adding 'UIKitToolbar' as a subview of UIHostingController.view is not supported and may result in a broken view hierarchy. Add your view above UIHostingController.view in a common superview or insert it into your SwiftUI content in a UIViewRepresentable instead. Ignoring searchBarPlacementBarButtonItem because its vending navigation item does not match the view controller's. view controller: <_TtGC7SwiftUI32NavigationStackHostingControllerVS_7AnyView_: 0x106014c00>; vc's navigationItem = <UINavigationItem: 0x105530320> title='Toolbar Repro' style=navigator searchController=0x106131200 SearchBarHidesWhenScrolling-default; vending navigation item <UINavigationItem: 0x106db4270> style=navigator searchController=0x106131200 SearchBarHidesWhenScrolling-explicit Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( "<NSLayoutConstraint:0x600002171450 _TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106a31fe0.width == _UIButtonBarButton:0x106dc4010.width (active)>", "<NSLayoutConstraint:0x6000021558b0 'IB_Leading_Leading' H:|-(8)-[_UIModernBarButton:0x106a38010] (active, names: '|':_UIButtonBarButton:0x106dc4010 )>", "<NSLayoutConstraint:0x600002170eb0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106a38010]-(8)-| (active, names: '|':_UIButtonBarButton:0x106dc4010 )>", "<NSLayoutConstraint:0x60000210aa80 'UIView-Encapsulated-Layout-Width' _TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106a31fe0.width == 0 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x600002170eb0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106a38010]-(8)-| (active, names: '|':_UIButtonBarButton:0x106dc4010 )> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful. Failed to send CA Event for app launch measurements for ca_event_type: 0 event_name: com.apple.app_launch_measurement.FirstFramePresentationMetric Failed to send CA Event for app launch measurements for ca_event_type: 1 event_name: com.apple.app_launch_measurement.ExtendedLaunchMetrics

I have a collection view that covers all the screen and it is scrolling behavior is paging. This collection view is embedded in a UIViewRepresentable and used in a SwiftUI app. The issue is that when users rotate the devices, sometimes the CollectionView.contentOffset get miscalculated and shows 2 pages. This is the code that I'm using for the collectionView and collectionViewLayout: class PageFlowLayout: UICollectionViewFlowLayout { override class var layoutAttributesClass: AnyClass { UICollectionViewLayoutAttributes.self } private var calculatedAttributes: [UICollectionViewLayoutAttributes] = [] private var calculatedContentWidth: CGFloat = 0 private var calculatedContentHeight: CGFloat = 0 public weak var delegate: PageFlowLayoutDelegate? override var collectionViewContentSize: CGSize { return CGSize(width: self.calculatedContentWidth, height: self.calculatedContentHeight) } override init() { super.init() self.estimatedItemSize = .zero self.scrollDirection = .horizontal self.minimumLineSpacing = 0 self.minimumInteritemSpacing = 0 self.sectionInset = .zero } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func prepare() { guard let collectionView = collectionView, collectionView.numberOfSections > 0, calculatedAttributes.isEmpty else { return } estimatedItemSize = collectionView.bounds.size for item in 0..<collectionView.numberOfItems(inSection: 0) { let indexPath = IndexPath(item: item, section: 0) let attributes = UICollectionViewLayoutAttributes(forCellWith: indexPath) let itemOrigin = CGPoint(x: CGFloat(item) * collectionView.frame.width, y: 0) attributes.frame = .init(origin: itemOrigin, size: collectionView.frame.size) calculatedAttributes.append(attributes) } calculatedContentWidth = collectionView.bounds.width * CGFloat(calculatedAttributes.count) calculatedContentHeight = collectionView.bounds.size.height } override func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? { return calculatedAttributes.compactMap { return $0.frame.intersects(rect) ? $0 : nil } } override func layoutAttributesForItem(at indexPath: IndexPath) -> UICollectionViewLayoutAttributes? { return calculatedAttributes[indexPath.item] } override func shouldInvalidateLayout(forBoundsChange newBounds: CGRect) -> Bool { guard let collectionView else { return false } if newBounds.size != collectionView.bounds.size { return true } if newBounds.size.width > 0 { let pages = calculatedContentWidth / newBounds.size.width // If the contentWidth matches the number of pages, // if not it requires to layout the cells let arePagesExact = pages.truncatingRemainder(dividingBy: 1) == 0 return !arePagesExact } return false } override func invalidateLayout() { calculatedAttributes = [] super.invalidateLayout() } override func shouldInvalidateLayout(forPreferredLayoutAttributes preferredAttributes: UICollectionViewLayoutAttributes, withOriginalAttributes originalAttributes: UICollectionViewLayoutAttributes) -> Bool { guard let collectionView, #available(iOS 18.0, *) else { return false } return preferredAttributes.size != collectionView.bounds.size } override func invalidateLayout(with context: UICollectionViewLayoutInvalidationContext) { guard let customContext = context as? UICollectionViewFlowLayoutInvalidationContext else { return } if let collectionView, let currentPage = delegate?.currentPage() { let delta = (CGFloat(currentPage) * collectionView.bounds.width) - collectionView.contentOffset.x customContext.contentOffsetAdjustment.x += delta } calculatedAttributes = [] super.invalidateLayout(with: customContext) } override func prepare(forAnimatedBoundsChange oldBounds: CGRect) { super.prepare(forAnimatedBoundsChange: oldBounds) guard let collectionView else { return } if oldBounds.width != collectionView.bounds.width { invalidateLayout() } } override func targetContentOffset(forProposedContentOffset proposedContentOffset: CGPoint) -> CGPoint { guard let collectionView, let currentPage = delegate?.currentPage() else { return .zero } let targetContentOffset = super.targetContentOffset(forProposedContentOffset: proposedContentOffset) let targetPage = targetContentOffset.x / collectionView.frame.width if targetPage != CGFloat(currentPage) { let xPosition = CGFloat(currentPage) * collectionView.frame.width return CGPoint(x: xPosition, y: 0) } return targetContentOffset } // This function updates the contentOffset in case is wrong override func finalizeCollectionViewUpdates() { guard let collectionView, let currentPage = delegate?.currentPage() else { return } let xPosition = CGFloat(currentPage) * collectionView.bounds.width if xPosition != collectionView.contentOffset.x { let offset = CGPoint(x: xPosition, y: 0) collectionView.setContentOffset(offset, animated: false) } } } The full implementation is attached in the .txt file: RotationTestView.txt

We're experiencing an EXC_BAD_ACCESS (SIGSEGV) crash in UIView.drawHierarchy(in:afterScreenUpdates: false) that occurs only on iOS 26.3.1 and later. It does not reproduce on iOS 26.3.0 or earlier. Crash Stack Thread 0 (Main Thread) — EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0 libvDSP.dylib vConvert_XRGB2101010ToARGB8888_vec 1 ImageIO IIOIOSurfaceWrapper_CIF10::CopyImageBlockSetWithOptions 2 ImageIO IIOImageProviderInfo::CopyImageBlockSetWithOptions 3 ImageIO CGImageReadGetBytesAtOffset 4 CoreGraphics CGAccessSessionGetBytes 5 CoreGraphics img_data_lock 6 CoreGraphics CGSImageDataLock 7 CoreGraphics ripc_AcquireImage 8 CoreGraphics ripc_DrawImage 9 CoreGraphics CGContextDrawImage 10 UIKitCore -[UIView(Rendering) drawHierarchy:afterScreenUpdates:] The crash occurs during 10-bit CIF10 → 8-bit ARGB8888 pixel conversion when the IOSurface backing a UIImageView in the view hierarchy is deallocated mid-render. How to Reproduce Display a scrollable list with multiple UIImageViews loaded via an async image library Call drawHierarchy(in: bounds, afterScreenUpdates: false) on visible cells periodically Scroll to trigger image recycling Crash occurs sporadically — more likely under memory pressure or rapid image recycling What We've Tried Both UIKit off-screen rendering approaches crash on iOS 26.3.1: Approach Result drawHierarchy(afterScreenUpdates: false) EXC_BAD_ACCESS in CIF10 IOSurface decompression view.layer.render(in:) EXC_BAD_ACCESS in Metal (agxaAssertBufferIsValid) iOS Version Correlation iOS 26.3.0 and earlier: No crash iOS 26.3.1 (23D8133)+: Crash occurs (~5 events per 7 days) We suspect the ImageIO security patches in iOS 26.3 (CVE-2026-20675, CVE-2026-20634) may have changed IOSurface lifecycle timing, exposing a race condition between drawHierarchy's composited buffer read and asynchronous IOSurface reclamation by the OS. Crash Data We sampled 3 crash events: Event 1 (iOS 26.3.1): 71 MB free memory — memory pressure Event 2 (iOS 26.3.1): 88 MB free memory — memory pressure Event 3 (iOS 26.3.2): 768 MB free memory — NOT memory pressure Event 3 shows this isn't purely a low-memory issue. The IOSurface can be reclaimed even with ample free memory, likely due to async image recycling. Question Is this a known regression in iOS 26.3.1? Is there a safe way to snapshot a view hierarchy containing IOSurface-backed images without risking EXC_BAD_ACCESS? Should drawHierarchy gracefully handle the case where an IOSurface backing store is reclaimed during the render? Any guidance or workarounds would be appreciated. We've also filed this as Feedback (will update with FB number after submission).

I am facing weird keyboard issue when building the app with Xcode 26 recently. Actual behaviour I need is: But one below is the issue as the keyboard keys are greyed out: Please tell how to resolve this issue

Hello, I am encountering a UI layout issue on iOS 26 where UITabBar items become squashed or overlapping during device rotation (from Portrait to Landscape). This glitch occurs specifically when a custom UITabBarAppearance is applied. 1. "Liquid Glass" and UITabBar Customization According to TN3106, Apple states: "Starting in iOS 26, reduce your use of custom backgrounds in navigation elements and controls. While the techniques in this document remain valid for iOS 18 and earlier, prefer to remove custom effects and let the system determine the navigation bar background appearance. Any custom backgrounds and appearances you use in the navigation bar might overlay or interfere with Liquid Glass or other effects that the system provides, such as the scroll edge effect." Does this guidance also apply to UITabBar? Specifically, could setting a custom background color via UITabBarAppearance interfere with internal layout constraints required for the Liquid Glass effect to adapt correctly during orientation changes? It appears that the internal UIStackView may fail to recalculate width in time when these system effects are active. 2. Validation of the Layout Workaround To maintain our app's visual identity while resolving this squashing issue, I implemented the following fix within the transition coordinator of my UITabBarController: Code Implementation (Objective-C) [coordinator animateAlongsideTransition:^(id<UIViewControllerTransitionCoordinatorContext> _Nonnull context) { // Forcing a layout refresh to synchronize with the rotation animation [weakSelf.tabBar invalidateIntrinsicContentSize]; [weakSelf.tabBar setNeedsLayout]; [weakSelf.tabBar layoutIfNeeded]; } completion:nil]; Is manually invalidating the intrinsic content size an acceptable practice for iOS 26? Or is there a more "system-native" approach to ensure UITabBar layout remains stable and compatible with Liquid Glass, especially when custom appearances are necessary?

I’ve been investigating a noticeable animation hitch when interactively dismissing a sheet over a SwiftUI screen with moderate complexity. This was not the case on iOS 18, so I’m curious if others are seeing the same on iOS 26 or have found any mitigations. When dismissing a sheet via the swipe gesture, there’s a visible hitch right after lift-off. The hitch comes from layout work in the underlying view (behind the sheet) The duration scales with the complexity of that view (e.g. number of TextFields/layout nodes) The animation for programmatic dismiss (e.g. tapping a “Done” button) is smooth, although it hangs for a similar amount of time before dismissing, so it appears that the underlying work still happens. SwiftUI is not reevaluating the body during this (validated with Self._printChanges()), so that is not the cause. Using Instruments, the hitch shows up as a layout spike on the main thread: 54ms UIView layoutSublayersOfLayer 54ms └─ _UIHostingView.layoutSubviews 38ms └─ SwiftUI.ViewGraph.updateOutputs 11ms ├─ partial apply for implicit closure #1 in closure #1 │ in closure #1 in Attribute.init<A>(_:) 4ms └─ -[UIView For the same hierarchy with varying complexity: ~3 TextFields in a List: ~25ms (not noticeable) ~20+ TextFields: ~60ms (clearly visible hitch) The same view hierarchy on iOS 18 did not exhibit a visible hitch. I’ve tested this on an iOS 26.4 device and simulator. I’ve also included a minimum reproducible example that illustrates this: struct ContentView: View { @State var showSheet = false var body: some View { NavigationStack { ScrollView { ForEach(0..<120) { _ in RowView() } } .navigationTitle("Repro") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Present") { showSheet = true } } } .sheet(isPresented: $showSheet) { PresentedSheet() } } } } struct RowView: View { @State var first = "" @State var second = "" var body: some View { VStack(alignment: .leading, spacing: 12) { Text("Row") .font(.headline) HStack(spacing: 12) { TextField("First", text: $first) .textFieldStyle(.roundedBorder) TextField("Second", text: $second) .textFieldStyle(.roundedBorder) } HStack(spacing: 12) { Text("Third") Text("Fourth") Image(systemName: "chevron.right") } } } } struct PresentedSheet: View { @Environment(\.dismiss) private var dismiss var body: some View { NavigationStack { List {} .navigationTitle("Swipe To Dismiss Me") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Done") { dismiss() } } } } } } Is anyone else experiencing this and have any mitigations been found beyond reducing view complexity? I’ve filed a feedback report under FB22501630.

Hi everyone, I’m building a SwiftUI app using NavigationStack and running into a weird nav bar issue. For the setup I have a 'home' screen with a vertical ScrollView and a large edge-to-edge header that extends under the top safe area (using .ignoresSafeArea(edges: .top)). I also have a 'detail' screen with a similar immersive layout, where the header/poster image sits at the top and the ScrollView also extends under the top area. I’m using the native navigation bar on both screens and default back button, not a custom nav bar, and I’m not manually configuring UINavigationBarAppearance, I'm just relying on SwiftUI’s default/automatic toolbar behavior. The problem I’m facing is when I push from home to the detail screen, the top nav area briefly flickers and shows the system navigation bar/material background (white in light mode, black in dark mode). It’s clearly the system material, not the poster/image underneath. The screen initially renders with that nav bar state (white/dark), and only after I start scrolling does it correct itself and visually align with the header/background behind it. What I'm thinking is that maybe the detail screen initially renders with systemBackground, so the nav bar uses its default (standard) appearance on the first frame, and only after layout/interaction, once the image-derived background settles, does it switch to the correct scroll-edge/transparent style. One important thing, if I hide the nav bar on the detail screen using .toolbar(.hidden, for: .navigationBar), the issue disappears completely. So this seems specifically tied to the native nav bar’s initial render/appearance timing during the push, rather than just the layout or image loading. I’d prefer to keep the native nav bar and back button rather than implement a custom approach. Has anyone faced this issue before, or is there a correct way to structure edge-to-edge content under the nav bar so it renders properly on first push? Video of the issue: https://imgur.com/a/OYHtYbp NavigationStack { ScrollView { HeroView() } .ignoresSafeArea(edges: .top) .navigationTitle("Cinema") .toolbarTitleDisplayMode(.inlineLarge) .toolbarBackgroundVisibility(.automatic, for: .navigationBar) .navigationDestination(for: Route.self) { route in DetailView(movie: route.movie) } } var body: some View { ScrollView { HeaderPosterView() } .ignoresSafeArea(edges: .top) .navigationBarTitleDisplayMode(.inline) .toolbarBackgroundVisibility(.automatic, for: .navigationBar) } }

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.

Hello! I have an iOS app where I am looking into support for visionOS. I have a whole bunch of gestures set up using UIGestureRecognizer and so far most of them work great in visionOS! But I do see something odd that I am not sure can be fixed on my end. I have a UITapGestureRecognizer which is set up with numberOfTouchesRequired = 2 which I am assuming translates in visionOS to when you tap your thumb and index finger on both hands. When I tap with both hands sometimes this tap gesture gets kicked off and other times it doesn't and it says it only received one touch when it should be two. Interestingly, I see this behavior in Apple Maps where tapping once with both hands should zoom out the map, which only works sometimes. Can anyone explain this or am I missing something?

Hello,I have some question regarding the alternative icons feature that comes with iOS 10.3.I'm working on a app, that allow user to select a broker from a list, after being logged. I would like to change the icon of the app to be the one of the selected broker. A user will all the time a have access to several brokers. The problem is that we have +3000 broker registered in our platform. So it will be really difficult for us to place the icon of all the 3000 broker in the app, because it will lead to some issue regarding the size of the app. What i would to do, is to set the name of all the broker app icon in the info.plist without having them locally in the app. After that, when the user is logged in the app and have selected the broker, i will do a call to our server and get back the broker app icon, save it and use it. Is it possible ? Will i have some problem with Apple regarding the approval of my app ? Thank a lot for your help.

Hi, I have an app that displays lines of text, that I want to make accessible with VoiceOver. It's based on a UITextView. I have implemented the UIAccessibilityReadingContent protocol, following the instructions in https://developer.apple.com/videos/play/wwdc2019/248 and now users can see the screen line by line, by moving their fingers on the screen. That works fine. However, users would also like to be able to use left-flick and right-flick to move to the previous or next line on the screen, and I haven't been able to make this work. I can see that left-flick triggers accessibilityPreviousTextNavigationElement and right-flick triggers accessibilityNextTextNavigationElement, but I don't understand what these variables should be.

I need constraint the window size for an iOS app running on Mac. That's easy for a MacApp, using self.window?.minSize.width = 450 self.window?.maxSize.width = 450 or use func windowDidResize(_ notification: Notification) { } but how to achieve it in UIKit ?

About a year ago, I developed and released an app on the App Store (I believe it was running on the Sequoia SDK at the time), and everything was working fine. I’m now revisiting the project using the newer Tahoe SDK, and I’m running into an issue with DiffableDataSource. Specifically, the app hangs and CPU usage spikes to 100% when applying snapshots. Has anyone experienced similar issues after upgrading to newer SDKs? Are there any recent changes or pitfalls with DiffableDataSource (e.g., threading, Hashable requirements, or snapshot handling) that I should be aware of? Any insights or suggestions would be greatly appreciated. extension Section { enum Identifier: Int, CaseIterable { case main } enum Item: Hashable { case file(FileViewData) } } struct FileViewData: Equatable, Hashable, Identifiable { let id: String let name: String var accessoryViewData: KTFDownloadAccessoryViewData init( id: String, name: String, accessoryViewData: KTFDownloadAccessoryViewData = .nothing ) { self.id = id self.name = name self.accessoryViewData = accessoryViewData } } public enum KTFDownloadAccessoryViewData: Equatable, Hashable { case nothing case selected(SelectedState) case completed public enum SelectedState: Equatable, Hashable { case nothing case waiting case downloading(Double) } } When I changed FileViewData as below, no hangs but item appearance doesn't change of course. struct FileViewData: Equatable, Hashable, Identifiable { let id: String let name: String var accessoryViewData: KTFDownloadAccessoryViewData init( id: String, name: String, accessoryViewData: KTFDownloadAccessoryViewData = .nothing ) { self.id = id self.name = name self.accessoryViewData = accessoryViewData } func hash(into hasher: inout Hasher) { hasher.combine(id) } static func == (lhs: FileViewData, rhs: FileViewData) -> Bool { return lhs.id == rhs.id } }

When developing a custom keyboard on iOS, even after enabling Full Access (RequestsOpenAccess = true), it is still not possible to record audio — the recording simply does not start. This is despite the fact that: the user is explicitly warned the user provides informed consent by enabling Full Access According to Apple’s documentation: https://developer.apple.com/documentation/uikit/configuring-open-access-for-a-custom-keyboard “However, with RequestsOpenAccess set to true, the keyboard has all the capabilities in the preceding list.” At the same time, the preceding list includes: “No access to microphone and speaker” This creates ambiguity. The wording suggests that enabling Full Access should lift prior restrictions, yet in practice, microphone access remains unavailable to third-party keyboards. Why this is concerning With Full Access enabled, a keyboard already has: network access the ability to transmit user input From a privacy standpoint, this is already highly sensitive. Preventing microphone access while allowing these capabilities appears inconsistent. Meanwhile, Apple’s own system keyboard supports voice dictation, which creates a functional gap between first-party and third-party keyboards. Competition perspective This raises a broader question about equal access to platform capabilities. Restricting third-party keyboards from using the microphone — while first-party solutions can — may be seen as: unequal treatment of developers a limitation of competition in input methods Such differences are increasingly scrutinized under EU regulations like the Digital Markets Act and Article 102 TFEU, which emphasize fair access to platform features and prohibit self-preferencing by dominant platforms. Request for clarification Is microphone access intentionally restricted for all third-party keyboards, even with Full Access enabled? If so, what is the technical or policy justification? Are there plans to provide a secure and user-consented way to enable audio input for custom keyboards? Clarification on this would help developers better understand platform limitations and design decisions.

MyOwnKeyboard Pad app has 4 text views with textfields that use touch screen for editing. There is one view, Compose, that has a textfield and a textview (UIRepresentable). The app enters text into the view using textfield buttons. The app has total control of editing. When entering text if the screen is touched it conflicts the cursor position and creates an "out of bounds" failure. In that view the app does not need any touch events. I need a method in UIRepresentable to disable the touch event. I am not familiar with UIRepresentable as this code was provided by Apple to solve a 16 bit unicode character issue. What would be the code to disable touch events in the UIRepresentable compose view. The app is free for a while until this problem is fixed. It is for iPads 11"+ . The name in the app store is MyOwnKeyboard Pad. I know some great engineer will find the answer. DTS tried. Thanks to all, maybe I'll sell some. Charlie 25mar26

My app uses TextKit 1 and unfortunately still cannot migrate to TextKit 2 because of some bugs (for instance in FB17103305 I show how NSTextView.shouldDrawInsertionPoint has no effect, but I opened that feedback exactly one year ago and it still has no answer). Unfortunately TextKit 1 has another bug which causes the text cursor to jump unpredictably up or down when pressing the arrow keys and setting UITextView.typingAttributes. Run the code below on iPhone 17 Pro Max Simulator. Scroll the text down until you see “Header 2”. Place the text cursor after “# “. Press the arrow down key twice to move the cursor two lines down. The cursor moves to the top of the view instead. Continuing to press the arrow keys up and down results in the cursor sometimes moving as expected, other times jumping around wildly. Does anyone know a workaround? I created FB22382453. class TextView: UITextView, UITextViewDelegate { override func awakeFromNib() { let _ = layoutManager delegate = self let header = textAttributes(fontSize: 30) let body = textAttributes(fontSize: 15) let string = NSMutableAttributedString(string: String(repeating: "a", count: 2681) + "\n", attributes: body) string.append(NSAttributedString(string: """ # Header 1 """, attributes: header)) string.append(NSMutableAttributedString(string: String(repeating: "a", count: 5198) + "\n", attributes: body)) string.append(NSAttributedString(string: """ # Header 2 """, attributes: header)) string.append(NSMutableAttributedString(string: String(repeating: "a", count: 7048) + "\n", attributes: body)) textStorage.setAttributedString(string) } func textViewDidChangeSelection(_ textView: UITextView) { typingAttributes = textStorage.attributes(at: selectedRange.location - 1, effectiveRange: nil) } private func textAttributes(fontSize: Double) -> [NSAttributedString.Key: Any] { var textAttributes = [NSAttributedString.Key: Any]() textAttributes[.font] = UIFont(name: "Courier", size: fontSize) let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.minimumLineHeight = round(fontSize * 1.3) paragraphStyle.maximumLineHeight = paragraphStyle.minimumLineHeight textAttributes[.paragraphStyle] = paragraphStyle return textAttributes } }