Two things I've seen using the iPhone Duo simulator. I'm updating a venerable Objective-C app that dates back to iOS 4, but has been updated to be perfectly functional and appearance-appropriate on iOS 26. I'm building using the 21.1 beta SDK in Xcode 27.1 beta. TL;DR version: (1) my toolbar items vanish in vertical mode except while being tapped or dragged; and (2) the nav bar has an opaque, fixed background even as its title scrolls with underlying content. Has anyone else seen these oddities, and any ideas as to how I can fix 'em? First, with the Duo opened and taller than wide, the nav and tab bars in my app appear horizontally, as I would expect them to. But in any other pose or orientation, the bars adopt a vertical display, and aside from the left edge, their items are invisible: When I tap or drag on them, they become visible: When I stop tapping or dragging, they vanish again. Why do the vertical items go invisible, and how can I keep 'em always visible? Second, my scrolling view lies under the nav bar (in z-order) but extends to the top of the screen. If I scroll the view, it moves up onscreen, behind the opaque nav bar, although the nav bar's title scrolls up, too: If I go "far enough", the title scrolls off completely and the view's contents are visible full-height, but with the nav bar's background remaining. If I don't scroll that far, the title reappears when I stop, and the area above the nav bar goes opaque white, too, covering the content: Is it possible to disable the scrolling behavior on the nav bar title? (I'll just position my scrolling view to start below it spatially.) Alternatively, how can I turn off the background opacity? I've tried setting the background to clearColor and opacity to false... nav.navigationBar.backgroundColor = [UIColor clearColor]; nav.navigationBar.opaque = false; ...but these had no effect. Help me Obi-Wan Kenobi, you're my only hope...

In our app we're hiding and showing things based on whether the keyboard is on the screen or not so we're observing: UIResponder.keyboardWillShowNotification UIResponder.keyboardWillHideNotification And now that we've got hte iPhone Duo in house, I've been testing on there and noticed that those events are firing when the device is open and rotating? Is this by design? There's no keyboard on screen, but I'm receiving the events? This behavior is not showing on the other iPhone/iPad devices. To double-check I created a sample app and I'm seeing the same behavior 😔 enum KeyboardNotification { case willShow case didShow case willHide case didHide } extension KeyboardNotification: CustomStringConvertible { var description: String { switch self { case .willShow: "Will Show" case .didShow: "Did Show" case .willHide: "Will Hide" case .didHide: "Did Hide" } } } struct NotificationEntry { let notification: KeyboardNotification let date: Date init(_ notification: KeyboardNotification) { self.notification = notification self.date = Date() } } struct TestView: View { @State private var entries: [NotificationEntry] = [] private let dateFormatter: DateFormatter = { let formatter = DateFormatter() formatter.dateStyle = .short formatter.timeStyle = .short return formatter }() var body: some View { ZStack { if !entries.isEmpty { List { ForEach(entries, id: \.date) { entry in VStack(alignment: .leading) { Text(String(describing: entry.notification)) Text(dateFormatter.string(from: entry.date)) .font(.caption) .foregroundStyle(.gray) } } } } else { VStack(alignment: .leading) { Text("No Keyboard Events") Text("Rotate the device to test.") .font(.caption) .foregroundStyle(.gray) } } } .onReceive(NotificationCenter.default.publisher(for: UIResponder.keyboardWillShowNotification)) { _ in entries.append(NotificationEntry(.willShow)) } .onReceive(NotificationCenter.default.publisher(for: UIResponder.keyboardDidShowNotification)) { _ in entries.append(NotificationEntry(.didShow)) } .onReceive(NotificationCenter.default.publisher(for: UIResponder.keyboardWillHideNotification)) { _ in entries.append(NotificationEntry(.willHide)) } .onReceive(NotificationCenter.default.publisher(for: UIResponder.keyboardDidHideNotification)) { _ in entries.append(NotificationEntry(.didHide)) } } }In my test app, the events will not always fire but after messing with it for a little bit it will eventually get in the state where it the events fire. Sometimes I will additionally see them when bringing down the notification center, or slightly going to the app switcher.

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

When changing the global locale by std::locale::global(std::locale(NAME)) where NAME is a valid and supported name of a locale all access using [UIImage systemImageNamed:@"..."] fails. Is there a way to modify the global locale and still have access to the SF Symbols?

struct ContentView: View { @State var searchText: String = "" var body: some View { TabView { Tab { NavigationStack { List { Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") } .navigationTitle("Have a title") .searchable(text: $searchText, placement: .toolbar) .searchToolbarBehavior(.minimize) .toolbar { DefaultToolbarItem(kind: .search, placement: .topBarTrailing) } } } } } } In iOS 26, this worked no problem. In iOS 27, this leaves the search bar either unable to collapse (when pressing the close button) or in a broken state where it cannot be opened again.

I'm using the new per-detent backgroundEffect (iOS 26.1+) on UISheetPresentationControllerDetent. When the user drags the sheet between two detents with different effects, nothing changes during the drag; the previous detent's effect stays until the finger lifts, then a fixed-length cross-fade runs on its own, decoupled from the sheet's settle animation. It reads as a jump. Minimal setup (form sheet, nothing else): UISheetPresentationControllerDetent *medium = [UISheetPresentationControllerDetent mediumDetent]; UISheetPresentationControllerDetent *tall = [UISheetPresentationControllerDetent customDetentWithIdentifier:@"c90" resolver:^CGFloat(id<UISheetPresentationControllerDetentResolutionContext> ctx) { return ctx.maximumDetentValue * 0.9; }]; medium.backgroundEffect = nil; tall.backgroundEffect = [UIColorEffect effectWithColor:UIColor.systemBackgroundColor]; sheet.detents = @[ medium, tall ];Expected: the effect transition is driven by the drag progress between adjacent detents, or at least runs inside the same settle animation as the height change. Reproduces on iOS 26.5 (23F77) and 27.0 (24A434) Simulator with iPhone 17 Pro, iOS 27.1 (24A94401) Simulator with iPhone Duo. Xcode 27.1. Is this intended, and is there a supported way to tie the per-detent effect transition to the gesture? Filed as FB25459597.

This is a bug of 27.3, and it was the result of Apple's restrictions.

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 am currently testing additionalOverflowItems with the expectation that it behaves as follows: Keep UIBarButtonItem instances visible directly on the toolbar as icons whenever there is sufficient space. Only move items into the overflow menu when there isn't enough screen real estate. In iOS 26, additionalOverflowItems behaves exactly as described above. However, in iOS 18, the system tends to aggressively move all UIBarButtonItem instances into the overflow menu regardless of available space. Is this change in layout behavior documented anywhere? Can we rely on iOS 26 and future releases maintaining this current behavior, or are the layout heuristics for additionalOverflowItems considered undefined implementation details? Because this behavior isn't clearly documented, I have held off on adopting additionalOverflowItems in production. I have attached screenshots and sample source code below for reference. // On iOS 26, the action mode bar buttons may not fit. iOS then moves the ones that do not fit into its own overflow // menu, listing each by title, and the more button's menu would become a nested "More" submenu there. Instead, in // note and archive action mode, the more button is not shown and its actions are added to the system overflow // menu directly. iOS shows that menu, and moves the buttons that do not fit into it, based on the available space. private var isActionModeMenuInOverflowMenu: Bool { guard #available(iOS 16, *) else { return false } guard actionMode else { return false } switch pageKind { case .notes, .archive: return true default: return false } } private func updateAdditionalOverflowItems() { guard #available(iOS 16, *) else { return } guard isActionModeMenuInOverflowMenu else { navigationItem.additionalOverflowItems = nil return } // Built when the menu is opened, so that it reflects the current selection. navigationItem.additionalOverflowItems = UIDeferredMenuElement.uncached { [weak self] completion in guard let self = self, self.isActionModeMenuInOverflowMenu else { completion([]) return } let selectedNSPlainNotes = self.selectedNSPlainNotes switch self.pageKind { case .notes: completion(self.generateNoteActionModeMenu(selectedNSPlainNotes).children) case .archive: completion(self.generateArchiveActionModeMenu(selectedNSPlainNotes).children) default: completion([]) } } }

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.

Hi, Charts—specifically those with multiple lines—are broken in Xcode 27. First, I spotted the bug in my program, and then I checked your example. Your own example Plotting-multiple-lines is not working correctly anymore. It shows 1 line or sometimes no lines at all, depending on the order of the data. It depends on how the data is passed to the chart. If the data is passed as separate series, it works. In Visualizing your app’s data it works, but the data is passed as described before. Don't follow Microslop: have the AI ​​generate the code and then skip the tests. This is a serious bug that requires a lot of work to rearrange the data, just to work around the issue. Christian

Feedback Assistant: FB25454822 On iOS 27, our app (com.netshort.abroad) crashes inside FrontBoardServices while releasing an object saved across a synchronous scene-update callout. The stack has only system frames. A build shipped in September 2025 (1.8.3) hits the same crash as soon as the device is updated to iOS 27, so this is not a recent app change. OS: iOS 27.0.0 (24A435), iOS 27.0.1 (24A446) On build 2.3.4: 1264 events, 1216 users 0 libobjc.A.dylib objc_release_x26 + 8 1 FrontBoardServices -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 780 2 FrontBoardServices _queue_updateScene…_block_invoke_2.cold.1 + 352 3 FrontBoardServices _queue_updateScene…_block_invoke_2 + 96 4 FrontBoardServices _calloutQueue_executeCalloutFromSource:withBlock: + 168 On 27.0.0 these frames show as <redacted> in Crashlytics. FrontBoardServices 0x19a88 is this method at 0x1977c plus 780, matching symbolicated 27.0.1 reports. In the 27.0.1 FrontBoardServices binary, +776 is objc_release(x26) and +780 is the return address. x26 is transitionContext.actions. The callout into UIKit is the bl at +0x2ac. The crash happens after that callout returns. 34 Apple crash reports with register state show the same pattern: the low byte of saved x26 is 0x01. 20 reports: objc_release_x26 + 8, x26 = 0x1 14 reports: objc_release_x26 + 16, x26 ends in 0x01 (for example 0x13c373a01) A nil actions value 0x0 becomes 0x1. A real pointer only has its low byte changed, so the isa read is off by one. In the +16 reports, x16 (0x8001000001fa8d89) is that isa shifted by one byte. This looks like a one-byte store of YES into the stack slot where x26 was saved across the callout. There is no single user action that reproduces it. It happens when the system delivers a scene settings update. The frame that wrote the byte is already gone, because the crash is recorded after the callout returns. Has anyone else seen this on iOS 27? I attached three .crash files with full register state to FB25454822.

On a 16" M5 MBP running 26.7.2 I have the display set to "1496 x 967" in the display section of Settings.app; the native resolution of the LCD panel is 3456 wide per the "System Information" report. When I inspect DOM nodes in a full screen width browser window, nodes which span the width of the screen show the expected 1496 CSS pixel width. However, when I run a Mac Catalyst app in Xcode, with its window at full screen width, and I inspect the bounds property of a UIView with the full width of the window, it reports its width as 1943 points wide, which doesn't match the value I expect (1496, same as FF sees) or the 'native point-resolution' of the display at 2x (1728 points). Furthermore, the nativeScale property of the UIWindow is 2, which combined with the point width contradicts the actual resolution of the LCD (i.e. 2*1943 != 3456.) I've looked for documentation but haven't found any. Where is 1943 point width coming from and why is the nativeScale 2? I was expecting 1496 and 1496/3456.

presentationPlacement(_:) is a great addition and brings us very close to being able to deprecate a custom side sheet we wrote, but one missing piece we found is that it isn't yet honored on Catalyst. It would be great if support for this could be added!

Adding and removing NSButton (any NSControl) in a window leaks AppKit-internal objects. A plain NSView does not. Environment: macOS 26.5.1 (25F80), Apple silicon (arm64), Swift, swiftc -O, no third-party code. Repro (single file): import AppKit func mb()->Int{ var i=task_vm_info_data_t(); var c=mach_msg_type_number_t(MemoryLayout<task_vm_info_data_t>.size/4); withUnsafeMutablePointer(to:&i){ $0.withMemoryRebound(to:integer_t.self,capacity:1){ _=task_info(mach_task_self_,task_flavor_t(TASK_VM_INFO),$0,&c)}}; return Int(i.phys_footprint/1048576)} let app = NSApplication.shared; app.setActivationPolicy(.accessory) let mode=CommandLine.arguments[1] let win=NSWindow(contentRect:NSRect(x:100,y:100,width:400,height:100),styleMask:[.titled],backing:.buffered,defer:false) let stack=NSStackView(); win.contentView=stack; win.orderFrontRegardless() var n=0 print(mode,"start",mb()); fflush(stdout) Timer.scheduledTimer(withTimeInterval:0.002,repeats:true){ t in autoreleasepool { for v in stack.arrangedSubviews { stack.removeArrangedSubview(v); v.removeFromSuperview() } for _ in 0..<10 { let b: NSView = mode=="view" ? NSView(frame:.zero) : NSButton(title:"", target:nil, action:nil) if mode=="plainadd" { win.contentView!.addSubview(b); b.removeFromSuperview() } else { stack.addArrangedSubview(b) } } } n+=1 if n%500==0 { print(mode,"iter",n*10,mb()); fflush(stdout) } if n>=2500 { t.invalidate() } } app.run()swiftc -O repro.swift -o tw ./tw button & # then: heap $(pgrep -x tw) -s | grep -E "NSKeyValueDependency |__NSMallocBlock__|NSButton " ./tw view & # control case: plain NSViewResults (25,000 buttons created and removed; only 10 alive at a time): modefootprint (MB) at 5k / 15k / 25kNSKeyValueDependencyNSMallocBlockbutton (NSButton in NSStackView)26 / 43 / 60 (steady growth)292,621251,145view (plain NSView)flat at 13172n/aheap shows only 10 live NSButton instances, so the buttons themselves are freed. leaks reports no leaks, so AppKit still holds references to the objects. That is about 12 objects (~3 KB) per button. Allocation stack (MallocStackLogging=1 + malloc_history -callTree NSKeyValueDependency, taken on my real app): -[NSStackView insertArrangedSubview:atIndex:] -[NSView addSubview:] -[NSView _setSuperview:] -[NSView(NSViewRoot) _updateViewRoot] -[NSControl _viewRootDidChange] -[NSControl _setupGestureRecognizers] __cons_NSDP_NSDPTypeBool_block_invoke.273 NSDP_getComputedPropertyValue -[NSKeyValueDependencyInfo addDependencyInContext:onValueForKey:] _objc_rootAllocWithZoneThe allocation happens when an NSControl is added to a view hierarchy that has a window (_viewRootDidChange → _setupGestureRecognizers). The KVO dependency objects are never released after the control is removed and deallocated. Real-world impact: an app rebuilt about 40 buttons every 5 s. That leaked about 40 objects per second (~16 MB/hour). After 19 days it reached 7.2 GB footprint, mostly small malloc blocks, with ~1.4M NSKeyValueDependency objects and ~1.4M blocks. Questions: Is this a known issue? Is there a Feedback number? Is there a supported way to avoid or release these dependency objects, other than not recreating NSControls? Does it reproduce on macOS 26.x or 27 betas? Workaround for now: reuse buttons and only rebuild when state actually changes.

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?

I have CarPlay Video enabled for my account and App ID. I tested both my main app and a completely new minimal iOS app with a new Bundle ID. The minimal app only contains: UIApplicationDelegate CPTemplateApplicationScene configuration CPTemplateApplicationSceneDelegate A single CPListTemplate root Results: With com.apple.developer.carplay-audio only, CarPlay launches normally. When com.apple.developer.carplay-video is added, CarPlay opens a blank screen. No CarPlay callbacks are called: application(:configurationForConnecting:options:) CPTemplateApplicationSceneDelegate.templateApplicationScene(:didConnect:) CPApplicationDelegate.didConnectCarInterfaceController The signed app and embedded provisioning profile both contain com.apple.developer.carplay-video. Does CarPlay Video require an additional runtime allowlist, specific head unit support, a different scene configuration, or another entitlement beyond com.apple.developer.carplay-video?

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.