“swiftui”

On iPadOS 27.0 beta 4, SwiftUI views hosted inside UIKit-managed containers/overlays can be laid out incorrectly. The same app and same code work correctly on iPadOS 26.x release versions. One visible example is the app’s About dialog. The dialog is implemented as a UIKit UIViewController presented with UIModalPresentationFormSheet. Inside that controller, a UIHostingController is added as a child view controller, and the hosting controller’s view is constrained to all four edges of the parent view. The SwiftUI root view is a VStack containing the app icon, app name, version, text, links, and buttons. Expected behavior: The SwiftUI content should be vertically centered inside the form sheet. The app icon should appear above the app title, followed by the version, text, links, and buttons. This is the behavior on iPadOS 26.x. Actual behavior on iPadOS 27.0 beta 4: When the About dialog is opened immediately after launching the app, this issue occurs intermittently. The form sheet its

On Mac Catalyst, RealityKit TextComponent renders vertically inverted text. The issue occurs with both ARView and RealityView. The same text renders correctly on iOS and in a native macOS RealityView application (not Catalyst). Tested on macOS 26 and macOS 27 beta, with Xcode 26 and Xcode 27 Beta. Here is a screenshot of a text entity with a text component rendering the string Text Component: Workaround On Mac Catalyst: Detect when the model generated by TextComponent becomes available on the text entity. Find the generated UnlitMaterial in the ModelComponent of the text entity. Disable face culling on the material. Invert the Y scale of the text entity. Here is the result: Reproduce Below is the full code that reproduces the problem, with both ARView and RealityView, as well as the workaround implementation. import SwiftUI import RealityKit import Combine // MARK: Text func createTextEntity() -> Entity { let textEntity = Entity() let attributes: [NSAttributedString.Key: Any] = [ .font: MeshResour

We build apps at Appther, and our sleep and anxiety app DeepRest had a stubborn onboarding problem. Users installed, opened it once, and a big chunk never reached the core experience. We rewrote the flow three times before it clicked. Sharing what actually moved the needle, in case it saves someone else the loops. What did not work first: We front-loaded everything. Account creation, notification permission, and a long value-pitch carousel all before the user touched anything real. Every gate was a place to quit, and people quit. What finally worked: We let people reach value before asking for anything. No sign-in wall on launch. They could try a core session first, then create an account only when they wanted to save progress. Drop-off fell sharply at that one change alone. We primed permissions instead of demanding them. Before the system notification prompt, we showed a plain screen explaining why reminders help sleep consistency. The soft ask before the hard ask lifted our opt-in rate a lot. We cut steps

I have a SwiftUI + SwiftData app where scrolling became very slow, and I've traced it to something about @Query I didn't expect. The app was running save for each lazy list item appearing in viewport (a separate bug, but it did highlight the problem), which made the whole list re-render on each save. After tracing why this happens I have discovered that it is because another model watched in the list parent is invalidated after every save, and the problem was that this another model has @Query in a separate view (sidebar), removing that @Query fixed the problem. Here is a minimal reproduction of this https://github.com/aytigra/QueryRefaultRepro I wonder if it is a bug or an expected behavior?

Here I have some demo code that is rendering a cylinder platter using RealityKit and there is a red circle rendered on top of it which uses Metal and SwiftUI. When the platter appears you will see in the console that makeUIView(context:) is called twice while it is documented that it will only be called once when the view appears for the first time. So this seems like a bug. If you remove ManipulationComponent from the platter's components you will see that this problem goes away so it seems like that is the cause of the problem. Any insight here would be appreciated! Thank you. Here is what is printed in the console: Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies. Make UI View! This should be called once. Make UI View! This should be called once. Here is the app code: import SwiftUI @main struct SomeApp: App { var

On visionOS 27 (27.0 Seed 4, 24M5326g), adding a ManipulationComponent to a single entity makes RealityKit remove the RealityView's ENTIRE content hierarchy from the scene and re-add it about 30ms later. Not just the manipulated entity — everything. Same app binary on visionOS 26: never happens. FB24092291. Bisected on the same build and device: two entities, neither with manipulation -> no detach add one entity with a ManipulationComponent -> detach, every time same entity, manipulation swapped for my own drag/rotate/ scale gesture handling -> no detach Everything else is identical between the last two cases — same entity, same collision shape, same InputTargetComponent, same ViewAttachmentComponent, same scene, same view hierarchy. The only variable is whether the component is installed. Setup: an immersive space containing a SwiftUI RealityView. One root entity added to the RealityViewContent in the make closure; all app content built as its descendants. The detach is brief but not harmle

Filed as FB24092251. On macOS 27.0 beta (26A5388g), clicking into any text input inside a WKWebView in a Mac Catalyst app makes focus oscillate forever and typing does nothing. CPU pegs at 100% while the editor is focused. The same binary works fine on macOS 26. The DOM element never actually loses focus. Only the window does: window focus -> activeElement=TEXTAREA.inputarea JS focus -> activeElement=TEXTAREA.inputarea window blur -> activeElement=TEXTAREA.inputarea <- window loses key status JS blur -> activeElement=TEXTAREA.inputarea <- element did not ...repeats indefinitely... Pausing during the loop shows why. Focusing the element sends WebKit into UIKit's software-keyboard machinery, on a platform that has no software keyboard: -[UIKeyboardSceneDelegate containerWindowForViewService:] -[UIKeyboardSceneDelegate _setKeyWindowSceneInputViews:animationStyle:] -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] -[UIResponder(UIResponderInputViewAdditions

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 ne

import SwiftUI import Playgrounds @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct AccountView: View{ var body: some View{ Text(111) } } struct ChatView: View{ var body: some View{ Text(222) } } struct ProjectView: View{ var body: some View{ Text(333) } } struct EnvView: View{ var body: some View{ Text(444) } } struct ContentView: View { var body: some View { NavigationSplitView { List{ NavigationLink(Account,value: 1) NavigationLink(Chat,value: 2) NavigationLink(Project,value: 3) NavigationLink(Enviroments,value: 4) } } detail: { NavigationStack{ VStack{ Text(SB) } .navigationDestination(for: Int.self) { number in switch number { case 1: AccountView() case 2: ChatView() case 3: ProjectView() case 4: EnvView() default: Text(未知页面) } } } } } } #Preview { ContentView() } I want to write a sidebar to change pages, I wrote some codes by advices of Deepseek, but it didn't work, it just stay in the VStack under the contentView. Help me:sob:

Description When a searchable List is presented inside a sheet and uses .searchPresentationToolbarBehavior(.avoidHidingContent) to keep the navigation bar visible during search, the list cells flicker/blink under the keyboard This reproduces with public SwiftUI API only — no UIKit, no appearance-proxy customization. Steps to Reproduce Create a new iOS App (SwiftUI) project (deployment target iOS 17.1+). Replace the generated App file with the sample code below. Run on iOS 26 (reproduces on both device and Simulator). Tap Open transfer methods to present the sheet. Tap the search field so the keyboard is shown (search becomes active). Scroll the list down, then up into the top bounce (overscroll) Observe the cells under the keyboard. Expected Cells scroll smoothly under the keyboard; no flicker. Actual Cells under the keyboard flicker/blink during top overscroll. See the attachments with shots of the process: 1. screen before a blink, 2. Screen in the moment of blinking Sample Code import SwiftUI

This was confirmed as a framework gap in an accepted answer from an Apple Vision Pro engineer in June 2024 (https://developer.apple.com/forums/thread/758014?answerId=792769022#792769022): .background fires identically whether the user taps a window's close button or the system backgrounds a window that's been out of the field of view for ~61 seconds, and there's no app-visible signal that distinguishes the two. The recommendation at the time was to use a gesture/affordance to reopen the window, and to file an enhancement request. Two years on, with the window-management APIs that have shipped since, I want to confirm whether the situation has changed as of visionOS 26. My case: VisionBlazer, a native spatial 3D creation tool (TestFlight beta, August 2026 launch). Users routinely work with several SwiftUI WindowGroup tool windows open at once — drawing tools, materials, timeline, properties, lighting — parked spatially around an ImmersiveSpace. Parking a window behind or beside you is core to the work

Hi, I've been using Xcode with Codex. I have come to the conclusions that the only window I need open 99.8% of the time is the AI conversation window. After working with this setup for almost a month duration and 80 hours of actual work, I don't bother to look at any of the code. I look at the results and guide Codex to design and implement and help debug. The fact that the AI window acts like a standard coding window is a mistake on the Xcode designers part. That window should never be closed or replaced if you happen to try to look at a file. That window is not the main focus for Xcode in the hands of an expert iOS developer. Yes I will place myself in the category, even though I don't know everything about iOS development. The entire approach is a shocking change for me, as I assume it is for others. I'm in awe of how well Codex works with Xcode and/or the MacOS command line tools. This brings up another point, it seems the Codex does most of it's work via the command line. I'm not sure I like this, but th