before this post I posted this question in Apple Support Community. I do not know this is about some part of beta. but I need to know have some way to change them in beta. My Macbook internal keyboard is ANSI Layout but in Keyboard setting input sources with beta is show the ISO layout. so I need to type `(backtick) but it show "§" instead. how to change keyboard type ISO to ANSI ?

Hello, I put the mac into hard reset, deleted all data and prepared for sale. But the restore did not complete and is in boot loop Can't go into recovery mode It is completely bricked or can be somehow "revived" as I read on the apple website. Thank you

[Also submitted as FB18858239] In Xcode 26.0 beta 3 (17A5276g), clicking the current branch (e.g. "main") in the Source Control navigator no longer displays the commit history. Instead, the editor area remains stuck on the previously viewed file. REPRO STEPS Create a new iOS Swift UI app. Name it "Test" and check the Create Git repository on my Mac checkbox. In the Navigator select Source Control navigator. In Source Control, select Repositories. Expand "Test" then "Branches" the select "main (current)" CURRENT RESULTS The main view remains on the ContentView.swift file. EXPECTED RESULTS The main view changes to show the commit history. SCREENSHOTS Xcode 26.0 beta 3 Xcode 16.4

I run otool from a script (actually from a program) and find it annoying that otool fails if I need to agree to a new version of the Xcode and SDKs license. Is there a way to test ahead of time whether this will happen, or detect when this problem occurs, so that I can display a dialog to tell me what I need to do? This happened after upgrading from macOS Tahoe beta 1 to beta 3.

My view structure in UIKit is like this: UITabBarController (with UITabBar) -> UINavigationController -> UIToolbar (by setting self.navigationController.toolbarHidden = NO). The toolbar is shown in red in the picture. I'm using it like so: self.navigationController.toolbarHidden = NO; self.toolbarItems = @[element1, element2]; This toolbar does work fine up to iOS 18.5 but it does not show up when compiling using iOS 26 Beta 3. Is this a bug? I don't see any deprecation in the documentation about it. Am I doing something wrong?

Project minimum iOS deployment is set to 16.4. When running this simple code in console we receive "Observation tracking feedback loop detected!" and map is unusable. Run code: Map(coordinateRegion: .constant(.init())) Console report: ... Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_TtGC7SwiftUI21UIKitPlatformViewHostGVS_P10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS2_P10$24ce3fc8014AnnotationData____: 0x10acc2d00; baseClass = _TtGC5UIKit22UICorePlatformViewHostGV7SwiftUIP10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS3_P10$24ce3fc8014AnnotationData____; frame = (0 0; 353 595); anchorPoint = (0, 0); tintColor = UIExtendedSRGBColorSpace 0.333333 0.333333 0.333333 1; layer = <CALayer: 0x12443a430>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observation tracking feedback loop detected! Make a symbolic breakpoint at UIObservationTrackingFeedbackLoopDetected to catch this in the debugger. Refer to the console logs for details about recent invalidations; you can also make a symbolic breakpoint at UIObservationTrackingInvalidated to catch invalidations in the debugger. Object receiving repeated [layout] invalidations: <_TtGC7SwiftUI21UIKitPlatformViewHostGVS_P10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS2_P10$24ce3fc8014AnnotationData____: 0x10acc2d00; baseClass = _TtGC5UIKit22UICorePlatformViewHostGV7SwiftUIP10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS3_P10$24ce3fc8014AnnotationData____; frame = (0 0; 353 595); anchorPoint = (0, 0); tintColor = UIExtendedSRGBColorSpace 0.333333 0.333333 0.333333 1; layer = <CALayer: 0x12443a430>> Observation tracking feedback loop detected! Make a symbolic breakpoint at UIObservationTrackingFeedbackLoopDetected to catch this in the debugger. Refer to the console logs for details about recent invalidations; you can also make a symbolic breakpoint at UIObservationTrackingInvalidated to catch invalidations in the debugger. Object receiving repeated [layout] invalidations: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> IDE: Xcode 26 Beta 3 Testing device: iPhone 15 Pro iOS 26 Beta 3 MacOS: Tahoe 26 Beta 3

Before I file a bug report I wanted to verify that I'm not missing something. If I setup a view controller in a navigation controller and I add a view with a constraint that lines it up with the view controller's view's layoutMarginsGuide (leadingAnchor or trailingAnchor), in several cases the view will not line up with buttons added in the navigation bar. Under iOS 18 everything lines up as expected. To demonstrate, create a new iOS project based on Swift/Storyboard. Setup the storyboard to show a UINavigationController with one UIViewController. Then in ViewController.swift (the one embedded in the navigation controller), use the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .yellow title = "Layout Margins" let leftCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.leftBarButtonItem = leftCancel let rightCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.rightBarButtonItem = rightCancel let leftView = UIView() leftView.backgroundColor = .blue leftView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(leftView) let rightView = UIView() rightView.backgroundColor = .red rightView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(rightView) NSLayoutConstraint.activate([ leftView.widthAnchor.constraint(equalToConstant: 80), leftView.heightAnchor.constraint(equalToConstant: 80), leftView.leadingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.leadingAnchor), leftView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), rightView.widthAnchor.constraint(equalToConstant: 80), rightView.heightAnchor.constraint(equalToConstant: 80), rightView.trailingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.trailingAnchor), rightView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), ]) } } This adds a "Cancel" button to both ends of the navigation bar and it adds two little square views lined up with the leading and trailing layout margins. Here's the results: iPad running iPadOS 26 beta 3 (note the misalignment). This is really jarring when trying to align another glass button below the cancel button: iPad running iPadOS 18.5 (aligned just fine): iPhone in portrait running iOS 26 beta (aligned just fine): iPhone in landscape running iOS 26 beta (no alignment at all): iPhone in portrait running iOS 18.5 (aligned just fine): iPhone in landscape running iOS 18.5 (aligned just fine): Under iOS 26 on an iPhone (simulator at least) in portrait, the cancel buttons line up with the colored squares. That's good. In landscape, the colored squares have much larger margins as expected (due to the larger safe areas caused by the notch), but the cancel buttons in the navigation bar are not using the same margins. This one is debatable. Under iOS 18 the cancel buttons use larger margins to match the larger safe area. But I can see why under iOS 26 they changed this since the navigation bar doesn't interfere with the notch. But it's inconsistent. Under iOS 26 on an iPad (simulator at least), it's wrong in any orientation. Despite the lack of any notch or need for a larger safe area, the colored squares are indented just a bit more than the buttons in the navigation bar. I see no reason for this. Under iOS 18 everything lines up as expected. My real question at this point: Is the mismatched margins on an iPad under iOS 26 between the buttons in the navigation bar and other views added to the view controller a likely bug or am I missing something?

I installed the third beta of Xcode 26 with Xcode 16.4 installed on my machine. Once Xcode 26 was installed, all of my previous simulators were wiped out, leaving only the default iOS 26 simulators. I cannot create new simulators for iOS versions below 26. Here are my failed attempts to fix the issue: Restarted Xcode 16.4 and my machine Reinstalled the iOS 18.5 runtime Uninstalled Xcode 26 and iOS 26 runtime Reinstalled Xcode 16.4 Now, I literally cannot use a simulator in Xcode 16.4. Here is what I see when I try to create a new simulator in Xcode 16.4: According to Xcode, the iOS 18.5 runtime is installed, so I have no idea what is going on. Is this a known issue? And how do I get Xcode 16.4 working with the iOS simulator?

It seems that beta 3 broke StoreKit Testing when running against an iOS 26 simulator device. Specifically, when validating product IDs, the debug console displays messages like the following: [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) In addition, the SKProductsResponse (I am using the original StoreKit API), lists all requested product IDs in invalidProductIdentifiers. The products array is empty. StoreKit Testing behaves as expected when Xcode 26 beta 3 is run against an iOS 18.4 simulator device.

I need a layout where I have a ScrollView with some content, and ScrollView has full screen background image. Screen is pushed as detail on stack. When my screen is pushed we display navigation bar. We want a new scrollEdgeEffectStyle .soft style work. But when we scroll the gradient blur effect bellow bars is fixed to top and bottom part of the scroll view background image and is not transparent. However when content underneath navigation bar is darker and navigation bar changes automatically to adapt content underneath the final effect looks as expected doesn't use background image. Expected bahaviour for us is that the effect under the navigation bar would not use background image but would be transparent based on content underneath. This is how it is intialy when user didn't interact with the screen: This is how it looks when user scrolls down: This is how it looks when navigation bar adapts to dark content underneath: Minimal code to reproduce this behaviour: import SwiftUI @main struct SwiftUIByExampleApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationStack { ScrollView(.vertical) { VStack(spacing: 0.0) { ForEach(1 ..< 101, id: \.self) { i in HStack { Text("Row \(i)") Spacer() } .frame(height: 50) .background(Color.random) } } } .scrollEdgeEffectStyle(.soft, for: .all) .scrollContentBackground(.hidden) .toolbar { ToolbarItem(placement: .title) { Label("My Awesome App", systemImage: "sparkles") .labelStyle(.titleAndIcon) } } .toolbarRole(.navigationStack) .background( ZStack { Color.white .ignoresSafeArea() Image(.sea) .resizable() .ignoresSafeArea() .scaledToFill() } ) } } } extension Color { static var random: Color { Color( red: .random(in: 0...1), green: .random(in: 0...1), blue: .random(in: 0...1) ) } } We've also tried using ZStack instead of .background modifier but we observed the same results. We want to basically achieve the same effect as showcased here, but with the static background image: https://youtu.be/3MugGCtm26A?si=ALG29NqX1jAMacM5&t=634

I downloaded the Xcode Beta 3 on my MacBook Pro M4 Base today and tested out some iOS26 mechanics of my app. And when I came back to my main Xcode to continue developing in iOS18, I couldn't build my app. I went to Product &gt; Destination &gt; Manage run destinations and then tried to create a simulator with iOS18 but it didn't show up, only choice that's showing up was iOS26. I tried deleting iOS18 platform and downloading it again but it didn't solve, I tried deleting Xcode Beta but it didn't solve the problem either. I deleted Runtimes folder, it didn't solve too. I can not create a simulator of iOS18 or below too, the error says "The iOS 18.5 simulator runtime is not available. Try reinstalling Xcode or the simulator runtime." How can I fix this problem?

I my App I use the sheetPresentationController to get a sheet that sits on top of the main view (a Map) and that can be slided up and down, similar to the Maps or FindMy Apps. This works great with iOS 18 and older. But under iOS 26 Beta I see issues, especially on the iPad. When the window is small (iPhone or compact size class on iPad), changing the height of the sheet works as expected, the sheet window is attached to the bottom of the screen and I can slide it up and down. But when the App window is wider (regular size class on the iPad), the sheet is shown at the left (as expected), but it is no longer attached to the bottom of the screen, there's a very large (but constant) gap between the bottom of the App window and the bottom of the sheet. I haven't found a way to minimize the gap, the sheet window seems to totally ignore the vertical position and size of the "sourceView" to which the sheet should be attached to (it still evaluates the horizontal position, so I can move the sheet to the right, but the vertical position can't be controlled anymore). The Maps App or FindMy Apps do not show this issue, also iOS 18 and older do not show this issue. Is this normal or can I do something to prevent this? The sheet should always be positioned to the bottom left corner of the App window, Another problem is the window background with a UIGlassContainer effect. In the Apple Maps App the sheet looses its glass effect transparency under iOS 26 when the sheet is fully expanded. The FindMy does not have this issue, here the glass effect/transparency is always present. In my App the background shows the glass effect when the window is not fully expanded when the overall App window is above a certain height (like the Apple Maps App), but when the App window is below a certain height then it is the opposite way: fully expanded it shows the glass effect and at smaller heights it is opaque. Why is this the case? How can I get the behavior of the FindMy App where the sheet window keeps its transparent glass effect in all cases? I do not want to have it changing its appearance depending of the height of the sheet. I can "solve" some of the issues when presenting the "sheet" as popover (via popoverPresentationController) and from within the popoverPresentationController use the adaptiveSheetPresentationController property to get the UISheetPresentationController (instead of directly using the sheetPresentationController property). In small App windows (iPhone or compact size class) it works exactly as when directly using sheetPresentationController. With larger App windows (iPad and regular size class) the sheet will be attached to the bottom of the App window (as expected) and the glass effect is always present. However in this case the detents which define the allowed heights of the sheet window will be always ignored, the window seems to have always the maximum height (minus some safe areas), Even when using the preferredContentSize property to set the size, only the width is respected, but never the height. Is there any way to get this working? Is this supposed to work this way or is this still a beta issue?

I noticed that trying to access safeAreaInsets from the active window causes an infinite run loop. This issue appeared after updating to Beta 3. Here’s an example of the code: extension UIDevice { var safeAreaInsets: UIEdgeInsets { guard let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene, let window = windowScene.windows.first(where: { $0.isKeyWindow }) else { return .zero } return window.safeAreaInsets } } The return doesn’t happen because it ends up in some kind of recursion.

I recently update version 26 Beta 2 , 3 can't working screenshot & Dont have split screen iphones

Error: Fatal error: init(coder:) has not been implemented File: UIKitCore/UICoreHostingView.swift:54 Stack Trace Snippet: swift Copy Edit UIKitCore/UICoreHostingView.swift:54: Fatal error: init(coder:) has not been implemented Can't show file for stack frame: &lt;DBGLldbStackFrame: 0x10ca74560&gt; - stackNumber: 23 name: @objc ThemeableViewController.init(coder:). The file path does not exist on the file system: /

Hello everybody! I’m encountering an unexpected guardrailViolation error when using Foundation Models on macOS Beta 3 (Tahoe) with an Apple M2 Pro chip. This issue didn’t occur on Beta 1 or Beta 2 using the same codebase. Reproduction Context I’m developing an app that leverages Foundation Models for structured generation, paired with a local database tool. After upgrading to macOS Beta 3, I started receiving this error consistently, despite no changes in the generation logic. To isolate the issue, I opened the official WWDC sample project from the Adding intelligent app features with generative models and the same guardrailViolation error appeared without any modifications. Simplified Working Example I attempted to narrow down the issue by starting with a minimal prompt structure. This basic case works fine: import Foundation import Playgrounds import FoundationModels @Generable struct GeneableLandmark { @Guide(description: "Name of the landmark to visit") var name: String } final class LandmarkSuggestionGenerator { var landmarkSuggestion: GeneableLandmark.PartiallyGenerated? private var session: LanguageModelSession init(){ self.session = LanguageModelSession( instructions: Instructions { """ generate a list of landmarks to visit """ } ) } func createLandmarkSuggestion(location: String) async throws { let stream = session.streamResponse( generating: GeneableLandmark.self, options: GenerationOptions(sampling: .greedy), includeSchemaInPrompt: false ) { """ Generate a list of landmarks to viist in \(location) """ } for try await partialResponse in stream { landmarkSuggestion = partialResponse } } } #Playground { let generator = LandmarkSuggestionGenerator() Task { do { try await generator.createLandmarkSuggestion(location: "New york") if let suggestion = generator.landmarkSuggestion { print("Suggested landmark: \(suggestion)") } else { print("No suggestion generated.") } } catch { print("Error generating landmark suggestion: \(error)") } } } But as soon as I use the Sample ItineraryPlanner: #Playground { // Example landmark for demonstration let exampleLandmark = Landmark( id: 1, name: "San Francisco", continent: "North America", description: "A vibrant city by the bay known for the Golden Gate Bridge.", shortDescription: "Iconic Californian city.", latitude: 37.7749, longitude: -122.4194, span: 0.2, placeID: nil ) let planner = ItineraryPlanner(landmark: exampleLandmark) Task { do { try await planner.suggestItinerary(dayCount: 3) if let itinerary = planner.itinerary { print("Suggested itinerary: \(itinerary)") } else { print("No itinerary generated.") } } catch { print("Error generating itinerary: \(error)") } } } The error pops up: Multiline Error generating itinerary: guardrailViolation(FoundationModels.LanguageModelSession. >GenerationError.Context(debug Description: "May contain sensitive or unsafe content", >underlyingErrors: [FoundationModels. LanguageModelSession. Gene >rationError.guardrailViolation(FoundationMo dels. >LanguageModelSession.GenerationError.C ontext (debugDescription: >"May contain unsafe content", underlyingErrors: []))])) Based on my tests: The error may not be tied to structure complexity (since more nested structures work) The issue may stem from the tools or prompt content used inside the ItineraryPlanner The guardrail sensitivity may have increased or changed in Beta 3, affecting models that worked in earlier betas Thank you in advance for your help. Let me know if more details or reproducible code samples are needed - I’m happy to provide them. Best, Sasha Morozov

In Xcode 26 Beta 2 I had no issues, but as soon as I updated to Beta 3, I get the following error when I attempt to build to my iPhone 15 Pro running iOS 26 beta 3: Failed to find a DDI that can be used to enable DDI services on the device. Usually this means the best DDI we could find for a platform did not have compatible CoreDevice content. Run 'devicectl list preferredDDI' from the command line to get more details on why no valid DDI can be found. Domain: com.apple.dt.CoreDeviceError Code: 12001 I ran xcrun devicectl list preferredDDI and get the following: WARNING: No usable DDI found for the iOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/iOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17A5241o • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: iOS ▿ projectMetadata: • Citrine-1070 • CoreDevice-477.23 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-310.16.1 • JetsamProperties-2624 • LiveExecutionResultsLogger-20007 • Mercury-64 • Playgrounds-8 • XCTest-24209.8 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external WARNING: No DDI was found for the macOS platform. No usable DDI found for the tvOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/tvOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17A5241o • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: tvOS ▿ projectMetadata: • Citrine-1070 • CoreDevice-477.23 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-310.16.1 • JetsamProperties-2624 • LiveExecutionResultsLogger-20007 • Mercury-64 • Playgrounds-8 • XCTest-24209.8 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external WARNING: No usable DDI found for the watchOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/watchOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17A5241o • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: watchOS ▿ projectMetadata: • Citrine-1070 • CoreDevice-477.23 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-310.16.1 • JetsamProperties-2624 • LiveExecutionResultsLogger-20007 • Mercury-64 • Playgrounds-8 • XCTest-24209.8 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external WARNING: No usable DDI found for the visionOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/xrOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17A5241o • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: xrOS ▿ projectMetadata: • Citrine-1070 • CoreDevice-477.23 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-310.16.1 • JetsamProperties-2624 • LiveExecutionResultsLogger-20007 • Mercury-64 • Playgrounds-8 • XCTest-24209.8 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external When I run xcrun devicectl manage ddis update it hangs and does not update. I have also tried the obvious steps of uninstalling and reinstalling as well as unpairing and repairing my run devices. I have not tried sudo rm -rf /Library/Developer/DeveloperDiskImages/* Is that step recommended? Or any insights how to solve this issue? Thanks!

Hello community, After unable to use Metal Toolchain for Xcode Beta 1 and 2 even after following the workarounds, and using Xcode Beta 3, I am still unable to use the downloaded Metal Compiler on my device. Building any project with metal file results in warning: Could not read serialized diagnostics file: error("Failed to open diagnostics file") (in target '<target>' from project '<project>') error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain Command CompileMetalFile failed with a nonzero exit code Here is my build environment, $ xcodebuild -version Xcode 26.0 Build version 17A5276g I have also checked the downloaded metal toolchain. $ xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MyMetalExport/ 2025-07-13 13:16:17.293 xcodebuild[2153:34019] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.5276.7.3KEJwX” couldn’t be opened because you don’t have permission to view it. Beginning asset download... 2025-07-13 13:16:17.427 xcodebuild[2153:34022] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.5276.7.3KEJwX” couldn’t be opened because you don’t have permission to view it. Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/47af11e2964f385d510c6a9d1a49c8165f334a51.asset/AssetData/Restore/022-19457-052.dmg Beginning asset export... Done exporting: /tmp/MyMetalExport/MetalToolchain-17A5276g.exportedBundle Done downloading: Metal Toolchain 17A5276g. The ExportMetadata.plist has a buildUpdateVersion of 17A5276g. Any suggestions are greatly appreciated.

The following repro case results in a previews crash on Xcode 26 beta 3 (report attached). FB18762054 import SwiftUI final class MyItem: Identifiable, Labelled { var label: String init(_ label: String) { self.label = label } } protocol Labelled { var label: String { get } } struct HelloView: View { let label: String var body: some View { Text(label) } } struct ListView<Element: Labelled & Identifiable>: View { @Binding var elements: [Element] var body: some View { List { ForEach($elements, id: \.id) { $element in HelloView(label: element.label) // crash // Replacing the above with a predefined view works correctly // Text(element.label) } } } } struct ForEachBindingRepro: View { @State var elements: [MyItem] = [ MyItem("hello"), MyItem("world"), ] var body: some View { ListView(elements: $elements) } } #Preview("ForEachBindingRepro") { ForEachBindingRepro() } foreachbindingrepro-2025-07-12-020628.ips

Our app includes the UIRequiresFullScreen plist key, but the iPadOS 26 betas seem to ignore this. The window handle is still displayed, and while the window aspect ratio seems to be constrained, you can still adjust it and arrange it alongside other apps. We do not want to support windowing or multi-tasking, and the WWDC sessions indicated there would be a way to opt out of the new windowing system. Has UIRequiresFullScreen been silently deprecated, or are we missing something in our implementation?