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

How do I have the NSToolbar "floating" on top of content scrollview on macOS Tahoe?
I have this MWE right here -- it has a toolbar with a random action on it, in addition to a scroll view as the content of the window, with random labels attached inside. Since the redeisgn of the NSToolbar stuff in Tahoe, I expect the share button be able to "float" on top of the scrolled out content as shown as the first image at https://developer.apple.com/documentation/TechnologyOverviews/adopting-liquid-glass. #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSToolbarDelegate> @property (strong) NSWindow *window; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { NSRect frame = NSMakeRect(100, 100, 600, 400); self.window = [[NSWindow alloc] initWithContentRect:frame styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable | NSWindowStyleMaskMiniaturizable) backing:NSBackingStoreBuffered defer:NO]; [self.window setTitle:@"Scroll View + Toolbar Demo"]; NSToolbar *toolbar = [[NSToolbar alloc] initWithIdentifier:@"MainToolbar"]; toolbar.displayMode = NSToolbarDisplayModeIconAndLabel; toolbar.delegate = self; [self.window setToolbar:toolbar]; NSScrollView *scrollView = [[NSScrollView alloc] initWithFrame:self.window.contentView.bounds]; [scrollView setAutoresizingMask:(NSViewWidthSizable | NSViewHeightSizable)]; [scrollView setHasVerticalScroller:YES]; [scrollView setHasHorizontalScroller:YES]; NSView *documentView = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 1000, 1000)]; for (int i = 0; i < 10; i++) { NSTextField *label = [[NSTextField alloc] initWithFrame:NSMakeRect(50, 950 - i*80, 400, 40)]; [label setStringValue:[NSString stringWithFormat:@"Sample Label #%d", i + 1]]; [label setBezeled:NO]; [label setDrawsBackground:NO]; [label setEditable:NO]; [label setSelectable:NO]; [documentView addSubview:label]; } [scrollView setDocumentView:documentView]; [self.window setContentView:scrollView]; [self.window makeKeyAndOrderFront:nil]; } - (NSArray<NSToolbarItemIdentifier> *)toolbarAllowedItemIdentifiers:(NSToolbar *)toolbar { return @[NSToolbarFlexibleSpaceItemIdentifier, @"ShareItem"]; } - (NSArray<NSToolbarItemIdentifier> *)toolbarDefaultItemIdentifiers:(NSToolbar *)toolbar { return @[@"ShareItem"]; } - (NSToolbarItem *)toolbar:(NSToolbar *)toolbar itemForItemIdentifier:(NSToolbarItemIdentifier)itemIdentifier willBeInsertedIntoToolbar:(BOOL)flag { if ([itemIdentifier isEqualToString:@"ShareItem"]) { NSToolbarItem *shareItem = [[NSToolbarItem alloc] initWithItemIdentifier:itemIdentifier]; shareItem.toolTip = @"Share this content"; shareItem.image = [NSImage imageNamed:NSImageNameShareTemplate]; shareItem.target = self; shareItem.action = @selector(shareAction:); return shareItem; } return nil; } - (void)shareAction:(id)sender { NSLog(@"Share button clicked!"); // Here you could present a sharing service picker NSSharingServicePicker *picker = [[NSSharingServicePicker alloc] initWithItems:@[@"Hello, world!"]]; [picker showRelativeToRect:[sender view].bounds ofView:[sender view] preferredEdge:NSRectEdgeMinY]; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app run]; } return EXIT_SUCCESS; } But it doesn't and produces this image: https://imgur.com/a/kA7MzIe I've tried to set various settings to make the top bar transparent, but all it does is that it makes it completely opaque instead. How can I make the share button float on top of the content? P.S. the app is a single-file app, compile it with clang -fobjc-arc -framework Cocoa -o ScrollApp toolbar.m
Topic: UI Frameworks SubTopic: AppKit
2
0
296
1w
What does it take for an app Window menu list to display the new items like Move & Resize?
Here's the result of a blank app from Xcode: https://imgur.com/a/1hMmwbO now there's only 3 items in the storyboard configuration: https://imgur.com/a/iGWWQE7 So I try to replicate that in code (some of this reproducer was generated by ChatGPT however the same issue I'm descrbing has been hit when using Python to objc bridges to construct the GUI) by specifying these 3 actions appropriately and see if the rest pops up. The code below changes the activation policy so that when I run ./a.out from the terminal it doesn't show as a window of Terminal but a separate app #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate> @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { // Build main menu NSMenu *mainMenu = [[NSMenu alloc] initWithTitle:@"MainMenu"]; // --- App menu with Quit --- NSMenuItem *appMenuItem = [[NSMenuItem alloc] init]; NSMenu *appMenu = [[NSMenu alloc] initWithTitle:@"App"]; NSMenuItem *quitItem = [[NSMenuItem alloc] initWithTitle:@"Quit" action:@selector(terminate:) keyEquivalent:@"q"]; [appMenu addItem:quitItem]; [appMenuItem setSubmenu:appMenu]; [mainMenu addItem:appMenuItem]; // --- Window menu with only Minimize, Zoom, Bring All to Front --- NSMenuItem *windowMenuItem = [[NSMenuItem alloc] initWithTitle:@"Window" action:NULL keyEquivalent:@""]; NSMenu *windowMenu = [[NSMenu alloc] initWithTitle:@"Window"]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Minimize" action:@selector(performMiniaturize:) keyEquivalent:@"m"]]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Zoom" action:@selector(performZoom:) keyEquivalent:@""]]; [windowMenu addItem:[NSMenuItem separatorItem]]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Bring All to Front" action:@selector(arrangeInFront:) keyEquivalent:@""]]; [windowMenuItem setSubmenu:windowMenu]; [mainMenu addItem:windowMenuItem]; [NSApp setMainMenu:mainMenu]; // Optional demo window (remove if you want zero windows) NSWindow *w = [[NSWindow alloc] initWithContentRect:NSMakeRect(200,200,400,200) styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable | NSWindowStyleMaskMiniaturizable) backing:NSBackingStoreBuffered defer:NO]; [w setTitle:@"Demo"]; [w makeKeyAndOrderFront:nil]; [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular]; } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { AppDelegate *delegate = [AppDelegate new]; [NSApplication sharedApplication]; [NSApp setDelegate:delegate]; return NSApplicationMain(argc, argv); } } Now, I only see 3 items that's literally specified https://imgur.com/a/LylRsaJ So, what allows interface builder to auto-add these extra items as opposed by creating it in code? Is there something in this reproducer of the Window menu that is missing that needs to make it happen programatically? Thanks! All tests done on macOS Tahoe
Topic: UI Frameworks SubTopic: AppKit
3
0
287
1w
Public API to overlay or hide the system keyboard while preserving its exact state?
I am building an iOS text composer with an attachment panel. When its UITextField is first responder and the system keyboard is visible, tapping the attachment button should present a panel that can extend into the region occupied by the keyboard. When the panel closes, the user should return to the same keyboard state without a visible dismissal and re-presentation. The required continuity is: The same UITextField remains first responder. The active input mode remains alphabet, 123, or Emoji. Emoji preserves its selected category, search state, and scroll position. The composer remains positioned above the keyboard throughout the transition. I have investigated the public UIKit approaches: A normal app-window overlay cannot render above the remotely hosted system keyboard. inputAccessoryView remains in the accessory region and cannot cover the keycaps. Resigning first responder visibly dismisses the keyboard and loses continuity. Assigning a custom inputView to the same UITextField and calling reloadInputViews() publicly replaces the keyboard. However, restoring inputView to nil reconstructs the system keyboard and does not preserve the exact Emoji or keyplane state. UIKeyboardLayoutGuide provides geometry but no presentation control. Is there a supported public API or recommended architecture that allows an app to: Temporarily obscure or visually hide the system keyboard while keeping it active and preserving its state? Present app-owned content in a layer above the keyboard keycaps? Temporarily replace the keyboard and restore the same mode, Emoji category, and scroll position? If these are unsupported, what is Apple's recommended way to create an attachment panel that visually occupies the keyboard region while maintaining input continuity? This occurs on iOS 26.x in Simulator and on a physical iPhone using a UIKit-backed text field inside a SwiftUI interface. I am specifically looking for a public API solution and do not want to access private keyboard windows or views.
0
0
99
1w
NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
Is anyone else getting these assertion crashes on developer beta 3 of Golden Gate? I've gotten more than a dozen crash logs from users running macOS 27 (26A5378j) that all look like this: assertion failed: '<NSRemoteView: 0x79cb366700 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x79cbef7480> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line 4221 of file /AppleInternal/Library/BuildRoots/4~CSuOugB1YCxzYMPRWEumvvfCTNtf98eItTmsbJU/Library/Caches/com.apple.xbs/TemporaryDirectory.N8fh9t/Sources/ViewBridge/NSRemoteView.m but with various windows from my app after "notified of". They're getting thrown when one of my windows is made frontmost, either using NSWindow.orderFrontRegardless or NSWindow.makeKeyAndOrderFront, or (in the case above) when my status item is shown. It's intermittent - I've been unable to reproduce it so far - but definitely happening repeatedly based on my Sentry crash logging. Is this a bug in Golden Gate b3, or am I doing something to provoke this? I've submitted it via Feedback Assistant (FB23642313). Thanks Jon P.S. Full stack trace attached for the exception thrown when the assertion fails for NSStatusBarWindow NSInternalInconsistencyException stack trace.txt
Topic: UI Frameworks SubTopic: AppKit
9
3
1.2k
1w
Full keyboard access blocks NSTextField from being the initial first responder in NSPopover
I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.
0
0
135
1w
ManipulationComponent + Warning messages in RealityView
Hi guys! I wanted to study this new ManipulationComponent(), but I keep getting a warning that I don’t understand, even in a very simple scenario. i don't have any collisions just binding the Manipulation the warning message is : ** Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies.** RealityView { content, attachments in if let loadedModel = try? await Entity(named: "cloud_glb", in: realityKitContentBundle) { content.add(loadedModel) loadedModel.components.set(ManipulationComponent()) } Thanks !
4
0
661
1w
visionOS 26: is there any way yet to distinguish a user-initiated window close from system out-of-FoV backgrounding
This was confirmed as a framework gap in an accepted answer from an Apple Vision Pro engineer in June 2024 (https://developer.apple.com/forums/thread/758014?answerId=792769022#792769022): .background fires identically whether the user taps a window's close button or the system backgrounds a window that's been out of the field of view for ~61 seconds, and there's no app-visible signal that distinguishes the two. The recommendation at the time was to use a gesture/affordance to reopen the window, and to file an enhancement request. Two years on, with the window-management APIs that have shipped since, I want to confirm whether the situation has changed as of visionOS 26. My case: VisionBlazer, a native spatial 3D creation tool (TestFlight beta, August 2026 launch). Users routinely work with several SwiftUI WindowGroup tool windows open at once — drawing tools, materials, timeline, properties, lighting — parked spatially around an ImmersiveSpace. Parking a window behind or beside you is core to the workflow. The app should terminate when the user closes the primary window, but must not terminate when a secondary window (or the primary) is simply parked out of view. What I've verified on-device (visionOS 26.5): scenePhase == .background fires identically for a user close tap and for the ~61s out-of-FoV backgrounding (SurfBoard: "…is out of FOV after 60.99 seconds. Backgrounding"). The phase sequence (active → inactive → background) and timing (~0.2–0.4s gap) are indistinguishable between the two cases. scenePhase on visionOS reflects visibility, not focus — a parked window stays .active while the user edits elsewhere, until the out-of-FoV timer fires. The session identifier reachable from the window's view hierarchy (view.window!.windowScene.session.persistentIdentifier) never matches the identifier reported by application(_:didDiscardSceneSessions:) or UIScene.didDisconnectNotification for that same close. The view-visible session stays in UIApplication.shared.openSessions indefinitely after the close. Those disconnect/discard callbacks arrive ~10–15s late and only ever carry foreign session identifiers, so they can't be attributed to a specific window. Stale-session discards from prior launches pollute the signal further. onDisappear does not fire on user close. Five strategies tried, all failed: (1) scene-object identity captured at didMoveToWindow; (2) session.persistentIdentifier matching against openSessions; (3) live re-capture of scene/session from the view hierarchy on every lifecycle change; (4) temporal correlation of didEnterBackground/didDisconnect; (5) a focus-recency heuristic on scenePhase transitions. All fail on the identifier mismatch and the visibility-not-focus semantics above. Questions: As of visionOS 26, is there now any supported way to detect that the user intentionally closed a specific window, distinct from system backgrounding? Is there a SwiftUI or scene-delegate callback tied to a window's own scene that fires only on user close? Is there a dismissalReason (or equivalent) anywhere on the close path? If none of the above exists, is an explicit in-app Quit button still the intended pattern for "quit when the main window is closed"? I have a focused test project reproducing all of this and can link it. Thanks.
6
0
945
1w
Mission Control Window Management update
Dear Apple, I am sending feedback regarding the desktop management of macOS to improve the user experience. Mission Control currently only has a “+” button to the right, meaning that all new desktops are forced to the right side of the line. Adding an identical “+” button to the left will increase ease of using the OS, as I don’t necessarily need every new desktop to be on the right side. This will increase usability and make using desktops significantly easier than manually dragging them into the needed positions every time I add a desktop. Another thing is that when I maximize apps, all desktops go to the left by one spot. There should be a setting where you can control where desktops go when maximizing screens, either you want every desktop to go to the right or the left. This makes things easier as sometimes I have my main app on the right, with all the multi-tasking on the left. If desktops move to the right instead of the left, no open apps will be interfered with. (Please put this setting in the “Desktop and Dock” section). I have been using macOS for a year now, and those details were quite clear. Please consider this as a software update for over 100 million Macbook users, increasing usability without changing the OS so much people barely know how to use it. I have been concentrating significantly on macOS lately, noticing an upgrade followed by another, and is how I noticed this. Please consider this a fresh start for my feedback. I apologize for my previous un-trained replies. I am not a trained professional, but I genuinely care about improving the user experience and wanted to share these layout ideas. I promise to keep my interactions respectful of the forum guidelines from now on. May these desktop management ideas be considered? Thanks, Alyaman
Topic: UI Frameworks SubTopic: General
1
0
255
1w
macOS 27 Catalyst: WKWebView text entry impossible, endless keyboard input-view focus loop
Filed as FB24092251. On macOS 27.0 beta (26A5388g), clicking into any text input inside a WKWebView in a Mac Catalyst app makes focus oscillate forever and typing does nothing. CPU pegs at 100% while the editor is focused. The same binary works fine on macOS 26. The DOM element never actually loses focus. Only the window does: window focus -> activeElement=TEXTAREA.inputarea JS focus -> activeElement=TEXTAREA.inputarea window blur -> activeElement=TEXTAREA.inputarea <- window loses key status JS blur -> activeElement=TEXTAREA.inputarea <- element did not ...repeats indefinitely... Pausing during the loop shows why. Focusing the element sends WebKit into UIKit's software-keyboard machinery, on a platform that has no software keyboard: -[UIKeyboardSceneDelegate containerWindowForViewService:] -[UIKeyboardSceneDelegate _setKeyWindowSceneInputViews:animationStyle:] -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] -[WKContentView(WKInteraction) _continueElementDidFocus:...] -[WKContentView(WKInteraction) _elementDidFocus:...] WebKit::WebPageProxy::elementDidFocus(...) Building that container steals key status from the web view. First responder ends up on the enclosing _UIHostingView, so key presses are delivered there and immediately cancelled: pressesBegan: [...], focusedItem: monacoEditor firstResponder at keypress: _UIHostingView<...> pressesCancelled: [...] The catch: -becomeFirstResponder cannot be used to recover, because it is the trigger. Calling it re-enters _elementDidFocus and re-arms the loop permanently. So there is no app-side way back — the only API that reclaims the keyboard is the one that breaks it. Minimal repro is just a WKWebView in a UIViewRepresentable inside a SwiftUI hierarchy, with any focusable . No Monaco needed. Partial mitigation, if you hit this: do not echo focus/blur commands back at the web view in response to its own focus events, and treat a blur where document.hasFocus() is false but activeElement is unchanged as a window-level blur rather than an editing-ended event. That stops the runaway loop and keeps your focus state correct — but it does not restore typing. Has anyone found a way to get first responder back to the web view without calling -becomeFirstResponder? Or a way to stop the keyboard scene delegate engaging on Catalyst in the first place? If you can reproduce on 27 beta, please file a duplicate referencing FB24092251.
1
0
219
1w
Intermittent UIHostingController layout regression after app launch on iPadOS 27 beta 4
On iPadOS 27.0 beta 4, SwiftUI views hosted inside UIKit-managed containers/overlays can be laid out incorrectly. The same app and same code work correctly on iPadOS 26.x release versions. One visible example is the app’s About dialog. The dialog is implemented as a UIKit UIViewController presented with UIModalPresentationFormSheet. Inside that controller, a UIHostingController is added as a child view controller, and the hosting controller’s view is constrained to all four edges of the parent view. The SwiftUI root view is a VStack containing the app icon, app name, version, text, links, and buttons. Expected behavior: The SwiftUI content should be vertically centered inside the form sheet. The app icon should appear above the app title, followed by the version, text, links, and buttons. This is the behavior on iPadOS 26.x. Actual behavior on iPadOS 27.0 beta 4: When the About dialog is opened immediately after launching the app, this issue occurs intermittently. The form sheet itself appears, but the SwiftUI content is shifted upward. The app icon is missing or clipped, the title starts too close to the top edge of the sheet, and a large empty area appears at the bottom of the sheet. This is not limited to the About dialog. Similar layout issues can also appear in other SwiftUI-hosted UI surfaces in the app. The issue also appears to be affected by system-level UI changes: If I put the app into windowed mode and resize the whole app window, the layout inside the dialog recovers and becomes correct. The issue only occurs with some probability the first time this dialog is opened after launching the app. After the layout is restored by resizing the app window, the issue does not appear again as long as the app process is not terminated. This suggests the problem may be related to an incorrect initial layout pass, cached geometry, trait/safe-area propagation, or UIHostingController layout invalidation after the app/window scene is first created. Environment: Device: iPad OS with issue: iPadOS 27.0 beta 4 OS without issue: iPadOS 26.x release App: VoidLink - Extreme UI stack: UIKit containers/overlays hosting SwiftUI through UIHostingController Relevant code: AboutView.swift: https://github.com/The-Fried-Fish/VoidLink-previously-moonlight-zwm/blob/Integration/VoidLink/AboutView.swift AboutViewController.swift: https://github.com/The-Fried-Fish/VoidLink-previously-moonlight-zwm/blob/Integration/VoidLink/AboutViewController.swift Attachments: IMG_0291.PNG: correct layout on iPadOS 26.x IMG_0292.PNG: incorrect layout on iPadOS 27.0 beta 4
1
0
363
1w
ViewAttachmentComponent Resolution Low After Moving Into Frame
If a ViewAttachmentComponent moves into frame, it is low resolution until something changes the view while it is in frame. Video demonstrating the behavior: https://youtu.be/KXEFFiAnv1s I am on visionOS 27 beta 4. This did not occur when I was on visionOS 26.5. Also using Xcode 27.0 beta 4 and macOS 27.0 beta 4. To reproduce, have a ViewAttachmentComponent in an immersive space, look away, then look back, and it'll be low resolution. Anything which would change the view while it's in frame will then cause it to update in full resolution. Screenshot of low-resolution view after it moves back into frame from being out of frame: Screenshot after updating the view, making it high-resolution again: I've submitted feedback as FB24116473.
0
0
312
1w
Is it normal that mounted @Query cause every object of that type to re-render, even after unrelated saves?
I have a SwiftUI + SwiftData app where scrolling became very slow, and I've traced it to something about @Query I didn't expect. The app was running save for each lazy list item appearing in viewport (a separate bug, but it did highlight the problem), which made the whole list re-render on each save. After tracing why this happens I have discovered that it is because another model watched in the list parent is invalidated after every save, and the problem was that this another model has @Query in a separate view (sidebar), removing that @Query fixed the problem. Here is a minimal reproduction of this https://github.com/aytigra/QueryRefaultRepro I wonder if it is a bug or an expected behavior?
0
0
474
1w
How to achieve the UIEditMenuInteraction (?) for Link Preview used in iOS 27 Messages
I've been using the iOS 27 beta and noticed in Messages app that the link presentation is now customisable. Upon tapping on the link it opens (what I assume is) an edit menu interaction, which allows customising which metadata is shown. I've seen some links offer more customisation than others, presumably based on available metadata. There's also an option in the menu to convert to a text link, and when highlighting a link in text there's an option to "show link preview" which converts it to an LPLinkView. I've been wondering for a while now if it was possible to add a similar feature to my own app, allowing the user more control over the link previews. How can I achieve similar? Especially "Customise Link" sheet seen in the middle two screenshots?
0
0
533
1w
X button disappeared on iPadOS 26.4 in MFMailComposeViewController
I’m using MFMailComposeViewController to send emails from my app. Since updating to iPadOS 26.4, there is no way to cancel the mail composer because the “X” button in the top-left corner has disappeared. On iPhone with iOS 26.4, everything still seems to work as expected. Is this a known issue, or am I missing something? Has anyone else experienced this, or found a workaround?
Topic: UI Frameworks SubTopic: UIKit
11
1
2.1k
1w
Xcode 26.3 Simulator renders SwiftUI app only inside a rounded rectangle instead of full screen
Hi everyone, I’m seeing a strange rendering issue in Xcode 26.3 that seems to affect only the iOS Simulator. Environment: Xcode 26.3 SwiftUI app Reproduces in Simulator only Reproduces across multiple simulator device models My code is just a minimal example Expected behavior: The view should fill the entire screen. Actual behavior: The app content is rendered only inside a centered rounded rectangle/card-like area, with black space around it, as if the app canvas is being clipped incorrectly. Minimal reproduction: import SwiftUI @main struct LayoutShowcaseApp: App { var body: some Scene { WindowGroup { Color.green.ignoresSafeArea() } } } I also tried wrapping it in a ZStack and using: .frame(maxWidth: .infinity, maxHeight: .infinity) .background(...) .ignoresSafeArea() but the result is the same. What I already tried: Clean Build Folder Switching simulator device models Resetting simulator content/settings Rebuilding from a fresh minimal SwiftUI project Since this happens with such a minimal example, it looks more like a Simulator/runtime rendering bug than a SwiftUI layout issue. Has anyone else seen this on Xcode 26.3? If yes, did you find any workaround? Thanks.
Topic: UI Frameworks SubTopic: SwiftUI
1
0
402
1w
How do I have the NSToolbar "floating" on top of content scrollview on macOS Tahoe?
I have this MWE right here -- it has a toolbar with a random action on it, in addition to a scroll view as the content of the window, with random labels attached inside. Since the redeisgn of the NSToolbar stuff in Tahoe, I expect the share button be able to "float" on top of the scrolled out content as shown as the first image at https://developer.apple.com/documentation/TechnologyOverviews/adopting-liquid-glass. #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSToolbarDelegate> @property (strong) NSWindow *window; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { NSRect frame = NSMakeRect(100, 100, 600, 400); self.window = [[NSWindow alloc] initWithContentRect:frame styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable | NSWindowStyleMaskMiniaturizable) backing:NSBackingStoreBuffered defer:NO]; [self.window setTitle:@"Scroll View + Toolbar Demo"]; NSToolbar *toolbar = [[NSToolbar alloc] initWithIdentifier:@"MainToolbar"]; toolbar.displayMode = NSToolbarDisplayModeIconAndLabel; toolbar.delegate = self; [self.window setToolbar:toolbar]; NSScrollView *scrollView = [[NSScrollView alloc] initWithFrame:self.window.contentView.bounds]; [scrollView setAutoresizingMask:(NSViewWidthSizable | NSViewHeightSizable)]; [scrollView setHasVerticalScroller:YES]; [scrollView setHasHorizontalScroller:YES]; NSView *documentView = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 1000, 1000)]; for (int i = 0; i < 10; i++) { NSTextField *label = [[NSTextField alloc] initWithFrame:NSMakeRect(50, 950 - i*80, 400, 40)]; [label setStringValue:[NSString stringWithFormat:@"Sample Label #%d", i + 1]]; [label setBezeled:NO]; [label setDrawsBackground:NO]; [label setEditable:NO]; [label setSelectable:NO]; [documentView addSubview:label]; } [scrollView setDocumentView:documentView]; [self.window setContentView:scrollView]; [self.window makeKeyAndOrderFront:nil]; } - (NSArray<NSToolbarItemIdentifier> *)toolbarAllowedItemIdentifiers:(NSToolbar *)toolbar { return @[NSToolbarFlexibleSpaceItemIdentifier, @"ShareItem"]; } - (NSArray<NSToolbarItemIdentifier> *)toolbarDefaultItemIdentifiers:(NSToolbar *)toolbar { return @[@"ShareItem"]; } - (NSToolbarItem *)toolbar:(NSToolbar *)toolbar itemForItemIdentifier:(NSToolbarItemIdentifier)itemIdentifier willBeInsertedIntoToolbar:(BOOL)flag { if ([itemIdentifier isEqualToString:@"ShareItem"]) { NSToolbarItem *shareItem = [[NSToolbarItem alloc] initWithItemIdentifier:itemIdentifier]; shareItem.toolTip = @"Share this content"; shareItem.image = [NSImage imageNamed:NSImageNameShareTemplate]; shareItem.target = self; shareItem.action = @selector(shareAction:); return shareItem; } return nil; } - (void)shareAction:(id)sender { NSLog(@"Share button clicked!"); // Here you could present a sharing service picker NSSharingServicePicker *picker = [[NSSharingServicePicker alloc] initWithItems:@[@"Hello, world!"]]; [picker showRelativeToRect:[sender view].bounds ofView:[sender view] preferredEdge:NSRectEdgeMinY]; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app run]; } return EXIT_SUCCESS; } But it doesn't and produces this image: https://imgur.com/a/kA7MzIe I've tried to set various settings to make the top bar transparent, but all it does is that it makes it completely opaque instead. How can I make the share button float on top of the content? P.S. the app is a single-file app, compile it with clang -fobjc-arc -framework Cocoa -o ScrollApp toolbar.m
Topic: UI Frameworks SubTopic: AppKit
Replies
2
Boosts
0
Views
296
Activity
1w
What does it take for an app Window menu list to display the new items like Move & Resize?
Here's the result of a blank app from Xcode: https://imgur.com/a/1hMmwbO now there's only 3 items in the storyboard configuration: https://imgur.com/a/iGWWQE7 So I try to replicate that in code (some of this reproducer was generated by ChatGPT however the same issue I'm descrbing has been hit when using Python to objc bridges to construct the GUI) by specifying these 3 actions appropriately and see if the rest pops up. The code below changes the activation policy so that when I run ./a.out from the terminal it doesn't show as a window of Terminal but a separate app #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate> @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { // Build main menu NSMenu *mainMenu = [[NSMenu alloc] initWithTitle:@"MainMenu"]; // --- App menu with Quit --- NSMenuItem *appMenuItem = [[NSMenuItem alloc] init]; NSMenu *appMenu = [[NSMenu alloc] initWithTitle:@"App"]; NSMenuItem *quitItem = [[NSMenuItem alloc] initWithTitle:@"Quit" action:@selector(terminate:) keyEquivalent:@"q"]; [appMenu addItem:quitItem]; [appMenuItem setSubmenu:appMenu]; [mainMenu addItem:appMenuItem]; // --- Window menu with only Minimize, Zoom, Bring All to Front --- NSMenuItem *windowMenuItem = [[NSMenuItem alloc] initWithTitle:@"Window" action:NULL keyEquivalent:@""]; NSMenu *windowMenu = [[NSMenu alloc] initWithTitle:@"Window"]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Minimize" action:@selector(performMiniaturize:) keyEquivalent:@"m"]]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Zoom" action:@selector(performZoom:) keyEquivalent:@""]]; [windowMenu addItem:[NSMenuItem separatorItem]]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Bring All to Front" action:@selector(arrangeInFront:) keyEquivalent:@""]]; [windowMenuItem setSubmenu:windowMenu]; [mainMenu addItem:windowMenuItem]; [NSApp setMainMenu:mainMenu]; // Optional demo window (remove if you want zero windows) NSWindow *w = [[NSWindow alloc] initWithContentRect:NSMakeRect(200,200,400,200) styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable | NSWindowStyleMaskMiniaturizable) backing:NSBackingStoreBuffered defer:NO]; [w setTitle:@"Demo"]; [w makeKeyAndOrderFront:nil]; [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular]; } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { AppDelegate *delegate = [AppDelegate new]; [NSApplication sharedApplication]; [NSApp setDelegate:delegate]; return NSApplicationMain(argc, argv); } } Now, I only see 3 items that's literally specified https://imgur.com/a/LylRsaJ So, what allows interface builder to auto-add these extra items as opposed by creating it in code? Is there something in this reproducer of the Window menu that is missing that needs to make it happen programatically? Thanks! All tests done on macOS Tahoe
Topic: UI Frameworks SubTopic: AppKit
Replies
3
Boosts
0
Views
287
Activity
1w
How to make a layout like Android's StaggeredGridLayoutManager in SwiftUI
Hi everyone In SwiftUI, are there any good solutions to achieve a layout similar to Android's StaggeredGridLayoutManager for displaying a large amount of data?
Replies
1
Boosts
0
Views
129
Activity
1w
Public API to overlay or hide the system keyboard while preserving its exact state?
I am building an iOS text composer with an attachment panel. When its UITextField is first responder and the system keyboard is visible, tapping the attachment button should present a panel that can extend into the region occupied by the keyboard. When the panel closes, the user should return to the same keyboard state without a visible dismissal and re-presentation. The required continuity is: The same UITextField remains first responder. The active input mode remains alphabet, 123, or Emoji. Emoji preserves its selected category, search state, and scroll position. The composer remains positioned above the keyboard throughout the transition. I have investigated the public UIKit approaches: A normal app-window overlay cannot render above the remotely hosted system keyboard. inputAccessoryView remains in the accessory region and cannot cover the keycaps. Resigning first responder visibly dismisses the keyboard and loses continuity. Assigning a custom inputView to the same UITextField and calling reloadInputViews() publicly replaces the keyboard. However, restoring inputView to nil reconstructs the system keyboard and does not preserve the exact Emoji or keyplane state. UIKeyboardLayoutGuide provides geometry but no presentation control. Is there a supported public API or recommended architecture that allows an app to: Temporarily obscure or visually hide the system keyboard while keeping it active and preserving its state? Present app-owned content in a layer above the keyboard keycaps? Temporarily replace the keyboard and restore the same mode, Emoji category, and scroll position? If these are unsupported, what is Apple's recommended way to create an attachment panel that visually occupies the keyboard region while maintaining input continuity? This occurs on iOS 26.x in Simulator and on a physical iPhone using a UIKit-backed text field inside a SwiftUI interface. I am specifically looking for a public API solution and do not want to access private keyboard windows or views.
Replies
0
Boosts
0
Views
99
Activity
1w
NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
Is anyone else getting these assertion crashes on developer beta 3 of Golden Gate? I've gotten more than a dozen crash logs from users running macOS 27 (26A5378j) that all look like this: assertion failed: '<NSRemoteView: 0x79cb366700 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x79cbef7480> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line 4221 of file /AppleInternal/Library/BuildRoots/4~CSuOugB1YCxzYMPRWEumvvfCTNtf98eItTmsbJU/Library/Caches/com.apple.xbs/TemporaryDirectory.N8fh9t/Sources/ViewBridge/NSRemoteView.m but with various windows from my app after "notified of". They're getting thrown when one of my windows is made frontmost, either using NSWindow.orderFrontRegardless or NSWindow.makeKeyAndOrderFront, or (in the case above) when my status item is shown. It's intermittent - I've been unable to reproduce it so far - but definitely happening repeatedly based on my Sentry crash logging. Is this a bug in Golden Gate b3, or am I doing something to provoke this? I've submitted it via Feedback Assistant (FB23642313). Thanks Jon P.S. Full stack trace attached for the exception thrown when the assertion fails for NSStatusBarWindow NSInternalInconsistencyException stack trace.txt
Topic: UI Frameworks SubTopic: AppKit
Replies
9
Boosts
3
Views
1.2k
Activity
1w
Full keyboard access blocks NSTextField from being the initial first responder in NSPopover
I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.
Replies
0
Boosts
0
Views
135
Activity
1w
ManipulationComponent + Warning messages in RealityView
Hi guys! I wanted to study this new ManipulationComponent(), but I keep getting a warning that I don’t understand, even in a very simple scenario. i don't have any collisions just binding the Manipulation the warning message is : ** Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies.** RealityView { content, attachments in if let loadedModel = try? await Entity(named: "cloud_glb", in: realityKitContentBundle) { content.add(loadedModel) loadedModel.components.set(ManipulationComponent()) } Thanks !
Replies
4
Boosts
0
Views
661
Activity
1w
visionOS 26: is there any way yet to distinguish a user-initiated window close from system out-of-FoV backgrounding
This was confirmed as a framework gap in an accepted answer from an Apple Vision Pro engineer in June 2024 (https://developer.apple.com/forums/thread/758014?answerId=792769022#792769022): .background fires identically whether the user taps a window's close button or the system backgrounds a window that's been out of the field of view for ~61 seconds, and there's no app-visible signal that distinguishes the two. The recommendation at the time was to use a gesture/affordance to reopen the window, and to file an enhancement request. Two years on, with the window-management APIs that have shipped since, I want to confirm whether the situation has changed as of visionOS 26. My case: VisionBlazer, a native spatial 3D creation tool (TestFlight beta, August 2026 launch). Users routinely work with several SwiftUI WindowGroup tool windows open at once — drawing tools, materials, timeline, properties, lighting — parked spatially around an ImmersiveSpace. Parking a window behind or beside you is core to the workflow. The app should terminate when the user closes the primary window, but must not terminate when a secondary window (or the primary) is simply parked out of view. What I've verified on-device (visionOS 26.5): scenePhase == .background fires identically for a user close tap and for the ~61s out-of-FoV backgrounding (SurfBoard: "…is out of FOV after 60.99 seconds. Backgrounding"). The phase sequence (active → inactive → background) and timing (~0.2–0.4s gap) are indistinguishable between the two cases. scenePhase on visionOS reflects visibility, not focus — a parked window stays .active while the user edits elsewhere, until the out-of-FoV timer fires. The session identifier reachable from the window's view hierarchy (view.window!.windowScene.session.persistentIdentifier) never matches the identifier reported by application(_:didDiscardSceneSessions:) or UIScene.didDisconnectNotification for that same close. The view-visible session stays in UIApplication.shared.openSessions indefinitely after the close. Those disconnect/discard callbacks arrive ~10–15s late and only ever carry foreign session identifiers, so they can't be attributed to a specific window. Stale-session discards from prior launches pollute the signal further. onDisappear does not fire on user close. Five strategies tried, all failed: (1) scene-object identity captured at didMoveToWindow; (2) session.persistentIdentifier matching against openSessions; (3) live re-capture of scene/session from the view hierarchy on every lifecycle change; (4) temporal correlation of didEnterBackground/didDisconnect; (5) a focus-recency heuristic on scenePhase transitions. All fail on the identifier mismatch and the visibility-not-focus semantics above. Questions: As of visionOS 26, is there now any supported way to detect that the user intentionally closed a specific window, distinct from system backgrounding? Is there a SwiftUI or scene-delegate callback tied to a window's own scene that fires only on user close? Is there a dismissalReason (or equivalent) anywhere on the close path? If none of the above exists, is an explicit in-app Quit button still the intended pattern for "quit when the main window is closed"? I have a focused test project reproducing all of this and can link it. Thanks.
Replies
6
Boosts
0
Views
945
Activity
1w
Mission Control Window Management update
Dear Apple, I am sending feedback regarding the desktop management of macOS to improve the user experience. Mission Control currently only has a “+” button to the right, meaning that all new desktops are forced to the right side of the line. Adding an identical “+” button to the left will increase ease of using the OS, as I don’t necessarily need every new desktop to be on the right side. This will increase usability and make using desktops significantly easier than manually dragging them into the needed positions every time I add a desktop. Another thing is that when I maximize apps, all desktops go to the left by one spot. There should be a setting where you can control where desktops go when maximizing screens, either you want every desktop to go to the right or the left. This makes things easier as sometimes I have my main app on the right, with all the multi-tasking on the left. If desktops move to the right instead of the left, no open apps will be interfered with. (Please put this setting in the “Desktop and Dock” section). I have been using macOS for a year now, and those details were quite clear. Please consider this as a software update for over 100 million Macbook users, increasing usability without changing the OS so much people barely know how to use it. I have been concentrating significantly on macOS lately, noticing an upgrade followed by another, and is how I noticed this. Please consider this a fresh start for my feedback. I apologize for my previous un-trained replies. I am not a trained professional, but I genuinely care about improving the user experience and wanted to share these layout ideas. I promise to keep my interactions respectful of the forum guidelines from now on. May these desktop management ideas be considered? Thanks, Alyaman
Topic: UI Frameworks SubTopic: General
Replies
1
Boosts
0
Views
255
Activity
1w
[API] cannot add handler to 3 from 3 - dropping New XCode error!
while resizing screen on mac, start getting this weird error [API] cannot add handler to 3 from 3 - dropping All lazyVgrids fail to show afterwards then app crashes if you keep resizing. This error started with macOS Ventura. Any help much appreciated.
Replies
6
Boosts
5
Views
3.2k
Activity
1w
macOS 27 Catalyst: WKWebView text entry impossible, endless keyboard input-view focus loop
Filed as FB24092251. On macOS 27.0 beta (26A5388g), clicking into any text input inside a WKWebView in a Mac Catalyst app makes focus oscillate forever and typing does nothing. CPU pegs at 100% while the editor is focused. The same binary works fine on macOS 26. The DOM element never actually loses focus. Only the window does: window focus -> activeElement=TEXTAREA.inputarea JS focus -> activeElement=TEXTAREA.inputarea window blur -> activeElement=TEXTAREA.inputarea <- window loses key status JS blur -> activeElement=TEXTAREA.inputarea <- element did not ...repeats indefinitely... Pausing during the loop shows why. Focusing the element sends WebKit into UIKit's software-keyboard machinery, on a platform that has no software keyboard: -[UIKeyboardSceneDelegate containerWindowForViewService:] -[UIKeyboardSceneDelegate _setKeyWindowSceneInputViews:animationStyle:] -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] -[WKContentView(WKInteraction) _continueElementDidFocus:...] -[WKContentView(WKInteraction) _elementDidFocus:...] WebKit::WebPageProxy::elementDidFocus(...) Building that container steals key status from the web view. First responder ends up on the enclosing _UIHostingView, so key presses are delivered there and immediately cancelled: pressesBegan: [...], focusedItem: monacoEditor firstResponder at keypress: _UIHostingView<...> pressesCancelled: [...] The catch: -becomeFirstResponder cannot be used to recover, because it is the trigger. Calling it re-enters _elementDidFocus and re-arms the loop permanently. So there is no app-side way back — the only API that reclaims the keyboard is the one that breaks it. Minimal repro is just a WKWebView in a UIViewRepresentable inside a SwiftUI hierarchy, with any focusable . No Monaco needed. Partial mitigation, if you hit this: do not echo focus/blur commands back at the web view in response to its own focus events, and treat a blur where document.hasFocus() is false but activeElement is unchanged as a window-level blur rather than an editing-ended event. That stops the runaway loop and keeps your focus state correct — but it does not restore typing. Has anyone found a way to get first responder back to the web view without calling -becomeFirstResponder? Or a way to stop the keyboard scene delegate engaging on Catalyst in the first place? If you can reproduce on 27 beta, please file a duplicate referencing FB24092251.
Replies
1
Boosts
0
Views
219
Activity
1w
iOS 27 Beta UIBarButtonItem isHidden/isEnabled not working
I set the flag isHidden to true and isEnabled to false, but seems both of them are not working on iOS 27 public beta. They were working fine on iOS 26 and priors. Will next version iOS 27 fix that or do i need to use another alternative like completely remove the uibarbuttonitem from the navigation tool bar?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
0
Views
750
Activity
1w
Intermittent UIHostingController layout regression after app launch on iPadOS 27 beta 4
On iPadOS 27.0 beta 4, SwiftUI views hosted inside UIKit-managed containers/overlays can be laid out incorrectly. The same app and same code work correctly on iPadOS 26.x release versions. One visible example is the app’s About dialog. The dialog is implemented as a UIKit UIViewController presented with UIModalPresentationFormSheet. Inside that controller, a UIHostingController is added as a child view controller, and the hosting controller’s view is constrained to all four edges of the parent view. The SwiftUI root view is a VStack containing the app icon, app name, version, text, links, and buttons. Expected behavior: The SwiftUI content should be vertically centered inside the form sheet. The app icon should appear above the app title, followed by the version, text, links, and buttons. This is the behavior on iPadOS 26.x. Actual behavior on iPadOS 27.0 beta 4: When the About dialog is opened immediately after launching the app, this issue occurs intermittently. The form sheet itself appears, but the SwiftUI content is shifted upward. The app icon is missing or clipped, the title starts too close to the top edge of the sheet, and a large empty area appears at the bottom of the sheet. This is not limited to the About dialog. Similar layout issues can also appear in other SwiftUI-hosted UI surfaces in the app. The issue also appears to be affected by system-level UI changes: If I put the app into windowed mode and resize the whole app window, the layout inside the dialog recovers and becomes correct. The issue only occurs with some probability the first time this dialog is opened after launching the app. After the layout is restored by resizing the app window, the issue does not appear again as long as the app process is not terminated. This suggests the problem may be related to an incorrect initial layout pass, cached geometry, trait/safe-area propagation, or UIHostingController layout invalidation after the app/window scene is first created. Environment: Device: iPad OS with issue: iPadOS 27.0 beta 4 OS without issue: iPadOS 26.x release App: VoidLink - Extreme UI stack: UIKit containers/overlays hosting SwiftUI through UIHostingController Relevant code: AboutView.swift: https://github.com/The-Fried-Fish/VoidLink-previously-moonlight-zwm/blob/Integration/VoidLink/AboutView.swift AboutViewController.swift: https://github.com/The-Fried-Fish/VoidLink-previously-moonlight-zwm/blob/Integration/VoidLink/AboutViewController.swift Attachments: IMG_0291.PNG: correct layout on iPadOS 26.x IMG_0292.PNG: incorrect layout on iPadOS 27.0 beta 4
Replies
1
Boosts
0
Views
363
Activity
1w
ViewAttachmentComponent Resolution Low After Moving Into Frame
If a ViewAttachmentComponent moves into frame, it is low resolution until something changes the view while it is in frame. Video demonstrating the behavior: https://youtu.be/KXEFFiAnv1s I am on visionOS 27 beta 4. This did not occur when I was on visionOS 26.5. Also using Xcode 27.0 beta 4 and macOS 27.0 beta 4. To reproduce, have a ViewAttachmentComponent in an immersive space, look away, then look back, and it'll be low resolution. Anything which would change the view while it's in frame will then cause it to update in full resolution. Screenshot of low-resolution view after it moves back into frame from being out of frame: Screenshot after updating the view, making it high-resolution again: I've submitted feedback as FB24116473.
Replies
0
Boosts
0
Views
312
Activity
1w
Customizing the spell checker red dots
Is there a way you can customize the look of the red dots? to offset the position or the size of the dots etc.?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
1
Boosts
0
Views
130
Activity
1w
Is it normal that mounted @Query cause every object of that type to re-render, even after unrelated saves?
I have a SwiftUI + SwiftData app where scrolling became very slow, and I've traced it to something about @Query I didn't expect. The app was running save for each lazy list item appearing in viewport (a separate bug, but it did highlight the problem), which made the whole list re-render on each save. After tracing why this happens I have discovered that it is because another model watched in the list parent is invalidated after every save, and the problem was that this another model has @Query in a separate view (sidebar), removing that @Query fixed the problem. Here is a minimal reproduction of this https://github.com/aytigra/QueryRefaultRepro I wonder if it is a bug or an expected behavior?
Replies
0
Boosts
0
Views
474
Activity
1w
How to achieve the UIEditMenuInteraction (?) for Link Preview used in iOS 27 Messages
I've been using the iOS 27 beta and noticed in Messages app that the link presentation is now customisable. Upon tapping on the link it opens (what I assume is) an edit menu interaction, which allows customising which metadata is shown. I've seen some links offer more customisation than others, presumably based on available metadata. There's also an option in the menu to convert to a text link, and when highlighting a link in text there's an option to "show link preview" which converts it to an LPLinkView. I've been wondering for a while now if it was possible to add a similar feature to my own app, allowing the user more control over the link previews. How can I achieve similar? Especially "Customise Link" sheet seen in the middle two screenshots?
Replies
0
Boosts
0
Views
533
Activity
1w
Unable to display a static cells table together with a dynamic property one in a UITableViewController
I have inserted a Static cells table with configuration items and a normal dynamic table for displaying results in a UITableViewController in a StoryBoard. I get no error, but still just the header is shown, none of the navigation bar or any hint of the two tables, as you may see in the pictures:
Replies
0
Boosts
0
Views
123
Activity
1w
X button disappeared on iPadOS 26.4 in MFMailComposeViewController
I’m using MFMailComposeViewController to send emails from my app. Since updating to iPadOS 26.4, there is no way to cancel the mail composer because the “X” button in the top-left corner has disappeared. On iPhone with iOS 26.4, everything still seems to work as expected. Is this a known issue, or am I missing something? Has anyone else experienced this, or found a workaround?
Topic: UI Frameworks SubTopic: UIKit
Replies
11
Boosts
1
Views
2.1k
Activity
1w
Xcode 26.3 Simulator renders SwiftUI app only inside a rounded rectangle instead of full screen
Hi everyone, I’m seeing a strange rendering issue in Xcode 26.3 that seems to affect only the iOS Simulator. Environment: Xcode 26.3 SwiftUI app Reproduces in Simulator only Reproduces across multiple simulator device models My code is just a minimal example Expected behavior: The view should fill the entire screen. Actual behavior: The app content is rendered only inside a centered rounded rectangle/card-like area, with black space around it, as if the app canvas is being clipped incorrectly. Minimal reproduction: import SwiftUI @main struct LayoutShowcaseApp: App { var body: some Scene { WindowGroup { Color.green.ignoresSafeArea() } } } I also tried wrapping it in a ZStack and using: .frame(maxWidth: .infinity, maxHeight: .infinity) .background(...) .ignoresSafeArea() but the result is the same. What I already tried: Clean Build Folder Switching simulator device models Resetting simulator content/settings Rebuilding from a fresh minimal SwiftUI project Since this happens with such a minimal example, it looks more like a Simulator/runtime rendering bug than a SwiftUI layout issue. Has anyone else seen this on Xcode 26.3? If yes, did you find any workaround? Thanks.
Topic: UI Frameworks SubTopic: SwiftUI
Replies
1
Boosts
0
Views
402
Activity
1w