Hi, Charts—specifically those with multiple lines—are broken in Xcode 27. First, I spotted the bug in my program, and then I checked your example. Your own example Plotting-multiple-lines is not working correctly anymore. It shows 1 line or sometimes no lines at all, depending on the order of the data. It depends on how the data is passed to the chart. If the data is passed as separate series, it works. In Visualizing your app’s data it works, but the data is passed as described before. Don't follow Microslop: have the AI ​​generate the code and then skip the tests. This is a serious bug that requires a lot of work to rearrange the data, just to work around the issue. Christian

presentationPlacement(_:) is a great addition and brings us very close to being able to deprecate a custom side sheet we wrote, but one missing piece we found is that it isn't yet honored on Catalyst. It would be great if support for this could be added!

I have CarPlay Video enabled for my account and App ID. I tested both my main app and a completely new minimal iOS app with a new Bundle ID. The minimal app only contains: UIApplicationDelegate CPTemplateApplicationScene configuration CPTemplateApplicationSceneDelegate A single CPListTemplate root Results: With com.apple.developer.carplay-audio only, CarPlay launches normally. When com.apple.developer.carplay-video is added, CarPlay opens a blank screen. No CarPlay callbacks are called: application(:configurationForConnecting:options:) CPTemplateApplicationSceneDelegate.templateApplicationScene(:didConnect:) CPApplicationDelegate.didConnectCarInterfaceController The signed app and embedded provisioning profile both contain com.apple.developer.carplay-video. Does CarPlay Video require an additional runtime allowlist, specific head unit support, a different scene configuration, or another entitlement beyond com.apple.developer.carplay-video?

Test complete. Markup was filtered as expected.

When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?

Since iOS 27, if an app runs in Arabic (or, presumably, any right-to-left language), typing digits or Latin letters into a SwiftUI TextField makes the field look empty. The binding updates and the caret shows, but the text isn't drawn until editing ends. What I measured: The text's layout fragment is placed at about x = −39,655 pt in a 370 pt wide field, so it's drawn far outside the field. A plain TextField and one with .environment(\.layoutDirection, .leftToRight) (phone and card numbers) are both affected. A UIKit UITextField on the same screen isn't affected. The same build on iOS 18.0 works, and iOS 27 in English works. Minimal repro: one SwiftUI file with four fields. Run it with App Language set to Arabic, tap the first field and type 523. Launch with -autoProbe to have it type into each field and print where the text was laid out. PROBE iOS 27.0, language ar, layout RTL PROBE field 1 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI TextField PROBE field 2 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI, LTR pinned PROBE field 3 text="523" fieldWidth=370 fragmentX=[314] visible=true // UIKit UITextFieldWorkaround that works for us, installed once at launch: import UIKit enum TextFieldDirection { static func install() { for name in [UITextField.textDidBeginEditingNotification, UITextField.textDidChangeNotification] { NotificationCenter.default.addObserver(forName: name, object: nil, queue: .main) { note in guard let field = note.object as? UITextField else { return } MainActor.assumeIsolated { settle(field) } // SwiftUI rebuilds the paragraph style right after; settle again. DispatchQueue.main.async { MainActor.assumeIsolated { settle(field) } } } } } @MainActor static func settle(_ field: UITextField) { let direction: NSWritingDirection = field.effectiveUserInterfaceLayoutDirection == .rightToLeft ? .rightToLeft : .leftToRight if let whole = field.textRange(from: field.beginningOfDocument, to: field.endOfDocument) { field.setBaseWritingDirection(direction, for: whole) } func directed(_ attributes: [NSAttributedString.Key: Any]) -> [NSAttributedString.Key: Any] { var attributes = attributes let style = (attributes[.paragraphStyle] as? NSParagraphStyle)?.mutableCopy() as? NSMutableParagraphStyle ?? NSMutableParagraphStyle() style.baseWritingDirection = direction attributes[.paragraphStyle] = style return attributes } if let typing = field.typingAttributes { field.typingAttributes = directed(typing) } field.defaultTextAttributes = directed(field.defaultTextAttributes) field.setNeedsLayout() field.layoutIfNeeded() } }Don't pin textAlignment instead. SwiftUI puts .natural back on every keystroke and the caret jumps from side to side. If you see this too, please file a duplicate referencing FB25410049. Duplicates help Apple prioritise it.

I have a detail view that has a @Binding var Thing, which is passed to it from the parent. It has TextFields that need to use that bound object's fields. // Using this to pass the selection around @Observable class AppSelection { var selectedThings:Set<Thing> = Set(); } struct ContentView: View { @State private var selectionStore = AppSelection(); var body: some View { NavigationSplitView { ... } content: { ...list that sets the selectionStore.selectedThings... } detail: { if !selectionStore.selectedThings.isEmpty { DetailView(thing:Binding( get: { selectionStore.selectedThings.first! }, // Crashes here set: { selectionStore.selectedThings = [$0] } )) .frame(maxHeight:.infinity, alignment:.top) } else { Text("Select a thing."); } } } } struct DetailView:View { @Binding var thing:Thing; var body:some View { TextField("Blah", $thing.name); TextField("Blerg", $thing.stuff); } }A crash happens when I navigate back from the DetailView in the line commented as such. I assume the NavigationSplitView is resetting the selection back to an empty state. Why the Binding given to the DetailView is even trying to get its value at that point is beyond me (so much weirdness in SwiftUI). I've taken so many different stabs at trying to make things work differently, but I just don't understand enough about SwiftUI. Like can I make the DetailView take an optional binding? If the Thing is nil, then all the TextFields complain that they require a non-optional binding. I don't even want to show the Detail view if nothing is selected (hence the "Select a thing.").

what is the swift UI code to make a button do something, like go to another page of my app

struct ContentView: View { @State var searchText: String = "" var body: some View { TabView { Tab { NavigationStack { List { Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") } .navigationTitle("Have a title") .searchable(text: $searchText, placement: .toolbar) .searchToolbarBehavior(.minimize) .toolbar { DefaultToolbarItem(kind: .search, placement: .topBarTrailing) } } } } } } In iOS 26, this worked no problem. In iOS 27, this leaves the search bar either unable to collapse (when pressing the close button) or in a broken state where it cannot be opened again.

Hi, I already had a problem with the NavigationSplitView before, and I'm still working on it. The NavigationSplitView issue on the phone occurs when trying to navigate back from the detail view to the content view; the app automatically navigates straight back to the detail view. I reproduced the issue in a small program and identified the critical section. However, I do not know why the problem is occurring. I did the same thing again, but this time with @Query, and there was no problem. The categories, recipes and single recipe, all loaded by @Query and no side effects. Requirements for the content: A state variable used in the view, e.g., isLoading A task that loads the data from a ModelActor in a ViewModel, setting isLoading to true beforehand and back to false upon completion Subsequently, it is only possible to exit the detail view after many attempts, because the app immediately navigates back to the detail view automatically upon trying to leave it. One issue is changing the isLoading status variable from within the task. That in itself isn't the problem; the issue only arises when reading data via a ModelActor. If the status variable is changed and, for example, the list is modified manually, there is no problem. It only occurs when a ModelActor is used. I based it on the NavigationCookbook: This is the view I use for the content section (list): @State private var vm: RecipeListViewModel = .init() @State var isLoading: Bool = false if isLoading { ProgressView("Loading...") } else { List(selection: $selectedRecipe) { ForEach(vm.recipes) { recipe in NavigationLink(recipe.name, value: recipe) } } } .task { // bug, when used in UI, because of ModelActor isLoading = true await vm.list(context, categoryName: selectedCategory.name) isLoading = false } .task { // works, because manually modifying the list isLoading = true await vm.addRecipe(context, categoryName: selectedCategory.name) isLoading = false } inside ViewModel // bug func list(_ modelContext: ModelContext, categoryName: String) async { recipes.removeAll() let dh: RecipeDataHandler = .init(modelContainer: modelContext.container) let values = await dh.listByName(categoryName: categoryName) for v in values { recipes.append(.init(recipeId: v.recipeId, name: v.name)) } } // works func addRecipe(_ modelContext: ModelContext, categoryName: String) async { isLoading = true defer { isLoading = false } recipes.removeAll() recipes.append(.init(recipeId: "a", name: "Pambazo")) } ModelActor @ModelActor actor RecipeDataHandler { func listByName(categoryName: String) async -> [RecipeData] { var list: [RecipeData] = [] do { let fd = FetchDescriptor<Recipe>(predicate: #Predicate { $0.category.name == categoryName }, sortBy: [SortDescriptor(\Recipe.name)]) let data = try modelContext.fetch(fd) for item in data { let rec: RecipeData = await .init(recipeId: item.recipeId, name: item.name) list.append(rec) } } catch { print("error: \(error.localizedDescription)") } return list } } Recipe is a @Model and RecipeData just a struct. In principle, everything should run on the MainActor, but the inclusion of the ModelActor still leads to this strange behavior. Any idea what the problem might be? Christian

Bug Report: Xcode 26.6 Codex Agent Fails with Response Decoding and Model Compatibility Errors Severity: High — Core agent functionality unavailableComponent: Xcode Intelligence / Codex Agent IntegrationEnvironment: macOS, Xcode 26.6 (17F113)Date reported: November 1, 2026 Summary The built-in Codex coding agent in Xcode consistently fails to process requests, despite successful ChatGPT Pro authentication and a functioning standalone Codex CLI. The problem occurs even with trivial prompts and prevents use of Codex's autonomous development functionality, including the Pursue Goal workflow. The standard ChatGPT integration inside Xcode works correctly. The failure is isolated to the Codex agent integration. Environment ComponentDetailsIDEXcode 26.6 (17F113)Built-in Codex agent0.140.0 (version observed before reinstall)Standalone Codex CLI0.166.0ACP adapter testedcodex-acp 2.5.0AccountChatGPT ProAuthenticationChatGPT account authenticationAffected projectsMultiple SwiftUI projectsModel testedgpt-5.5, gpt-6.1-solActual Behavior When initiating a conversation with the built-in Codex agent in Xcode, the request fails with the following messages: Error 1: Response decoding failure The data couldn’t be read because it isn’t in the correct format.Accompanied by: Your request couldn't be completed.Error 2: Unsupported model With the original model selection: Codex encountered an error: The 'gpt-5.5' model is not supported when using Codex with a ChatGPT account.After explicitly configuring gpt-6.1-sol: Codex encountered an error: The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.Error 3: ACP communication failure When testing a separately registered Codex ACP adapter: JSON-RPC request with ID [...] failed to produce a response.This was observed in a separate integration experiment and should not automatically be assumed to share the same root cause as the built-in Codex failure. Expected Behavior The built-in Codex agent should: Authenticate with an eligible ChatGPT Pro account. Select a model supported by the account and installed agent version. Correctly initialize the agent and decode its protocol responses. Execute basic prompts without errors. Support Xcode's native agentic development workflows, including Pursue Goal. Present actionable diagnostics when authentication, model selection, or protocol initialization fails. Reproduction Steps Open Xcode 26.6. Open an existing SwiftUI project. Open the Coding Assistant. Start a new conversation. Select Codex under Agents, rather than OpenAI under Chat. Submit a trivial prompt, such as: Reply with exactly OK. Observe the request failing with a response-format error or an unsupported-model error, depending on configuration. The issue is reproducible across multiple attempts and is not specific to a complex coding task. Troubleshooting Performed The following troubleshooting actions have already been attempted: Reauthenticated using the ChatGPT account. Tested configuration-file-based authentication. Reset Codex authentication. Reinstalled Xcode. Reinstalled the Xcode Codex component. Restarted Xcode and created new conversations. Tested explicit model selection through config.toml. Tested standalone Codex with the same ChatGPT Pro account. Tested a separate ACP adapter integration. The built-in Codex agent remains unusable. Confirmed Successful Control Test Standalone Codex CLI 0.166.0 successfully executed a request using GPT-6.1 Sol. Command: codex exec --model gpt-6.1-sol --skip-git-repo-check \ "Reply with exactly OK. Do not edit files or use tools."Observed output: OpenAI Codex v0.166.0 model: gpt-6.1-sol provider: openai reasoning effort: high codex OKThe request completed without an API error. Additionally, Xcode's separate ChatGPT integration displays the ChatGPT Pro account as authenticated, with usage status Under Limit. These observations strongly suggest that the problem is specific to the Xcode Codex integration or its runtime environment, rather than a general account authentication failure. Suspected Root Causes The following are hypotheses requiring investigation, not confirmed causes: 1. Bundled agent version incompatibility Xcode was observed using Codex 0.140.0, while standalone Codex 0.166.0 successfully accessed GPT-6.1 Sol. Please verify whether the bundled Codex agent is compatible with currently available ChatGPT-authenticated models. 2. Model discovery or selection mismatch The bundled agent's model catalog included models that were subsequently rejected by the service. Please investigate whether Xcode refreshes the model catalog, respects model configuration overrides, and selects models based on account eligibility. 3. Agent protocol response decoding The generic data-format error suggests a possible failure to decode an agent response, handle an unsupported response schema, or propagate an underlying API error. Please inspect the agent initialization, response parsing, and error-handling paths. 4. Configuration and authentication isolation The normal ChatGPT integration authenticates successfully, while the Codex agent fails. Please verify how Xcode manages distinct authentication contexts, configuration locations, agent versions, and model capabilities. Requested Engineering Actions Please investigate and address the following: Ensure the Xcode Codex agent is compatible with supported ChatGPT-authenticated models. Verify that the bundled agent version is current and that component updates are correctly delivered. Validate model availability before dispatching requests. Ensure the model selected in Xcode matches the actual model submitted by the agent. Correct any incompatible protocol or JSON response handling. Expose the underlying error details rather than only reporting a generic data-format failure. Confirm that reinstalling or updating the Xcode Codex component restores a functional agent without requiring manual configuration changes. Add regression coverage for ChatGPT Pro authentication, model selection, agent initialization, and basic prompt execution. Impact The issue prevents me from using the Codex agent directly inside Xcode, despite having a ChatGPT Pro subscription and a fully functional standalone Codex CLI. As a result, I cannot use the integrated agentic coding experience or the Pursue Goal workflow that previously worked. Please investigate the bundled Codex runtime, model selection, and protocol compatibility. The successful standalone Codex 0.166.0 test provides a control case for reproducing and isolating the failure.

In the Photos app, the Collections title doesn't collapse into a small inline title when scrolling, unlike a standard inline large title display mode. How is this implemented?

I try to create a Navigation that works on iPhone, iPhone Duo and iPad. NavigationSplitView collapses for compact form factors and makes iPhone Duo support much simpler. The Problem is the semantic of the collapse. Switch from detail to sidebar on compact is not a 'back' action in my case. It should have my choosen Icon and has a meaning. So i wanted to control this using the NavigationSpliViewColumn Binding. This does work forward and backward as long as no NavigationStack was used before. But it stops working when you return to the detail root from a Navigation-Action. I left the Backbutton visible so you can test, that it continues to work, when no Navigation-Action preceeded the switch. Here is my Code: import SwiftUI @Observable final class Compass { var path: [Route] init() { self.path = [] } } enum Route: Hashable { case goal } struct ContentView: View { @Environment(\.horizontalSizeClass) private var hsize @State private var compass: Compass = Compass() @State var column: NavigationSplitViewColumn = .detail var body: some View { NavigationSplitView(preferredCompactColumn: $column) { OverviewScreen(column: $column) } detail: { TodayScreen() .toolbar { ToolbarItem(placement: .topBarLeading) { Button("overview", systemImage: "calendar") { self.column = .sidebar } } } } .environment(compass) .onChange(of: column) { old, new in print("column:", old, "→", new) } } } struct OverviewScreen: View { @Binding var column: NavigationSplitViewColumn @Environment(Compass.self) var compass var body: some View { @Bindable var compass = self.compass ScrollView { Text("Overview") .font(.largeTitle) .fontWeight(.heavy) Button("Switch") { self.column = .detail } } } } struct TodayScreen: View { @Environment(Compass.self) var compass var body: some View { @Bindable var compass = self.compass NavigationStack(path: $compass.path) { ScrollView { Text("Today") .font(.largeTitle) .fontWeight(.heavy) Button("Goals programtically", systemImage: "flag.fill") { self.compass.path = [.goal] } NavigationLink(value: Route.goal) { Label("Goal Link", systemImage: "flag.fill") } } .navigationDestination(for: Route.self, destination: self.screen) } } @ContentBuilder func screen(for route: Route) -> some View { switch route { case .goal: Text("Goals") } } } #Preview { ContentView() }This seems unexpected behaviour. If you ask AI the mental model is NavigationSplitViewColumn represents which column is currently visible for the user. That model would be wrong. Also i can't understand why a NavigationStack has to change the Binding? What am i missing here? Is my idea of the programmatic switch not supported? There are other ways to push from compact to your detail column again, but they all have trade-offs or run into other problems. I would appreciate any help here. AI has not understood this and only does surface level work arounds that fix nothing.

I have an iPhone tab view application that has not been designed for iPad, and I am aiming to add a left-hand bar that summarises some content and keeps visible what is normally a sheet. What pattern would work best for this? At present, I pass the view to another view with a navigation stack containing an arrangement view with the previous view and then the sidebar as a secondary view within it—would that be the appropriate approach?

For a full-screen game with a Metal/Unreal rendering view and a SwiftUI overlay for touch controls, what is the recommended way to keep interactive controls away from the hinge while still allowing the rendered game world to use the full display? Would you recommend querying ReservedRegion in the SwiftUI overlay while allowing the underlying render view to remain edge-to-edge? Also, should control placement respond continuously while the device is being folded, or primarily respond to layout/reserved-region changes once the pose changes?

Hi everyone, I'm experiencing a significant difference in SwiftUI layout behavior between the iPhone Duo simulator and a physical iPhone Duo. I've already adjusted my layout to work correctly in the simulator, but the same app behaves differently on the actual device. 1. Folded Simulator: The tab bar is positioned on the right side, as expected for iPhone Duo. The view respects the right-side layout, and scroll views extend naturally behind the tab bar, behaving as expected. Physical device: The tab bar appears at the bottom, like a regular iPhone, instead of on the right. The view is also cropped on the right side. 2. Unfolded Simulator: The tab bar and navigation view both appear correctly. Physical device: The tab bar remains at the bottom, even in landscape orientation, instead of using the expected Duo layout. The main content also starts from the bottom of the navigation view, resulting in an incorrect layout. The most confusing part is that the layout works correctly in the simulator but not on the physical device. Has anyone encountered this behavior on a physical iPhone Duo? Could this be related to the iOS version, SDK version, SwiftUI's automatic tab bar adaptation, or a device-specific bug? I'd appreciate any insights, especially from developers who have tested their SwiftUI apps on actual iPhone Duo hardware. Environment: Xcode version: 27.1 iOS SDK: 27.1 Physical device iOS version: 27.2 Thanks!

Description: The time scale values on the battery usage curve in macOS 27 are displayed incorrectly. The screenshot timestamp is 14:39:11, October 20. Under the "Last 24 Hours" tab for Battery Level and Screen On Time charts, the timeline shows usage extending past 21:00 on October 20. This timestamp does not match the actual current time. It appears the timeline axis failed to shift correctly as time progresses. For comparison: a reference screenshot captured on macOS 26 at 09:30, August 8. Its battery usage timeline rendered correctly. The bottom time span covered August 7 to August 8, which is the expected and proper display behavior. This bug only exists in macOS 27’s battery usage chart. The older macOS 26 implementation works correctly. Device: MacBook Air M5 macOS version: macOS 27.2 RC

Will the App Store surface apps that are optimised for iPhone Duo, for example a badge, a filter or editorial placement? And is "optimised" decided just by building against 27.1, or by something else? Will App Store Connect require dedicated iPhone Duo screenshots for the outer and inner displays?

I'm seeing a delayed appearance change when moving a row between two collections using the new SwiftUI reordering APIs. The data updates immediately, but the dragged row retains its source appearance throughout settling, then abruptly switches to its destination appearance about 0.9 seconds after the move callback. Environment Xcode 27.0 (27A266a), macOS 26.7 (25G229) iOS Simulator 27.0 (24A434), iPhone 17 Pro Feedback: FB25054984 These observations are from the original simulator tests. I haven't established whether the same behavior occurs on a physical device or a newer runtime. Structure and observed behavior The hierarchy is a ScrollView containing a LazyVStack with sections. Each section uses ForEach(...).reorderable(collectionID:), under one .reorderContainer(for:in:move:). A dragContainer supplies transferable items, with DragConfiguration(allowMove: true). The same item has a compact appearance inside a group and a wider card appearance when standalone. Moving it between those collections updates membership, order, and the state driving its appearance synchronously in the move callback. Item IDs remain stable. Drag a compact grouped row into the standalone collection. Drop it between two standalone rows. The model and live presentation state update immediately. The dropped row keeps the source appearance during settling, then snaps to the destination appearance approximately 0.9 seconds later. Moving it back shows the same behavior. Different row heights also cause adjacent rows to step when the appearance changes. Measured delays in the application's synthetic-data sandbox were approximately 930 ms out and 921 ms back in. What I've tried Removing role-dependent content identity. Moving into an already populated destination collection. Giving source and destination rows equal occupied height. Using identity transitions. Bypassing the app's drawer modifier. None removed the late appearance switch. Equal occupied height removed the displacement of adjacent rows, but not the delayed visual change. A comparison using custom drop handling updated the appearance promptly, but did not preserve native insertion-position reordering. The feedback contains the original video, relevant logs and before/after frames. I also have a reduced standalone project that builds, but its manual drag-and-drop reproduction hasn't yet been verified; the timings above are from the application's sandbox, not that standalone sample. Questions Is retaining the source row's appearance until after settling expected when moving between collections? Is there a supported API or recommended row structure that lets the destination appearance and geometry participate in the settling animation? Has anyone reproduced this on iOS 27, or found it fixed in a newer runtime? I'd like to keep native reordering without timed refreshes, container identity resets, or private APIs.

On iPad, text in a web view is always rendered at the same font size regardless of device orientation, sidebar presence, and window resizing. The text simply reflows according to the available space, as you would expect. In comparison, there appears to be a bug in iPhone Duo (or the Duo simulator) that causes web views to scale inconsistently depending on device orientation, presense/absence of the sidebar, and inner vs. outer screens. For example, showing and hiding the sidebar causes text in a web view to be rendered at different sizes rather than reflowing the text. Likewise, switching between portrait and landscape orientations causes text to be rendered at different sizes rather than reflowing. This occurs with the modern WebPage APIs introduced in iOS 26 as well as the older WKWebView APIs. Is this a known bug on the iPhone Duo? Is it just a simulator problem? Are there any recommended workarounds? Here's a quick example: import SwiftUI import WebKit struct ContentView: View { let webPage = WebPage() var body: some View { NavigationStack { WebView(webPage) } .task { webPage.load(html: """ <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Test page</title> </head> <body> <h1>This is a title</h1> <p>This is a paragraph.</p> </body> </html> """ ) } } }