I'm trying to update one of my apps to the new Liquid Glass effects using Xcode 26. Came across a weird issue in that I reproduced in an empty project on its own with a storyboard with a single segmented control on the initial viewController I have a UISegmentedControl with 3 options. If I click index 2, while index 0 is selected, everything works as normal However if I select index 1, and then index 2, it jumps back to index 0 instead of selecting 2. All the events fire as though I tapped index 0

I am using Unreal Engine 5.6 on a MacBook Pro with an M3 chip and macOS 15.5. I’ve installed Xcode and accepted the license, but Unreal is not detecting the latest Metal Shader Standard (Metal v3.0). The maximum version Unreal sees is Metal v2.4, even though the hardware and OS should support Metal 3.0. I’ve also run sudo xcode-select -s /Applications/Xcode.app and accepted the license via Terminal. Is there anything in Xcode settings, SDK availability, or system permissions that could be preventing access to Metal 3.0 features?"

Can anyone explain why I would be getting this warning ? [Internal] Thread running at User-interactive quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions. The code (NB: This method is called on the main thread) - (void)parseAudioTracks:(NSArray<AVAssetTrack *> *)audioTracks { NSMutableArray<AVAudioMixInputParameters *> *inputParameters = [NSMutableArray arrayWithCapacity:audioTracks.count]; NSMutableArray *tracksNames = [NSMutableArray array]; NSMutableArray *tracksChannels = [NSMutableArray array]; NSUInteger lastChannel = 0; for ( NSUInteger i = 0 ; i < audioTracks.count; i++ ) { AVAssetTrack *track = audioTracks[i]; for ( AVMetadataItem *item in track.metadata ) <-- WARNING HERE ...```

Just repro'd in the latest Xcode 26 Beta 3. Building an iOS app using xcstrings for localization. We have a URL that uses percent encoding for a query param. For example: Upon compiling in the latest Xcode 26 beta this fails with: Unable to create a Swift type from the format specifier “%20S”. This was not the case in prior Xcode versions.

I've been trying out the new .safeAreaBar modifier for iOS 26, but I cannot seem to notice any difference between that and .safeAreaInset? The documentation says: the bar modifier configures the content to support views to automatically extend the edge effect of any scroll view’s the bar adjusts safe area of. But I can't seem to see that in action.

Issue Description I'm developing a hybrid iOS app and encountering WebView bridge communication issues after updating to Xcode 16 with iOS 18 SDK. App Architecture AViewController: Initial view controller displayed at app launch Handles WebView setup and web-to-native bridge communication Pushes BViewController when receiving "B" bridge message from web BViewController: View controller stacked on top of AViewController Managed by navigation controller AViewController's WebView continues bridge communication even when BViewController is active Problem Behavior Xcode 15 (iOS 18): WebView bridge communication in AViewController works normally while BViewController is active Xcode 16 (iOS 18 SDK): Server communication breaks or hangs without response while BViewController is active Communication resumes only after popping back to AViewController from BViewController Questions Is the current architecture (configuring WebView in AViewController and maintaining bridge communication through AViewController's WebView while BViewController is presented) not a recommended pattern? Is Xcode 16's iOS 18 SDK the cause of this issue? If so, could you help me understand which specific changes are affecting this behavior? This is urgent as we need to deploy soon. I would greatly appreciate a prompt response.

Under Xcode 26 beta 3 I'm trying to build a project which uses Metal. I've installed the Metal Toolchain 26.0 under Settings -> Components, but when I start a build it fails during the "Prepare build" step with the following error (repeated many times): stat(/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.5276.7.Pb9SLL/Metal.xctoolchain/usr/bin/clang): No such file or directory (2) I've confirmed that there is in fact no 'clang' binary in that directory. I've tried using xcode-select to set the Xcode 26 Beta app as the active developer directory, and xcodebuild -version shows: Xcode 26.0 Build version 17A5276g Any ideas on other things to try?

I know there are several existing threads on this topic but things keep changing. The release notes for Xcode 26 beta 3 have the following statements for a couple of resolved issues: Asset Catalog Fixed: Unable to set Icon Composer icon as alternate iOS icon (153305178) (FB18025356) Icon Composer Fixed: Icon Composer icons back deploy to older versions of iOS, macOS, and watchOS with inconsistent rendering. (152258860) I had a working solution under beta 1 and beta 2 for both of these. But under beta 3, I am now seeing the new glass icons for my app when running on a simulated iOS 18 device. This is happening for both the main app icon and any alternates. This contradicts the statement that beta 3 fixes this issue. There is no documentation (that I can find) describing how you are supposed to support old icons for iOS 18 and new glass icons for iOS 26. There is no documentation for how to support alternate glass icons for iOS 26. What I'm doing at the moment (that worked before beta 3) was to have the normal iOS 18 app icons in the Asset catalog and to have the new glass icons added to the project. The filenames for the glass .icon files have the same name as the app icons in the Assets catalog. This worked under beta 1 and beta 2. And despite the Xcode 26 beta 3 release notes stating that Icon Composer icons no longer back deploy to iOS 18, I'm seeing the opposite. Beta 3 now does the opposite of that statement. Does anyone have a working solution that supports old iOS 18 app icons and new iOS 26 glass icons using Xcode 26 beta 3? Note, all of my testing is with simulated iOS devices and I'm running Xcode 26 beta 3 under macOS 15.5. Maybe that's an issue?

Below is an English version of your post, ready to copy-and-paste into the Apple Developer Forums: I’m seeing a crash in Xcode 26 beta 3 whenever the StoreKit symbol SKStoreProductParameterAdNetworkSourceIdentifier is present while running on an iOS 15 simulator. Steps to reproduce Install Xcode 26 beta 3. Create any iOS app and run it on an iOS 15 simulator (device model doesn’t matter). Add the following code anywhere and run: override func viewDidLoad() { super.viewDidLoad() if #available(iOS 16.1, *) { print("SKStoreProductParameterAdNetworkSourceIdentifier: \(SKStoreProductParameterAdNetworkSourceIdentifier)") } } The project builds successfully, but before the #available(iOS 16.1, *) check is reached, the app crashes with: Symbol not found: _SKStoreProductParameterAdNetworkSourceIdentifier When I build the same project with Xcode 16.4 and launch it on an iOS 15 simulator, it runs without crashing. Investigation so far Because SKStoreProductParameterAdNetworkSourceIdentifier is just an NSString, I could substitute the string literal "SKStoreProductParameterAdNetworkSourceIdentifier" as a temporary workaround, but that doesn’t feel like a proper fix. The symbol is still declared in both SDKs: /Applications/Xcode-16.4.0.app/.../StoreKit.framework/Headers/SKAdNetwork.h:48: SK_EXTERN NSString * const SKStoreProductParameterAdNetworkSourceIdentifier API_AVAILABLE(ios(16.1)) API_UNAVAILABLE(macos, watchos, visionos); /Applications/Xcode-26.0.0-Beta.3.app/.../StoreKit.framework/Headers/SKAdNetwork.h:48: SK_EXTERN NSString * const SKStoreProductParameterAdNetworkSourceIdentifier API_AVAILABLE(ios(16.1)) API_UNAVAILABLE(macos, watchos, visionos); So the symbol hasn’t been removed in the beta SDK. Given that the code is wrapped in #available(iOS 16.1, *), I don’t believe the sample itself is at fault. Questions Could this be a bug in Xcode 26’s availability checking or linker? Has anyone else encountered the same issue or found a more robust workaround? Any insights would be greatly appreciated.

Hi, moving from Xcode 16.1 to 16.2, the code coverage percentage is still 0. The project is quite old, but it worked with 16.1. What I tried: converted the old tests to test plans in the settings, including all the various targets (for internal functionality contained in frameworks, each framework has its own test target). added the various code coverage flags to YES. added test hosts to the main targets. played with various settings found in dozens of guides. But nothing. The main app shows 0% coverage, even though the internal frameworks have their own coverage and the files within the main app are tested. On Xcode 16.1, the % appears, but from 16.2 onwards, it doesn't. Also tried with Xcode 26. Any ideas? Thanks

Greetings, Ive been exerimenting with the new Apple intelligence chat. I want to be able to use my custom LLM and I made that work (I can chat back and forward from the left panel with my server) but I cannot find out how to change the editor contents like chatgpt does. chatgpt is able to change the current editor and, seems like, all files in the pbx. I tried to catch the call with charles with no success. In the OpenIA platform docs it doesnt mention anything that could change the code shown. does anyone know how to achieve this? Is the apple intelliece documentation lacking this features and will it be completed soon? will this features even be open for developers?

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.

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!

Dear Apple Developer Support, We are experiencing a critical issue after upgrading our development environment from Xcode 15 to Xcode 16 (beta). Our iOS application integrates Flutter via CocoaPods (install_all_flutter_pods and flutter_post_install) and uses plugins like webview_flutter. After the upgrade, our project started failing at the linking stage with the following errors: Undefined symbol: _XPluginsGetDataFuncOrAbort Undefined symbol: _XPluginsGetFunctionPtrFromID Undefined symbol: Plugins::SocketThreadLocalScope::SocketThreadLocalScope(int) Undefined symbol: Plugins::SocketThreadLocalScope::~SocketThreadLocalScope() Linker command failed with exit code 1 These symbols seem to originate from Flutter’s new native C++ plugin architecture (possibly via webview_flutter_wkwebview), and were previously resolving fine with Xcode 15. We have ensured the following: Added -lc++ and -ObjC to OTHER_LDFLAGS Cleaned and rebuilt Flutter module via flutter build ios --release Re-installed CocoaPods with pod install Verified Flutter.xcframework and plugin xcframeworks are present Despite this, the linker fails to resolve the mentioned symbols under Xcode 16. This suggests a stricter linker behavior or a compatibility issue with the new C++ plugin system Flutter uses. Can you confirm: If Xcode 16 introduces stricter C++/Objective-C++ linker constraints? Is there an official workaround or updated documentation for dealing with Plugins::SocketThreadLocalScope and related symbol resolution? Should these symbols be declared explicitly or provided in .xcframework format from plugin developers? We would appreciate guidance or clarification on how to proceed with Flutter plugin compatibility under Xcode 16. Thank you.

In the last three betas of Xcode 26, opening XIB files that rely on the older struts-and-springs setup (rather than Auto Layout) has exposed a new problem: Xcode 26 ignore the difference between a view’s frame and alignment rectangle. If you had arranged views using their frame rectangle (the default for the old method) this causes two problems: All UI widgets are both larger and no longer aligned. Switching between frame and alignment rectangles while configuring any NSView (through the inspector setting) has no effect. Is anyone else seeing this? It’s one thing to convert a few smaller views to Auto-layout (its reliance on alignment rectangles makes it immune to the "death" of frame rectangle-based layout) it is a rather different task to re-layout thousands of UI widgets as a result of this one bug. Filed as FB18835363

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'm using Version 16.4 (16F6) of Xcode on macOS 15.5 (24F74) and everything was working fine until I selected an older build to branch out from. Now, Xcode cant properly know the file status as it keeps on changing it after quitting and relaunching it. The changes in the file are there and when trying to commit to the local repo it doesn't show any changes to stage. At present I'm relying on making project folder backups as a way of backing up builds. Any suggestions what can be done?

ISSUE SUMMARY: iOS app receives "The app contains one or more corrupted binaries" error during Apple's SPI (Static Program Interface) analysis after successful upload to App Store Connect. Exhaustive systematic debugging indicates this is an Apple validation infrastructure issue, not application code. ERROR IDs ENCOUNTERED: f3de06b6-6a60-45a2-9856-77327004a64e 386f96fc-851f-42ec-91d7-c77b590ffeb6 ae1a9f9a-b980-490f-ad61-27f4552a4346 3e3c1839-f3f5-4f7b-9221-659dda8de970 COMPREHENSIVE DEBUGGING PERFORMED: PHASE 1: INITIAL TROUBLESHOOTING ✅ Attempted upload without manual IPA modifications - STILL FAILS ✅ Tested with Xcode Cloud builds (Apple's own infrastructure) - STILL FAILS ✅ Tried different upload methods (Xcode Organizer, Transporter) - STILL FAILS PHASE 2: CONFIGURATION FIXES ✅ Removed all iOS 26 references from codebase - STILL FAILS ✅ Fixed missing NSPhotoLibraryUsageDescription in Info.plist - STILL FAILS ✅ Removed empty entitlements file - STILL FAILS ✅ Verified all build settings and code signing - STILL FAILS PHASE 3: SYSTEMATIC COMPONENT ISOLATION Created blank test project and tested individual components: ✅ GRDB 7.5.0 package alone - PASSES validation ✅ Supabase 2.30.1 package alone - PASSES validation ✅ RevenueCat 5.32.0 package alone - PASSES validation ✅ PostHog 3.28.3 package alone - PASSES validation ✅ airports.db database file alone - PASSES validation ✅ HTML template files alone - PASSES validation ✅ CLAUDE.md documentation file alone - PASSES validation ✅ Localizable.strings files alone - PASSES validation ✅ ALL COMPONENTS TOGETHER in test project - PASSES validation PHASE 4: CODE AUDIT AND FIXES ✅ Comprehensive multi-agent code audit identified potential issues: Fixed threading deadlock in AppContext.swift (removed DispatchQueue.main.sync) Eliminated UIPrintPageRenderer KVC usage (replaced with UIGraphicsPDFRenderer) Verified no private API usage throughout codebase ✅ Applied all fixes - STILL FAILS validation PHASE 5: COMPLETE PROJECT RECREATION ✅ Copied ALL source code from failing project to working test project ✅ Same dependencies, same resources, same configuration ✅ Test project with individual components: PASSES validation ✅ Test project with complete source code: FAILS validation with identical error PHASE 6: FINAL COMPREHENSIVE AUDIT ✅ 4 specialized code audits completed: Runtime & Reflection analysis: CLEAN String-based API & KVC analysis: CLEAN System Integration analysis: CLEAN Constants & Private Values analysis: CLEAN ✅ No violations of Apple guidelines detected ✅ No private API usage found ✅ No dangerous code patterns identified DEFINITIVE EVIDENCE OF INFRASTRUCTURE ISSUE: Every individual component passes Apple SPI analysis when tested alone All components together in test project pass Apple SPI analysis Complete source code fails Apple SPI analysis with identical error Both local builds and Xcode Cloud builds fail identically Comprehensive code audits find no violations whatsoever Issue persists across different projects, build environments, and upload methods REPRODUCTION STEPS: Archive complete iOS app using Xcode 16.4.0 Upload to App Store Connect (upload succeeds) Apple's automated SPI analysis runs Validation fails with "corrupted binary" error EXPECTED BEHAVIOR: App should pass SPI analysis as systematic testing proves all components are individually valid. ACTUAL BEHAVIOR: SPI analysis consistently reports "corrupted binary" despite exhaustive debugging showing clean code. TECHNICAL DETAILS: Bundle ID: [your bundle ID] Target: iOS 18+ Xcode: 16.4.0 Architecture: arm64 Dependencies: GRDB 7.5.0, Supabase 2.30.1, RevenueCat 5.32.0, PostHog 3.28.3 SwiftUI app with @Observable pattern Offline-first SQLite + cloud sync architecture CONCLUSION: This level of systematic debugging definitively isolates the issue to Apple's SPI analysis infrastructure. No reasonable code-level explanation remains for why individual components pass validation but the complete app fails with identical errors across multiple build environments. Requesting urgent investigation of SPI analysis validation logic that may be incorrectly flagging legitimate applications as having "corrupted binaries."

In out project, we are creating a modular architecture where each module conform to certain protocol requirements for displaying the UI. For example: public protocol ModuleProviding: Sendable { associatedtype Content: View /// Creates and returns the main entry point view for this module /// - Parameter completion: Optional closure to be called when the flow completes /// - Returns: The main view for this module @MainActor func createView(_ completion: (() -> Void)?) -> Content } This protocol can be implemented by all different modules in the app, and I use a ViewProvider structure to build the UI from the module provided: public struct ViewProvider: Equatable { let id = UUID() let provider: any ModuleProviding let completion: () -> Void public init(provider: any ModuleProviding, completion: @escaping () -> Void) { self.provider = provider self.completion = completion } @MainActor public func layoutUI() -> some View { provider.createView(completion) } This code throws an error: Type 'any View' cannot conform to 'View' To solve this error, there are two ways, one is to wrap it in AnyView, which I don't want to do. The other option is to type check the provider with its concrete type: @ViewBuilder @MainActor private func buildViewForProvider(_ provider: any ModuleProviding, completion: (() -> Void)?) -> some View { switch provider { case let p as LoginProvider: p.createView(completion) case let p as PostAuthViewProvider: p.createView(completion) case let p as OnboardingProvider: p.createView(completion) case let p as RewardsProvider: p.createView(completion) case let p as SplashScreenProvider: p.createView(completion) default: EmptyView() } } This approach worked, but it defeats the purpose of using protocols and it is not scalable anymore. Are there any other approaches I can look at ? Or is this limitation in SwiftUI ?