What we're doing During time-limited sales, our app shows a countdown Live Activity on the Lock Screen. It's started locally when the user opens the app (no push, no pushType, no push tokens), and its end is scheduled for the sale's start/end time: let activity = try Activity<SaleAttributes>.request(attributes: attributes, contentState: .init()) await activity.end(using: .init(), dismissalPolicy: .after(saleEndDate))The sale time is the same for every user, so the Live Activity ends at the same second on every device. What we expected At saleEndDate, the system removes the Live Activity from the Lock Screen, and nothing else happens. What actually happens If the app isn't running at that moment (the user left it earlier and didn't swipe it away), the system removes the Live Activity and then launches our app in the background: 01:18:59.995 SpringBoard [BundleID: com.example.app] finished, removing from the list... 01:19:00.019 liveactivitiesd Sending request to open "com.example.app" 01:19:00.023 SpringBoard Received trusted open application request … from <… com.apple.liveactivitiesd …> 01:19:00.069 SpringBoard Bootstrapping app<com.example.app> with intent backgroundThe app receives a normal application(_:didFinishLaunchingWithOptions:) with applicationState == .background and empty launchOptions. No other app delegate callback follows. Our app can't tell this apart from any other launch, so it runs its full startup: it builds the home screen and calls our backend APIs. Because this happens on a large number of devices in the same second, our backend gets a sharp burst of traffic exactly at sale start and sale end, from users who never opened the app. What we've checked App still running in the background at the end time: no new launch. App swiped away by the user before the end time: no launch. Live Activity removed by the user before the end time: no launch at the end time. Steps to reproduce Open the app; it starts a Live Activity with its end scheduled 15 minutes ahead. Leave the app with the Home gesture (don't swipe it away) and lock the device. Wait until the system terminates the app process. At the scheduled end time, the Live Activity is removed and the app is launched in the background (log above). Environment iPhone 15, iOS 26.6 (23G71) UIKit app, UIApplicationDelegate lifecycle (no scenes) NSSupportsLiveActivities = YES; UIBackgroundModes = [processing, remote-notification] Questions Why does the system launch the app when a Live Activity reaches its scheduled end? Is this intended? Can we avoid it? Is there a supported way to end a Live Activity at a scheduled time without the system launching the app? If not, how should we handle it? Is there a way to know at launch that it was caused by the Live Activity ending, or what's the recommended way to avoid running the full startup (UI and network calls) for this launch?

We're adding an option to our Unity SDK that gives a game a native launch screen: a launch storyboard (set through UILaunchStoryboardName) showing a full-screen image from an asset catalog. What we see On a clean install, the new launch screen shows as expected. When the same device installs an update over the existing app (tested through TestFlight), the previous launch screen keeps showing. Launching the app several times does not change it. Deleting the app, restarting the device and reinstalling shows the new launch screen straight away. We checked the build itself: the compiled storyboard, the image in Assets.car and the Info.plist keys are all correct, so this looks like the system's launch screen snapshot cache. We assume App Store updates behave the same way. What we're considering On the first launch after an update, the app would delete the cached launch screen snapshots in its own container (Library/SplashBoard), so the system regenerates them and the new launch screen shows on the next launch. This only uses public file APIs inside the app's own sandbox. But Library/SplashBoard is not documented anywhere, so we'd rather ask before shipping it. Questions Is deleting Library/SplashBoard from the app's own container a supported or acceptable practice, or could it cause problems (with the system, or in a future iOS version)? Is there a supported way to make iOS refresh a cached launch screen after an app update? If not, is the expected behaviour simply that the system refreshes the snapshot at some point? Is it documented when that happens (for example after a reboot, or after a certain time)? If clearing the folder isn't recommended, we won't ship it. Updating players would just keep the old launch screen until iOS refreshes it. Thanks!

Our app crashes when compiled with the iOS 27 beta 3 SDK and run as an iOS app on Mac, on both macOS 26 and macOS 27, as soon as a UISearchBar receives focus. The crash is due to this exception: *** Assertion failure in BOOL _screenBasedFocusUnsupported(void)(), UIScreen.m:3.725 Accessing the focus system through UIScreen is no longer supported. ( 0 CoreFoundation 0x000000018bea31c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018b91e91c objc_exception_throw + 88 2 Foundation 0x000000018e092644 -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 UIKitCore 0x00000001c5dae8ec _screenBasedFocusUnsupported + 272 4 UIKitCore 0x00000001c5dae960 -[UIScreen _preferredFocusedWindow] + 24 5 UIKitCore 0x00000001c4ea3a60 -[UIScreen _mainSceneReferenceBounds] + 200 6 UIKitCore 0x00000001c4ea3914 -[UIScreen _mainSceneBoundsForInterfaceOrientation:] + 40 7 UIKitCore 0x00000001c5708134 +[UINavigationBar defaultSizeForOrientation:] + 76 8 UIKitCore 0x00000001c6222c88 -[_UISearchPresentationController _layoutPresentationWithSize:transitionCoordinator:] + 704 9 UIKitCore 0x00000001c622296c -[_UISearchPresentationController containerViewWillLayoutSubviews] + 84 10 UIKitCore 0x00000001c549304c block_destroy_helper.13 + 25112 11 UIKitCore 0x00000001c549344c block_destroy_helper.13 + 26136 12 UIKitCore 0x00000001c4ea26a8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1648 13 QuartzCore 0x0000000196103dbc _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 460 14 QuartzCore 0x000000019610390c _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 692 15 QuartzCore 0x0000000196035d2c _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 608 16 QuartzCore 0x0000000195e69520 _ZN2CA11Transaction6commitEv + 652 17 AppKit 0x0000000190fe116c __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.7 + 44 18 CoreFoundation 0x000000018be34ad0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 19 CoreFoundation 0x000000018be34a10 __CFRunLoopDoBlocks + 396 20 CoreFoundation 0x000000018be33e54 __CFRunLoopRun + 2356 21 CoreFoundation 0x000000018bf06234 _CFRunLoopRunSpecificWithOptions + 532 22 HIToolbox 0x0000000198c1f560 RunCurrentEventLoopInMode + 320 23 HIToolbox 0x0000000198c228bc ReceiveNextEventCommon + 488 24 HIToolbox 0x0000000198dac14c _BlockUntilNextEventMatchingListInMode + 48 25 AppKit 0x00000001909163d0 _DPSBlockUntilNextEventMatchingListInMode + 228 26 AppKit 0x000000019026a084 _DPSNextEvent + 576 27 AppKit 0x0000000190dff96c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 28 AppKit 0x0000000190dff678 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 29 AppKit 0x000000019025d13c -[NSApplication run] + 368 30 AppKit 0x00000001902357b0 NSApplicationMain + 880 31 AppKit 0x000000019047c958 +[NSWindow _savedFrameFromString:] + 0 32 UIKitMacHelper 0x00000001aa2651bc UINSApplicationMain + 972 33 UIKitCore 0x00000001c4e1aed4 UIApplicationMain + 144 34 UIKitCore 0x00000001c548bda0 block_destroy_helper.31 + 8880 35 DigitalConcertHall.debug.dylib 0x0000000106e41bd8 $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ + 128 36 DigitalConcertHall.debug.dylib 0x0000000106e41b4c $s18DigitalConcertHall11AppDelegateC5$mainyyFZ + 32 37 DigitalConcertHall.debug.dylib 0x0000000106e4afc0 __debug_main_executable_dylib_entry_point + 28 38 dyld 0x000000018b9ac4e4 start + 6992 ) I could not test with the iOS 27 beta 4 SDK due to this blocking issue: https://developer.apple.com/forums/thread/839012 However, when I tried to set up a simple sample project, I could not reproduce the issue. Does anybody know what might be causing this? I filed feedback FB24201508

Hi, I am trying to list the contents of a directory selected by the user using the following code: let documentPicker = UIDocumentPickerViewController(forOpeningContentTypes: [.folder]) documentPicker.delegate = self self.present(documentPicker, animated: true) func documentPicker(_ controller: UIDocumentPickerViewController, didPickDocumentsAt urls: [URL]) {         guard let folderUrl = urls.first else {return} let startAccessing&#9;= folderUrl.startAccessingSecurityScopedResource()         guard startAccessing else { print("ERROR")             return         }         defer {             if startAccessing {                 folderUrl.stopAccessingSecurityScopedResource()             }         }         var error : NSError? = nil         NSFileCoordinator().coordinate(readingItemAt: folderUrl, error: &error) { (url) in             let startAccessing = url.startAccessingSecurityScopedResource()             guard startAccessing else {                 print("ERROR 2")                 return             }             defer {                 if startAccessing { folderUrl.stopAccessingSecurityScopedResource()                 }             }                          do {                 let files = try FileManager.default.contentsOfDirectory(at: url, includingPropertiesForKeys: [.nameKey])                 print(files)             } catch let filesError {                 print(filesError)             }         }     } This works for iCloud and for local files. It also, curiously, works on empty folders on the SMB server (though, obviously, it returns an empty array). However, for SMB folders with contents I get the following cryptic error message. Error Domain=NSCocoaErrorDomain Code=256 "The file “downloads” couldn’t be opened." UserInfo={NSURL=file:///private/var/mobile/Library/LiveFiles/com.apple.filesystems.smbclientd/Gabgugfiles/downloads, NSFilePath=/private/var/mobile/Library/LiveFiles/com.apple.filesystems.smbclientd/Gabgugfiles/downloads, NSUnderlyingError=0x28010b0c0 {Error Domain=NSPOSIXErrorDomain Code=10006 "Unknown error: 10006"}} In addition, modifying the code slightly so the user picks an image instead works just fine too. I can load the image from the supplied URL. I have read the documentation here - https://developer.apple.com/documentation/uikit/view_controllers/providing_access_to_directories and watched the WWDC 2019 presentation, What's New in File Management and Quicklook, where this was introduced but this hasn't turned up any answers. My app is set up with Supports Document Browser. Is there something I'm doing wrong? The way this is described what I'm trying to do, get a list of files and act on each of them, is exactly what this is intended for yet it's not working.

Background Our app previously bundled ヒラギノ角ゴシック W4.ttc and W5.ttc via UIAppFonts. App Store review flagged them under ITMS-91198 as Apple-provided fonts. We removed the bundled .ttc files and need to verify the runtime font-resolution behavior before shipping. Case C below shows the original state (with .ttc present) for comparison. Environment Same app, same code, same XIB, physical devices only. Tested OS: iOS 16.5.1 (two builds: with and without bundled .ttc) and iOS 18.0.1 (without bundled .ttc). Xcode 16.x. How to read the logs Each log has three sections: SYSTEM HIRAGINO SANS — UIFont.fontNames(forFamilyName: "Hiragino Sans"), i.e. what the OS itself provides. RAW UIFont(name:) — UIFont(name: "HiraginoSans-W4", size: 16) etc. This is the code path our App.Font wrapper uses. XIB LABEL RESOLVED — four UILabels whose XIB fontDescription specifies HiraginoSans-W3/W4/W5/W6 respectively. resolved= is label.font.fontName at runtime. Case A — iOS 18.0.1, physical device, bundled .ttc removed ===== ENV ===== systemVersion : 18.0.1 target : Physical Device ===== SYSTEM HIRAGINO SANS ===== HiraginoSans-W3 HiraginoSans-W4 HiraginoSans-W5 HiraginoSans-W6 HiraginoSans-W7 HiraginoSans-W8 ===== RAW UIFont(name:) ===== HiraginoSans-W3 OK family=Hiragino Sans HiraginoSans-W4 OK family=Hiragino Sans HiraginoSans-W5 OK family=Hiragino Sans HiraginoSans-W6 OK family=Hiragino Sans ===== XIB LABEL RESOLVED ===== W3Lab xib=HiraginoSans-W3 resolved=HiraginoSans-W3 family=Hiragino Sans W4Lab xib=HiraginoSans-W4 resolved=HiraginoSans-W4 family=Hiragino Sans W5Lab xib=HiraginoSans-W5 resolved=HiraginoSans-W5 family=Hiragino Sans W6Lab xib=HiraginoSans-W6 resolved=HiraginoSans-W6 family=Hiragino Sans ===== END =====Case B — iOS 16.5.1, physical device, bundled .ttc removed ===== ENV ===== systemVersion : 16.5.1 target : Physical Device ===== SYSTEM HIRAGINO SANS ===== HiraginoSans-W3 HiraginoSans-W6 HiraginoSans-W7 ===== RAW UIFont(name:) ===== HiraginoSans-W3 OK family=Hiragino Sans HiraginoSans-W4 nil HiraginoSans-W5 nil HiraginoSans-W6 OK family=Hiragino Sans ===== XIB LABEL RESOLVED ===== W3Lab xib=HiraginoSans-W3 resolved=HiraginoSans-W3 family=Hiragino Sans W4Lab xib=HiraginoSans-W4 resolved=Helvetica family=Helvetica W5Lab xib=HiraginoSans-W5 resolved=Helvetica family=Helvetica W6Lab xib=HiraginoSans-W6 resolved=HiraginoSans-W6 family=Hiragino Sans ===== END =====Case C — iOS 16.5.1, physical device, bundled .ttc present (original state) ===== ENV ===== systemVersion : 16.5.1 target : Physical Device ===== SYSTEM HIRAGINO SANS ===== HiraginoSans-W3 HiraginoSans-W4 HiraginoSans-W5 HiraginoSans-W6 HiraginoSans-W7 ===== RAW UIFont(name:) ===== HiraginoSans-W3 OK family=Hiragino Sans HiraginoSans-W4 OK family=Hiragino Sans HiraginoSans-W5 OK family=Hiragino Sans HiraginoSans-W6 OK family=Hiragino Sans ===== XIB LABEL RESOLVED ===== W3Lab xib=HiraginoSans-W3 resolved=HiraginoSans-W3 family=Hiragino Sans W4Lab xib=HiraginoSans-W4 resolved=HiraginoSans-W4 family=Hiragino Sans W5Lab xib=HiraginoSans-W5 resolved=HiraginoSans-W5 family=Hiragino Sans W6Lab xib=HiraginoSans-W6 resolved=HiraginoSans-W6 family=Hiragino Sans ===== END =====Observations Comparing B and C (same OS, only .ttc presence differs): removing the bundled .ttc removes HiraginoSans-W4/W5 from the system font list, makes UIFont(name:) return nil for them, and makes XIB labels naming them fall back to Helvetica — not SF, not the nearest weight in the same family. Comparing B and A (same .ttc state, only OS differs): iOS 18.0.1 ships HiraginoSans-W3–W8 in the system, so removing the bundled .ttc has no effect there. Question 1 — System font inventory by OS version Is there an official, versioned list of system-provided fonts (PostScript names) per iOS release? We need to determine which Hiragino Sans weights are available on a given OS at runtime, without hard-coding assumptions. Our observations show that iOS 16.5.1 does not provide HiraginoSans-W4/W5 in the system font set, while iOS 18.0.1 provides W3–W8. If no per-version official list exists, is UIFont.familyNames / UIFont.fontNames(forFamilyName:) the recommended runtime enumeration method? Or is there a documented recommendation to avoid relying on specific PostScript names across OS versions? Question 2 — XIB fontDescription fallback rule When a UILabel's XIB fontDescription specifies a font PostScript name that is not available at runtime (e.g. HiraginoSans-W4 on iOS 16.5.1 after removing the bundled .ttc), we observe UIKit falls back to Helvetica — not SF, not the nearest available weight in the same family. Is this fallback rule documented? Is it stable across iOS versions, or should we treat the fallback target as unspecified? If the fallback target cannot be relied upon, what is the recommended approach for XIB-based layouts that must not render with an unexpected font? Must every such label be re-assigned in code after awakeFromNib / viewDidLoad? Or is there a supported way to declare a fallback chain in Interface Builder?

Affected devices (all show the same problem): 1x iPhone 17 Pro Max 2x iPhone 18 Pro Max 1x iPhone 18 Pro Many demo iPhones at several Apple Stores Current iOS version: 27.2 Issue: Vertical scrolling inside apps frequently stutters and drops frames. It happens in many, many apps, including Apple's own App Store and Apple Store apps. During a normal flick-and-decelerate scroll, the content repeatedly freezes for one or more frames and then jumps forward. Because this reproduces on four of my own devices and on many Apple Store demo units, I believe it is a widespread, system-level issue, not a defect of a single device or my settings. Impact: I have been living with this for more than six months. I use my iPhone heavily every day, and the constant stutter has made using it genuinely distressing. Everything else about iPhone feels excellent, which makes this problem even harder to accept. Steps to reproduce: Open the App Store app (or almost any app with a scrolling list). Scroll with a normal flick and let it decelerate. Observe repeated hitches during the scroll. Measurements: I filmed the screen with a second iPhone at 4K 120 fps and measured content movement frame by frame: iPhone 18 Pro Max, third-party video feed: about 4 hitches per second of scrolling, about 4% of frames dropped, mostly single-frame drops. iPhone 18 Pro Max, third-party social app list: about 11 hitches per second, about 12% of frames dropped, at a regular rhythm every 6-8 frames. About a third of the stalls last 2-3 frames, and the content does not catch up afterwards. iPhone 17 Pro Max, third-party comment list: about 5 hitches per second, about 8% of frames dropped, including several full freezes of 50-75 ms. Expected: Smooth 120 Hz scrolling, as ProMotion is designed to deliver. Is Apple aware of this issue? I am happy to provide videos, frame-by-frame data, or sysdiagnose logs.

I have an app almost ready to submit for distribution. It is a game with a fixed background view and a token that moves around on the fixed background. The token is moved by tilting the iPhone/iPad which is translated to movement based on CMMotionManager as roll and pitch readings. This simulates a flat level playing field with gravity pulling the token when the device is tipped. The app works well only when the user has set the device to have Autorotate locked. The following code lets me sample the status of Autorate: guard let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene else { return } print("Orientation locked: ", windowScene.effectiveGeometry.isInterfaceOrientationLocked) The problem is that I always get a reading of false regardless of whether Autorotate is locked or not. Can anyone help me understand. Is this the wrong approach for getting this information? If so, how is this achieved? Thanks for your attention to this, Mike Ricker

27.3 beta iPhone Duo's tabBar only supports displaying 5 tabs on the vertical bar, whereas previously it could display 8 tabs. This is a bug of 27.3, and it was the result of Apple's restrictions.

I can reproduce a phone-keypad popover reopening issue in a standalone UIKit app, with no third-party frameworks or custom input view. Environment iPad Pro 11-inch (M4) simulator, iPadOS 26.5, landscape Xcode 27.1 Observed when UIKit presents the small telephone-keypad popover for a UITextField whose keyboardType is .phonePad. Device Hub's hardware/software keyboard settings affect whether this popover or the full-width keyboard appears. Reproduced both in a plain UIViewController inside UINavigationController and in a stock UISplitViewController. Physical-device behavior and other OS versions have not been verified. Steps Add a normal UITextField, set keyboardType = .phonePad, and call becomeFirstResponder() in viewDidAppear. With the small phone-keypad popover visible, tap blank space outside it to dismiss it. Tap the same text field again. Expected: The telephone-keypad popover reopens so the user can continue entering a phone number. Actual: The popover does not reopen. Sometimes an AutoFill edit menu appears instead. The text field still reports isFirstResponder == true. Calling becomeFirstResponder() again returns true but does not restore the keypad. The baseline has no UITextFieldDelegate, custom gesture recognizer, custom inputView, or automatic focus-recovery code. Diagnostic results in this environment Repeating becomeFirstResponder() while already first responder: returns true, keypad remains absent. Explicitly calling reloadInputViews(): keypad reappears. Explicitly calling resignFirstResponder(), then becomeFirstResponder() in a separate button action: keypad reappears. Recreating the view controller: keypad reappears. The attached animated screen recording shows initial presentation, dismissal, a failed retap, a responder-state snapshot, another becomeFirstResponder() call, and recovery after Reload inputs. The diagnostic buttons only perform the named action; no recovery runs automatically. Relevant setup/actions from the standalone app: private let phoneField = UITextField() // viewDidLoad: add phoneField to the view and set its constraints phoneField.keyboardType = .phonePad // viewDidAppear let result = phoneField.becomeFirstResponder() print(result, phoneField.isFirstResponder) // Diagnostic button A, after dismissing and retapping: let again = phoneField.becomeFirstResponder() print(again, phoneField.isFirstResponder) // true, true; keypad absent // Diagnostic button B: phoneField.reloadInputViews() // popover reappears in this testOne additional observation: keyboard hide notifications can be delivered even while the small telephone-keypad popover is visibly present. Therefore, the last keyboard notification/frame is not a reliable visibility signal for this popover in this test. Is this an expected distinction between the phone-keypad popover and the software keyboard, or a UIKit/Simulator issue? What is the recommended public-API approach to allow a user to reopen it after dismissal? In particular, is calling reloadInputViews() when the field is already first responder an appropriate workaround, and is there a supported way to detect this popover's dismissed state? I have not yet filed a Feedback Assistant report, so there is no FB number to reference. I can provide the standalone reproduction project if needed.

Since iOS 27, showing a system permission alert no longer deactivates the app. On iOS 26, sceneWillResignActive / applicationWillResignActive arrive about 0.05–0.1 s after ATTrackingManager.requestTrackingAuthorization. On iOS 27.0, 27.0.1 and 27.2 they don't arrive at all while the prompt is up, and SwiftUI's scenePhase stays .active. Apps that pause on resign, like games (Unity's iOS player pauses only on applicationWillResignActive), keep running behind the prompt: tutorials start, and timers and audio keep going. Minimal repro (plain UIKit with UIScene, fresh install so the status is .notDetermined): private var askedForTracking = false func sceneDidBecomeActive(_ scene: UIScene) { print("sceneDidBecomeActive") guard !askedForTracking else { return } askedForTracking = true DispatchQueue.main.asyncAfter(deadline: .now() + 3) { print("requesting ATT") ATTrackingManager.requestTrackingAuthorization { status in print("ATT finished: \(status.rawValue)") } } } func sceneWillResignActive(_ scene: UIScene) { print("sceneWillResignActive") }iOS 26.6: 3.27s requesting ATT 3.35s willResignActive 16.81s ATT finished: authorized 17.24s didBecomeActiveiOS 27.2: 3.21s requesting ATT 16.88s ATT finished: authorized 17.32s willResignActive 17.33s didBecomeActiveSo on iOS 27 the only lifecycle events are a resign/active pair about 0.44 s after the answer. What we found: The camera and notification permission alerts behave the same. It doesn't depend on the SDK the app is linked against, or on the thread making the request. SpringBoard's log shows the systemModalAlert deactivation assertion being added, but on iOS 27 the updateAllScenesForBand - Assertion added update never reaches the app's scene. The pending reason is only applied on the next unrelated scene update, such as a notification banner arriving, the screen dimming, an unlock, or the alert being dismissed. Taps outside the alert, a Control Center swipe or a home-indicator drag don't trigger it. Filed as FB25446786, with a sample project, delay sweeps on iOS 26 vs 27 (simulator and device) and a sysdiagnose. Is anyone else seeing this? And is there a supported way to know a permission alert is on screen until it's fixed? If you're affected, please file a Feedback and mention FB25446786; duplicates help.

Issue: Screen rotation becomes locked when updating the status bar on an iPhone Duo. This does not appear to be a device-specific hardware issue; however, it occurs specifically on the iPhone Duo. In my app, if I change the status bar visibility (using prefersStatusBarHidden) while on the iPhone Duo’s external screen, and then immediately unfold the device to reveal the internal screen, the app’s rotation state becomes locked. Although I use prefersInterfaceOrientationLocked to manage rotation, the app remains locked even when this property returns false. The issue persists even when prefersInterfaceOrientationLocked is commented out or removed entirely. Returning to the device’s home screen, rotating the device, and then re-entering the app resolves the lock. Has anyone encountered or resolved a similar issue?

I'm creating a custom keyboard by subclassing UIInputView. This is set as a text field's inputView property. This is a simple keypad similar to the standard numeric keypad keyboard. In fact, my UI lets the user switch between the standard numeric keypad and my custom input view. Given this it would be very nice if my custom input view was the same height as the standard keypad. If there a proper way to subclass UIInputView such that its height is the same "standard" height as the numeric keypad when run on any iOS device from iOS 17 through 27.3? I do not want to have to hardcode dozens of heights for every model iPhone and iPad, not to mention the 5 different heights you get on the iPhone Duo. I've tried various combinations of setting allowsSelfSizing to true and false along with returning a height of UIView.noIntrinsicMetric in intrinsicContentSize as well as not setting intrinsicContentSize at all. The closest result is when allowsSelfSizing is set to false. In that case my custom input view's height is somewhat similar to the standard keypad but in some cases it's off by 20-30 points roughly. Has anyone implemented a custom UIInputView that gets the standard keyboard height without hardcoding device specific heights?

When using a background color for a UINavigation controller it seems the header does not extend to the top of the device for iPhone Duo when its closed in portrait mode. See screenshot. It should fill the entire 'status' bar up to top of device, Landscape correctly works, its just Portrait. Any thoughts on if this is 'expected' behavior? Seems odd to not just extend the navbar alll the way to the top.

Hi everyone: I'm experiencing an issue in iOS 26. I've implemented a custom ViewController. It's super simple to edit images with flip, crop, zoom in, and zoom out. My question is that it seems very strange to me. It works without problems in iOS 17.5 and iOS 18. However, when I try to run it with iOS 26, the entire ViewController seems disabled; it doesn't recognize touches or anything. When I checked the UI hierarchy, I saw a strange FloatingBarContainerView overlaying the entire ViewController. I searched the documentation for information about this view, but I couldn't find anything. Any help on how to hide or remove this view in iOS 26? This hasn't been implemented anywhere.

Our app is a secure enterprise portal (business email, files, chat) for MDM-managed corporate devices. Preventing selected text from leaving the app is a hard product requirement, so we opt out of Writing Tools everywhere. On iOS 27.2, the Siri AI entry still appears in the text-selection edit menu (the bubble menu shown on long-press/selection), in both WKWebView and UITextView, and it allows sending the selected text to Siri. We have exhausted every public API and documented all of it: writingToolsBehavior = .none is set and verified at runtime. WKWebViewConfiguration.writingToolsBehavior == .none (-1) before the web view is created, and the web view's internal content view also reports -1. UITextView.writingToolsBehavior = .none as well. The documentation for UIWritingToolsBehavior.none says "Writing Tools will ignore this view", so we expected no AI entry point for selections in these views. The entry is not in UIMenuBuilder. We dumped the entire menu tree in buildMenu(with:) (root and all children, before and after calling super): only standard-edit / open / format / learn / speech / share are present. There is no Siri-related menu or command to remove. The entry does not go through canPerformAction(_:withSender:). We log every selector that is queried; no Siri/WritingTools-related selector ever appears. Our override returns false for everything except cut/copy/paste/select/ selectAll/delete — yet the Siri AI entry is still shown. Even a fully custom menu does not help. Returning a UIMenu built from scratch (only our own UIActions, ignoring suggestedActions) from textView(_:editMenuForTextIn:suggestedActions:) still gets the Siri AI entry attached to the presented edit menu. So the entry is attached to the edit-menu container itself, not to the menu contents. Questions: Is there any supported API on iOS 27 for an app to suppress the Siri AI entry in the edit menu for specific views (or app-wide)? If not, is this intended behavior? It appears to contradict the documented contract of UIWritingToolsBehavior.none ("Writing Tools will ignore this view"). Is there a recommended approach for apps handling confidential data (banking/меdical/enterprise) other than the MDM allowWritingTools restriction? Environment: iOS 27.2 (Iphone 16Pro), Xcode 27.2, deployment target iOS 13.

Filed as FB25405148 with a small sample project. Posting here in case anyone else has hit this or knows a better workaround. Once a MapKit location view has been in a window, addSubview: anywhere in the process takes time proportional to the number of subviews the parent already has. The parent doesn't have to belong to the map. On iPhone Air with iOS 27.2, in a clean app, adding 8,000 plain UIViews to a plain UIView took 85 ms without a location view and 4,992 ms with one. You won't see this with a few hundred views. Up to about 1,000 siblings, the whole batch costs less than 100 ms extra. Map apps can hit it because annotation views are siblings under one container. On the same phone, adding 5,000 annotation views in batches took the longest frame from 25 ms to 208 ms. It happens with the default location view, with an MKUserLocationView returned from mapView(_:viewFor:), and with a bare MKUserLocationView added to a window by hand. A plain MKAnnotationView doesn't cause it. From LLDB on the simulator, it looks like MapKit's first call to _accessibilitySetInterfaceStyleIntent: installs _UIAccessibilityInterfaceStyleVisitor, and that's what slows later adds. Returning a plain MKAnnotationView for MKUserLocation avoids it, but gives up the system view. Only iOS 27.2 has been tested so far. Has anyone seen this on other versions, or found a way to keep the system location view without the cost?

I’m investigating an issue with simultaneous Apple Pencil and finger input on iPad. Apple Pencil + finger input works correctly while the Pencil user’s hand/palm is off the display. However, when drawing naturally with Apple Pencil with the palm resting on the display, an existing finger drawing contact elsewhere on the screen can be cancelled and then stop receiving input for several seconds. Pencil input continues normally throughout. Initially I suspected PencilKit, but I’ve reproduced the underlying behaviour below PencilKit/SwiftUI. Instrumenting UIKit at UIApplication.sendEvent shows the finger touch being cancelled and, in some cases, no further events for that finger for ~4–5 seconds while Pencil MOVED events continue to arrive normally. Everything delivered to the application is accounted for, so this appears to occur before our drawing/rendering code. Is this expected behaviour from the iPad’s Pencil/palm rejection? More specifically: Is there any supported way to tell UIKit that an existing finger contact should remain intentional while Pencil + palm contact is present? Is palm rejection configurable at this level? Is there another public input API we should be using for this scenario? We’re currently testing UIEvent.coalescedTouches(for:) to determine whether additional genuine finger samples are available during these apparent gaps, but haven’t completed that test yet. Any guidance on whether this interaction is expected to be supportable through public UIKit APIs would be appreciated.

Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.

Since iOS 27, if an app runs in Arabic (or, presumably, any right-to-left language), typing digits or Latin letters into a SwiftUI TextField makes the field look empty. The binding updates and the caret shows, but the text isn't drawn until editing ends. What I measured: The text's layout fragment is placed at about x = −39,655 pt in a 370 pt wide field, so it's drawn far outside the field. A plain TextField and one with .environment(\.layoutDirection, .leftToRight) (phone and card numbers) are both affected. A UIKit UITextField on the same screen isn't affected. The same build on iOS 18.0 works, and iOS 27 in English works. Minimal repro: one SwiftUI file with four fields. Run it with App Language set to Arabic, tap the first field and type 523. Launch with -autoProbe to have it type into each field and print where the text was laid out. PROBE iOS 27.0, language ar, layout RTL PROBE field 1 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI TextField PROBE field 2 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI, LTR pinned PROBE field 3 text="523" fieldWidth=370 fragmentX=[314] visible=true // UIKit UITextFieldWorkaround that works for us, installed once at launch: import UIKit enum TextFieldDirection { static func install() { for name in [UITextField.textDidBeginEditingNotification, UITextField.textDidChangeNotification] { NotificationCenter.default.addObserver(forName: name, object: nil, queue: .main) { note in guard let field = note.object as? UITextField else { return } MainActor.assumeIsolated { settle(field) } // SwiftUI rebuilds the paragraph style right after; settle again. DispatchQueue.main.async { MainActor.assumeIsolated { settle(field) } } } } } @MainActor static func settle(_ field: UITextField) { let direction: NSWritingDirection = field.effectiveUserInterfaceLayoutDirection == .rightToLeft ? .rightToLeft : .leftToRight if let whole = field.textRange(from: field.beginningOfDocument, to: field.endOfDocument) { field.setBaseWritingDirection(direction, for: whole) } func directed(_ attributes: [NSAttributedString.Key: Any]) -> [NSAttributedString.Key: Any] { var attributes = attributes let style = (attributes[.paragraphStyle] as? NSParagraphStyle)?.mutableCopy() as? NSMutableParagraphStyle ?? NSMutableParagraphStyle() style.baseWritingDirection = direction attributes[.paragraphStyle] = style return attributes } if let typing = field.typingAttributes { field.typingAttributes = directed(typing) } field.defaultTextAttributes = directed(field.defaultTextAttributes) field.setNeedsLayout() field.layoutIfNeeded() } }Don't pin textAlignment instead. SwiftUI puts .natural back on every keystroke and the caret jumps from side to side. If you see this too, please file a duplicate referencing FB25410049. Duplicates help Apple prioritise it.

On a physical iPhone Duo running iOS 27.1 and later, the system dictation button is placed inside the system keyboard, next to the space bar. Because the button belongs to the system keyboard layout, it isn't available while a third-party keyboard is active. On other iPhone models, the dictation button appears separately from the keyboard, so it stays available with third-party keyboards. On iPhone Duo, our users have no way to start dictation without switching back to the system keyboard. The iPhone Duo Simulator shows the button at the far right, which doesn't match the physical device, so this can't be evaluated accurately in the Simulator. As far as I can tell, there is no public API that lets a keyboard extension start system dictation, so we can't work around this from the extension. My questions: Is this placement intended on iPhone Duo? Is there a supported way for a keyboard extension to offer dictation on this device? If not, are there plans for a separate system dictation button, as on other iPhone models, or a public API for keyboard extensions? I've filed this as FB[number]. If you develop a keyboard extension and see the same issue, please file your own report and reference this number.