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

Change in UITextFieldDelegate shouldChangeCharactersIn range.location behavior for Japanese input in iOS 26 with increased value
This problem occurs only when using the Japanese keyboard. After typing ""あい"" into a text field and pressing Enter, insert ""う"" between ""あ"" and ""い"". As a result, the displayed text becomes ""あううい"". Text field: ""あい"" → ""あううい"" The range values at this point: range.location = 2 range.length = 2 ・Behavior in iOS versions before 26 After typing ""あい"" into a text field and pressing Enter, insert ""う"" between ""あ"" and ""い"". As a result, the displayed text becomes ""あうい"". Text field: ""あい"" → ""あうい"" The range values at this point: range.location = 1 range.length = 1 The following source code can be used to reproduce the issue. mainApp (displaying a UIKit ViewController from SwiftUI) import SwiftUI import UIKit struct ViewControllerWrapper: UIViewControllerRepresentable { func makeUIViewController(context: Context) -> ViewController { return ViewController() } func updateUIViewController(_ uiViewController: ViewController, context: Context) {} } @main struct konnitihaApp: App { var body: some Scene { WindowGroup { ViewControllerWrapper() // UIKitのViewControllerを表示 } } } ViewController import UIKit class ViewController: UIViewController, UITextFieldDelegate { let textField = UITextField() let displayLabel = UILabel() // 追加で管理するプロパティ var replacementText: String = "" var textInsertLocation: Int = 0 var textSelectedLength: Int = 0 override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .white // UITextFieldの設定 textField.borderStyle = .roundedRect textField.placeholder = "" textField.delegate = self textField.translatesAutoresizingMaskIntoConstraints = false view.addSubview(textField) // UILabelの設定 displayLabel.text = "" displayLabel.layer.borderWidth = 2 displayLabel.layer.borderColor = UIColor.blue.cgColor displayLabel.translatesAutoresizingMaskIntoConstraints = false view.addSubview(displayLabel) // レイアウト NSLayoutConstraint.activate([ textField.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 40), textField.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20), textField.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20), textField.heightAnchor.constraint(equalToConstant: 40), //label displayLabel.topAnchor.constraint(equalTo: textField.bottomAnchor, constant: 500), displayLabel.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20), displayLabel.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20), displayLabel.heightAnchor.constraint(equalToConstant: 40), ]) } // UITextFieldDelegate func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool { self.replacementText = string self.textInsertLocation = range.location self.textSelectedLength = range.length print("rangeは",range) // ラベルに最新の文字列を反映 if let text = textField.text, let textRange = Range(range, in: text) { let updatedText = text.replacingCharacters(in: textRange, with: string) if textField == self.textField { displayLabel.text = updatedText } } return true } }
Topic: UI Frameworks SubTopic: UIKit
0
0
67
1w
SwiftUI Map menu / chrome placement — three approaches (overlay, ZStack + safeAreaPadding, safeAreaInset): which one is best practice?
Hi everyone, I’m building a full-screen Map (MapKit + SwiftUI) with persistent top/bottom chrome (menu buttons on top, session stats + map controls on bottom). I have three working implementations and I’d like guidance on which pattern Apple recommends long-term (gesture correctness, safe areas, Dynamic Island/home indicator, and future compatibility). Version 1 — overlay(alignment:) on Map Idea: Draw chrome using .overlay(alignment:) directly on the map and manage padding manually. Map(position: $viewModel.previewMapCameraPosition, scope: mapScope) { UserAnnotation { UserLocationCourseMarkerView(angle: viewModel.userCourse - mapHeading) } } .mapStyle(viewModel.mapType.mapStyle) .mapControls { MapUserLocationButton().mapControlVisibility(.hidden) MapCompass().mapControlVisibility(.hidden) MapPitchToggle().mapControlVisibility(.hidden) MapScaleView().mapControlVisibility(.hidden) } .overlay(alignment: .top) { mapMenu } // manual padding inside .overlay(alignment: .bottom) { bottomChrome } // manual padding inside Version 2 — ZStack + .safeAreaPadding Idea: Place the map at the back, then lay out top/bottom chrome in a VStack inside a ZStack, and use .safeAreaPadding(.all) so content respects safe areas. ZStack(alignment: .top) { Map(...).ignoresSafeArea() VStack { mapMenu Spacer() bottomChrome } .safeAreaPadding(.all) } Version 3 — .safeAreaInset on the Map Idea: Make the map full-bleed and then reserve top/bottom space with safeAreaInset, letting SwiftUI manage insets Map(...).ignoresSafeArea() .mapStyle(viewModel.mapType.mapStyle) .mapControls { MapUserLocationButton().mapControlVisibility(.hidden) MapCompass().mapControlVisibility(.hidden) MapPitchToggle().mapControlVisibility(.hidden) MapScaleView().mapControlVisibility(.hidden) } .safeAreaInset(edge: .top) { mapMenu } // manual padding inside .safeAreaInset(edge: .bottom) { bottomChrome } // manual padding inside Question I noticed: Safe-area / padding behavior – Version 2 requires the least extra padding and seems to create a small but partial safe-area spacing automatically. – Version 3 still needs roughly the same manual padding as Version 1, even though it uses safeAreaInset. Why doesn’t safeAreaInset fully handle that spacing? Rotation crash (Metal) When using Version 3 (safeAreaInset + ignoresSafeArea), rotating the device portrait↔landscape several times triggers a Metal crash: failed assertion 'The following Metal object is being destroyed while still required… CAMetalLayer Display Drawable' The same crash can happen with Version 1, though less often. I haven’t tested it much with Version 2. Is this a known issue or race condition between Map’s internal Metal rendering and view layout changes? Expected behavior What’s the intended or supported interaction between safeAreaInset, safeAreaPadding, and overlay when embedding persistent chrome inside a SwiftUI Map? Should safeAreaInset normally remove the need for manual padding, or is that by design?
0
0
29
1w
tabViewBottomAccessory AttributeGraph cycles, broken behavior of views participating in cycles
Seemingly innocuous contents passed to tabViewBottomAccessory can trigger inscrutable AttributeGraph cycles, which can then cause unexplained broken behavior of views that may be participating in these cycles. These cycles can be introduced by adding common elements to the tabViewBottomAccessory view hierarchy, like Slider, Button, Toggle, and even things simple if statements surrounding Text elements. These cycles can even also be triggered in a manner that causes the tabViewBottomAccessoryPlacement Environment value to be nil, which can then cause views that depend on this value to render incorrectly or not at all. The errors logged to the Xcode console are of the form: === AttributeGraph: cycle detected through attribute 29528 === === AttributeGraph: cycle detected through attribute 324264 === No further information about this attribute is available in any public Xcode tools. Environment XCode Version 26.0 (17A324) iOS 26.0 (23A343) Steps to reproduce Run the sample above in Simulator Observe no AttributeGraph cycles in Xcode console. Uncomment any of the commented out examples in SliderView.body Observe Xcode console for AttributeGraph cycle messages. Observe glitchy animation behavior Expected Behavior No AttributeGraph cycle diagnostics for ordinary state changes. tabViewBottomAccessoryPlacement always present (non-nil) while accessory is attached. Dependent views update consistently. Errors logged to the Console would help guide me towards a resolution Impact Undermines confidence in adopting tabViewBottomAccessory. Hard to debug: cycle traces are opaque and environment silently degrades (becomes nil) instead of asserting. Nearly shipped a UI where accessory layout fails sporadically. What would help Underlying fix to prevent cycles for ordinary accessory content mutations. Guarantee (or documented contract) that tabViewBottomAccessoryPlacement is never nil while accessory is active, or an assert if invariants break. Option to enable detailed environment propagation trace when a cycle is detected. Symbolic source identifiers in cycle backtraces. Documentation note on current limitations (if certain view types are not yet supported in accessory regions).
Topic: UI Frameworks SubTopic: SwiftUI
7
9
499
1w
EXC_BREAKPOINT in BKSHIDEventDeliveryManager during background scene invalidation
We're seeing a high velocity crash with our users in background tasks in an internal Apple Framework. It seems to have started in iOS 17/18, but has increased heavily in iOS 26+. EXC_BREAKPOINT · 0 BackBoardServices -[BKSHIDEventDeliveryManager _initWithConnectionFactory:forTesting:] 1 BackBoardServices ___44+[BKSHIDEventDeliveryManager sharedInstance]_block_invoke 2 libdispatch.dylib __dispatch_client_callout 3 libdispatch.dylib __dispatch_once_callout 4 BackBoardServices +[BKSHIDEventDeliveryManager sharedInstance] 5 UIKitCore _stateMachineSpec_block_invoke_3 6 UIKitCore _handleEvent 7 UIKitCore -[_UIEventDeferringManager _processEventDeferringActions:actionsCount:inScope:forDeferringToken:environments:target:addingRecreationReason:removingRecreationReason:forReason:] 8 UIKitCore -[_UIEventDeferringManager _sceneWillInvalidate:] 9 UIKitCore -[UIScene _invalidate] 10 UIKitCore -[UIWindowScene _invalidate] 11 UIKitCore -[UIApplication workspace:willDestroyScene:withTransitionContext:completion:] 12 UIKitCore -[UIApplicationSceneClientAgent scene:willInvalidateWithEvent:completion:] 13 FrontBoardServices -[FBSScene _callOutQueue_willDestroyWithTransitionContext:completion:] 14 FrontBoardServices ___84-[FBSWorkspaceScenesClient _queue_invalidateScene:withTransitionContext:completion:]_block_invoke_3 15 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] 16 libdispatch.dylib __dispatch_client_callout 17 libdispatch.dylib __dispatch_block_invoke_direct 18 BoardServices ___BSSERVICEMAINRUNLOOPQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ 19 BoardServices _BSServiceMainRunLoopSourceHandler 20 CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 21 CoreFoundation ___CFRunLoopDoSource0 22 CoreFoundation ___CFRunLoopDoSources0 23 CoreFoundation ___CFRunLoopRun 24 CoreFoundation __CFRunLoopRunSpecificWithOptions 25 GraphicsServices _GSEventRunModal 26 UIKitCore -[UIApplication _run] 27 UIKitCore _UIApplicationMain 28 Aura main.m main 29 dyld start
3
0
200
1w
UIRequiresFullScreen Deprecation
I work on a universal app that targets both iPhone and iPad. Our iPad app currently requires full screen. When testing on the latest iPadOS 26 beta, we see the following warning printed to the console: Update the Info.plist: 1) `UIRequiresFullScreen` will soon be ignored. 2) Support for all orientations will soon be required. It will take a fair amount of effort to update our app to properly support presentation in a resizable window. We wanted to gauge how urgent this change is. Our testing has shown that iPadOS 26 supports our app in a non-resizable window. Can someone from Apple provide any guidance as to how soon “soon” is? Will UIRequiresFullScreen be ignored in iPadOS 26? Will support for all orientations be required in iPadOS 26?
8
2
601
1w
Tabview accessory always visible
I just updated to Xcode 26.1 and am using simulators for iOS 26.1. Previously I could have a hidden tabview accessory where nothing would be displayed but now whenever no view is placed in the closure or even an EmptyView, it is visible all the time. Does anyone else have this issue?
Topic: UI Frameworks SubTopic: SwiftUI
1
0
100
1w
tabViewBottomAccessory in 26.1: View's @State is lost when switching tabs
Any view that is content for the tabViewBottomAccessory API fails to retain its state as of the last couple of 26.1 betas (and RC). The loss of state happens (at least) when the currently selected tab is switched (filed as FB20901325). Here's code to reproduce the issue: struct ContentView: View { @State private var selectedTab = TabSelection.one enum TabSelection: Hashable { case one, two } var body: some View { TabView(selection: $selectedTab) { Tab("One", systemImage: "1.circle", value: .one) { BugExplanationView() } Tab("Two", systemImage: "2.circle", value: .two) { BugExplanationView() } } .tabViewBottomAccessory { AccessoryView() } } } struct AccessoryView: View { @State private var counter = 0 // This guy's state gets lost (as of iOS 26.1) var body: some View { Stepper("Counter: \(counter)", value: $counter) .padding(.horizontal) } } struct BugExplanationView: View { var body: some View { ScrollView { VStack(alignment: .leading, spacing: 16) { Text("(1) Manipulate the counter state") Text("(2) Then switch tabs") Text("BUG: The counter state gets unexpectedly reset!") } .multilineTextAlignment(.leading) } } }
1
2
215
1w
when UIAlertController dismisses app hangup
Before iOS 26.1 our app work fine. but, when some users update to iOS 26.1 our app has very strange issues. Our app has a feature to upload pictures to server, before update pictures we will popup a UIAlertController to let user choose, there are 3 options, album, take a photo, cloud, or cancel. when click option button UIAlertController is hangup here not any response, and Xcode has no useful logs. How can I fix it? This app is work online for 8 years!!
Topic: UI Frameworks SubTopic: UIKit
2
0
29
1w
Hide sensitive data on watchOS with WidgetKit
I am looking for a way to hide sensitive information on my Complication, basically whenever the user does not actively look at it. That includes Always-On state Locked State (e.g. Watch not on wrist) I could observe differences in behavior between Preview, Simulator and Real Device. In general it looks like the .privacySensitive() modifier does not do anything for my purpose (except if the user enables redaction in settings). For the always-on state I could use @Environment(\.isLuminanceReduced) to conditionally apply .redacted(reason: .placeholder). This works most of the time. @ViewBuilder func preservePrivacy(_ isLuminanceReduced: Bool) -> some View { if isLuminanceReduced { self .redacted(reason: .placeholder) } else { self } } However I still cannot hide the information when the Watch is locked completely (via PIN-Code). I still believe that .privacySensitive() should take care of it, but apparently it doesn't. So the question is: How can I hide sensitive information when the Watch is locked? This is my widget: Text("1234") .privacySensitive() .preservePrivacy(isLuminanceReduced) .widgetCurvesContent() .widgetLabel { Text("PIN") .widgetAccentable() .foregroundStyle(.secondary) } .containerBackground(.teal.gradient, for: .widget) (I included the whole story, because possibly my whole approach is wrong.)
1
0
48
1w
EXC_BAD_ACCESS (code=EXC_I386_GPFLT) when using RegisterEventHotKey + SwiftUI AppDelegate
Hi everyone, I’m working on a macOS SwiftUI app that integrates a global keyboard shortcut using the old Carbon API (RegisterEventHotKey, InstallEventHandler, etc.). Everything works fine initially, but I’m running into a consistent EXC_BAD_ACCESS (code=EXC_I386_GPFLT) crash when the app is reopened, or sometimes even while drawing on my SwiftUI canvas view. Setup Here’s the relevant setup (simplified): private let hotKeySignature: FourCharCode = 0x626c6e6b // 'blnk' private weak var hotKeyDelegate: AppDelegate? private func overlayHotKeyHandler( _ callRef: EventHandlerCallRef?, _ event: EventRef?, _ userData: UnsafeMutableRawPointer? ) -> OSStatus { guard let appDelegate = hotKeyDelegate else { return noErr } return appDelegate.handleHotKey(event: event) } final class AppDelegate: NSObject, NSApplicationDelegate { private var hotKeyRef: EventHotKeyRef? private var eventHandlerRef: EventHandlerRef? override init() { super.init() hotKeyDelegate = self } func applicationDidFinishLaunching(_ notification: Notification) { registerGlobalHotKey() } func applicationWillTerminate(_ notification: Notification) { unregisterGlobalHotKey() } private func registerGlobalHotKey() { var eventType = EventTypeSpec(eventClass: OSType(kEventClassKeyboard), eventKind: UInt32(kEventHotKeyPressed)) InstallEventHandler(GetEventDispatcherTarget(), overlayHotKeyHandler, 1, &eventType, nil, &eventHandlerRef) var hotKeyID = EventHotKeyID(signature: hotKeySignature, id: 1) RegisterEventHotKey(UInt32(kVK_Space), UInt32(cmdKey | shiftKey), hotKeyID, GetEventDispatcherTarget(), 0, &hotKeyRef) } private func unregisterGlobalHotKey() { if let ref = hotKeyRef { UnregisterEventHotKey(ref) } if let handler = eventHandlerRef { RemoveEventHandler(handler) } } } What happens The first run works fine. If I close the app window and reopen (SwiftUI recreates the AppDelegate), the next time the hot key triggers, I get: Thread 8: EXC_BAD_ACCESS (code=EXC_I386_GPFLT) 0x7ff824028ff0 <+240>: callq *%rax The debugger stops at a ud2 instruction, which likely means the handler is calling through a freed pointer (hotKeyDelegate). What I suspect Because RegisterEventHotKey and InstallEventHandler store global callbacks, they may outlive my SwiftUI AppDelegate instance. When SwiftUI reinitializes the app scene or recreates AppDelegate, the old handler still points to a now-freed object. What I’ve tried Unregistering the hot key and removing the handler in applicationWillTerminate(). Setting the global delegate to nil in deinit. Replacing the weak global with a static weak reference cleared on deallocation. Confirmed no Combine or SwiftUI memory leaks; the crash still occurs exactly when the Carbon handler fires after reopening. Question How should a modern SwiftUI macOS app safely integrate a global keyboard shortcut using the Carbon Hot Key APIs? Is there a recommended way to manage the callback lifetime so it doesn’t call into a deallocated AppDelegate or scene? Any advice on a modern alternative (e.g., using NSEvent.addGlobalMonitorForEvents or another framework) that can replace this global hotkey mechanism would also be appreciated. Environment macOS 15.0 Sonoma Xcode 16.0 Swift 5.10 AppKit + SwiftUI hybrid app
Topic: UI Frameworks SubTopic: SwiftUI
1
0
37
1w
Duplicate toolbar item and wrong document name in SwiftUI document based app
My app is a SwiftUI document based app using DocumentGroupLaunchScene. In iOS(iPadOS) 18.4, when it launches, it has duplicate toolbar items, and when I close the current document and open other documents, it adds more duplicates. It also shows a wrong document name, which shows the first opened document name. This issue can be reproduced in the sample code (Building a document-based app with SwiftUI). I have submitted Feedback (FB17025216), but not sure if this is a known bug or if I'm missing anything.
8
8
373
1w
LiveActivity on device with Dynamic Island
I am developing a live activity for my app and am running into issues on devices with dynamic islands. The live activity will randomly get in a state where it displays a spinner and does not update. For devices without dynamic islands, the activity works perfectly fine. I have tried breaking down the views to determine the root cause, but at times it seems very random. These are all TestFlight builds as we are currently developing the feature. I have tried using the console app and looking at the various processes that have been called out in other threads and cannot see any actual errors being logged. Looking for any pointers on how to pinpoint the root cause of this issue.
2
1
460
1w
UIManagedDocument and Swift 6
I open this post to bring attention to overlooked UIManagedDocument. It still marked with @MainActor despite the fact that UIDocument is gonna be nonisolated in iOS 26.1. Here is what we will have with iOS 26.1 (the fix was there since, at least, beta 2): UIDocument was incorrectly annotated to be main actor only. This has been corrected. As a result you might see new warnings or errors show up in your Swift code using UIDocument. (149990945) Seems that UIManagedDocument should also have to be corrected the same way. Otherwise, in Swift 6 we will have crashes. Feedback report for this issue is FB20555456.
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
81
1w
iOS 26 regression: Slider does not respect step parameter
In iOS 26, the Slider control no longer respects the step parameter. For example, import SwiftUI struct ContentView: View { @State private var sliderValue: CGFloat = 16 var body: some View { Slider( value: $sliderValue, in: 0...100, step: 5, onEditingChanged: { editing in print(sliderValue) } ) } } In iOS 18, this prints values like 5, 35, 60, 95, etc. In iOS 26.0 (release version), this prints floats that are not rounded to the nearest 5, and the slider does not snap to values ending in 5. Feedback report number: FB20320542
Topic: UI Frameworks SubTopic: SwiftUI
6
4
282
1w
Incorrect system color on popover view, and does not update while switching dark mode on iOS 26 beta 3
All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.
4
0
376
1w
iPadOS 26 - Status bar overlaps with navigation bar
Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?
7
1
489
1w
UITextField selects all text on focus when the content is long — how to keep the caret at the end?
I’m building a custom input field using UITextField. When the user taps to focus the field and the text is long, the entire text becomes selected by default. This is the same behavior you can see in iOS Safari’s search field or the Messages app search field. What I want: when the field becomes first responder, the caret should be placed at the end of the text (latest word), without selecting all the text. Here’s the code that builds my text field: public func makeTextField() -> UITextField { let textField = UITextField() textField.autocorrectionType = .no textField.setContentCompressionResistancePriority(.required, for: .horizontal) textField.setContentCompressionResistancePriority(.required, for: .vertical) if #available(iOS 13.0, *) { textField.smartInsertDeleteType = .no } textField.smartQuotesType = .no textField.smartDashesType = .no textField.autocapitalizationType = .none textField.contentMode = .scaleToFill if let font = attributes[.font] as? UIFont { textField.font = font } if let color = attributes[.foregroundColor] as? UIColor { textField.textColor = color } // Truncate long text at the head let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.lineBreakMode = .byTruncatingHead textField.defaultTextAttributes[.paragraphStyle] = paragraphStyle textField.delegate = self textField.backgroundColor = .clear textField.addTarget(self, action: #selector(textFieldDidChange(_:)), for: .editingChanged) return textField } Entire text is selected when focusing the field if the text is long. What I’ve tried Forcing the caret to the end in textFieldDidBeginEditing: func textFieldDidBeginEditing(_ textField: UITextField) { let end = textField.endOfDocument textField.selectedTextRange = textField.textRange(from: end, to: end) } Doing the same asynchronously (next runloop) to avoid the system overriding selection: func textFieldDidBeginEditing(_ textField: UITextField) { DispatchQueue.main.async { let end = textField.endOfDocument textField.selectedTextRange = textField.textRange(from: end, to: end) } } Despite these, the system still selects all text on focus when the string is long/truncated at the head.
2
0
204
1w
Sheet background in share extension ignores Liquid Glass effect in iOS 26/Xcode 26
I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?
1
0
51
1w
Matching launch image with with background image
The document-based SwiftUI example app (https://developer.apple.com/documentation/swiftui/building-a-document-based-app-with-swiftui) doesn't specify a launch image. It would seem per the HIG that the "pinkJungle" background in the app would be a decent candidate for a launch image, since it will be in the background when the document browser comes up. However when specifying it as the UIImageName, it is not aligned the same as the background image. I'm having trouble figuring out how it should be aligned to match the image. The launch image seems to be scaled up a bit over scaledToFill. I suppose a launch storyboard might make this more explicit, but I still should be able to do it without one. This is the image when displayed as the launch image: and this is how it's rendered in the background right before the document browser comes up:
0
0
16
1w