Explore the various UI frameworks available for building app interfaces. Discuss the use cases for different frameworks, share best practices, and get help with specific framework-related questions.

All subtopics
Posts under UI Frameworks topic

Post

Replies

Boosts

Views

Activity

NavigationSplitView Binding to NavigationSplitViewColumn reset with every NavigationStack path change
I try to create a Navigation that works on iPhone, iPhone Duo and iPad. NavigationSplitView collapses for compact form factors and makes iPhone Duo support much simpler. The Problem is the semantic of the collapse. Switch from detail to sidebar on compact is not a 'back' action in my case. It should have my choosen Icon and has a meaning. So i wanted to control this using the NavigationSpliViewColumn Binding. This does work forward and backward as long as no NavigationStack was used before. But it stops working when you return to the detail root from a Navigation-Action. I left the Backbutton visible so you can test, that it continues to work, when no Navigation-Action preceeded the switch. Here is my Code: import SwiftUI @Observable final class Compass { var path: [Route] init() { self.path = [] } } enum Route: Hashable { case goal } struct ContentView: View { @Environment(\.horizontalSizeClass) private var hsize @State private var compass: Compass = Compass() @State var column: NavigationSplitViewColumn = .detail var body: some View { NavigationSplitView(preferredCompactColumn: $column) { OverviewScreen(column: $column) } detail: { TodayScreen() .toolbar { ToolbarItem(placement: .topBarLeading) { Button("overview", systemImage: "calendar") { self.column = .sidebar } } } } .environment(compass) .onChange(of: column) { old, new in print("column:", old, "→", new) } } } struct OverviewScreen: View { @Binding var column: NavigationSplitViewColumn @Environment(Compass.self) var compass var body: some View { @Bindable var compass = self.compass ScrollView { Text("Overview") .font(.largeTitle) .fontWeight(.heavy) Button("Switch") { self.column = .detail } } } } struct TodayScreen: View { @Environment(Compass.self) var compass var body: some View { @Bindable var compass = self.compass NavigationStack(path: $compass.path) { ScrollView { Text("Today") .font(.largeTitle) .fontWeight(.heavy) Button("Goals programtically", systemImage: "flag.fill") { self.compass.path = [.goal] } NavigationLink(value: Route.goal) { Label("Goal Link", systemImage: "flag.fill") } } .navigationDestination(for: Route.self, destination: self.screen) } } @ContentBuilder func screen(for route: Route) -> some View { switch route { case .goal: Text("Goals") } } } #Preview { ContentView() }This seems unexpected behaviour. If you ask AI the mental model is NavigationSplitViewColumn represents which column is currently visible for the user. That model would be wrong. Also i can't understand why a NavigationStack has to change the Binding? What am i missing here? Is my idea of the programmatic switch not supported? There are other ways to push from compact to your detail column again, but they all have trade-offs or run into other problems. I would appreciate any help here. AI has not understood this and only does surface level work arounds that fix nothing.
0
0
45
6d
NSSegmentedControl style ineffective.
I'm not sure if it's something wrong with my XCode install (Version 27.1, macOS 27.2) or what, because such a serious issue should be mentioned already... Basically, building my objC app with the latest XCode makes the NSSegmentedControl style ineffective. Likewise, changing the style in the attribute of the control in interface builder has no visible effect on the preview either. Changing the style in code or in IB has no effect. The control appears stuck with a style that implements a blue background for the selected segment (some default style I guess). I tried with a minimalistic app that includes only one window and the control. The issue is still present. Any suggestion? Am I the only one experiencing this?
Topic: UI Frameworks SubTopic: AppKit
8
0
503
6d
NSScrollView scrolling hitch
When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?
Topic: UI Frameworks SubTopic: AppKit Tags:
9
3
1.4k
1w
What pattern to use for an iPhone Tabview app
I have an iPhone tab view application that has not been designed for iPad, and I am aiming to add a left-hand bar that summarises some content and keeps visible what is normally a sheet. What pattern would work best for this? At present, I pass the view to another view with a navigation stack containing an arrangement view with the previous view and then the sidebar as a secondary view within it—would that be the appropriate approach?
Topic: UI Frameworks SubTopic: SwiftUI
3
0
412
1w
State Restoration no longer works in a Mac Catalyst based app when run on macOS 27.x
As reported in FB25363417: A UIKit based app running on macOS 27.2 (or macOS 27.0.1) via Mac Catalyst no longer has functioning state restoration. Upon app restart, there is no NSUserActivity being provided to the scene in the UISceneDelegate method scene(_:willConnectTo:options:). This can be tested with Apple’s own sample app “Restoring your app’s state”. Just update the sample project with support for a Mac Catalyst build. Using Xcode 27.2 on a Mac with macOS 27.0 or 27.2, build and run the Mac Catalyst version of the app. The main screen appears with a list of products. Select any product so you see details of the product. Quit the app. Run the app again. Note that you are not returned to the previously selected product detail screen. Instead, you just see the main list of products. If you run the same app and perform the same steps on a Mac running macOS 26.x, then when the app is restarted, you correctly get returned to the previously selected product detail screen. The problem is being caused by no NSUserActivity being passed into the scene delegate on app startup. While running the app on a Mac with macOS 27.x, put a breakpoint on the initial guard statement in scene(_:willConnectTo:options:) and you will see there is no activity on app restart. This is impacting paid customers of my existing app since upgrading to macOS 27. They no longer get returned to the app’s previous state when restarting the app. It is expected that state restoration should work on macOS 27 just as well as it does under macOS 26 in an app built with Mac Catalyst.
0
0
108
1w
UITextContentType.cellularIMEI works on iOS 27+ only
During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. Test details Implementation: textContentType = .cellularIMEI on the IMEI input field Entitlement status: no carrier-related entitlements in the test build Observed results iOS 27: The IMEI AutoFill suggestion appears and works in any app, regardless of carrier entitlement. iOS 26 and earlier: The IMEI AutoFill suggestion does not appear. Questions Is it the expected and intended behavior that, on iOS 27, IMEI AutoFill is available to any app without a carrier entitlement? On iOS versions earlier than 27 (iOS 17.4 to 26), is the public cellular plan entitlement required for IMEI AutoFill to work? If not, are there other conditions or requirements? On dual-IMEI devices, which IMEI (IMEI or IMEI2) is filled when .cellularIMEI is used on iOS 27? Should we use .cellularIMEI1 / .cellularIMEI2 to specify it explicitly? Thank you for your support.
1
0
132
1w
UIKit snapshot views render empty into UIImage on physical devices, but work in Simulator
Is there a supported way to convert the cached contents of a UIKit snapshot view into a UIImage on physical iOS/iPadOS devices? A view returned by snapshotView(afterScreenUpdates:) displays correctly on hardware, but drawing that view into a UIGraphicsImageRenderer produces no cached-content pixels. drawHierarchy(in:afterScreenUpdates:) still returns true. The same base experiment succeeds in Simulator. Feedback Assistant report: FB25336445. A standalone reproducer and measurements are attached there; use the corrected replica-readback-ios-27.0.1-fixed-project.zip attachment. Tested environments Physical iPhone 15 Pro Max: iOS 27.0.1 (24A446). Physical iPad mini (6th generation): iPadOS 26.6.1 (23G83). Two independent app launches produced identical measurements. Simulator: iPhone 18 Pro / iOS 27.0 and iPhone 15 Pro Max / iOS 26.1. The app is a standalone UIKit Release build, launched without a debugger or XCTest. It uses an ordinary red UIView and a white UILabel: no WebKit, Liquid Glass, video, secure text fields, third-party libraries, or private API calls. I have not tested a physical iPhone on the 26 series or iOS 27.0.2. The Simulator and device OS patch versions differ, so this is not a controlled OS-only comparison. Reproduction Display a red 240 x 160 UIView containing a white UILabel; allow it to render. Draw the original view into an image as a positive control. Call source.snapshotView(afterScreenUpdates: false), attach the replica to the window at the source frame, wait 500 ms, hide the original, then wait another 500 ms. Draw the attached replica into transparent and cyan-prefilled image contexts. Add an ordinary red 30 x 30 child UIView to the replica, wait 500 ms, and capture again. Repeat with replicas from UIWindow.snapshotView and UIScreen.snapshotView. This is the capture operation, called on the main actor after those waits: func rasterize(_ target: UIView, cyanBackground: Bool) -> UIImage { let format = UIGraphicsImageRendererFormat() format.scale = 1 format.opaque = false return UIGraphicsImageRenderer(size: target.bounds.size, format: format) .image { context in if cyanBackground { UIColor.cyan.setFill() context.fill(target.bounds) } let success = target.drawHierarchy( in: target.bounds, afterScreenUpdates: true ) print("drawHierarchy:", success) } }Results On both physical devices: The original 240 x 160 UIView renders normally: all 38,400 pixels are nontransparent. The replica on a transparent target produces zero nontransparent pixels. The replica on a cyan target leaves all 38,400 pixels cyan. Adding an ordinary child view produces approximately 900 red pixels, but the replica's cached contents are still missing. UIView, UIWindow and UIScreen replicas all exhibit the omission, while drawHierarchy returns true. In both tested Simulators, the base experiment renders the replica contents and overwrites the cyan background. The child-marker addition was tested on physical devices only. These counts are measured from the CGImage before PNG encoding. Thus “black output” with an opaque context appears to be missing content, not pixels painted black: transparent and cyan targets retain their original contents. Questions Is bitmap readback of these snapshot views supported on physical devices, or are they only intended for on-screen composition? If unsupported, is the Simulator behavior expected, and why does drawHierarchy return success despite omitting the visible cached contents? Is there a supported API to materialize those cached contents as an image, without starting a screen-recording session? Capturing the original view directly is a useful control, but does not answer how to read back an already-created snapshot. I found this older AVSampleBufferDisplayLayer discussion, which also describes a correctly displayed snapshot view becoming black when converted to an image. My reproducer uses only ordinary UIKit views; I do not know whether the underlying cause is related.
Topic: UI Frameworks SubTopic: UIKit
5
0
358
1w
Best way to position game touch controls around the iPhone Duo hinge
For a full-screen game with a Metal/Unreal rendering view and a SwiftUI overlay for touch controls, what is the recommended way to keep interactive controls away from the hinge while still allowing the rendered game world to use the full display? Would you recommend querying ReservedRegion in the SwiftUI overlay while allowing the underlying render view to remain edge-to-edge? Also, should control placement respond continuously while the device is being folded, or primarily respond to layout/reserved-region changes once the pose changes?
Topic: UI Frameworks SubTopic: SwiftUI
1
0
102
1w
Where can we find the official WWDC session / sample code for adopting the foldable iPhone (this generation's Duo hardware)?
We've been reverse-engineering behavior from the Simulator device profile alone. Is there a WWDC session, updated UIKit/SwiftUI documentation, or sample project specifically covering foldable iPhone adoption (window/scene handling, size-class behavior, collection/table view sizing, and the fold-posture API surface) that we should be building against instead of inferring behavior empirically?
Topic: UI Frameworks SubTopic: UIKit
1
0
115
1w
Is UIScreen.main.bounds valid on iPhone Duo?
During a fold, UIScreen.main.bounds stays at the outer-display size while window.windowScene?.screen.bounds updates. Layout that still reads UIScreen.main (sheet heights, map padding, title widths) is wrong on the inner display. Should apps stop using UIScreen.main entirely and always read the window scene’s screen?
Topic: UI Frameworks SubTopic: UIKit
2
0
303
1w
iPhone Duo supports multiple windows but `requestSceneSessionDestruction` fails due to unsupported device idiom
Problem: iPhone Duo supports multiple windows using Split Views. However, we cannot programmatically close windows using requestSceneSessionDestruction because we get the following error: "This functionality is not supported for this device idiom." This seems like a miss in Apple's requestSceneSessionDestruction implementation. If the Duo is going to let users open multiple windows (where supportsMultipleScenes is true for the Duo), then developers should be able to close them via requestSceneSessionDestruction, too. 🤔 Is this a bug? I have filed a ticket here in case it is: FB25353479 Additional implementation details: Our app supports multiple windows on iPad devices. The Duo is the first phone to support multiple windows as well. For user convenience, our app has an option to combine information from all windows and then collapse everything down to one single window. We use requestSceneSessionDestruction to close the extraneous windows afterward. This works great on iPad, but we get the unsupported device idiom error on the Duo only. We have no way of closing windows programmatically as far as I can tell.
Topic: UI Frameworks SubTopic: UIKit Tags:
2
0
109
1w
macOS 27: reproducible native menu hang in TextEdit using a short mouse sequence
Since upgrading to macOS 27, I have encountered native menus becoming unresponsive. It is reproducible via a short sequence of mouse actions in Apple’s TextEdit application. The following linked zip contains a Python reproduction script and a shell launcher that prepares its dependencies: https://drive.google.com/uc?export=download\&id=1q9DtRC7zpnhK50v4VmvuRAf2sq6I9jaz Expected: The menu continues responding to mouse movement, clicks and Escape. Observed: The menu becomes unresponsive after the sequence. Could anyone confirm whether the attached reproduction triggers the issue on their system? Is this a known AppKit menu-tracking issue, and are there any suggested workarounds or additional diagnostics that would help investigate it? Thank you.
Topic: UI Frameworks SubTopic: AppKit Tags:
1
0
145
1w
iPad: How to prevent the new floating decimalPad when using a keyboard toolbar (iPadOS 26)
On iPad running iOS 26, UIKeyboardType.decimalPad sometimes appears as a floating keypad (compact panel) instead of the docked, full-width keyboard. Our app attaches a custom toolbar via inputAccessoryView, so the floating keypad hides the toolbar and breaks the flow. We’d like to opt out of the floating keypad or force the keyboard to remain docked when a toolbar is present. Environment Device: iPad (multiple models) OS: iPadOS 26.0 App type: UIKit Field: UITextField with keyboardType = .decimalPad We present a custom toolbar via inputAccessoryView Expected Docked (full-width) keyboard so the inputAccessoryView toolbar is visible and sized correctly. Actual A floating decimal keypad appears and covers content; our accessory toolbar isn’t visible/attached to it. Why this matters Our toolbar contains required domain actions (Done/Next, Previous). When the keypad floats, the user loses these controls. Questions Is there a supported way to opt out of the floating numeric keypad on iPad when using decimalPad? Is there an API/trait to prefer docked keyboard (e.g., when an inputAccessoryView is present)?
Topic: UI Frameworks SubTopic: UIKit Tags:
4
0
974
1w
iPhone Duo: SwiftUI Layout Differs Between Simulator and Physical Device (Tab Bar Placement and Content Cropping)
Hi everyone, I'm experiencing a significant difference in SwiftUI layout behavior between the iPhone Duo simulator and a physical iPhone Duo. I've already adjusted my layout to work correctly in the simulator, but the same app behaves differently on the actual device. 1. Folded Simulator: The tab bar is positioned on the right side, as expected for iPhone Duo. The view respects the right-side layout, and scroll views extend naturally behind the tab bar, behaving as expected. Physical device: The tab bar appears at the bottom, like a regular iPhone, instead of on the right. The view is also cropped on the right side. 2. Unfolded Simulator: The tab bar and navigation view both appear correctly. Physical device: The tab bar remains at the bottom, even in landscape orientation, instead of using the expected Duo layout. The main content also starts from the bottom of the navigation view, resulting in an incorrect layout. The most confusing part is that the layout works correctly in the simulator but not on the physical device. Has anyone encountered this behavior on a physical iPhone Duo? Could this be related to the iOS version, SDK version, SwiftUI's automatic tab bar adaptation, or a device-specific bug? I'd appreciate any insights, especially from developers who have tested their SwiftUI apps on actual iPhone Duo hardware. Environment: Xcode version: 27.1 iOS SDK: 27.1 Physical device iOS version: 27.2 Thanks!
1
0
108
1w
Setting UITextContentType.cellularIMEI works differently on iOS 27 and others
During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. TL;DR Setting UITextContentType.cellularIMEI works on iOS 27 without any entitlement while not on prior verisons. is it expected behaviour? Test details Implementation: textContentType = .cellularIMEI on the IMEI input field Entitlement status: no carrier-related entitlements in the test build Observed results iOS 27: The IMEI AutoFill suggestion appears and works in any app, regardless of carrier entitlement. iOS 26 and earlier: The IMEI AutoFill suggestion does not appear. Questions Is it the expected and intended behavior that, on iOS 27, IMEI AutoFill is available to any app without a carrier entitlement? On iOS versions earlier than 27 (iOS 17.4 to 26), is the public cellular plan entitlement required for IMEI AutoFill to work? If not, are there other conditions or requirements? On dual-IMEI devices, which IMEI (IMEI or IMEI2) is filled when .cellularIMEI is used on iOS 27? Should we use .cellularIMEI1 / .cellularIMEI2 to specify it explicitly? Thank you in advance.
0
0
68
1w
Battery usage timeline graph shows incorrect time labels in macOS 27
Description: The time scale values on the battery usage curve in macOS 27 are displayed incorrectly. The screenshot timestamp is 14:39:11, October 20. Under the "Last 24 Hours" tab for Battery Level and Screen On Time charts, the timeline shows usage extending past 21:00 on October 20. This timestamp does not match the actual current time. It appears the timeline axis failed to shift correctly as time progresses. For comparison: a reference screenshot captured on macOS 26 at 09:30, August 8. Its battery usage timeline rendered correctly. The bottom time span covered August 7 to August 8, which is the expected and proper display behavior. This bug only exists in macOS 27’s battery usage chart. The older macOS 26 implementation works correctly. Device: MacBook Air M5 macOS version: macOS 27.2 RC
Topic: UI Frameworks SubTopic: SwiftUI
2
2
120
1w
Document-based app always opens untitled document even when a document is restored
If my NSDocument.canConcurrentlyReadDocuments(ofType:) implementation returns true, often when launching the app, an untitled document is created regardless whether another document is restored. If document reading is not concurrent, an untitled document is only created when no other document is restored, as expected. The issue happens on most app launches when a document is restored. If the restored document takes long to load (which can be simulated by putting sleep(1) in the Document.read(from:ofType:) implementation), the issue always happens. Is this expected, or is there a workaround? I created FB25340015.
Topic: UI Frameworks SubTopic: AppKit Tags:
0
0
49
1w
Cannot move window by its background (macOS 27)
Hi, My app (SmashTunes) can display a floating window with artwork of a music track that is displaying. It does for over a decade in multiple versions of macOS. I do this by calling window?.isMovableByWindowBackground = true. This stopped working under macOS 27. I've read some reports of others not being able to move windows. It should supposedly have been fixed in macOS 27.2, but it is not. Has anyone on this forum run into the same problem, or know of a different way to move windows around on the screen? When I add add a titlebar, I can drag it by the titlebar, but that is not really an option for my use case.
Topic: UI Frameworks SubTopic: General
0
0
57
1w
iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices
# iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices ## Description After upgrading a physical iPhone to iOS 27.2, my Ionic Angular application running on Cordova no longer renders correctly. The left and right black areas that were previously visible along the screen edges have disappeared, and the iOS status bar (time, network connectivity, and battery) is now visible in a way that affects the app's layout. Some UI components are consequently shifted from their expected positions. For example, some of the header components are pushed as the status bar starts to appear(status bar does not show on iOS 27.1 or lower) **The same app works correctly on iOS 27.1 on the same device.** The problem only appears after upgrading to iOS 27.2. Interestingly, I cannot reproduce the issue in the iOS simulator, even when running the same app on the iOS 27.2 simulator. So far, the issue appears to affect physical devices only. ## Expected behavior The app should retain its previous layout, including the black areas on the left and right edges(safe area view). The status bar and safe-area handling should remain consistent with the behavior on iOS 27.1, without unexpectedly shifting UI components. ## Actual behavior - The black areas on the left and right edges disappear. - The iOS status bar becomes visible and appears to affect the page layout. - Some UI components are shifted from their expected positions. - The issue occurs on a physical device running iOS 27.2 but cannot currently be reproduced in the simulator. ## Current configuration My `config.xml` contains: ```xml <preference name="StatusBarOverlaysWebView" value="false" /> ``` My viewport meta tag is: ```html <meta name="viewport" content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"> ``` I am using Ionic Angular with Cordova and an embedded iOS WebView. ## Steps to reproduce 1. Install and launch the app on a physical iPhone running iOS 27.1. 2. Observe that the layout and left/right black areas render as expected. 3. Upgrade the same device to iOS 27.2. 4. Launch the same app build. 5. Observe that the black areas disappear and the status bar/layout behavior changes. The issue has not been reproduced in the simulator. ## Questions 1. Has there been a change in iOS 27.2 affecting `WKWebView` safe-area insets, viewport sizing, or status-bar layout? 2. Could the native WebView frame or safe-area handling behave differently on physical devices compared with the simulator? 3. Is there a known workaround that does not require upgrading `cordova-ios`? 4. Is this more likely to be an iOS/WebKit regression or an incompatibility with the Cordova StatusBar plugin? I would appreciate any guidance on how to diagnose or work around this issue. I can provide screenshots from iOS 27.1 and 27.2, as well as additional diagnostics, if helpful. ## Environment - Framework: Ionic Angular - Platform: Cordova iOS - Affected OS: iOS 27.2 - Previously working OS: iOS 27.1 - Device: iPhone (physical device; exact model to be provided) - Simulator: Issue not reproducible - `StatusBarOverlaysWebView`: `false` - Viewport: `viewport-fit=cover`
Topic: UI Frameworks SubTopic: UIKit
0
3
179
1w
NavigationSplitView Binding to NavigationSplitViewColumn reset with every NavigationStack path change
I try to create a Navigation that works on iPhone, iPhone Duo and iPad. NavigationSplitView collapses for compact form factors and makes iPhone Duo support much simpler. The Problem is the semantic of the collapse. Switch from detail to sidebar on compact is not a 'back' action in my case. It should have my choosen Icon and has a meaning. So i wanted to control this using the NavigationSpliViewColumn Binding. This does work forward and backward as long as no NavigationStack was used before. But it stops working when you return to the detail root from a Navigation-Action. I left the Backbutton visible so you can test, that it continues to work, when no Navigation-Action preceeded the switch. Here is my Code: import SwiftUI @Observable final class Compass { var path: [Route] init() { self.path = [] } } enum Route: Hashable { case goal } struct ContentView: View { @Environment(\.horizontalSizeClass) private var hsize @State private var compass: Compass = Compass() @State var column: NavigationSplitViewColumn = .detail var body: some View { NavigationSplitView(preferredCompactColumn: $column) { OverviewScreen(column: $column) } detail: { TodayScreen() .toolbar { ToolbarItem(placement: .topBarLeading) { Button("overview", systemImage: "calendar") { self.column = .sidebar } } } } .environment(compass) .onChange(of: column) { old, new in print("column:", old, "→", new) } } } struct OverviewScreen: View { @Binding var column: NavigationSplitViewColumn @Environment(Compass.self) var compass var body: some View { @Bindable var compass = self.compass ScrollView { Text("Overview") .font(.largeTitle) .fontWeight(.heavy) Button("Switch") { self.column = .detail } } } } struct TodayScreen: View { @Environment(Compass.self) var compass var body: some View { @Bindable var compass = self.compass NavigationStack(path: $compass.path) { ScrollView { Text("Today") .font(.largeTitle) .fontWeight(.heavy) Button("Goals programtically", systemImage: "flag.fill") { self.compass.path = [.goal] } NavigationLink(value: Route.goal) { Label("Goal Link", systemImage: "flag.fill") } } .navigationDestination(for: Route.self, destination: self.screen) } } @ContentBuilder func screen(for route: Route) -> some View { switch route { case .goal: Text("Goals") } } } #Preview { ContentView() }This seems unexpected behaviour. If you ask AI the mental model is NavigationSplitViewColumn represents which column is currently visible for the user. That model would be wrong. Also i can't understand why a NavigationStack has to change the Binding? What am i missing here? Is my idea of the programmatic switch not supported? There are other ways to push from compact to your detail column again, but they all have trade-offs or run into other problems. I would appreciate any help here. AI has not understood this and only does surface level work arounds that fix nothing.
Replies
0
Boosts
0
Views
45
Activity
6d
NSSegmentedControl style ineffective.
I'm not sure if it's something wrong with my XCode install (Version 27.1, macOS 27.2) or what, because such a serious issue should be mentioned already... Basically, building my objC app with the latest XCode makes the NSSegmentedControl style ineffective. Likewise, changing the style in the attribute of the control in interface builder has no visible effect on the preview either. Changing the style in code or in IB has no effect. The control appears stuck with a style that implements a blue background for the selected segment (some default style I guess). I tried with a minimalistic app that includes only one window and the control. The issue is still present. Any suggestion? Am I the only one experiencing this?
Topic: UI Frameworks SubTopic: AppKit
Replies
8
Boosts
0
Views
503
Activity
6d
NSScrollView scrolling hitch
When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
9
Boosts
3
Views
1.4k
Activity
1w
What pattern to use for an iPhone Tabview app
I have an iPhone tab view application that has not been designed for iPad, and I am aiming to add a left-hand bar that summarises some content and keeps visible what is normally a sheet. What pattern would work best for this? At present, I pass the view to another view with a navigation stack containing an arrangement view with the previous view and then the sidebar as a secondary view within it—would that be the appropriate approach?
Topic: UI Frameworks SubTopic: SwiftUI
Replies
3
Boosts
0
Views
412
Activity
1w
State Restoration no longer works in a Mac Catalyst based app when run on macOS 27.x
As reported in FB25363417: A UIKit based app running on macOS 27.2 (or macOS 27.0.1) via Mac Catalyst no longer has functioning state restoration. Upon app restart, there is no NSUserActivity being provided to the scene in the UISceneDelegate method scene(_:willConnectTo:options:). This can be tested with Apple’s own sample app “Restoring your app’s state”. Just update the sample project with support for a Mac Catalyst build. Using Xcode 27.2 on a Mac with macOS 27.0 or 27.2, build and run the Mac Catalyst version of the app. The main screen appears with a list of products. Select any product so you see details of the product. Quit the app. Run the app again. Note that you are not returned to the previously selected product detail screen. Instead, you just see the main list of products. If you run the same app and perform the same steps on a Mac running macOS 26.x, then when the app is restarted, you correctly get returned to the previously selected product detail screen. The problem is being caused by no NSUserActivity being passed into the scene delegate on app startup. While running the app on a Mac with macOS 27.x, put a breakpoint on the initial guard statement in scene(_:willConnectTo:options:) and you will see there is no activity on app restart. This is impacting paid customers of my existing app since upgrading to macOS 27. They no longer get returned to the app’s previous state when restarting the app. It is expected that state restoration should work on macOS 27 just as well as it does under macOS 26 in an app built with Mac Catalyst.
Replies
0
Boosts
0
Views
108
Activity
1w
UITextContentType.cellularIMEI works on iOS 27+ only
During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. Test details Implementation: textContentType = .cellularIMEI on the IMEI input field Entitlement status: no carrier-related entitlements in the test build Observed results iOS 27: The IMEI AutoFill suggestion appears and works in any app, regardless of carrier entitlement. iOS 26 and earlier: The IMEI AutoFill suggestion does not appear. Questions Is it the expected and intended behavior that, on iOS 27, IMEI AutoFill is available to any app without a carrier entitlement? On iOS versions earlier than 27 (iOS 17.4 to 26), is the public cellular plan entitlement required for IMEI AutoFill to work? If not, are there other conditions or requirements? On dual-IMEI devices, which IMEI (IMEI or IMEI2) is filled when .cellularIMEI is used on iOS 27? Should we use .cellularIMEI1 / .cellularIMEI2 to specify it explicitly? Thank you for your support.
Replies
1
Boosts
0
Views
132
Activity
1w
UIKit snapshot views render empty into UIImage on physical devices, but work in Simulator
Is there a supported way to convert the cached contents of a UIKit snapshot view into a UIImage on physical iOS/iPadOS devices? A view returned by snapshotView(afterScreenUpdates:) displays correctly on hardware, but drawing that view into a UIGraphicsImageRenderer produces no cached-content pixels. drawHierarchy(in:afterScreenUpdates:) still returns true. The same base experiment succeeds in Simulator. Feedback Assistant report: FB25336445. A standalone reproducer and measurements are attached there; use the corrected replica-readback-ios-27.0.1-fixed-project.zip attachment. Tested environments Physical iPhone 15 Pro Max: iOS 27.0.1 (24A446). Physical iPad mini (6th generation): iPadOS 26.6.1 (23G83). Two independent app launches produced identical measurements. Simulator: iPhone 18 Pro / iOS 27.0 and iPhone 15 Pro Max / iOS 26.1. The app is a standalone UIKit Release build, launched without a debugger or XCTest. It uses an ordinary red UIView and a white UILabel: no WebKit, Liquid Glass, video, secure text fields, third-party libraries, or private API calls. I have not tested a physical iPhone on the 26 series or iOS 27.0.2. The Simulator and device OS patch versions differ, so this is not a controlled OS-only comparison. Reproduction Display a red 240 x 160 UIView containing a white UILabel; allow it to render. Draw the original view into an image as a positive control. Call source.snapshotView(afterScreenUpdates: false), attach the replica to the window at the source frame, wait 500 ms, hide the original, then wait another 500 ms. Draw the attached replica into transparent and cyan-prefilled image contexts. Add an ordinary red 30 x 30 child UIView to the replica, wait 500 ms, and capture again. Repeat with replicas from UIWindow.snapshotView and UIScreen.snapshotView. This is the capture operation, called on the main actor after those waits: func rasterize(_ target: UIView, cyanBackground: Bool) -> UIImage { let format = UIGraphicsImageRendererFormat() format.scale = 1 format.opaque = false return UIGraphicsImageRenderer(size: target.bounds.size, format: format) .image { context in if cyanBackground { UIColor.cyan.setFill() context.fill(target.bounds) } let success = target.drawHierarchy( in: target.bounds, afterScreenUpdates: true ) print("drawHierarchy:", success) } }Results On both physical devices: The original 240 x 160 UIView renders normally: all 38,400 pixels are nontransparent. The replica on a transparent target produces zero nontransparent pixels. The replica on a cyan target leaves all 38,400 pixels cyan. Adding an ordinary child view produces approximately 900 red pixels, but the replica's cached contents are still missing. UIView, UIWindow and UIScreen replicas all exhibit the omission, while drawHierarchy returns true. In both tested Simulators, the base experiment renders the replica contents and overwrites the cyan background. The child-marker addition was tested on physical devices only. These counts are measured from the CGImage before PNG encoding. Thus “black output” with an opaque context appears to be missing content, not pixels painted black: transparent and cyan targets retain their original contents. Questions Is bitmap readback of these snapshot views supported on physical devices, or are they only intended for on-screen composition? If unsupported, is the Simulator behavior expected, and why does drawHierarchy return success despite omitting the visible cached contents? Is there a supported API to materialize those cached contents as an image, without starting a screen-recording session? Capturing the original view directly is a useful control, but does not answer how to read back an already-created snapshot. I found this older AVSampleBufferDisplayLayer discussion, which also describes a correctly displayed snapshot view becoming black when converted to an image. My reproducer uses only ordinary UIKit views; I do not know whether the underlying cause is related.
Topic: UI Frameworks SubTopic: UIKit
Replies
5
Boosts
0
Views
358
Activity
1w
Best way to position game touch controls around the iPhone Duo hinge
For a full-screen game with a Metal/Unreal rendering view and a SwiftUI overlay for touch controls, what is the recommended way to keep interactive controls away from the hinge while still allowing the rendered game world to use the full display? Would you recommend querying ReservedRegion in the SwiftUI overlay while allowing the underlying render view to remain edge-to-edge? Also, should control placement respond continuously while the device is being folded, or primarily respond to layout/reserved-region changes once the pose changes?
Topic: UI Frameworks SubTopic: SwiftUI
Replies
1
Boosts
0
Views
102
Activity
1w
Where can we find the official WWDC session / sample code for adopting the foldable iPhone (this generation's Duo hardware)?
We've been reverse-engineering behavior from the Simulator device profile alone. Is there a WWDC session, updated UIKit/SwiftUI documentation, or sample project specifically covering foldable iPhone adoption (window/scene handling, size-class behavior, collection/table view sizing, and the fold-posture API surface) that we should be building against instead of inferring behavior empirically?
Topic: UI Frameworks SubTopic: UIKit
Replies
1
Boosts
0
Views
115
Activity
1w
Is UIScreen.main.bounds valid on iPhone Duo?
During a fold, UIScreen.main.bounds stays at the outer-display size while window.windowScene?.screen.bounds updates. Layout that still reads UIScreen.main (sheet heights, map padding, title widths) is wrong on the inner display. Should apps stop using UIScreen.main entirely and always read the window scene’s screen?
Topic: UI Frameworks SubTopic: UIKit
Replies
2
Boosts
0
Views
303
Activity
1w
iPhone Duo supports multiple windows but `requestSceneSessionDestruction` fails due to unsupported device idiom
Problem: iPhone Duo supports multiple windows using Split Views. However, we cannot programmatically close windows using requestSceneSessionDestruction because we get the following error: "This functionality is not supported for this device idiom." This seems like a miss in Apple's requestSceneSessionDestruction implementation. If the Duo is going to let users open multiple windows (where supportsMultipleScenes is true for the Duo), then developers should be able to close them via requestSceneSessionDestruction, too. 🤔 Is this a bug? I have filed a ticket here in case it is: FB25353479 Additional implementation details: Our app supports multiple windows on iPad devices. The Duo is the first phone to support multiple windows as well. For user convenience, our app has an option to combine information from all windows and then collapse everything down to one single window. We use requestSceneSessionDestruction to close the extraneous windows afterward. This works great on iPad, but we get the unsupported device idiom error on the Duo only. We have no way of closing windows programmatically as far as I can tell.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
0
Views
109
Activity
1w
macOS 27: reproducible native menu hang in TextEdit using a short mouse sequence
Since upgrading to macOS 27, I have encountered native menus becoming unresponsive. It is reproducible via a short sequence of mouse actions in Apple’s TextEdit application. The following linked zip contains a Python reproduction script and a shell launcher that prepares its dependencies: https://drive.google.com/uc?export=download\&id=1q9DtRC7zpnhK50v4VmvuRAf2sq6I9jaz Expected: The menu continues responding to mouse movement, clicks and Escape. Observed: The menu becomes unresponsive after the sequence. Could anyone confirm whether the attached reproduction triggers the issue on their system? Is this a known AppKit menu-tracking issue, and are there any suggested workarounds or additional diagnostics that would help investigate it? Thank you.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
1
Boosts
0
Views
145
Activity
1w
iPad: How to prevent the new floating decimalPad when using a keyboard toolbar (iPadOS 26)
On iPad running iOS 26, UIKeyboardType.decimalPad sometimes appears as a floating keypad (compact panel) instead of the docked, full-width keyboard. Our app attaches a custom toolbar via inputAccessoryView, so the floating keypad hides the toolbar and breaks the flow. We’d like to opt out of the floating keypad or force the keyboard to remain docked when a toolbar is present. Environment Device: iPad (multiple models) OS: iPadOS 26.0 App type: UIKit Field: UITextField with keyboardType = .decimalPad We present a custom toolbar via inputAccessoryView Expected Docked (full-width) keyboard so the inputAccessoryView toolbar is visible and sized correctly. Actual A floating decimal keypad appears and covers content; our accessory toolbar isn’t visible/attached to it. Why this matters Our toolbar contains required domain actions (Done/Next, Previous). When the keypad floats, the user loses these controls. Questions Is there a supported way to opt out of the floating numeric keypad on iPad when using decimalPad? Is there an API/trait to prefer docked keyboard (e.g., when an inputAccessoryView is present)?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
4
Boosts
0
Views
974
Activity
1w
iPhone Duo: SwiftUI Layout Differs Between Simulator and Physical Device (Tab Bar Placement and Content Cropping)
Hi everyone, I'm experiencing a significant difference in SwiftUI layout behavior between the iPhone Duo simulator and a physical iPhone Duo. I've already adjusted my layout to work correctly in the simulator, but the same app behaves differently on the actual device. 1. Folded Simulator: The tab bar is positioned on the right side, as expected for iPhone Duo. The view respects the right-side layout, and scroll views extend naturally behind the tab bar, behaving as expected. Physical device: The tab bar appears at the bottom, like a regular iPhone, instead of on the right. The view is also cropped on the right side. 2. Unfolded Simulator: The tab bar and navigation view both appear correctly. Physical device: The tab bar remains at the bottom, even in landscape orientation, instead of using the expected Duo layout. The main content also starts from the bottom of the navigation view, resulting in an incorrect layout. The most confusing part is that the layout works correctly in the simulator but not on the physical device. Has anyone encountered this behavior on a physical iPhone Duo? Could this be related to the iOS version, SDK version, SwiftUI's automatic tab bar adaptation, or a device-specific bug? I'd appreciate any insights, especially from developers who have tested their SwiftUI apps on actual iPhone Duo hardware. Environment: Xcode version: 27.1 iOS SDK: 27.1 Physical device iOS version: 27.2 Thanks!
Replies
1
Boosts
0
Views
108
Activity
1w
Setting UITextContentType.cellularIMEI works differently on iOS 27 and others
During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. TL;DR Setting UITextContentType.cellularIMEI works on iOS 27 without any entitlement while not on prior verisons. is it expected behaviour? Test details Implementation: textContentType = .cellularIMEI on the IMEI input field Entitlement status: no carrier-related entitlements in the test build Observed results iOS 27: The IMEI AutoFill suggestion appears and works in any app, regardless of carrier entitlement. iOS 26 and earlier: The IMEI AutoFill suggestion does not appear. Questions Is it the expected and intended behavior that, on iOS 27, IMEI AutoFill is available to any app without a carrier entitlement? On iOS versions earlier than 27 (iOS 17.4 to 26), is the public cellular plan entitlement required for IMEI AutoFill to work? If not, are there other conditions or requirements? On dual-IMEI devices, which IMEI (IMEI or IMEI2) is filled when .cellularIMEI is used on iOS 27? Should we use .cellularIMEI1 / .cellularIMEI2 to specify it explicitly? Thank you in advance.
Replies
0
Boosts
0
Views
68
Activity
1w
Battery usage timeline graph shows incorrect time labels in macOS 27
Description: The time scale values on the battery usage curve in macOS 27 are displayed incorrectly. The screenshot timestamp is 14:39:11, October 20. Under the "Last 24 Hours" tab for Battery Level and Screen On Time charts, the timeline shows usage extending past 21:00 on October 20. This timestamp does not match the actual current time. It appears the timeline axis failed to shift correctly as time progresses. For comparison: a reference screenshot captured on macOS 26 at 09:30, August 8. Its battery usage timeline rendered correctly. The bottom time span covered August 7 to August 8, which is the expected and proper display behavior. This bug only exists in macOS 27’s battery usage chart. The older macOS 26 implementation works correctly. Device: MacBook Air M5 macOS version: macOS 27.2 RC
Topic: UI Frameworks SubTopic: SwiftUI
Replies
2
Boosts
2
Views
120
Activity
1w
Document-based app always opens untitled document even when a document is restored
If my NSDocument.canConcurrentlyReadDocuments(ofType:) implementation returns true, often when launching the app, an untitled document is created regardless whether another document is restored. If document reading is not concurrent, an untitled document is only created when no other document is restored, as expected. The issue happens on most app launches when a document is restored. If the restored document takes long to load (which can be simulated by putting sleep(1) in the Document.read(from:ofType:) implementation), the issue always happens. Is this expected, or is there a workaround? I created FB25340015.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
0
Boosts
0
Views
49
Activity
1w
Cannot move window by its background (macOS 27)
Hi, My app (SmashTunes) can display a floating window with artwork of a music track that is displaying. It does for over a decade in multiple versions of macOS. I do this by calling window?.isMovableByWindowBackground = true. This stopped working under macOS 27. I've read some reports of others not being able to move windows. It should supposedly have been fixed in macOS 27.2, but it is not. Has anyone on this forum run into the same problem, or know of a different way to move windows around on the screen? When I add add a titlebar, I can drag it by the titlebar, but that is not really an option for my use case.
Topic: UI Frameworks SubTopic: General
Replies
0
Boosts
0
Views
57
Activity
1w
iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices
# iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices ## Description After upgrading a physical iPhone to iOS 27.2, my Ionic Angular application running on Cordova no longer renders correctly. The left and right black areas that were previously visible along the screen edges have disappeared, and the iOS status bar (time, network connectivity, and battery) is now visible in a way that affects the app's layout. Some UI components are consequently shifted from their expected positions. For example, some of the header components are pushed as the status bar starts to appear(status bar does not show on iOS 27.1 or lower) **The same app works correctly on iOS 27.1 on the same device.** The problem only appears after upgrading to iOS 27.2. Interestingly, I cannot reproduce the issue in the iOS simulator, even when running the same app on the iOS 27.2 simulator. So far, the issue appears to affect physical devices only. ## Expected behavior The app should retain its previous layout, including the black areas on the left and right edges(safe area view). The status bar and safe-area handling should remain consistent with the behavior on iOS 27.1, without unexpectedly shifting UI components. ## Actual behavior - The black areas on the left and right edges disappear. - The iOS status bar becomes visible and appears to affect the page layout. - Some UI components are shifted from their expected positions. - The issue occurs on a physical device running iOS 27.2 but cannot currently be reproduced in the simulator. ## Current configuration My `config.xml` contains: ```xml <preference name="StatusBarOverlaysWebView" value="false" /> ``` My viewport meta tag is: ```html <meta name="viewport" content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"> ``` I am using Ionic Angular with Cordova and an embedded iOS WebView. ## Steps to reproduce 1. Install and launch the app on a physical iPhone running iOS 27.1. 2. Observe that the layout and left/right black areas render as expected. 3. Upgrade the same device to iOS 27.2. 4. Launch the same app build. 5. Observe that the black areas disappear and the status bar/layout behavior changes. The issue has not been reproduced in the simulator. ## Questions 1. Has there been a change in iOS 27.2 affecting `WKWebView` safe-area insets, viewport sizing, or status-bar layout? 2. Could the native WebView frame or safe-area handling behave differently on physical devices compared with the simulator? 3. Is there a known workaround that does not require upgrading `cordova-ios`? 4. Is this more likely to be an iOS/WebKit regression or an incompatibility with the Cordova StatusBar plugin? I would appreciate any guidance on how to diagnose or work around this issue. I can provide screenshots from iOS 27.1 and 27.2, as well as additional diagnostics, if helpful. ## Environment - Framework: Ionic Angular - Platform: Cordova iOS - Affected OS: iOS 27.2 - Previously working OS: iOS 27.1 - Device: iPhone (physical device; exact model to be provided) - Simulator: Issue not reproducible - `StatusBarOverlaysWebView`: `false` - Viewport: `viewport-fit=cover`
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
3
Views
179
Activity
1w