Provide views, controls, and layout structures for declaring your app's user interface using SwiftUI.

Posts under SwiftUI tag

200 Posts

Post

Replies

Boosts

Views

Activity

iOS 27: SwiftUI keyboard safe area is not restored after returning to a UIHostingController
I have a SwiftUI view embedded in a UIHostingController. It contains a numeric text field at the top and a .borderedProminent button at the bottom. The text field is automatically focused when the view appears. The bottom button pushes another instance of the same hosting controller. On the initial appearance, SwiftUI correctly positions the button above the keyboard. However, after navigating back from VC2 to VC1, the text field is focused and the keyboard is visible, but the button remains behind the keyboard. This occurs regardless of whether VC2 is closed using the navigation bar back button or the interactive back gesture. This appears to be an iOS 27 regression involving SwiftUI keyboard avoidance inside a UIHostingController. The issue is especially problematic with a numeric keyboard because it has no Return or Done key. If the covered button is the primary way to continue or dismiss the keyboard, the user can no longer access it. Interestingly, the button is repositioned correctly as soon as I begin moving the app into the background. This suggests that SwiftUI still knows about the keyboard safe area but does not update the layout correctly when the hosting controller reappears after being popped to. Minimal reproducible example import SwiftUI import UIKit final class NumericInputHostingController: UIHostingController<NumericInputView> { init() { super.init( rootView: NumericInputView(onContinue: {}) ) rootView = NumericInputView { [weak self] in self?.navigationController?.pushViewController( NumericInputHostingController(), animated: true ) } } @available(*, unavailable) @MainActor required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } } struct NumericInputView: View { @State private var value = "" @FocusState private var isTextFieldFocused: Bool let onContinue: () -> Void var body: some View { VStack(spacing: 24) { TextField("Enter a number", text: $value) .keyboardType(.numberPad) .focused($isTextFieldFocused) .padding(.horizontal, 16) .frame(height: 52) .background { RoundedRectangle(cornerRadius: 10) .stroke( Color.accentColor, lineWidth: 1.5 ) } Spacer() Button("Open Another", action: onContinue) .buttonStyle(.borderedProminent) .controlSize(.large) .frame(maxWidth: .infinity) } .padding(20) .background(Color(.systemBackground)) .onAppear { DispatchQueue.main.async { isTextFieldFocused = true } } .onDisappear { isTextFieldFocused = false } } } The initial controller is embedded in a navigation controller: let controller = NumericInputHostingController() let navigationController = UINavigationController( rootViewController: controller ) Steps to reproduce Present VC1. VC1 automatically focuses the numeric text field. Confirm that the bottom button is above the keyboard. Tap the button to push VC2. Navigate back to VC1. VC1 focuses its text field and displays the numeric keyboard. Observe that the bottom button is now behind the keyboard. Begin putting the app into the background. Observe that the button suddenly moves to the correct position above the keyboard. UIKit’s keyboardLayoutGuide handles the equivalent UIKit layout correctly. Is this a known issue with keyboard safe-area updates when a UIHostingController reappears after navigation? Is there a supported SwiftUI solution that does not require observing keyboard notifications manually?
0
0
33
14h
iOS 27 beta 1: .scrollEdgeEffectStyle(.soft) renders fully transparent above safeAreaBar
Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.
22
13
4.4k
16h
Proposal: Add a System Readable Content Layout to SwiftUI SwiftUI currently does not provide a native equivalent of UIKit’s UIView.readableContentGuide. For content-heavy applications such as articles, documentation, settings, email, and media desc
Proposal: Add a System Readable Content Layout to SwiftUI SwiftUI currently does not provide a native equivalent of UIKit's UIView.readableContentGuide. For content-heavy applications such as articles, documentation, settings, email, and media descriptions, developers often need to prevent text from becoming excessively wide on iPad, Mac, and other large displays. UIKit already provides a system-level solution through: view.readableContentGuide However, there is currently no equivalent API in SwiftUI. Current Workarounds Developers currently have to choose between several approaches, none of which provides the same behavior as UIKit's readableContentGuide. 1. Hard-coded maximum width content .frame(maxWidth: 700) This is simple, but the value is arbitrary and does not adapt to the platform, window size, Dynamic Type, or system layout rules. 2. containerRelativeFrame A developer can approximate a readable width: content .containerRelativeFrame(.horizontal) { length, axis in length * 0.52 } However, this is only an approximation. Developers still have to determine the appropriate ratio themselves, and the result does not necessarily match the system's readable content width. 3. Bridging to UIKit Another workaround is to create a UIKit view/controller and obtain: view.readableContentGuide.layoutFrame The resulting width can then be passed back into SwiftUI. This works for iOS and iPadOS, but introduces UIKit-specific implementation details into an otherwise pure SwiftUI view and does not provide a natural cross-platform solution for macOS, tvOS, and other SwiftUI platforms. Proposed API I propose that SwiftUI provide a system-defined readable content layout. For example: .contentWidth(.readable) or a dedicated layout/container: ReadableContent { content } Another possibility would be a layout guide exposed through the SwiftUI environment: @Environment(\.readableContentGuide) private var readableContentGuide allowing: content .frame( maxWidth: readableContentGuide.width ) The exact API design is of course up to Apple, but the important part is that the readable width should be determined by the system rather than by application-specific constants. Expected Behavior The readable content width should be determined by the current platform and environment, taking into account factors such as: Available window/container size Platform-specific layout conventions Dynamic Type / accessibility text sizes Layout margins Safe areas Orientation Size classes where applicable Current window size on macOS Appropriate platform-specific readable widths For example, the same SwiftUI view could behave naturally across devices: iPhone ┌─────────────────────────┐ │ │ │ Readable content │ │ │ └─────────────────────────┘ iPad ┌─────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └─────────────────────────────────────────────┘ Mac ┌──────────────────────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ The developer should not need to know the exact width used by the system. Why This Belongs in SwiftUI SwiftUI already provides many environment-driven layout behaviors that automatically adapt to the current platform and device. Readable content width is similarly a semantic layout concept, rather than a fixed visual dimension. For example, developers generally should not need to write: #if os(iOS) let maxWidth = 700 #elseif os(macOS) let maxWidth = 800 #elseif os(tvOS) let maxWidth = 1000 #endif A system-provided readable layout would allow the application to express its intent instead: ReadableContent { ArticleView() } This would also make SwiftUI applications more resilient to future platform changes because Apple could adjust the underlying readable-content rules without requiring developers to update hard-coded constants. Use Cases This would be particularly useful for: Article and reading applications Documentation viewers News applications Email clients Settings and preference screens Legal/privacy documents Markdown viewers AI/chat applications Book and EPUB readers Media descriptions and metadata Forms containing large amounts of text Relationship to UIKit UIKit already establishes a precedent with: UIView.readableContentGuide SwiftUI developers should have access to the same semantic concept without needing to bridge through UIKit. The SwiftUI API does not necessarily need to expose the UIKit implementation. It could instead provide a platform-independent abstraction whose implementation is appropriate for each SwiftUI platform. Summary I would like to request a native SwiftUI API for system-defined readable content width. The ideal solution would allow developers to express: ReadableContent { ArticleView() } or: ArticleView() .contentWidth(.readable) while SwiftUI automatically determines the appropriate readable width for the current platform, window, Dynamic Type settings, and layout environment. This would eliminate the need for hard-coded maximum widths and platform-specific UIKit/AppKit workarounds, while bringing SwiftUI closer to the adaptive layout behavior already available in UIKit through readableContentGuide.
1
1
164
23h
Combining NavigationSplitView and TabView in iOS 18
Hi folks, I've used a NavigationSplitView within one of the tabs of my app since iOS 16, but with the new styling in iOS 18 the toolbar region looks odd. In other tabs using e.g. simple stacks, the toolbar buttons are horizontally in line with the new tab picker, but with NavigationSplitView, the toolbar leaves a lot of empty space at the top (see below). Is there anything I can do to adjust this, or alternatively, continue to use the old style? Thanks!
15
3
3.4k
1d
Using CABTMIDILocalPeripheralViewController with SwiftUI
I'm trying to make an app that can send MIDI data over Bluetooth from my iPhone to my Mac. I'm using AudioKit as a framework for the MIDI aspect, and it's working great over a wired connection. I can't figure out how to implement MIDI over Bluetooth though.I found the CABTMIDILocalPeripheralViewController page here: https://developer.apple.com/documentation/coreaudiokit/cabtmidilocalperipheralviewcontroller, which looks promising, but I'm confused about how to use it.I'd really like to implement it using SwiftUI as opposed to UIKit, because the rest of the app is made with SwiftUI. Could someone please show me how I could use this in SwiftUI to make my iPhone discoverable as a Bluetooth MIDI device?I found some sample code written with UIKit, but I'd like to translate this to SwiftUI:import UIKit import CoreAudioKit import CoreMIDI class ViewController: UIViewController { var localPeripheralViewController:CABTMIDILocalPeripheralViewController? override func viewDidLoad() { super.viewDidLoad() localPeripheralViewController = CABTMIDILocalPeripheralViewController() } @IBAction func someAction(sender: AnyObject) { self.navigationController?.pushViewController(localPeripheralViewController!, animated: true) } }Thank you,Jack
5
0
1.3k
1d
SwiftUI Navigation Flicker When Navigating Between Screens With and Without .searchable
I’m experiencing a UI flickering issue in a SwiftUI application related to navigation and the .searchable modifier. I have the following navigation flow: Case 1: Event Dashboard ↓ Attendee List ↓ Back to Event Dashboard The Event Dashboard contains an event image at the top. The Attendee List has a navigation bar with a .searchable search field. When I navigate back from the Attendee List to the Event Dashboard, the event image briefly becomes smaller and then returns to its original size after approximately one second. Case 2: Event Dashboard ↓ Attendee List ↓ Attendee Detail The Attendee List contains .searchable, while the Attendee Detail screen does not. When navigating from the Attendee List to the Attendee Detail screen, the attendee profile image similarly becomes slightly smaller and then enlarges back to its original size. The behavior appears to be related to the navigation bar/search bar layout changing between screens. For example, the Attendee List currently uses: .searchable( text: $model.searchQuery, placement: .navigationBarDrawer, prompt: "Search" ) If I completely remove .searchable from the Attendee List, the flickering does not occur. I would like to understand whether this is expected SwiftUI behavior or a known issue with .searchable and navigation transitions. I am considering testing the Attendee List with ScrollView + LazyVStack instead of List to determine whether List is contributing to the issue.
4
0
702
1d
Incorrect initial Navigation Bar height when combining topEdgeEffect, .toolbar, and .ignoresSafeArea()
Description: When wrapping a UIKit UIScrollView in SwiftUI via UIViewControllerRepresentable, applying topEdgeEffect.style = .hard, then using .toolbar() and .ignoresSafeArea(.container) on the SwiftUI view causes an incorrect/truncated initial height of Navigation Bar on first load. The height will refresh to the correct value after backgrounding the app or switching tabs. Steps to Reproduce: Wrap a UICollectionViewController in UIViewControllerRepresentable. Set collectionView.topEdgeEffect.style = .hard. Embed it in a SwiftUI NavigationStack and apply .toolbar() and .ignoresSafeArea() Happens on Xcode 26.x and iOS 26.x (untested on 27s).
1
0
340
1d
How to implement correct horizontal padding for iPhone Duo
On iPhone Duo in the folded state, the outer screen displays a vertical bar on the right edge with view contents inset. I noticed Form displays an appropriate amount of leading padding but 0 padding on the trailing edge, since the vertical bar provides some padding already, so it looks nice. I have a view that looks kind of like a form, multiple stacked text fields, that should align the same way. I used scenePadding to achieve this and it looks correct on iPhone 18 Pro perfectly aligning with Form. Unfortunately on iPhone Duo there is extra trailing padding such that it doesn't align with the edit button that remains in the horizontal axis navigation bar (and it is not inset enough on the leading edge, off by a few pixels, interestingly). Note when you unfold it and add the app on the left side in Split View, the vertical bar is on the leading edge, in which case there's too much padding on the leading edge. How can I achieve the correct padding? My actual app: struct ContentView: View { var body: some View { TabView { NavigationStack { SystemFormView() .navigationTitle("System Form") } .tabItem { Label("System Form", systemImage: "list.bullet.rectangle") } NavigationStack { CustomFormView() .navigationTitle("Custom Form") } .tabItem { Label("Custom Form", systemImage: "rectangle.3.group") } } } } private struct SystemFormView: View { var body: some View { Form { Text("Row 1") Text("Row 2") Text("Row 3") } } } private struct CustomFormView: View { var body: some View { ScrollView { VStack(spacing: 0) { customRow("Row 1") Divider() .padding(.leading) customRow("Row 2") Divider() .padding(.leading) customRow("Row 3") } .background(.background) .scenePadding(.horizontal) } .background(Color(uiColor: .systemGroupedBackground)) } private func customRow(_ title: LocalizedStringKey) -> some View { Text(title) .frame(maxWidth: .infinity, minHeight: 44, alignment: .leading) .padding(.horizontal) } }
0
1
207
2d
How to separate/add space between Liquid Glass toolbar items when using ToolbarOverflowMenu
The following code works as expected to display two separate Liquid Glass toolbar buttons with space between them: struct ContentView: View { var body: some View { NavigationStack { Text("Hello, World") .toolbar { ToolbarItem { Button("Add", systemImage: "plus") { } } ToolbarSpacer(.fixed) ToolbarItem { Menu { Button("Settings", systemImage: "gearshape") { } } label: { Label("More", systemImage: "ellipsis") } } } } } } When optimizing for iPhone Duo (and in general) I understand the recommendation is to replace custom "more" menus with the system overflow menu, otherwise it's possible you can see two ... buttons in various scenarios. struct ContentView: View { var body: some View { NavigationStack { Text("Hello, World") .toolbar { ToolbarItem { Button("Add", systemImage: "plus") { } } ToolbarSpacer(.fixed) ToolbarOverflowMenu { Button("Settings", systemImage: "gearshape") { } } } } } } This unexpectedly places both + and ... inside the same shared Liquid Glass background. How do you separate / add space between them, or is this a bug, is there a workaround? Before / After
0
0
63
2d
New Swiftui Text timer not counting down
Hi using this new Text method for timers is not counting down. Here is an example of how I implemented it. Text(.now, format:.timer(countingDownIn: Date.now..<Date.now.addingTimeInterval(120), showsHours: true, maxFieldCount: 2, maxPrecision: .seconds(60)) ) After waiting over a minute it never counts down
4
1
2.7k
3d
Best practice Replacement for Edit Button on iPhone Duo
On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?
0
0
125
3d
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
6
1
2.3k
3d
DragGesture latency on iOS 27
As of iOS 27, DragGesture(minimumDistance: 0) no longer functions as a reliable touch detector, at least without a noticeable delay before the gesture is recognized. This is very frustrating, as this was one of the few decent ways to detect touch down (and up) events in more complicated gesture handling scenarios. Some level of delay for gesture disambiguation is of course expected in certain cases, but this is reproducible even when the drag gesture is the sole gesture in the view hierarchy. Further, this was never a problem on iOS 26 and below. To see the issue, run an app containing the following view and tap the green rectangle rapidly. On iOS 27, the opacity won't change at all, while on iOS 26 and below it will flash rapidly as expected. To make matters much worse, the latency goes from slight but noticeable to ridiculous if the view is placed anywhere in the bottom 1/5 or so of the screen. System gestures seem to be interfering. Again, this was not an issue before iOS 27. struct PressDetectView: View { @GestureState private var isPressed = false var body: some View { Rectangle() .fill(.green) .opacity(isPressed ? 0.5 : 1) .gesture(dragGesture) } private var dragGesture: some Gesture { DragGesture(minimumDistance: 0) .updating($isPressed) { value, state, _ in state = true print("drag") } } } Any workarounds?
1
4
609
4d
Looking for feedback on my newly published iOS app: Nexora AI (Built with SwiftUI)
Hello everyone 👋 I’m an engineer and self-taught iOS developer. I recently published my app, Nexora AI, on the App Store. The app is designed to help students study smarter using AI-driven features like PDF analysis, instant problem solving, flashcard generation, and study/exam planning. As a solo developer, I’d love to gather feedback on UX/UI flow, performance, and general user experience from the community. If you have a moment to test it out or share any thoughts, I’d greatly appreciate it! 📲 App Store Link: https://apps.apple.com/tr/app/nexora-ai/id6770621015 Thanks for your time and feedback!
0
0
132
4d
.contactAccessPicker shows blank sheet on iOS 26.2.1 on device
Calling contactAccessPicker results in a blank sheet and a jetsam error, rather than the expected contact picker, using Apple’s sample code, only on device with iOS 26.2.1. This is happening on a iPhone 17 Pro Max running 26.2.1, and not on a simulator. I’m running Apple's sample project Accessing a person’s contact data using Contacts and ContactsUI Steps: Run the sample app on device running iOS 26.2.1. Use the flow to authorize .limited access with 1 contact: Tap request access, Continue, Select Contacts. Select a contact, Continue, Allow Selected Contact. This all works as expected. Tap the add contact button in the toolbar to add a second contact. Expected: This should show the Contact Access Picker UI. Actual: Sheet is shown with no contents. See screenshot of actual results on iOS device running 26.2.1. Reported as FB21812568 I see a similar (same?) error reported for 26.1. It seems strange that the feature is completely broken for multiple point releases. Is anyone else seeing this or are the two of us running into the same rare edge case? Expected Outcome, seen on simulator running 26.2 Actual outcome, seen on device running 26.2.1
9
3
1.3k
4d
iOS Dynamically loaded custom fonts in WidgetKit not working on real device (simulator is fine). Sandbox chronod deny file-read-data for font file.
Project structure is: App target + widget extension + widget intent extension All share a common appgroup group.com.x.y and all file handling is done using FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.x.y") so that only the shared container is used. Using the Main app target, a font "Chewy-Regular.ttf" is downloaded and saved to the shared AppGroup container. Font can now be loaded via CTFontManagerRegisterFontsForURL and displayed in a Main App Text view Text("Testing...").font(Font.custom("Chewy-Regular", size: 20)) Now add a Widgetkit widget instance that uses this font. In 'getTimeLine() and getSnapShot() of IntentTimelineProvider we load the font again via CTFontManagerRegisterFontsForURL (this needs to happen again probably because widget runs in a separate process from the main app?). On simulator, the widget will show the correct font. BUT On iPhone7 real device, the widget will show the 'redacted placeholder view'. It seems that something is crashing. I see in the device console : error 14:39:07.567120-0800 chronod No configuration found for configured widget identifier: D9BF75EE-4A04-441A-8C85-1507F7ECE379 fault 14:39:07.625600-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.672733-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; error 14:39:07.672799-0800 chronod [co.appevolve.onewidget.widgetx:widgetx:small:1536744920620481560@148.0/148.0/20.2] reload: could not decode view error 14:39:07.674984-0800 kernel Sandbox: chronod(2128) deny(1) file-read-metadata /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.675762-0800 kernel Sandbox: chronod(2128) deny(1) file-read-data /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.708914-0800 chronod [u 8D2C83B3-A6CB-432E-A9D4-9BC8F7056B10:m (null)] [&amp;lt;private&amp;gt;(&amp;lt;private&amp;gt;)] Connection to plugin invalidated while in use. fault 14:39:07.710284-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.803468-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; It seems that it's a permission issue, and the textview can't access the font file it needs when the widget is rendering. Notes: 1) Font is definitely registered because I can see them in for fontFamily in UIFont.familyNames {             for fontName in UIFont.fontNames(forFamilyName: fontFamily) {                 print(fontName) &amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;... in both the Main App target and the Widget Extension target 2) If I make make the font part of the app bundle and add to 'Fonts provided by application' , the are loaded absolutely fine in the Main App and the Widget on simulator and iPhone 7 real device. 3) I do see this error sometimes in the Widget extension target log, don't know if it's related. widgetxExtension[1385:254599] [User Defaults] Couldn't read values in CFPrefsPlistSource&amp;lt;0x28375b880&amp;gt; (Domain: group.co.appevolve.onewidget, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd 4) I suspected something to do with app groups, so I tried to copy the font into the Widget Extension container and load from there, but had the same result. Please help! Thank you.
9
1
3.6k
6d
Is there a difference that we should know about between using multiple @State vars or single @state store with multiple vars
Example of code: @State private var state1 = "hello" @State private var state2 = "world" @State private var state3 = 0 @State private var state4 = false Or using store @Observable class Store { var state1 = "hello" var state2 = "world" var state3 = 0 var state4 = false } // and @State var store = Store() Some things I found myself, is that using Store I can use didSet, willSet to update other vars when one changes. But if that is not needed - is there an advantage of one
0
0
69
6d
iOS 27: Opening Notification Center triggers didEnterBackground instead of remaining inactive
Has anyone else observed an app entering the background when the user simply opens Notification Center on iOS 27? In our app, fully pulling down Notification Center triggers both UIScene.didEnterBackgroundNotification and UIApplication.didEnterBackgroundNotification. The user has not pressed the side button, gone to the Home Screen, or switched to another app. In the iOS 26 environments we checked, opening Notification Center only made the app inactive. User-visible impact and recording Our app currently treats background entry during an active medication reminder as leaving that reminder session: it closes the reminder screen and schedules a follow-up. As a result, merely checking Notification Center now triggers that existing behavior. Screen recording: https://drive.google.com/file/d/1KmXEKwg1vJpCWqe56IrC_iHaEC2aH_fc/view?usp=sharing The recording shows Notification Center being opened from the reminder screen, including a return to the app's main screen instead of the reminder screen. It also includes opening and dismissing Control Center, as well as going to the Home Screen and returning to the app. These are separate interactions, not one continuous Notification Center interaction. The video illustrates the visible impact; the lifecycle evidence below comes from separate logging. Environment and observations Physical device with the issue: iPhone 14 Pro, iOS 27.0 release build 24A435. We also observed it on an iOS 27 developer beta. Devices without the issue: iPhone 11 Pro running iOS 26.5.2 and iPhone 16 Pro running iOS 26.6. Opening Notification Center did not trigger background entry on either device. These comparisons involve different devices; we have not isolated the OS version as the only variable. App lifecycle: SwiftUI App + WindowGroup + @UIApplicationDelegateAdaptor. Multiple-scene support is disabled. The app uses AlarmKit for medication reminders. Verified build environments (simulator reproduction) Reproduction build Xcode iOS SDK Our app 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 27.0 RC (27A266a) 27.0 All three groups reproduced background entry when fully opening Notification Center on the iOS 27.0 simulator (24A434). The same SDK 26.4-built minimal apps remained inactive, without entering the background, on the iOS 26.4.1 simulator (23E254a). The behavior therefore also reproduces with apps built against the older SDK, not only with the iOS 27 SDK. Steps to reproduce in our app Open the app and leave it in the foreground. Swipe down from the top-left edge to fully open Notification Center. Do not tap a notification, lock the device, or switch apps. Observe the lifecycle notifications, then dismiss Notification Center to return to the app. On the affected iOS 27 device, the behavior differs between these actions: Action Observed behavior Fully open Notification Center App becomes inactive, then enters the background Open Control Center App becomes inactive, without background entry Enter the app switcher without selecting another app or going Home App becomes inactive, without background entry Go to the Home Screen App enters the background, as expected Lifecycle evidence This is a representative trace from earlier instrumented runs, separate from the screen recording above. Times are relative to the first event: +0.000s scene.willDeactivate +0.002s app.willResignActive +0.778s scene.didEnterBackground +0.780s app.didEnterBackground In subsequent instrumented runs on the iOS 27 release build, we also observed UIScene.activationState == .background after opening Notification Center. Our application's background handler is connected to the UIKit notification, rather than an onChange handler for SwiftUI's scenePhase: .onReceive( NotificationCenter.default.publisher( for: UIApplication.didEnterBackgroundNotification ) ) { _ in delegate.handleBackgroundEntry() } Separately, a diagnostic observer uses NotificationCenter.default.addObserver to record the UIKit application and scene notifications. The background events are therefore not inferred solely from our own session state or from the reminder screen disappearing. Questions Has anyone reproduced this on iOS 27? Reports of either reproduction or non-reproduction, including device model and OS build, would be helpful. Is background entry when fully opening Notification Center expected on iOS 27, or could this be a regression or an interaction with our app configuration? Is there a supported API or documented lifecycle distinction between opening Notification Center and actually leaving the app for the Home Screen or another app? Our standalone simulator comparisons reproduced the behavior with both SwiftUI and UIKit scene-based app lifecycles, including direct sceneDidEnterBackground callbacks. For context, this earlier Apple staff response describes Notification Center as making an app foreground-inactive. I also found this iOS 27 AVPlayer report about playback stopping after Notification Center is fully opened, but I do not know whether it has the same underlying cause. Any clarification from Apple or observations from other developers would be appreciated.
0
0
317
6d
RealityKit: How to read the current audio playback position, and sync audio across multiple entities?
Hi, in RealityKit, AudioPlaybackController exposes duration, gain, speed, play/pause/stop, and a completion handler, but I can't find a way to read the current playhead position while a resource is playing. I need this to trigger animations and other timed events in sync with the audio. Is there a supported way to read the current playback position on AudioPlaybackController? If not, is this planned any time soon? Also, is there a sample-accurate way to start/keep audio playback in sync across multiple entities in RealityKit? Appreciate any guidance, thanks.
1
0
709
1w
iOS 27: SwiftUI keyboard safe area is not restored after returning to a UIHostingController
I have a SwiftUI view embedded in a UIHostingController. It contains a numeric text field at the top and a .borderedProminent button at the bottom. The text field is automatically focused when the view appears. The bottom button pushes another instance of the same hosting controller. On the initial appearance, SwiftUI correctly positions the button above the keyboard. However, after navigating back from VC2 to VC1, the text field is focused and the keyboard is visible, but the button remains behind the keyboard. This occurs regardless of whether VC2 is closed using the navigation bar back button or the interactive back gesture. This appears to be an iOS 27 regression involving SwiftUI keyboard avoidance inside a UIHostingController. The issue is especially problematic with a numeric keyboard because it has no Return or Done key. If the covered button is the primary way to continue or dismiss the keyboard, the user can no longer access it. Interestingly, the button is repositioned correctly as soon as I begin moving the app into the background. This suggests that SwiftUI still knows about the keyboard safe area but does not update the layout correctly when the hosting controller reappears after being popped to. Minimal reproducible example import SwiftUI import UIKit final class NumericInputHostingController: UIHostingController<NumericInputView> { init() { super.init( rootView: NumericInputView(onContinue: {}) ) rootView = NumericInputView { [weak self] in self?.navigationController?.pushViewController( NumericInputHostingController(), animated: true ) } } @available(*, unavailable) @MainActor required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } } struct NumericInputView: View { @State private var value = "" @FocusState private var isTextFieldFocused: Bool let onContinue: () -> Void var body: some View { VStack(spacing: 24) { TextField("Enter a number", text: $value) .keyboardType(.numberPad) .focused($isTextFieldFocused) .padding(.horizontal, 16) .frame(height: 52) .background { RoundedRectangle(cornerRadius: 10) .stroke( Color.accentColor, lineWidth: 1.5 ) } Spacer() Button("Open Another", action: onContinue) .buttonStyle(.borderedProminent) .controlSize(.large) .frame(maxWidth: .infinity) } .padding(20) .background(Color(.systemBackground)) .onAppear { DispatchQueue.main.async { isTextFieldFocused = true } } .onDisappear { isTextFieldFocused = false } } } The initial controller is embedded in a navigation controller: let controller = NumericInputHostingController() let navigationController = UINavigationController( rootViewController: controller ) Steps to reproduce Present VC1. VC1 automatically focuses the numeric text field. Confirm that the bottom button is above the keyboard. Tap the button to push VC2. Navigate back to VC1. VC1 focuses its text field and displays the numeric keyboard. Observe that the bottom button is now behind the keyboard. Begin putting the app into the background. Observe that the button suddenly moves to the correct position above the keyboard. UIKit’s keyboardLayoutGuide handles the equivalent UIKit layout correctly. Is this a known issue with keyboard safe-area updates when a UIHostingController reappears after navigation? Is there a supported SwiftUI solution that does not require observing keyboard notifications manually?
Replies
0
Boosts
0
Views
33
Activity
14h
iOS 27 beta 1: .scrollEdgeEffectStyle(.soft) renders fully transparent above safeAreaBar
Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.
Replies
22
Boosts
13
Views
4.4k
Activity
16h
Proposal: Add a System Readable Content Layout to SwiftUI SwiftUI currently does not provide a native equivalent of UIKit’s UIView.readableContentGuide. For content-heavy applications such as articles, documentation, settings, email, and media desc
Proposal: Add a System Readable Content Layout to SwiftUI SwiftUI currently does not provide a native equivalent of UIKit's UIView.readableContentGuide. For content-heavy applications such as articles, documentation, settings, email, and media descriptions, developers often need to prevent text from becoming excessively wide on iPad, Mac, and other large displays. UIKit already provides a system-level solution through: view.readableContentGuide However, there is currently no equivalent API in SwiftUI. Current Workarounds Developers currently have to choose between several approaches, none of which provides the same behavior as UIKit's readableContentGuide. 1. Hard-coded maximum width content .frame(maxWidth: 700) This is simple, but the value is arbitrary and does not adapt to the platform, window size, Dynamic Type, or system layout rules. 2. containerRelativeFrame A developer can approximate a readable width: content .containerRelativeFrame(.horizontal) { length, axis in length * 0.52 } However, this is only an approximation. Developers still have to determine the appropriate ratio themselves, and the result does not necessarily match the system's readable content width. 3. Bridging to UIKit Another workaround is to create a UIKit view/controller and obtain: view.readableContentGuide.layoutFrame The resulting width can then be passed back into SwiftUI. This works for iOS and iPadOS, but introduces UIKit-specific implementation details into an otherwise pure SwiftUI view and does not provide a natural cross-platform solution for macOS, tvOS, and other SwiftUI platforms. Proposed API I propose that SwiftUI provide a system-defined readable content layout. For example: .contentWidth(.readable) or a dedicated layout/container: ReadableContent { content } Another possibility would be a layout guide exposed through the SwiftUI environment: @Environment(\.readableContentGuide) private var readableContentGuide allowing: content .frame( maxWidth: readableContentGuide.width ) The exact API design is of course up to Apple, but the important part is that the readable width should be determined by the system rather than by application-specific constants. Expected Behavior The readable content width should be determined by the current platform and environment, taking into account factors such as: Available window/container size Platform-specific layout conventions Dynamic Type / accessibility text sizes Layout margins Safe areas Orientation Size classes where applicable Current window size on macOS Appropriate platform-specific readable widths For example, the same SwiftUI view could behave naturally across devices: iPhone ┌─────────────────────────┐ │ │ │ Readable content │ │ │ └─────────────────────────┘ iPad ┌─────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └─────────────────────────────────────────────┘ Mac ┌──────────────────────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ The developer should not need to know the exact width used by the system. Why This Belongs in SwiftUI SwiftUI already provides many environment-driven layout behaviors that automatically adapt to the current platform and device. Readable content width is similarly a semantic layout concept, rather than a fixed visual dimension. For example, developers generally should not need to write: #if os(iOS) let maxWidth = 700 #elseif os(macOS) let maxWidth = 800 #elseif os(tvOS) let maxWidth = 1000 #endif A system-provided readable layout would allow the application to express its intent instead: ReadableContent { ArticleView() } This would also make SwiftUI applications more resilient to future platform changes because Apple could adjust the underlying readable-content rules without requiring developers to update hard-coded constants. Use Cases This would be particularly useful for: Article and reading applications Documentation viewers News applications Email clients Settings and preference screens Legal/privacy documents Markdown viewers AI/chat applications Book and EPUB readers Media descriptions and metadata Forms containing large amounts of text Relationship to UIKit UIKit already establishes a precedent with: UIView.readableContentGuide SwiftUI developers should have access to the same semantic concept without needing to bridge through UIKit. The SwiftUI API does not necessarily need to expose the UIKit implementation. It could instead provide a platform-independent abstraction whose implementation is appropriate for each SwiftUI platform. Summary I would like to request a native SwiftUI API for system-defined readable content width. The ideal solution would allow developers to express: ReadableContent { ArticleView() } or: ArticleView() .contentWidth(.readable) while SwiftUI automatically determines the appropriate readable width for the current platform, window, Dynamic Type settings, and layout environment. This would eliminate the need for hard-coded maximum widths and platform-specific UIKit/AppKit workarounds, while bringing SwiftUI closer to the adaptive layout behavior already available in UIKit through readableContentGuide.
Replies
1
Boosts
1
Views
164
Activity
23h
Combining NavigationSplitView and TabView in iOS 18
Hi folks, I've used a NavigationSplitView within one of the tabs of my app since iOS 16, but with the new styling in iOS 18 the toolbar region looks odd. In other tabs using e.g. simple stacks, the toolbar buttons are horizontally in line with the new tab picker, but with NavigationSplitView, the toolbar leaves a lot of empty space at the top (see below). Is there anything I can do to adjust this, or alternatively, continue to use the old style? Thanks!
Replies
15
Boosts
3
Views
3.4k
Activity
1d
Unable to display bluetooth paired device on iOS app
Hi there, I am working on bluetooth functionality of iOS and I have a feature that display all bluetooth paired devices on list view. Is there a way to get the list of paired device using swift programming. Many Thanks!
Replies
1
Boosts
0
Views
89
Activity
1d
Using CABTMIDILocalPeripheralViewController with SwiftUI
I'm trying to make an app that can send MIDI data over Bluetooth from my iPhone to my Mac. I'm using AudioKit as a framework for the MIDI aspect, and it's working great over a wired connection. I can't figure out how to implement MIDI over Bluetooth though.I found the CABTMIDILocalPeripheralViewController page here: https://developer.apple.com/documentation/coreaudiokit/cabtmidilocalperipheralviewcontroller, which looks promising, but I'm confused about how to use it.I'd really like to implement it using SwiftUI as opposed to UIKit, because the rest of the app is made with SwiftUI. Could someone please show me how I could use this in SwiftUI to make my iPhone discoverable as a Bluetooth MIDI device?I found some sample code written with UIKit, but I'd like to translate this to SwiftUI:import UIKit import CoreAudioKit import CoreMIDI class ViewController: UIViewController { var localPeripheralViewController:CABTMIDILocalPeripheralViewController? override func viewDidLoad() { super.viewDidLoad() localPeripheralViewController = CABTMIDILocalPeripheralViewController() } @IBAction func someAction(sender: AnyObject) { self.navigationController?.pushViewController(localPeripheralViewController!, animated: true) } }Thank you,Jack
Replies
5
Boosts
0
Views
1.3k
Activity
1d
SwiftUI Navigation Flicker When Navigating Between Screens With and Without .searchable
I’m experiencing a UI flickering issue in a SwiftUI application related to navigation and the .searchable modifier. I have the following navigation flow: Case 1: Event Dashboard ↓ Attendee List ↓ Back to Event Dashboard The Event Dashboard contains an event image at the top. The Attendee List has a navigation bar with a .searchable search field. When I navigate back from the Attendee List to the Event Dashboard, the event image briefly becomes smaller and then returns to its original size after approximately one second. Case 2: Event Dashboard ↓ Attendee List ↓ Attendee Detail The Attendee List contains .searchable, while the Attendee Detail screen does not. When navigating from the Attendee List to the Attendee Detail screen, the attendee profile image similarly becomes slightly smaller and then enlarges back to its original size. The behavior appears to be related to the navigation bar/search bar layout changing between screens. For example, the Attendee List currently uses: .searchable( text: $model.searchQuery, placement: .navigationBarDrawer, prompt: "Search" ) If I completely remove .searchable from the Attendee List, the flickering does not occur. I would like to understand whether this is expected SwiftUI behavior or a known issue with .searchable and navigation transitions. I am considering testing the Attendee List with ScrollView + LazyVStack instead of List to determine whether List is contributing to the issue.
Replies
4
Boosts
0
Views
702
Activity
1d
Incorrect initial Navigation Bar height when combining topEdgeEffect, .toolbar, and .ignoresSafeArea()
Description: When wrapping a UIKit UIScrollView in SwiftUI via UIViewControllerRepresentable, applying topEdgeEffect.style = .hard, then using .toolbar() and .ignoresSafeArea(.container) on the SwiftUI view causes an incorrect/truncated initial height of Navigation Bar on first load. The height will refresh to the correct value after backgrounding the app or switching tabs. Steps to Reproduce: Wrap a UICollectionViewController in UIViewControllerRepresentable. Set collectionView.topEdgeEffect.style = .hard. Embed it in a SwiftUI NavigationStack and apply .toolbar() and .ignoresSafeArea() Happens on Xcode 26.x and iOS 26.x (untested on 27s).
Replies
1
Boosts
0
Views
340
Activity
1d
How to implement correct horizontal padding for iPhone Duo
On iPhone Duo in the folded state, the outer screen displays a vertical bar on the right edge with view contents inset. I noticed Form displays an appropriate amount of leading padding but 0 padding on the trailing edge, since the vertical bar provides some padding already, so it looks nice. I have a view that looks kind of like a form, multiple stacked text fields, that should align the same way. I used scenePadding to achieve this and it looks correct on iPhone 18 Pro perfectly aligning with Form. Unfortunately on iPhone Duo there is extra trailing padding such that it doesn't align with the edit button that remains in the horizontal axis navigation bar (and it is not inset enough on the leading edge, off by a few pixels, interestingly). Note when you unfold it and add the app on the left side in Split View, the vertical bar is on the leading edge, in which case there's too much padding on the leading edge. How can I achieve the correct padding? My actual app: struct ContentView: View { var body: some View { TabView { NavigationStack { SystemFormView() .navigationTitle("System Form") } .tabItem { Label("System Form", systemImage: "list.bullet.rectangle") } NavigationStack { CustomFormView() .navigationTitle("Custom Form") } .tabItem { Label("Custom Form", systemImage: "rectangle.3.group") } } } } private struct SystemFormView: View { var body: some View { Form { Text("Row 1") Text("Row 2") Text("Row 3") } } } private struct CustomFormView: View { var body: some View { ScrollView { VStack(spacing: 0) { customRow("Row 1") Divider() .padding(.leading) customRow("Row 2") Divider() .padding(.leading) customRow("Row 3") } .background(.background) .scenePadding(.horizontal) } .background(Color(uiColor: .systemGroupedBackground)) } private func customRow(_ title: LocalizedStringKey) -> some View { Text(title) .frame(maxWidth: .infinity, minHeight: 44, alignment: .leading) .padding(.horizontal) } }
Replies
0
Boosts
1
Views
207
Activity
2d
How to separate/add space between Liquid Glass toolbar items when using ToolbarOverflowMenu
The following code works as expected to display two separate Liquid Glass toolbar buttons with space between them: struct ContentView: View { var body: some View { NavigationStack { Text("Hello, World") .toolbar { ToolbarItem { Button("Add", systemImage: "plus") { } } ToolbarSpacer(.fixed) ToolbarItem { Menu { Button("Settings", systemImage: "gearshape") { } } label: { Label("More", systemImage: "ellipsis") } } } } } } When optimizing for iPhone Duo (and in general) I understand the recommendation is to replace custom "more" menus with the system overflow menu, otherwise it's possible you can see two ... buttons in various scenarios. struct ContentView: View { var body: some View { NavigationStack { Text("Hello, World") .toolbar { ToolbarItem { Button("Add", systemImage: "plus") { } } ToolbarSpacer(.fixed) ToolbarOverflowMenu { Button("Settings", systemImage: "gearshape") { } } } } } } This unexpectedly places both + and ... inside the same shared Liquid Glass background. How do you separate / add space between them, or is this a bug, is there a workaround? Before / After
Replies
0
Boosts
0
Views
63
Activity
2d
New Swiftui Text timer not counting down
Hi using this new Text method for timers is not counting down. Here is an example of how I implemented it. Text(.now, format:.timer(countingDownIn: Date.now..<Date.now.addingTimeInterval(120), showsHours: true, maxFieldCount: 2, maxPrecision: .seconds(60)) ) After waiting over a minute it never counts down
Replies
4
Boosts
1
Views
2.7k
Activity
3d
Best practice Replacement for Edit Button on iPhone Duo
On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?
Replies
0
Boosts
0
Views
125
Activity
3d
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
Replies
6
Boosts
1
Views
2.3k
Activity
3d
DragGesture latency on iOS 27
As of iOS 27, DragGesture(minimumDistance: 0) no longer functions as a reliable touch detector, at least without a noticeable delay before the gesture is recognized. This is very frustrating, as this was one of the few decent ways to detect touch down (and up) events in more complicated gesture handling scenarios. Some level of delay for gesture disambiguation is of course expected in certain cases, but this is reproducible even when the drag gesture is the sole gesture in the view hierarchy. Further, this was never a problem on iOS 26 and below. To see the issue, run an app containing the following view and tap the green rectangle rapidly. On iOS 27, the opacity won't change at all, while on iOS 26 and below it will flash rapidly as expected. To make matters much worse, the latency goes from slight but noticeable to ridiculous if the view is placed anywhere in the bottom 1/5 or so of the screen. System gestures seem to be interfering. Again, this was not an issue before iOS 27. struct PressDetectView: View { @GestureState private var isPressed = false var body: some View { Rectangle() .fill(.green) .opacity(isPressed ? 0.5 : 1) .gesture(dragGesture) } private var dragGesture: some Gesture { DragGesture(minimumDistance: 0) .updating($isPressed) { value, state, _ in state = true print("drag") } } } Any workarounds?
Replies
1
Boosts
4
Views
609
Activity
4d
Looking for feedback on my newly published iOS app: Nexora AI (Built with SwiftUI)
Hello everyone 👋 I’m an engineer and self-taught iOS developer. I recently published my app, Nexora AI, on the App Store. The app is designed to help students study smarter using AI-driven features like PDF analysis, instant problem solving, flashcard generation, and study/exam planning. As a solo developer, I’d love to gather feedback on UX/UI flow, performance, and general user experience from the community. If you have a moment to test it out or share any thoughts, I’d greatly appreciate it! 📲 App Store Link: https://apps.apple.com/tr/app/nexora-ai/id6770621015 Thanks for your time and feedback!
Replies
0
Boosts
0
Views
132
Activity
4d
.contactAccessPicker shows blank sheet on iOS 26.2.1 on device
Calling contactAccessPicker results in a blank sheet and a jetsam error, rather than the expected contact picker, using Apple’s sample code, only on device with iOS 26.2.1. This is happening on a iPhone 17 Pro Max running 26.2.1, and not on a simulator. I’m running Apple's sample project Accessing a person’s contact data using Contacts and ContactsUI Steps: Run the sample app on device running iOS 26.2.1. Use the flow to authorize .limited access with 1 contact: Tap request access, Continue, Select Contacts. Select a contact, Continue, Allow Selected Contact. This all works as expected. Tap the add contact button in the toolbar to add a second contact. Expected: This should show the Contact Access Picker UI. Actual: Sheet is shown with no contents. See screenshot of actual results on iOS device running 26.2.1. Reported as FB21812568 I see a similar (same?) error reported for 26.1. It seems strange that the feature is completely broken for multiple point releases. Is anyone else seeing this or are the two of us running into the same rare edge case? Expected Outcome, seen on simulator running 26.2 Actual outcome, seen on device running 26.2.1
Replies
9
Boosts
3
Views
1.3k
Activity
4d
iOS Dynamically loaded custom fonts in WidgetKit not working on real device (simulator is fine). Sandbox chronod deny file-read-data for font file.
Project structure is: App target + widget extension + widget intent extension All share a common appgroup group.com.x.y and all file handling is done using FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.x.y") so that only the shared container is used. Using the Main app target, a font "Chewy-Regular.ttf" is downloaded and saved to the shared AppGroup container. Font can now be loaded via CTFontManagerRegisterFontsForURL and displayed in a Main App Text view Text("Testing...").font(Font.custom("Chewy-Regular", size: 20)) Now add a Widgetkit widget instance that uses this font. In 'getTimeLine() and getSnapShot() of IntentTimelineProvider we load the font again via CTFontManagerRegisterFontsForURL (this needs to happen again probably because widget runs in a separate process from the main app?). On simulator, the widget will show the correct font. BUT On iPhone7 real device, the widget will show the 'redacted placeholder view'. It seems that something is crashing. I see in the device console : error 14:39:07.567120-0800 chronod No configuration found for configured widget identifier: D9BF75EE-4A04-441A-8C85-1507F7ECE379 fault 14:39:07.625600-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.672733-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; error 14:39:07.672799-0800 chronod [co.appevolve.onewidget.widgetx:widgetx:small:1536744920620481560@148.0/148.0/20.2] reload: could not decode view error 14:39:07.674984-0800 kernel Sandbox: chronod(2128) deny(1) file-read-metadata /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.675762-0800 kernel Sandbox: chronod(2128) deny(1) file-read-data /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.708914-0800 chronod [u 8D2C83B3-A6CB-432E-A9D4-9BC8F7056B10:m (null)] [&amp;lt;private&amp;gt;(&amp;lt;private&amp;gt;)] Connection to plugin invalidated while in use. fault 14:39:07.710284-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.803468-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; It seems that it's a permission issue, and the textview can't access the font file it needs when the widget is rendering. Notes: 1) Font is definitely registered because I can see them in for fontFamily in UIFont.familyNames {             for fontName in UIFont.fontNames(forFamilyName: fontFamily) {                 print(fontName) &amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;... in both the Main App target and the Widget Extension target 2) If I make make the font part of the app bundle and add to 'Fonts provided by application' , the are loaded absolutely fine in the Main App and the Widget on simulator and iPhone 7 real device. 3) I do see this error sometimes in the Widget extension target log, don't know if it's related. widgetxExtension[1385:254599] [User Defaults] Couldn't read values in CFPrefsPlistSource&amp;lt;0x28375b880&amp;gt; (Domain: group.co.appevolve.onewidget, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd 4) I suspected something to do with app groups, so I tried to copy the font into the Widget Extension container and load from there, but had the same result. Please help! Thank you.
Replies
9
Boosts
1
Views
3.6k
Activity
6d
Is there a difference that we should know about between using multiple @State vars or single @state store with multiple vars
Example of code: @State private var state1 = "hello" @State private var state2 = "world" @State private var state3 = 0 @State private var state4 = false Or using store @Observable class Store { var state1 = "hello" var state2 = "world" var state3 = 0 var state4 = false } // and @State var store = Store() Some things I found myself, is that using Store I can use didSet, willSet to update other vars when one changes. But if that is not needed - is there an advantage of one
Replies
0
Boosts
0
Views
69
Activity
6d
iOS 27: Opening Notification Center triggers didEnterBackground instead of remaining inactive
Has anyone else observed an app entering the background when the user simply opens Notification Center on iOS 27? In our app, fully pulling down Notification Center triggers both UIScene.didEnterBackgroundNotification and UIApplication.didEnterBackgroundNotification. The user has not pressed the side button, gone to the Home Screen, or switched to another app. In the iOS 26 environments we checked, opening Notification Center only made the app inactive. User-visible impact and recording Our app currently treats background entry during an active medication reminder as leaving that reminder session: it closes the reminder screen and schedules a follow-up. As a result, merely checking Notification Center now triggers that existing behavior. Screen recording: https://drive.google.com/file/d/1KmXEKwg1vJpCWqe56IrC_iHaEC2aH_fc/view?usp=sharing The recording shows Notification Center being opened from the reminder screen, including a return to the app's main screen instead of the reminder screen. It also includes opening and dismissing Control Center, as well as going to the Home Screen and returning to the app. These are separate interactions, not one continuous Notification Center interaction. The video illustrates the visible impact; the lifecycle evidence below comes from separate logging. Environment and observations Physical device with the issue: iPhone 14 Pro, iOS 27.0 release build 24A435. We also observed it on an iOS 27 developer beta. Devices without the issue: iPhone 11 Pro running iOS 26.5.2 and iPhone 16 Pro running iOS 26.6. Opening Notification Center did not trigger background entry on either device. These comparisons involve different devices; we have not isolated the OS version as the only variable. App lifecycle: SwiftUI App + WindowGroup + @UIApplicationDelegateAdaptor. Multiple-scene support is disabled. The app uses AlarmKit for medication reminders. Verified build environments (simulator reproduction) Reproduction build Xcode iOS SDK Our app 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 27.0 RC (27A266a) 27.0 All three groups reproduced background entry when fully opening Notification Center on the iOS 27.0 simulator (24A434). The same SDK 26.4-built minimal apps remained inactive, without entering the background, on the iOS 26.4.1 simulator (23E254a). The behavior therefore also reproduces with apps built against the older SDK, not only with the iOS 27 SDK. Steps to reproduce in our app Open the app and leave it in the foreground. Swipe down from the top-left edge to fully open Notification Center. Do not tap a notification, lock the device, or switch apps. Observe the lifecycle notifications, then dismiss Notification Center to return to the app. On the affected iOS 27 device, the behavior differs between these actions: Action Observed behavior Fully open Notification Center App becomes inactive, then enters the background Open Control Center App becomes inactive, without background entry Enter the app switcher without selecting another app or going Home App becomes inactive, without background entry Go to the Home Screen App enters the background, as expected Lifecycle evidence This is a representative trace from earlier instrumented runs, separate from the screen recording above. Times are relative to the first event: +0.000s scene.willDeactivate +0.002s app.willResignActive +0.778s scene.didEnterBackground +0.780s app.didEnterBackground In subsequent instrumented runs on the iOS 27 release build, we also observed UIScene.activationState == .background after opening Notification Center. Our application's background handler is connected to the UIKit notification, rather than an onChange handler for SwiftUI's scenePhase: .onReceive( NotificationCenter.default.publisher( for: UIApplication.didEnterBackgroundNotification ) ) { _ in delegate.handleBackgroundEntry() } Separately, a diagnostic observer uses NotificationCenter.default.addObserver to record the UIKit application and scene notifications. The background events are therefore not inferred solely from our own session state or from the reminder screen disappearing. Questions Has anyone reproduced this on iOS 27? Reports of either reproduction or non-reproduction, including device model and OS build, would be helpful. Is background entry when fully opening Notification Center expected on iOS 27, or could this be a regression or an interaction with our app configuration? Is there a supported API or documented lifecycle distinction between opening Notification Center and actually leaving the app for the Home Screen or another app? Our standalone simulator comparisons reproduced the behavior with both SwiftUI and UIKit scene-based app lifecycles, including direct sceneDidEnterBackground callbacks. For context, this earlier Apple staff response describes Notification Center as making an app foreground-inactive. I also found this iOS 27 AVPlayer report about playback stopping after Notification Center is fully opened, but I do not know whether it has the same underlying cause. Any clarification from Apple or observations from other developers would be appreciated.
Replies
0
Boosts
0
Views
317
Activity
6d
RealityKit: How to read the current audio playback position, and sync audio across multiple entities?
Hi, in RealityKit, AudioPlaybackController exposes duration, gain, speed, play/pause/stop, and a completion handler, but I can't find a way to read the current playhead position while a resource is playing. I need this to trigger animations and other timed events in sync with the audio. Is there a supported way to read the current playback position on AudioPlaybackController? If not, is this planned any time soon? Also, is there a sample-accurate way to start/keep audio playback in sync across multiple entities in RealityKit? Appreciate any guidance, thanks.
Replies
1
Boosts
0
Views
709
Activity
1w