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

My macOS app is getting closed by the system
Hi, I've been trying to resolve an issue that my users are facing for about one year, but I haven't been able to so far. That's why I'm turning to you all for some ideas. Some of my users have noticed that my app suddenly exits. It runs in the background as a menu bar app, so when they go to use it, they realize it's no longer running. I've checked Crashlytics and asked users to check their Console app for crash reports, but there are none. The conclusion so far is that it's not a crash, but a silent termination. I haven't experienced this on my own machine, which makes it incredibly difficult to debug or identify the cause. Recently, I thought I'd pinned down the problem. My app was declaring: <key>NSSupportsSuddenTermination</key> <true/> Based on the documentation, this is intended to quickly terminate the app during logout or system shutdown, but I read it can also be triggered when the system needs resources. It seemed like the perfect root cause. However, even after turning it off, one of my users is still experiencing the problem. I'm officially running out of ideas. Does anyone have suggestions on what else I should check? My app currently declares: <key>LSUIElement</key> <true/> <key>NSSupportsAutomaticTermination</key> <false/> <key>NSSupportsSuddenTermination</key> <false/>
16
0
1.7k
2w
UITextField and UITextView abnormally popped up the network permission application interface
in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.
8
0
1.7k
2w
NavigationSplitView to go from 3 columns to 1 detailview and back?
Heya, Been struggling with getting a 3 column NavigationSplitView hide both the Sidebar and Content column to only show the Detail view and back to 3 columns in the same window. Basically applying the hide sidebar when pressing the toggle to both the sidebar and the content view. On iOS I could use .displaydetail but on macOs it seems impossible to do as one or the other shows up. I was able to force it to a width of 0 but that gives other issues such as the need to disable the animates otherwise things start flying. Any ideas on how to solve this? ideally we would have something as a double sidebar or a split view that does not extend that nav to all columns as thats a pain to deal with.
Topic: UI Frameworks SubTopic: General
0
0
312
2w
Animations become choppy in NSStatusItem when other window contains ScrollView
Feedback ID: FB23984230 This issue for some reason does not happen on my external 165 Hz display, but happens on my built-in MacBook Air display (60Hz). See attached example project: Contains two parts NSStatusItem with animation that triggers during ‘.onTapGesture()’ a window with ContentView that contains List and ScrollView while any ScrollView / List is in the view hierarchy in ContentView, triggering an animation in NSStatusItem (on a built-in MacBook display) is very choppy once removing ScrollView / List from view hierarchy from ContentView, animation in NSStatusItem is very smooth Project: Link macOS 26.5.2 (25F84)
1
0
414
2w
Recommended public approach for a glass-like effect on iOS 16–25.
Hello, we are updating our application to adopt the new Liquid Glass design introduced in iOS 26 with UIGlassEffect and UIGlassContainerEffect. Since our minimum supported version is iOS 16, we'd like to provide a visually similar effect on earlier iOS versions using only public APIs. Could you please advise the recommended App Store–compliant approach? In particular: is there any public API on iOS 16–25 that provides a system glass effect comparable to UIGlassEffect? If not, is the recommended fallback to use UIVisualEffectView with UI BlurEffect, plus custom borders and decoration? Would a custom implementation using Metal or Core Image, relying only on public APIs and application-owned content (for example, our chat wallpaper), be acceptable for App Store distribution if it is used solely to achieve a visually similar appearance? Are there any public APIs, sample code, or best practices that Apple recommends for approximating the Liquid Glass look on iOS 16–25 without private APIs? Our goal is to fully comply with App Store Review Guideline 2.5.1 and ensure the approach we choose follows Apple's recommendations. thank you We understand that responses on the Developer Forums do not constitute formal App Review pre-approval. We are specifically seeking guidance on the recommended use of public APIs and any known compliance concerns.
Topic: UI Frameworks SubTopic: UIKit
1
0
164
2w
NSSplitViewController-like inspector in custom view
From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?
1
0
206
2w
iOS 26 regression? `enablesReturnKeyAutomatically`'s disabled return key re-enables after switching keyboard planes (letters ⇄ numbers)
On iOS 26, the auto-disabled state of the return key driven by UITextInputTraits.enablesReturnKeyAutomatically is lost whenever the user switches keyboard planes (letters ⇄ numbers/symbols via the 123/ABC key). The key renders as enabled even though the text is still empty. Tapping it does nothing (the disable is still honored functionally), but the visual state is wrong until the next re-evaluation. This is a regression: iOS/iPadOS 17 behaves correctly (verified on iPadOS 17.7). It also reproduces in Safari's own address bar on iOS 26, so it does not appear to be app-specific. Minimal reproduction (stock UIKit, no custom code): let textField = UITextField() textField.enablesReturnKeyAutomatically = true // present it, focus it, leave it empty Focus the empty text field — the return key is disabled (correct). Tap 123 to switch to the numeric plane → the return key becomes enabled (incorrect — text is still empty). Type one character and delete it (still in the numeric plane) → the key becomes disabled again (correct). Tap ABC to switch back to the letters plane → the key becomes enabled again (incorrect). Safari reproduction (stock behavior, physical device): Open Safari on iOS 26, focus the address bar, and delete all text → the Go key disables (correct). Switch to the numeric plane → the Go key re-enables (incorrect). Tapping it gives haptic feedback but performs no action — the disable is still honored functionally; only the rendered state is wrong. Still in the numeric plane, type something (e.g. 123.456) and delete it all → the key correctly disables again (the hasText round-trip re-syncs it?) Switch back to the letters plane → the key wrongly re-enables again. The glitch triggers on plane switches in either direction. Additional observations (from our app's UITextFields — the same enablesReturnKeyAutomatically mechanism, but driven by a stricter text-validity rule than plain empty/non-empty, which makes the desync observable in more states): Two further workarounds restore the correct state after the glitch: switching the keyboard language (globe key), or changing the text and then tapping anywhere in the text field. A text change that does not flip the hasText state, without a follow-up tap, does not repaint the key. The pattern suggests that the keyboard rebuild triggered by switching planes defaults the return key to enabled without consulting the text state, and that the keyboard otherwise repaints the key only when the hasText answer transitions, or on input-session changes (tapping into the field, switching keyboard language). Environment: all reproductions and verifications were done on physical devices, not simulators — reproduced on an iPhone SE (iOS 26.5.2) and an iPad Pro 12.9" 4th gen (iPadOS 26.4.2); not reproducible on an iPad 6th gen (iPadOS 17.7.10). Is this a known issue, and is there a supported way to force the keyboard to re-evaluate the return key state after a plane switch?
0
1
405
2w
Is NavigationSplitView on macOS 27 broken?
On macOS 27 Beta 2, a simple NavigationSplitView example exhibits bizarre behaviour when the window is resized. The sidebar seemingly expands and collapses at random as the window is resized. The symptoms can be exacerbated with toolbar items. The sidebar appears to behave correctly when an inspector view is not present. Copy paste the code below into a new Xcode 27 project and run on macOS 27 and then resize the window: File -> New -> Project... -> App import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { Text("Content") } .inspector(isPresented: .constant(true)) { Text("Inspector") } } } Adding .frame or .inspectorColumnWidth to any of the Text views does not appear to fix the issues. macOS: 27.0 Beta (26A5368g) Xcode: 27.0 beta 2 (27A5209h)
Topic: UI Frameworks SubTopic: SwiftUI Tags:
3
1
350
2w
Should UISceneSizeRestriction be available on iPhone in iOS 27?
I'm trying to require a minimum size in my UIKit-based iOS app. I added code to set that using the UIWindowScene.sizeRestrictions property to my app's scene delegate as recommended in Apple's documentation: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let currentScene = (scene as? UIWindowScene) else { return } currentScene.sizeRestrictions?.minimumSize.height = 400 currentScene.sizeRestrictions?.minimumSize.width = 320 print("*** Size restrictions: \(String(describing: currentScene.sizeRestrictions))") ... } When I run that in the simulator for an iOS 27 iPhone, the size restrictions property prints out as being nil. That's surprising to me, since the documentation states that "The system provides this object only when it supports variable-sized windows.", and iPhone windows are resizable in iOS 27. If this is working as expected, is there another way to restrict the size of an iPhone window in iOS 27?
Topic: UI Frameworks SubTopic: UIKit
4
0
412
2w
iPhone 15 touchscreen intermittently becomes unresponsive while charging on iOS 26.6
Device: iPhone 15 Affected Versions: • iOS 26.5 • iOS 26.6 Summary While using my iPhone 15 during charging, the touchscreen occasionally becomes less responsive. Some touches are delayed or not recognized, making the device difficult to use. This issue was present on iOS 26.5 and still occurs after updating to iOS 26.6. Steps to Reproduce Connect the iPhone 15 to a charger. Unlock the device. Use the touchscreen while the phone is charging. Continue interacting with the screen for several minutes. Expected Result The touchscreen should remain fully responsive while charging. Actual Result The touchscreen occasionally becomes less responsive. Some taps or gestures are delayed or not recognized. The issue is intermittent but noticeable during charging. Frequency Intermittent. It does not happen every time, but it has occurred multiple times on both iOS 26.5 and iOS 26.6. Additional Information • Device: iPhone 15 • The issue has persisted across two stable iOS versions. • I have restarted the device and updated to the latest iOS version, but the issue still occurs. Has anyone else experienced this issue on iPhone 15 or other iPhone models? If so, does it occur with the Apple charger, a third-party charger, or both?
Topic: UI Frameworks SubTopic: UIKit
0
0
117
2w
Unexpected behavior in the interaction between LazyVStack and GeometryReader
Hello! I'd like to share a problem and its potential solution. Steps to reproduce: The issue can be reproduced with the following minimal example: struct TestConditionalScrollView: View { var body: some View { ConditionalScrollView { LazyVStack(spacing: 16) { Text("Text 1") .frame(height: 20) Text("Text 2") .frame(height: 30) Text("Text 3") .frame(height: 40) Text("Text 4") .frame(height: 500) Text("Text 5") .frame(height: 400) } .padding() } } } struct ConditionalScrollView<Content: View>: View { let content: Content init(@ViewBuilder content: () -> Content) { self.content = content() } @State private var contentHeight: CGFloat = 0 var body: some View { GeometryReader { geo in _ = print("Height: \(contentHeight)") return Group { if contentHeight > geo.size.height { ScrollView { measuredContent } } else { measuredContent } } } } private var measuredContent: some View { content .background( GeometryReader { geo in Color.clear .preference( key: ContentHeightKey.self, value: geo.size.height ) } ) .onPreferenceChange(ContentHeightKey.self) { contentHeight = $0 } } } struct ContentHeightKey: PreferenceKey { static var defaultValue: CGFloat = 0 static func reduce(value: inout CGFloat, nextValue: () -> CGFloat) { value = max(value, nextValue()) } } If we hit the breakpoint on the following line: _ = print("Height: (contentHeight)") the output looks like this: Problems observed Different values are reported, and it is unclear where those values originate from. The selected execution branch appears to change multiple times during the layout process. Possible reason As Rens Breur mentioned in the WWDC26 session "Dive into lazy stacks and scrolling with SwiftUI", LazyVStack relies on estimated layout information during certain phases of the layout process. I do not want to rely on or investigate SwiftUI's non-public implementation details, but I would like to explain what I believe is happening internally. To do that, let me show how the value reaches the GeometryReader closure: Step 1 In AttributeGraph, the GeometryReader<...> node and the LazyVStack node appear to be connected as shown below: Step 2 When the LazyVStack node is updated, the layout process appears to follow roughly this logic: `SwiftUICore 'SwiftUI.ForEachState.forEachItem:` n = number of cells to evaluate (initially n == 2) For first n cells: SwiftUICore`SwiftUI.ViewLayoutEngine.sizeThatFits(...) SwiftUI.EstimationCache.add(...) The total size of the lazy stack is then estimated: SwiftUI.LazyStack<...>.sizeThatFits(...): averageCellInfo = EstimationCache.average averageCellInfo.height = (firstCellHeight + secondCellHeight) / 2 totalHeight = firstCellHeight + secondCellHeight + averageCellInfo.height * remainingCells For the sample project, this produces an estimated height of 189. This value then appears to be cached inside a LazyLayoutComputer node. Step 3 When GeometryReader is updated and its closure executes, geo.size.height appears to be resolved from the cached value stored by LazyLayoutComputer. As a result, the reported height is: 189 + 32 (padding) = 221 Step 4 My assumption is that LazyVStack subsequently validates the estimated layout against the actual layout results. It seems to compare: The maximum Y position of the last list's cell The cached sizeThatFits value If those values differ sufficiently, the transaction is not committed and another layout pass is triggered. During a later pass, the real sizes become available and GeometryReader eventually reports the final correct value. If this interpretation is correct, the behavior shown in the logs would be expected: followed later by: Possible solution I could not find a public SwiftUI API that provides an accurate content size during the initial layout pass. I tried the following options: LazyVStack + GeometryReader LazyVStack + ViewThatFits LazyVStack + .scrollBounceBehavior(...) At the same time, SwiftUI itself appears to have information about layout validity. For example, the layout logs contain entries such as: placed(...) -> ... invalid: true This suggests that SwiftUI can determine when an estimated layout result is no longer valid and requires additional layout passes. If SwiftUI knows that the current layout is invalid, is there a way to access this information from within a GeometryReader closure or by some other means? Otherwise, clients may perform layout calculations based on invalid geometry, which can result in a broken dependent layout. Have a good day!
0
2
138
2w
Public generated asset symbols
Is there currently an option to make generated asset symbols public? If not, would it be possible to set the generated asset symbol so they are public. It's quite common to have an apps design system implemented in a separate framework. Currently the generate assets symbols is useless for this as they can't be access in the framework consumer. It would be great to add it to this new dropdown in Xcode 16 or along side it. (113704993 in the release notes) So the options would be Internal, Public and Off. This should affect the symbols, the extensions and the framework support. (There's a post on the swift forums about this as well here: https://forums.swift.org/t/generate-images-and-colors-inside-a-swift-package/65674)
7
35
3.0k
2w
Invalid parameter not satisfying: parentEnvironment != nil
Since the beta releases of iPadOS 26 we have been having some crashes about Invalid parameter not satisfying: parentEnvironment != nil We got to contact a couple of users and we found out that the crash appears when entering a screen in a UINavigationController with the iPad device connected to a Magic Keyboard. If the device is not connected to the keyboard then nothing happens and everything works ok. From our end we haven't managed to reproduce the crash so I am pasting part of the stacktrace if it can be of any help. 3 UIKitCore 0x19dfd2e14 -[_UIFocusContainerGuideFallbackItemsContainer initWithParentEnvironment:childItems:] + 224 (_UIFocusContainerGuideFallbackItemsContainer.m:23) 4 UIKitCore 0x19dae3108 -[_UIFocusContainerGuideImpl _searchForFocusRegionsInContext:] + 368 (_UIFocusGuideImpl.m:246) 5 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 6 UIKitCore 0x19db28900 -[_UIFocusMapSnapshot addRegionsInContainers:] + 160 (_UIFocusMapSnapshot.m:545) 7 UIKitCore 0x19d1313dc _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 632 (_UIFocusRegion.m:143) 8 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 9 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 10 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 11 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 12 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 13 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 14 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 15 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 16 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 17 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 18 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 19 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 20 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 21 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 22 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 23 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 24 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 25 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 26 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 27 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 28 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 29 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 30 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 31 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 32 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 33 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 34 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 35 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 36 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 37 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 38 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 39 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 40 UIKitCore 0x19d132e08 -[_UIFocusMapSnapshot _capture] + 424 (_UIFocusMapSnapshot.m:403) 41 UIKitCore 0x19db2675c -[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 476 (_UIFocusMapSnapshot.m:171) 42 UIKitCore 0x19d130dcc -[_UIFocusMapSnapshotter captureSnapshot] + 192 (_UIFocusMapSnapshotter.m:137) 43 UIKitCore 0x19db2045c -[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 136 (_UIFocusMap.m:168) 44 UIKitCore 0x19daffd2c -[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 140 (_UIFocusEnvironmentPreferenceEnumerator.m:313) 45 UIKitCore 0x19d127ab4 -[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 104 (_UIFocusEnvironmentPreferenceEnumerator.m:250) 46 UIKitCore 0x19d127394 -[_UIFocusEnvironmentPreferenceEnumerationContext preferredEnvironments] + 36 (_UIFocusEnvironmentPreferenceEnumerator.m:184) 47 UIKitCore 0x19d126e94 _enumeratePreferredFocusEnvironments + 400 (_UIFocusEnvironmentPreferenceEnumerator.m:503)
17
3
2.5k
2w
iOS27: Bar Marks in Swift Charts exhibit multiple severe issues
Bar Marks in Swift Charts exhibit multiple severe issues on iOS27. Tested on: iPad Pro M2, 13", iOS27 Beta 2. Feedback submitted: FB23354502 Charts form a visual backbone of our app, and these issues render the chart unusable. Without a fix, we will not be able to support iOS27. The issues we identified: (1) We arrange mutually exclusive BarMarks on a time-based x-axis, inside a vertically scrolling Chart. We use init(xStart:, xEnd:, yStart: yEnd:), creating a visual timeline. Everything renders correctly on iOS26. On iOS27, many BarMarks are missing. (2) When we tap on a BarMark, we increase its height so make it appear selected. This works nicely in iOS26. The BarMark does not animate or change size at all on iOS27. (3) We have an outline around a BarMark, as part of styling. This uses .annotation(position: .overlay). The outline renders nicely in iOS26. On iOS27, the outline is rendered as a small circle inside the BarMark.
3
1
346
2w
iOS 26 Beta bug - keyboard toolbar with bottom safe area inset
Hello! I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators. When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar. On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator. Here's a clip from a simulator: Here's the code that reproduced the bug I experienced in our app. #Preview { NavigationStack { ScrollView { TextField("", text: .constant("")) .padding() .background(Color.secondary) TextField("", text: .constant("")) .padding() .background(Color.green) } .padding() .safeAreaInset(edge: .bottom, content: { Color.red .frame(maxWidth: .infinity) .frame(height: 40) }) .toolbar { ToolbarItem(placement: .keyboard) { Button {} label: { Text("test") } } } } }
4
12
1.4k
2w
LazyVStack layout issue and potential fix
Hello! Over the last several months I've spent a lot of time investigating various LazyVStack issues. I’d like to share a one problem. Blank Screen + Cell trimming For reference, I've also submitted a Feedback Assistant report for this issue. Let's use the minimal example Copy the following code into a new project and run it: struct ScrollableLazyVStack: View { @StateObject private var viewModel: ScrollableLazyVStackViewModel init(count: Int) { self._viewModel = StateObject( wrappedValue: ScrollableLazyVStackViewModel(count: count) ) } var body: some View { ScrollView { LazyVStack(spacing: 8) { ForEach(viewModel.items, id: \.index) { CellView(by: $0) } } } .padding(.horizontal, 8) } } final class ScrollableLazyVStackViewModel: ObservableObject { @Published var items: [CellModel] = [] init(count: Int) { self.items = (0..<count).map { CellModel(index: $0) } } } private struct CellView: View { let item: CellModel init(by item: CellModel) { self.item = item } var body: some View { VStack(alignment: .leading, spacing: 2) { HStack(spacing: 4) { Image(systemName: item.icon) VStack(alignment: .leading, spacing: 4) { Text(item.title) .font(.body) Text(item.subtitle) .font(.caption) .foregroundColor(.secondary) if item.index < 100 { Text("Extra Text") .frame(height: 500) } } Spacer(minLength: .zero) } } .padding(16) .background( RoundedRectangle(cornerRadius: 14, style: .continuous) .fill(Color(.systemGray5)) ) } } struct CellModel: Hashable { private static let icons = [ "star.fill", "heart.fill", "bolt.fill", "flame.fill", "leaf.fill", "moon.fill", "cloud.fill", "paperplane.fill" ] private static let titles = [ "Random Item", "Sample Entry", "List Element", "Demo Cell", "Example Row", "Test Object" ] private static let subtitles = [ "Additional information", "Secondary description", "Some extra details", "Short explanation", "Supporting text" ] let index: Int let title: String let subtitle: String let icon: String init(index: Int) { self.index = index self.title = "\(index). \(Self.titles.randomElement()!)" self.subtitle = Self.subtitles.randomElement()! self.icon = Self.icons.randomElement()! } } Steps to Reproduce Fast-scroll to the bottom of the list using the scroll indicator. Then fast-scroll back to the top by dragging and holding the scroll indicator. Actual Results Blank Screen During fast scrolling, the visible content may temporarily disappear, resulting in a white screen. In most cases, the content eventually reappears. Truncated Cells After scrolling back toward the top, some of the topmost cells may become partially truncated. Possible Cause Blank Screen I do not want to rely on or investigate SwiftUI's non-public implementation details, but I would like to explain what I believe is happening internally. I'd like to assume what appears to be the underlying algorithm. When fast scrolling is active, the following sequence seems to occur: Step 1 SwiftUICore::resolveIndexAndPosition calculates an anchorIndex. For example: anchorIndex ≈ (scrollOffset / contentSize) * totalRows Step 2 SwiftUICore::resolveIndexAndPosition calculates an anchorPosition. For example: anchorPosition ≈ anchorIndex * (estimatedCellSize + spacing) Step 3 SwiftUI searches for the first visible cell and updates the position of the last laid-out cell (y_max_last_cell). Step 4 (the most important) The layout's correctness validation: Conceptually: d1 = abs(y_last_max - cachedSizeThatFits) d2 = 0.1 * min(y_last_max, cachedSizeThatFits) If: d1 < d2 -> the current CA::Transaction is committed. Otherwise: cachedSizeThatFits = sizeThatFits(...) and the process restarts from Step 1. If logging is enabled via: com.apple.SwiftUI.LazyStackLogging the behavior can be observed in the attached screenshot. Why this may fail The algorithm appears to assume that the estimated cell size does not change dramatically while fast scrolling. However, if the beginning of the list contains very tall cells and the remainder contains much smaller cells, the estimate may become significantly inaccurate. In that situation, comparing cachedSizeThatFits against the position of the last visible cell does not seem sufficient to guarantee a stable result, which may explain the temporary blank screen. Cell Truncation While scrolling upward, the following state can occur (see attached screenshot): SwiftUICore::resolveIndexAndPosition produces: anchorIndex = 2 anchorPosition = -562 The content is translated by 486.47, which corresponds approximately to: estimatedCellSize * 2 As a result, the effective anchor position becomes: -76.32 and the first 0...1 cells are truncated. Possible Solution Blank screen's problem My assumption is that the current layout validation criteria may not be sufficient in all cases. An alternative approach could be to always fill the visible region sequentially: top → bottom while scrolling downward bottom → top while scrolling upward With such a strategy, the layout result could potentially be committed immediately once the visible area is fully covered by realized cells. Cell's Truncation For the truncation issue, it seems that the current translation-based approach may be the source of the problem. One possible alternative would be to use a contentInset-based adjustment combined with clipping against the first visible cell's minY. In that model, negative inset values would not necessarily be problematic, and the visible content could remain correctly aligned. What do you think about this?
Topic: UI Frameworks SubTopic: SwiftUI
0
2
640
2w
Siri “Found in Apps” Messenger contact suggestion change into raw metadata
Hey guys, just after some possible answers. Why might’ve a Siri “Found in Apps” Messenger contact suggestion change into raw metadata and then create a second clean suggestion? Device: iPhone 14 iOS 17 Occurred sometime around 2023–2024 The issue involved one unsaved Siri Suggested Contact under “Found in Apps” from Facebook Messenger. The sequence was: A normal Siri suggestion appeared: Messenger: name redacted Months later, that same suggested contact no longer displayed normally. Instead, it showed what looked like raw metadata while still being labelled as Messenger: Messenger: HQ_UPhdmaAMnPegcbDmgaAMfH_PPf-PtSVXehqahXZOUgA;x-userid=PR:HQ_UPhdmaAMnPegcbDmgaAMfH_PPfPtSVXehqahXZOUgA;x-displayname=name redacted;x-teamidentifier=V9WTTPBFK9;x-bundleidentifiers=com.facebook.Messenger;x-apple:PR%3AHQ_UPhdmaAMnPegcbDmgaAMfH_PPfPtSVXehqahXZOUgA After this occurred, another Siri “Found in Apps” suggestion appeared underneath: Messenger: name redacted The new entry appeared normal, while the older entry continued to show the raw metadata string. I have only seen this happen with this one contact. Other Messenger Siri suggestions display normally. My questions: What would cause a Siri “Found in Apps” suggestion to display the underlying metadata/social profile fields instead of the normal app name and contact name? Why would iOS create another clean “Messenger: Name” suggestion afterwards instead of replacing the malformed entry? Is this likely related to Siri Suggestions indexing, Contacts framework social profile data, Core Spotlight, or Messenger’s app integration? Could this happen from stale cached data or a re-indexing event after an app/iOS update? I am mainly trying to understand the technical reason for the duplicate entries and the raw metadata display, and why it may have only affected this one Siri suggested contact, not the dozen others I had as well.
Topic: UI Frameworks SubTopic: AppKit
0
0
320
2w
EKEventEditViewController broken in iOS 27 Beta
UIKit app can not edit an event using EKEventEditViewController in iOS 27 Betas. The Done tick button at the top does not work after editing an event. Also does not work if EKEventViewController is first used to display the event. Then the "Edit" tapped to display the EKEventEditViewController. Anyone else seeing this?
3
0
396
2w
SwiftUI Button with Image view label has smaller hit target
[Also submitted as FB20213961] SwiftUI Button with a label: closure containing only an Image view has a smaller tap target than buttons created with a Label or the convenience initializer. The hit area shrinks to the image bounds instead of preserving the standard minimum tappable size. SCREEN RECORDING On a physical device, the difference is obvious—it’s easy to miss the button. Sometimes it even shows the button-tapped bounce animation but doesn’t trigger the action. SYSTEM INFO Xcode Version 26.0 (17A321) macOS 15.6.1 (24G90) iOS 26.0 (23A340) SAMPLE CODE The following snippet shows the difference in hit targets between the convenience initializer, a Label, and an Image (the latter two in a label: closure). // ✅ Hit target is entire button Button("Button 1", systemImage: "1.square.fill") { print("Button 1 tapped") } // ✅ Hit target is entire button Button { print("Button 2 tapped") } label: { Label("Button 2", systemImage: "2.square.fill") } // ❌ Hit target is smaller than button Button { print("Button 3 tapped") } label: { Image(systemName: "3.square.fill") }
7
4
868
2w
My macOS app is getting closed by the system
Hi, I've been trying to resolve an issue that my users are facing for about one year, but I haven't been able to so far. That's why I'm turning to you all for some ideas. Some of my users have noticed that my app suddenly exits. It runs in the background as a menu bar app, so when they go to use it, they realize it's no longer running. I've checked Crashlytics and asked users to check their Console app for crash reports, but there are none. The conclusion so far is that it's not a crash, but a silent termination. I haven't experienced this on my own machine, which makes it incredibly difficult to debug or identify the cause. Recently, I thought I'd pinned down the problem. My app was declaring: <key>NSSupportsSuddenTermination</key> <true/> Based on the documentation, this is intended to quickly terminate the app during logout or system shutdown, but I read it can also be triggered when the system needs resources. It seemed like the perfect root cause. However, even after turning it off, one of my users is still experiencing the problem. I'm officially running out of ideas. Does anyone have suggestions on what else I should check? My app currently declares: <key>LSUIElement</key> <true/> <key>NSSupportsAutomaticTermination</key> <false/> <key>NSSupportsSuddenTermination</key> <false/>
Replies
16
Boosts
0
Views
1.7k
Activity
2w
UITextField and UITextView abnormally popped up the network permission application interface
in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.
Replies
8
Boosts
0
Views
1.7k
Activity
2w
NavigationSplitView to go from 3 columns to 1 detailview and back?
Heya, Been struggling with getting a 3 column NavigationSplitView hide both the Sidebar and Content column to only show the Detail view and back to 3 columns in the same window. Basically applying the hide sidebar when pressing the toggle to both the sidebar and the content view. On iOS I could use .displaydetail but on macOs it seems impossible to do as one or the other shows up. I was able to force it to a width of 0 but that gives other issues such as the need to disable the animates otherwise things start flying. Any ideas on how to solve this? ideally we would have something as a double sidebar or a split view that does not extend that nav to all columns as thats a pain to deal with.
Topic: UI Frameworks SubTopic: General
Replies
0
Boosts
0
Views
312
Activity
2w
Animations become choppy in NSStatusItem when other window contains ScrollView
Feedback ID: FB23984230 This issue for some reason does not happen on my external 165 Hz display, but happens on my built-in MacBook Air display (60Hz). See attached example project: Contains two parts NSStatusItem with animation that triggers during ‘.onTapGesture()’ a window with ContentView that contains List and ScrollView while any ScrollView / List is in the view hierarchy in ContentView, triggering an animation in NSStatusItem (on a built-in MacBook display) is very choppy once removing ScrollView / List from view hierarchy from ContentView, animation in NSStatusItem is very smooth Project: Link macOS 26.5.2 (25F84)
Replies
1
Boosts
0
Views
414
Activity
2w
Recommended public approach for a glass-like effect on iOS 16–25.
Hello, we are updating our application to adopt the new Liquid Glass design introduced in iOS 26 with UIGlassEffect and UIGlassContainerEffect. Since our minimum supported version is iOS 16, we'd like to provide a visually similar effect on earlier iOS versions using only public APIs. Could you please advise the recommended App Store–compliant approach? In particular: is there any public API on iOS 16–25 that provides a system glass effect comparable to UIGlassEffect? If not, is the recommended fallback to use UIVisualEffectView with UI BlurEffect, plus custom borders and decoration? Would a custom implementation using Metal or Core Image, relying only on public APIs and application-owned content (for example, our chat wallpaper), be acceptable for App Store distribution if it is used solely to achieve a visually similar appearance? Are there any public APIs, sample code, or best practices that Apple recommends for approximating the Liquid Glass look on iOS 16–25 without private APIs? Our goal is to fully comply with App Store Review Guideline 2.5.1 and ensure the approach we choose follows Apple's recommendations. thank you We understand that responses on the Developer Forums do not constitute formal App Review pre-approval. We are specifically seeking guidance on the recommended use of public APIs and any known compliance concerns.
Topic: UI Frameworks SubTopic: UIKit
Replies
1
Boosts
0
Views
164
Activity
2w
NSSplitViewController-like inspector in custom view
From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?
Replies
1
Boosts
0
Views
206
Activity
2w
iOS 26 regression? `enablesReturnKeyAutomatically`'s disabled return key re-enables after switching keyboard planes (letters ⇄ numbers)
On iOS 26, the auto-disabled state of the return key driven by UITextInputTraits.enablesReturnKeyAutomatically is lost whenever the user switches keyboard planes (letters ⇄ numbers/symbols via the 123/ABC key). The key renders as enabled even though the text is still empty. Tapping it does nothing (the disable is still honored functionally), but the visual state is wrong until the next re-evaluation. This is a regression: iOS/iPadOS 17 behaves correctly (verified on iPadOS 17.7). It also reproduces in Safari's own address bar on iOS 26, so it does not appear to be app-specific. Minimal reproduction (stock UIKit, no custom code): let textField = UITextField() textField.enablesReturnKeyAutomatically = true // present it, focus it, leave it empty Focus the empty text field — the return key is disabled (correct). Tap 123 to switch to the numeric plane → the return key becomes enabled (incorrect — text is still empty). Type one character and delete it (still in the numeric plane) → the key becomes disabled again (correct). Tap ABC to switch back to the letters plane → the key becomes enabled again (incorrect). Safari reproduction (stock behavior, physical device): Open Safari on iOS 26, focus the address bar, and delete all text → the Go key disables (correct). Switch to the numeric plane → the Go key re-enables (incorrect). Tapping it gives haptic feedback but performs no action — the disable is still honored functionally; only the rendered state is wrong. Still in the numeric plane, type something (e.g. 123.456) and delete it all → the key correctly disables again (the hasText round-trip re-syncs it?) Switch back to the letters plane → the key wrongly re-enables again. The glitch triggers on plane switches in either direction. Additional observations (from our app's UITextFields — the same enablesReturnKeyAutomatically mechanism, but driven by a stricter text-validity rule than plain empty/non-empty, which makes the desync observable in more states): Two further workarounds restore the correct state after the glitch: switching the keyboard language (globe key), or changing the text and then tapping anywhere in the text field. A text change that does not flip the hasText state, without a follow-up tap, does not repaint the key. The pattern suggests that the keyboard rebuild triggered by switching planes defaults the return key to enabled without consulting the text state, and that the keyboard otherwise repaints the key only when the hasText answer transitions, or on input-session changes (tapping into the field, switching keyboard language). Environment: all reproductions and verifications were done on physical devices, not simulators — reproduced on an iPhone SE (iOS 26.5.2) and an iPad Pro 12.9" 4th gen (iPadOS 26.4.2); not reproducible on an iPad 6th gen (iPadOS 17.7.10). Is this a known issue, and is there a supported way to force the keyboard to re-evaluate the return key state after a plane switch?
Replies
0
Boosts
1
Views
405
Activity
2w
Is NavigationSplitView on macOS 27 broken?
On macOS 27 Beta 2, a simple NavigationSplitView example exhibits bizarre behaviour when the window is resized. The sidebar seemingly expands and collapses at random as the window is resized. The symptoms can be exacerbated with toolbar items. The sidebar appears to behave correctly when an inspector view is not present. Copy paste the code below into a new Xcode 27 project and run on macOS 27 and then resize the window: File -> New -> Project... -> App import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { Text("Content") } .inspector(isPresented: .constant(true)) { Text("Inspector") } } } Adding .frame or .inspectorColumnWidth to any of the Text views does not appear to fix the issues. macOS: 27.0 Beta (26A5368g) Xcode: 27.0 beta 2 (27A5209h)
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
3
Boosts
1
Views
350
Activity
2w
Should UISceneSizeRestriction be available on iPhone in iOS 27?
I'm trying to require a minimum size in my UIKit-based iOS app. I added code to set that using the UIWindowScene.sizeRestrictions property to my app's scene delegate as recommended in Apple's documentation: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let currentScene = (scene as? UIWindowScene) else { return } currentScene.sizeRestrictions?.minimumSize.height = 400 currentScene.sizeRestrictions?.minimumSize.width = 320 print("*** Size restrictions: \(String(describing: currentScene.sizeRestrictions))") ... } When I run that in the simulator for an iOS 27 iPhone, the size restrictions property prints out as being nil. That's surprising to me, since the documentation states that "The system provides this object only when it supports variable-sized windows.", and iPhone windows are resizable in iOS 27. If this is working as expected, is there another way to restrict the size of an iPhone window in iOS 27?
Topic: UI Frameworks SubTopic: UIKit
Replies
4
Boosts
0
Views
412
Activity
2w
iPhone 15 touchscreen intermittently becomes unresponsive while charging on iOS 26.6
Device: iPhone 15 Affected Versions: • iOS 26.5 • iOS 26.6 Summary While using my iPhone 15 during charging, the touchscreen occasionally becomes less responsive. Some touches are delayed or not recognized, making the device difficult to use. This issue was present on iOS 26.5 and still occurs after updating to iOS 26.6. Steps to Reproduce Connect the iPhone 15 to a charger. Unlock the device. Use the touchscreen while the phone is charging. Continue interacting with the screen for several minutes. Expected Result The touchscreen should remain fully responsive while charging. Actual Result The touchscreen occasionally becomes less responsive. Some taps or gestures are delayed or not recognized. The issue is intermittent but noticeable during charging. Frequency Intermittent. It does not happen every time, but it has occurred multiple times on both iOS 26.5 and iOS 26.6. Additional Information • Device: iPhone 15 • The issue has persisted across two stable iOS versions. • I have restarted the device and updated to the latest iOS version, but the issue still occurs. Has anyone else experienced this issue on iPhone 15 or other iPhone models? If so, does it occur with the Apple charger, a third-party charger, or both?
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
0
Views
117
Activity
2w
Unexpected behavior in the interaction between LazyVStack and GeometryReader
Hello! I'd like to share a problem and its potential solution. Steps to reproduce: The issue can be reproduced with the following minimal example: struct TestConditionalScrollView: View { var body: some View { ConditionalScrollView { LazyVStack(spacing: 16) { Text("Text 1") .frame(height: 20) Text("Text 2") .frame(height: 30) Text("Text 3") .frame(height: 40) Text("Text 4") .frame(height: 500) Text("Text 5") .frame(height: 400) } .padding() } } } struct ConditionalScrollView<Content: View>: View { let content: Content init(@ViewBuilder content: () -> Content) { self.content = content() } @State private var contentHeight: CGFloat = 0 var body: some View { GeometryReader { geo in _ = print("Height: \(contentHeight)") return Group { if contentHeight > geo.size.height { ScrollView { measuredContent } } else { measuredContent } } } } private var measuredContent: some View { content .background( GeometryReader { geo in Color.clear .preference( key: ContentHeightKey.self, value: geo.size.height ) } ) .onPreferenceChange(ContentHeightKey.self) { contentHeight = $0 } } } struct ContentHeightKey: PreferenceKey { static var defaultValue: CGFloat = 0 static func reduce(value: inout CGFloat, nextValue: () -> CGFloat) { value = max(value, nextValue()) } } If we hit the breakpoint on the following line: _ = print("Height: (contentHeight)") the output looks like this: Problems observed Different values are reported, and it is unclear where those values originate from. The selected execution branch appears to change multiple times during the layout process. Possible reason As Rens Breur mentioned in the WWDC26 session "Dive into lazy stacks and scrolling with SwiftUI", LazyVStack relies on estimated layout information during certain phases of the layout process. I do not want to rely on or investigate SwiftUI's non-public implementation details, but I would like to explain what I believe is happening internally. To do that, let me show how the value reaches the GeometryReader closure: Step 1 In AttributeGraph, the GeometryReader<...> node and the LazyVStack node appear to be connected as shown below: Step 2 When the LazyVStack node is updated, the layout process appears to follow roughly this logic: `SwiftUICore 'SwiftUI.ForEachState.forEachItem:` n = number of cells to evaluate (initially n == 2) For first n cells: SwiftUICore`SwiftUI.ViewLayoutEngine.sizeThatFits(...) SwiftUI.EstimationCache.add(...) The total size of the lazy stack is then estimated: SwiftUI.LazyStack<...>.sizeThatFits(...): averageCellInfo = EstimationCache.average averageCellInfo.height = (firstCellHeight + secondCellHeight) / 2 totalHeight = firstCellHeight + secondCellHeight + averageCellInfo.height * remainingCells For the sample project, this produces an estimated height of 189. This value then appears to be cached inside a LazyLayoutComputer node. Step 3 When GeometryReader is updated and its closure executes, geo.size.height appears to be resolved from the cached value stored by LazyLayoutComputer. As a result, the reported height is: 189 + 32 (padding) = 221 Step 4 My assumption is that LazyVStack subsequently validates the estimated layout against the actual layout results. It seems to compare: The maximum Y position of the last list's cell The cached sizeThatFits value If those values differ sufficiently, the transaction is not committed and another layout pass is triggered. During a later pass, the real sizes become available and GeometryReader eventually reports the final correct value. If this interpretation is correct, the behavior shown in the logs would be expected: followed later by: Possible solution I could not find a public SwiftUI API that provides an accurate content size during the initial layout pass. I tried the following options: LazyVStack + GeometryReader LazyVStack + ViewThatFits LazyVStack + .scrollBounceBehavior(...) At the same time, SwiftUI itself appears to have information about layout validity. For example, the layout logs contain entries such as: placed(...) -> ... invalid: true This suggests that SwiftUI can determine when an estimated layout result is no longer valid and requires additional layout passes. If SwiftUI knows that the current layout is invalid, is there a way to access this information from within a GeometryReader closure or by some other means? Otherwise, clients may perform layout calculations based on invalid geometry, which can result in a broken dependent layout. Have a good day!
Replies
0
Boosts
2
Views
138
Activity
2w
Public generated asset symbols
Is there currently an option to make generated asset symbols public? If not, would it be possible to set the generated asset symbol so they are public. It's quite common to have an apps design system implemented in a separate framework. Currently the generate assets symbols is useless for this as they can't be access in the framework consumer. It would be great to add it to this new dropdown in Xcode 16 or along side it. (113704993 in the release notes) So the options would be Internal, Public and Off. This should affect the symbols, the extensions and the framework support. (There's a post on the swift forums about this as well here: https://forums.swift.org/t/generate-images-and-colors-inside-a-swift-package/65674)
Replies
7
Boosts
35
Views
3.0k
Activity
2w
Invalid parameter not satisfying: parentEnvironment != nil
Since the beta releases of iPadOS 26 we have been having some crashes about Invalid parameter not satisfying: parentEnvironment != nil We got to contact a couple of users and we found out that the crash appears when entering a screen in a UINavigationController with the iPad device connected to a Magic Keyboard. If the device is not connected to the keyboard then nothing happens and everything works ok. From our end we haven't managed to reproduce the crash so I am pasting part of the stacktrace if it can be of any help. 3 UIKitCore 0x19dfd2e14 -[_UIFocusContainerGuideFallbackItemsContainer initWithParentEnvironment:childItems:] + 224 (_UIFocusContainerGuideFallbackItemsContainer.m:23) 4 UIKitCore 0x19dae3108 -[_UIFocusContainerGuideImpl _searchForFocusRegionsInContext:] + 368 (_UIFocusGuideImpl.m:246) 5 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 6 UIKitCore 0x19db28900 -[_UIFocusMapSnapshot addRegionsInContainers:] + 160 (_UIFocusMapSnapshot.m:545) 7 UIKitCore 0x19d1313dc _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 632 (_UIFocusRegion.m:143) 8 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 9 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 10 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 11 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 12 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 13 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 14 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 15 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 16 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 17 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 18 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 19 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 20 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 21 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 22 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 23 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 24 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 25 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 26 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 27 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 28 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 29 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 30 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 31 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 32 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 33 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 34 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 35 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 36 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 37 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 38 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 39 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 40 UIKitCore 0x19d132e08 -[_UIFocusMapSnapshot _capture] + 424 (_UIFocusMapSnapshot.m:403) 41 UIKitCore 0x19db2675c -[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 476 (_UIFocusMapSnapshot.m:171) 42 UIKitCore 0x19d130dcc -[_UIFocusMapSnapshotter captureSnapshot] + 192 (_UIFocusMapSnapshotter.m:137) 43 UIKitCore 0x19db2045c -[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 136 (_UIFocusMap.m:168) 44 UIKitCore 0x19daffd2c -[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 140 (_UIFocusEnvironmentPreferenceEnumerator.m:313) 45 UIKitCore 0x19d127ab4 -[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 104 (_UIFocusEnvironmentPreferenceEnumerator.m:250) 46 UIKitCore 0x19d127394 -[_UIFocusEnvironmentPreferenceEnumerationContext preferredEnvironments] + 36 (_UIFocusEnvironmentPreferenceEnumerator.m:184) 47 UIKitCore 0x19d126e94 _enumeratePreferredFocusEnvironments + 400 (_UIFocusEnvironmentPreferenceEnumerator.m:503)
Replies
17
Boosts
3
Views
2.5k
Activity
2w
iOS27: Bar Marks in Swift Charts exhibit multiple severe issues
Bar Marks in Swift Charts exhibit multiple severe issues on iOS27. Tested on: iPad Pro M2, 13", iOS27 Beta 2. Feedback submitted: FB23354502 Charts form a visual backbone of our app, and these issues render the chart unusable. Without a fix, we will not be able to support iOS27. The issues we identified: (1) We arrange mutually exclusive BarMarks on a time-based x-axis, inside a vertically scrolling Chart. We use init(xStart:, xEnd:, yStart: yEnd:), creating a visual timeline. Everything renders correctly on iOS26. On iOS27, many BarMarks are missing. (2) When we tap on a BarMark, we increase its height so make it appear selected. This works nicely in iOS26. The BarMark does not animate or change size at all on iOS27. (3) We have an outline around a BarMark, as part of styling. This uses .annotation(position: .overlay). The outline renders nicely in iOS26. On iOS27, the outline is rendered as a small circle inside the BarMark.
Replies
3
Boosts
1
Views
346
Activity
2w
iOS 26 Beta bug - keyboard toolbar with bottom safe area inset
Hello! I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators. When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar. On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator. Here's a clip from a simulator: Here's the code that reproduced the bug I experienced in our app. #Preview { NavigationStack { ScrollView { TextField("", text: .constant("")) .padding() .background(Color.secondary) TextField("", text: .constant("")) .padding() .background(Color.green) } .padding() .safeAreaInset(edge: .bottom, content: { Color.red .frame(maxWidth: .infinity) .frame(height: 40) }) .toolbar { ToolbarItem(placement: .keyboard) { Button {} label: { Text("test") } } } } }
Replies
4
Boosts
12
Views
1.4k
Activity
2w
Accessing SwiftData document package?
I would very much like to store some additional data in my SwiftData document package, outside of SwiftData. Metadata about the document that doesn't lend itself well to the underlying RDBMS nature of SwiftData. Is that possible?
Replies
1
Boosts
1
Views
1k
Activity
2w
LazyVStack layout issue and potential fix
Hello! Over the last several months I've spent a lot of time investigating various LazyVStack issues. I’d like to share a one problem. Blank Screen + Cell trimming For reference, I've also submitted a Feedback Assistant report for this issue. Let's use the minimal example Copy the following code into a new project and run it: struct ScrollableLazyVStack: View { @StateObject private var viewModel: ScrollableLazyVStackViewModel init(count: Int) { self._viewModel = StateObject( wrappedValue: ScrollableLazyVStackViewModel(count: count) ) } var body: some View { ScrollView { LazyVStack(spacing: 8) { ForEach(viewModel.items, id: \.index) { CellView(by: $0) } } } .padding(.horizontal, 8) } } final class ScrollableLazyVStackViewModel: ObservableObject { @Published var items: [CellModel] = [] init(count: Int) { self.items = (0..<count).map { CellModel(index: $0) } } } private struct CellView: View { let item: CellModel init(by item: CellModel) { self.item = item } var body: some View { VStack(alignment: .leading, spacing: 2) { HStack(spacing: 4) { Image(systemName: item.icon) VStack(alignment: .leading, spacing: 4) { Text(item.title) .font(.body) Text(item.subtitle) .font(.caption) .foregroundColor(.secondary) if item.index < 100 { Text("Extra Text") .frame(height: 500) } } Spacer(minLength: .zero) } } .padding(16) .background( RoundedRectangle(cornerRadius: 14, style: .continuous) .fill(Color(.systemGray5)) ) } } struct CellModel: Hashable { private static let icons = [ "star.fill", "heart.fill", "bolt.fill", "flame.fill", "leaf.fill", "moon.fill", "cloud.fill", "paperplane.fill" ] private static let titles = [ "Random Item", "Sample Entry", "List Element", "Demo Cell", "Example Row", "Test Object" ] private static let subtitles = [ "Additional information", "Secondary description", "Some extra details", "Short explanation", "Supporting text" ] let index: Int let title: String let subtitle: String let icon: String init(index: Int) { self.index = index self.title = "\(index). \(Self.titles.randomElement()!)" self.subtitle = Self.subtitles.randomElement()! self.icon = Self.icons.randomElement()! } } Steps to Reproduce Fast-scroll to the bottom of the list using the scroll indicator. Then fast-scroll back to the top by dragging and holding the scroll indicator. Actual Results Blank Screen During fast scrolling, the visible content may temporarily disappear, resulting in a white screen. In most cases, the content eventually reappears. Truncated Cells After scrolling back toward the top, some of the topmost cells may become partially truncated. Possible Cause Blank Screen I do not want to rely on or investigate SwiftUI's non-public implementation details, but I would like to explain what I believe is happening internally. I'd like to assume what appears to be the underlying algorithm. When fast scrolling is active, the following sequence seems to occur: Step 1 SwiftUICore::resolveIndexAndPosition calculates an anchorIndex. For example: anchorIndex ≈ (scrollOffset / contentSize) * totalRows Step 2 SwiftUICore::resolveIndexAndPosition calculates an anchorPosition. For example: anchorPosition ≈ anchorIndex * (estimatedCellSize + spacing) Step 3 SwiftUI searches for the first visible cell and updates the position of the last laid-out cell (y_max_last_cell). Step 4 (the most important) The layout's correctness validation: Conceptually: d1 = abs(y_last_max - cachedSizeThatFits) d2 = 0.1 * min(y_last_max, cachedSizeThatFits) If: d1 < d2 -> the current CA::Transaction is committed. Otherwise: cachedSizeThatFits = sizeThatFits(...) and the process restarts from Step 1. If logging is enabled via: com.apple.SwiftUI.LazyStackLogging the behavior can be observed in the attached screenshot. Why this may fail The algorithm appears to assume that the estimated cell size does not change dramatically while fast scrolling. However, if the beginning of the list contains very tall cells and the remainder contains much smaller cells, the estimate may become significantly inaccurate. In that situation, comparing cachedSizeThatFits against the position of the last visible cell does not seem sufficient to guarantee a stable result, which may explain the temporary blank screen. Cell Truncation While scrolling upward, the following state can occur (see attached screenshot): SwiftUICore::resolveIndexAndPosition produces: anchorIndex = 2 anchorPosition = -562 The content is translated by 486.47, which corresponds approximately to: estimatedCellSize * 2 As a result, the effective anchor position becomes: -76.32 and the first 0...1 cells are truncated. Possible Solution Blank screen's problem My assumption is that the current layout validation criteria may not be sufficient in all cases. An alternative approach could be to always fill the visible region sequentially: top → bottom while scrolling downward bottom → top while scrolling upward With such a strategy, the layout result could potentially be committed immediately once the visible area is fully covered by realized cells. Cell's Truncation For the truncation issue, it seems that the current translation-based approach may be the source of the problem. One possible alternative would be to use a contentInset-based adjustment combined with clipping against the first visible cell's minY. In that model, negative inset values would not necessarily be problematic, and the visible content could remain correctly aligned. What do you think about this?
Topic: UI Frameworks SubTopic: SwiftUI
Replies
0
Boosts
2
Views
640
Activity
2w
Siri “Found in Apps” Messenger contact suggestion change into raw metadata
Hey guys, just after some possible answers. Why might’ve a Siri “Found in Apps” Messenger contact suggestion change into raw metadata and then create a second clean suggestion? Device: iPhone 14 iOS 17 Occurred sometime around 2023–2024 The issue involved one unsaved Siri Suggested Contact under “Found in Apps” from Facebook Messenger. The sequence was: A normal Siri suggestion appeared: Messenger: name redacted Months later, that same suggested contact no longer displayed normally. Instead, it showed what looked like raw metadata while still being labelled as Messenger: Messenger: HQ_UPhdmaAMnPegcbDmgaAMfH_PPf-PtSVXehqahXZOUgA;x-userid=PR:HQ_UPhdmaAMnPegcbDmgaAMfH_PPfPtSVXehqahXZOUgA;x-displayname=name redacted;x-teamidentifier=V9WTTPBFK9;x-bundleidentifiers=com.facebook.Messenger;x-apple:PR%3AHQ_UPhdmaAMnPegcbDmgaAMfH_PPfPtSVXehqahXZOUgA After this occurred, another Siri “Found in Apps” suggestion appeared underneath: Messenger: name redacted The new entry appeared normal, while the older entry continued to show the raw metadata string. I have only seen this happen with this one contact. Other Messenger Siri suggestions display normally. My questions: What would cause a Siri “Found in Apps” suggestion to display the underlying metadata/social profile fields instead of the normal app name and contact name? Why would iOS create another clean “Messenger: Name” suggestion afterwards instead of replacing the malformed entry? Is this likely related to Siri Suggestions indexing, Contacts framework social profile data, Core Spotlight, or Messenger’s app integration? Could this happen from stale cached data or a re-indexing event after an app/iOS update? I am mainly trying to understand the technical reason for the duplicate entries and the raw metadata display, and why it may have only affected this one Siri suggested contact, not the dozen others I had as well.
Topic: UI Frameworks SubTopic: AppKit
Replies
0
Boosts
0
Views
320
Activity
2w
EKEventEditViewController broken in iOS 27 Beta
UIKit app can not edit an event using EKEventEditViewController in iOS 27 Betas. The Done tick button at the top does not work after editing an event. Also does not work if EKEventViewController is first used to display the event. Then the "Edit" tapped to display the EKEventEditViewController. Anyone else seeing this?
Replies
3
Boosts
0
Views
396
Activity
2w
SwiftUI Button with Image view label has smaller hit target
[Also submitted as FB20213961] SwiftUI Button with a label: closure containing only an Image view has a smaller tap target than buttons created with a Label or the convenience initializer. The hit area shrinks to the image bounds instead of preserving the standard minimum tappable size. SCREEN RECORDING On a physical device, the difference is obvious—it’s easy to miss the button. Sometimes it even shows the button-tapped bounce animation but doesn’t trigger the action. SYSTEM INFO Xcode Version 26.0 (17A321) macOS 15.6.1 (24G90) iOS 26.0 (23A340) SAMPLE CODE The following snippet shows the difference in hit targets between the convenience initializer, a Label, and an Image (the latter two in a label: closure). // ✅ Hit target is entire button Button("Button 1", systemImage: "1.square.fill") { print("Button 1 tapped") } // ✅ Hit target is entire button Button { print("Button 2 tapped") } label: { Label("Button 2", systemImage: "2.square.fill") } // ❌ Hit target is smaller than button Button { print("Button 3 tapped") } label: { Image(systemName: "3.square.fill") }
Replies
7
Boosts
4
Views
868
Activity
2w