I can create an ipa file with vs using the wildcard bundle identifier but this is rejected by apple when I upload with the Transporter app saying invalid identifier and no distribution profile/certificate. When I create a new distribution profile with the correct XC identifier and distribution certificate and try to archive with visual studio publish says the bundle id is not a match for the distribution profile with iOS? This is a net 10 net maui project and my first build attempt

LLVM Linker Crash on ARM64 with bfloat16 Symbols (Xcode 17.0.0) We're encountering a critical linker crash in Xcode 17.0.0 (clang-1700.4.4.1) on macOS 15.1.0 (Darwin 25.1.0) with Apple Silicon M3 Max when linking a pybind11 C++ extension against the MLX framework (v0.30.1). The linker consistently crashes with LLVM ERROR: No way to correctly truncate anything but float to bfloat during the linking phase, even though our code uses only integer types (int64, uint32) for BPE tokenization and never directly references bfloat16 types. Error Details: [100%] Linking CXX shared module _metal_trainer.cpython-312-darwin.so LLVM ERROR: No way to correctly truncate anything but float to bfloat clang++: error: unable to execute command: Abort trap: 6 clang++: error: linker command failed due to signal (use -v to see invocation) Reproduction: Install MLX framework: pip install mlx (any version with bfloat16 support) Create a minimal pybind11 extension that links against MLX: Compiler: AppleClang 17.0.0.17000404 Target: arm64-apple-darwin25.1.0 Flags: -std=c++17 -O2 -march=native Link against: libmlx.dylib (contains bfloat16 symbols) Run: cmake .. && make Linker crashes during final linking phase Root Cause: The LLVM ARM64 backend in Xcode 17.0.0 has a code generation bug when processing bfloat16 truncation operations during link-time. The crash occurs when the linker processes bfloat16 symbols from libmlx.dylib, regardless of whether the application code uses them. The error originates from LLVM's type legalization pass attempting to truncate bfloat16 values, but the ARM64 backend lacks a valid code path for this operation. Workarounds Attempted (all failed): Disabling LTO: INTERPROCEDURAL_OPTIMIZATION FALSE Linker flags: -Wl,-no_compact_unwind, -fno-lto Runtime symbol resolution: -undefined dynamic_lookup Compiler optimizations: Changed from -O3 to -O2 Impact: This blocks any C++ extension development that links against libraries containing bfloat16 symbols on Xcode 17.0.0. The issue does not occur on Xcode 16.x. Linker Crash Dump Location: /var/folders/gn/7_g6wy1j66b8z3lkywyrbsx00000gn/T/linker-crash-* Expected Behavior: Linker should successfully link the extension, or at minimum, gracefully handle bfloat16 symbols without crashing. Temporary Solution: Downgrade to Xcode 16.x or use Python-only implementations until this is fixed in a future Xcode release.

I am developing an iOS in-app SDK for collecting code coverage data. The SDK writes coverage data to a specified file by calling __llvm_profile_set_filename and __llvm_profile_write_file. This implementation worked correctly until I switched to Xcode 26.0 to build my project. Now, when __llvm_profile_write_file() is executed, it crashes with the following error stack. Can anyone provide any assistance? Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000001 Exception Codes: 0x0000000000000001, 0x0000000000000001 Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11 Terminating Process: exc handler [454] Thread 96 name: Dispatch queue: com.test-coverage.processing Thread 96: Crashed: 0 Demo 0x122602ea8 initializeValueProfRuntimeRecord (in Demo) (InstrProfilingValue.c:351) 1 Demo 0x00000001226064c0 writeOneValueProfData (in Demo) (InstrProfilingWriter.c:153) 2 Demo 0x0000000122606308 writeValueProfData (in Demo) (InstrProfilingWriter.c:234) 3 Demo 0x00000001226060d0 lprofWriteDataImpl (in Demo) (InstrProfilingWriter.c:401) 4 Demo 0x0000000122605d98 lprofWriteData (in Demo) (InstrProfilingWriter.c:261) 5 Demo 0x0000000122604804 writeFile (in Demo) (InstrProfilingFile.c:536) 6 Demo 0x122604664 __llvm_profile_write_file_alias + 228 7 Demo 0x000000011c6dd108 -[BDTestCoverage p_dumpMainCoverageInfoWithCustomKey:] (in Demo) (TestCoverage.m:995) 8 Demo 0x000000011c6dcef8 -[BDTestCoverage p_dumpAllCoverageProfileWithCustomKey:] (in Demo) (TestCoverage.m:970)

Failed to generate code coverage report when doing Swift Testing on iPhone device, but it's ok in UI testing or running on "My Mac(Designed for iPad)". I have enable code coverage in test plan. My app can't run on simulator due to frameworks limitations. Platform: Mac mini M2 w/ macOS15.7, iPhoneXR 18.6.2 Xcode version: 26.1 & 16.0 error msg: Failed to download profiles from paths ["/private/var/mobile/Containers/Data/Application/76A1F9BC-98C8-4349-998B-0FC030DEE3EC/tmp/3A424286-872D-40AD-B4CA-65B232B57EB4"] on device 'iPhoneXR' for application with bundle ID 'xxx.xxxx.xxxx' to directory /Users//Library/Developer/Xcode/DerivedData/-bosqsqmqiqwweldrfrtgsfpnhroht/Build/ProfileData/00008020-00042C2A3E38002E: Failed to retrieve the file node for tmp/3A424286-872D-40AD-B4CA-65B232B57EB4. (Underlying Error: Failed to retrieve the file node for tmp/3A424286-872D-40AD-B4CA-65B232B57EB4)

Hello, Is there any plan to integrate realtime sanitier (RTSan) in Apple Clang? This tool has been introduced in Clang 20.1.0 back in March 2025. This tool is incredibly useful, and having it in AppleClang (and ideally integrated in Xcode and xcodebuild) would be great. Thank you, Best, Thomas

Fails to gather code coverage and throws this error Showing All Messages Failed to merge raw profiles in directory /Users//Library/Developer/Xcode/DerivedData/Receiver-ekqrbpsaciuxmlfslviajhoecyat/Build/ProfileData/0B0C6B69-FD46-4801-B106-56B7FCD44370 to destination /Users//Library/Developer/Xcode/DerivedData/Receiver-ekqrbpsaciuxmlfslviajhoecyat/Build/ProfileData/0B0C6B69-FD46-4801-B106-56B7FCD44370/Coverage.profdata: Aggregation tool '/Users/shwethamugeraya/Downloads/Xcode 2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/llvm-profdata' failed with exit code 1: warning: /Users/shwethamugeraya/Library/Developer/Xcode/DerivedData/Receiver-ekqrbpsaciuxmlfslviajhoecyat/Build/ProfileData/0B0C6B69-FD46-4801-B106-56B7FCD44370/2F4EFBF7-1CCF-4E9E-8FD6-482EEDB98B6C-34646.profraw: raw profile version mismatch: Profile uses raw profile format version = 4; expected version = 8 PLEASE update this tool to version in the raw profile, or regenerate raw profile with expected version. error: no profile can be merged

After uprgading to new XCode version 26.0.1 my project can't be longer build. There are strange compiler errors without concrete error message. If I want to investigate the single errors they disappears on selection... I can send a recorded screen-video. I invested over 2 weeks on trying to solve the problem without success. That's not the first time that the project couldnt be build after a xcode upgrade. Thats really annoying.

After upgrading to macOS Tahoe 26.0.1, I encountered an issue where the debugger could no longer display standard C++ library types such as std::map, std::string, and other std:: containers. Instead, the debugger simply showed: Summary Unavailable 🧪 What I Tried • Switched from the default LLVM compiler to GDB to check if it was a debugger-related problem — no improvement. • Cleaned and rebuilt the project — the issue persisted. ✅ Solution Downgrading Xcode to version 16.4 immediately resolved the issue. According to Apple’s official Xcode support documentation, Xcode 16.4 is compatible with macOS Sequoia 15.6 and later, which includes macOS Tahoe 26.0.1. This suggests that the problem may be caused by a compatibility issue in the latest Command Line Tools bundled with newer versions of Xcode. 💡 Takeaway If you encounter the same problem: 1. Try downgrading to Xcode 16.4 or reinstalling the corresponding Command Line Tools. 2. Make sure your debugger (LLDB or GDB) is correctly linked to the appropriate SDK version. Hopefully this helps anyone experiencing the same issue!

After upgrading to macOS Tahoe 26.0.1, I encountered an issue where the debugger could no longer display standard C++ library types such as std::map, std::string, and other std:: containers. Instead, the debugger simply showed: Summary Unavailable 🧪 What I Tried • Switched from the default LLVM compiler to GDB to check if it was a debugger-related problem — no improvement. • Cleaned and rebuilt the project — the issue persisted. ✅ Solution Downgrading Xcode to version 16.4 immediately resolved the issue. According to Apple’s official Xcode support documentation, Xcode 16.4 is compatible with macOS Sequoia 15.6 and later, which includes macOS Tahoe 26.0.1. This suggests that the problem may be caused by a compatibility issue in the latest Command Line Tools bundled with newer versions of Xcode. 💡 Takeaway If you encounter the same problem: Try downgrading to Xcode 16.4 or reinstalling the corresponding Command Line Tools. Make sure your debugger (LLDB or GDB) is correctly linked to the appropriate SDK version. Hopefully this helps anyone experiencing the same issue!

In my app target Foo, I have a dependency on package Bar. Bar itself have a dependency on another package Other. In my test target FooTests, I have a dependency on package BarTestsHelpers. BarTestsHelpers depends on Bar. When compiling test target FooTests, I get the following unexpected warning in Xcode 26 only: 'Bar' is missing a dependency on 'Other' because dependency scan of Swift module 'Bar' discovered a dependency on 'Other' I can see this is being discussed here as well without a solution. I filled a feedback with a sample project here: FB20602885 It seems that we can remove the warning by explicitly adding the dependency Other on BarTestHelpers. But this shouldn't be needed as BarTestHelpers doesn't use nor know about Other, it only needs it as part of its dependency on Bar.

When upgrading to a new version of Xcode, normally we look in the "Toolchain version history" table of the Xcode wikipedia page. But for Xcode 16.2, it lists git tag swift-6.0.3-RELEASE, which fails to compile with a known error. There was a fix for this error way back on July 4, 2024, but for some reason this fix does not appear in swift-6.0.3-RELEASE (as confirmed with git log, even though the tag occurred on December 2, 2024). So it turns out the minimum tag is swift-6.1-RELEASE for building LLVM with Xcode 16.2 (there are no other release tags between these two). Is it possible that the wikipedia table is simply incorrect in this case? If not, is there a workaround to build swift-6.0.3-RELEASE using Xcode 16.2, as published by Apple?

Hi all, I’m running into a persistent build issue with my Swift project ORSOFINAL after migrating from Xcode stable to Xcode-beta.app 26 (June 2025 version). ⸻ 💥 Errors displayed: 1. C99 was enabled in PCH file but is currently disabled 2. module file .../ModuleCache.noindex/SwiftShims-AXUM98L131W4...pcm cannot be loaded due to a configuration mismatch with the current compilation 3. missing required module 'SwiftShims' ⸻ 🛠 What I’ve already tried: • xcode-select -s /Applications/Xcode-beta.app/Contents/Developer • Deleted ~/Library/Developer/Xcode/DerivedData, ModuleCache.noindex, Archives, and Products • Ran sudo xcodebuild -runFirstLaunch • Clean Build Folder in Xcode-beta • Verified Command Line Tools setting points to Xcode-beta ⸻ ❓Looking for guidance on: • Whether this is a known bug in Xcode-beta • If SwiftShims/PCM conflicts are expected between versions • Best practices to safely migrate from Xcode stable to beta for Swift-based projects Any advice is much appreciated. Thanks, Mathéo

Hi all, I’m running into a persistent build issue with my Swift project ORSOFINAL after migrating from Xcode stable to Xcode-beta.app (June 2025 version). ⸻ 💥 Errors displayed: 1. C99 was enabled in PCH file but is currently disabled 2. module file .../ModuleCache.noindex/SwiftShims-AXUM98L131W4...pcm cannot be loaded due to a configuration mismatch with the current compilation 3. missing required module 'SwiftShims' ⸻ 🛠 What I’ve already tried: • xcode-select -s /Applications/Xcode-beta.app/Contents/Developer • Deleted ~/Library/Developer/Xcode/DerivedData, ModuleCache.noindex, Archives, and Products • Ran sudo xcodebuild -runFirstLaunch • Clean Build Folder in Xcode-beta • Verified Command Line Tools setting points to Xcode-beta ⸻ ❓Looking for guidance on: • Whether this is a known bug in Xcode-beta • If SwiftShims/PCM conflicts are expected between versions • Best practices to safely migrate from Xcode stable to beta for Swift-based projects Any advice is much appreciated. Thanks, Mathéo

(Copy pasted from FB17261080 that I submitted) Hi: Apple's SDK (libSystem.B.tbd) provides definition for multiple symbols(__unw_add_dynamic_fde / __unw_add_find_dynamic_unwind_sections ), but doesn't provide corresponding headers, available in LLVM upstream as libunwind_ext.h We need such headers to write Exception-Enabled JIT Framework for macOS

Hello, I am programming a CLI tool to partition USB disks. I am calling diskutil to do the work, but I am hitting issues with permissions, it seems. Here is a trial run of the same command running diskutil directly on the terminal vs running from my code: Calling diskutil directly (works as expected) % /usr/sbin/diskutil partitionDisk /dev/disk2 MBR Free\ Space gap 2048S fat32 f-fix 100353S Free\ Space tail 0 Started partitioning on disk2 Unmounting disk Creating the partition map Waiting for partitions to activate Formatting disk2s1 as MS-DOS (FAT32) with name f-fix 512 bytes per physical sector /dev/rdisk2s1: 98784 sectors in 98784 FAT32 clusters (512 bytes/cluster) bps=512 spc=1 res=32 nft=2 mid=0xf8 spt=32 hds=16 hid=2079 drv=0x80 bsec=100360 bspf=772 rdcl=2 infs=1 bkbs=6 Mounting disk Finished partitioning on disk2 /dev/disk2 (disk image): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme +104.9 MB disk2 1: DOS_FAT_32 F-FIX 51.4 MB disk2s1 Calling diskutil programmatically (error -69877) % sudo ./f-fix DEBUG: /usr/sbin/diskutil partitionDisk /dev/disk2 MBR Free Space gap 2048S fat32 f-fix 100353S Free Space tail 0 Started partitioning on disk2 Unmounting disk Error: -69877: Couldn't open device (Is a disk in use by a storage system such as AppleRAID, CoreStorage, or APFS?) Failed to fix drive `/dev/disk2' Source Code The relevant code from my program is this: char *args[16]; int n = 0; args[n++] = "/usr/sbin/diskutil"; args[n++] = "partitionDisk"; args[n++] = (char *)disk; args[n++] = (char *)scheme; (...) args[n++] = NULL; char **parent_env = *_NSGetEnviron(); if (posix_spawnp(&pid, args[0], NULL, NULL, args, parent_env) != 0) return 1; if (waitpid(pid, &status, 0) < 0) return 1; return 0; Question Are there any system protections against running it like so? What could I be missing? Is this a Disk Arbitration issue?

Issue: During app execution, the intended method is not being called; instead, the method preceding (written above the intended method) is being executed. For Example: //In my case the ViewController class is at 3rd level of inheritance. class ViewController: UIViewController { func methodA() { print("methodA") } func methodB() { print("methodB") } } let vc = ViewController() vc.methodB() Output: //"methodA" Expected: //"methodB" Observations: Recent code changes have revealed that enabling the below Swift-6 flag leads to this linking issue. When this flag is commented out, the problem disappears. .enableUpcomingFeature("InternalImportsByDefault") Additionally, moving the intended method into an extension of the same class resolves the issue when the flag is enabled. Conclusion: To resolve the issue: Comment out the Swift-6 flag. Alternatively, move the method into an extension of the same class, which addresses the issue for this specific case. I had similar issue in other class where it crashes with message "method not found", but actually the method is there. When moving the method into an extension of same class resolve this issue. Any help is much appreciated. Thanking you..

C++ code that compiled fine on Xcode 16.2 when targeting macOS 13.3 after upgrading to Xcode 16.3 gives an error that the minimum required target is macOS 13.4 with an error like: `/Applications/Xcode-16.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk/usr/include/c++/v1/__format/formatter_floating_point.h:74:30: error: 'to_chars' is unavailable: introduced in macOS 13.4 unknown 74 | to_chars_result __r = std::to_chars(__first, __last, __value, __fmt, __precision); Here’s example taken directly from (https://en.cppreference.com/w/cpp/utility/format/format): #include <format> #include <iostream> #include <string> #include <string_view> template<typename... Args> std::string dyna_print(std::string_view rt_fmt_str, Args&&... args) { return std::vformat(rt_fmt_str, std::make_format_args(args...)); } int main() { std::cout << std::format("Hello {}!\n", "world"); std::string fmt; for (int i{}; i != 3; ++i) { fmt += "{} "; // constructs the formatting string std::cout << fmt << " : "; std::cout << dyna_print(fmt, "alpha", 'Z', 3.14, "unused"); std::cout << '\n'; } } It doesn’t make any sense to suddenly require targeting 13.4 for features that worked fine on 13.3. The Apple documentation for C++ feature support explicitly discusses 13.3. https://developer.apple.com/xcode/cpp/ (search for P0067R5 on the page) I haven't tested it, but based on the standard library headers the minimum required iOS version has also been bumped - from 16.3 to 16.5. Am I doing something wrong? Is there a known work-around? Filed feedback: FB17081499

It didn't happen with Xcode 16.2 that I used before, but after updating to 16.3, when I build the app, the following error is output to the console and the app doesn't run. dyld[2150]: Symbol not found: ___cxa_current_primary_exception Referenced from: <6B00A4F2-B208-3FDB-BA38-B7095AF0034A> /private/var/containers/Bundle/Application/B590DB18-9C66-4C9E-8330-104943419E60/Mubeat DEV.app/Mubeat DEV.debug.dylib Expected in: <7F51CB08-A0CA-386E-BB62-4B8BFB0CED9F> /usr/lib/libc++.1.dylib Symbol not found: ___cxa_current_primary_exception Referenced from: <6B00A4F2-B208-3FDB-BA38-B7095AF0034A> /private/var/containers/Bundle/Application/B590DB18-9C66-4C9E-8330-104943419E60/Mubeat DEV.app/Mubeat DEV.debug.dylib Expected in: <7F51CB08-A0CA-386E-BB62-4B8BFB0CED9F> /usr/lib/libc++.1.dylib dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib After looking for another solution, I found a way to remove the -Objc option in Other Linker Flags, but this method only works on iOS 18.4 and doesn't work on other versions. Is there another solution?

I've observed a significant performance regression in Apple Clang 16 (Xcode 16.0/16.2) compared to Clang 15 (Xcode 15.2) when processing flutter aot compilation. Further research shows that clang -cc1as process became extremely slow. The compilation time has increased by approximately 4x. Environment Machine: Apple M2 (8C8T) Memory: 16GB macOS Version: 14.7.2 Target: Flutter AOT compilation (snapshot_assembly.o) Performance Comparison Xcode Version iOS SDK Duration 15.2 17.2 1:08.90 15.2 18.2 1:03.98 16.2 17.2 4:11.07 16.2 18.2 4:08.43 16.0 18.2 4:29.32 Reproduction Steps The issue can be reproduced with the following command which is generated by flutter aot_assembly_release process: time ${xcode_app_path}/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc \ -arch arm64 \ -miphoneos-version-min=12.0 \ -v \ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS18.2.sdk \ -c ${project_path}/.dart_tool/flutter_build/f9ebf46f040933de7c8d103c84d38156/arm64/snapshot_assembly.S \ -o ${project_path}/.dart_tool/flutter_build/f9ebf46f040933de7c8d103c84d38156/arm64/snapshot_assembly.o Additional Information This issue specifically affects large assembly files generated by Flutter's AOT compilation The performance regression appears to be consistent across different iOS SDK versions The same assembly file compiles significantly faster with Xcode 15.2 Same performance regression observed on M4 Mac mini, suggesting this is not hardware-specific Size of object: size -m ${project_path}/.dart_tool/flutter_build/f9ebf46f040933de7c8d103c84d38156/arm64/snapshot_assembly.o Segment : 64577616 Section (__TEXT, __text): 26603344 Section (__DATA, __bss): 48 (zerofill) Section (__TEXT, __const): 21292928 Section (__DWARF, __debug_abbrev): 61 Section (__DWARF, __debug_info): 8934534 Section (__DWARF, __debug_line): 4464443 Section (__LD, __compact_unwind): 3282208 total 64577566 total 64577616 Questions Is this a known issue with Apple Clang 16? Are there any workarounds or compiler flags we can use to improve the performance? Is this behavior expected or should it be considered a regression? Any insights or suggestions would be greatly appreciated.

Hi, I want to build an ios app that uses static c libraries. For reference, i did the following as a test: Compiled a simple c date and time program with clang -c -arch arm64 -sysroot <iPhoneOSSDK_path> date.c -o date_arm64.o Created the static lib ar rcs libdatetime_arm64.a date_arm64.o Added the lib in my Xcode project. Added the (.a) file in Build Rules -> Link Binary With Libraries Included the (.a) and (.h) file path in Build Settings -> Search Paths -> Header and Library Search Path Created a Bridging-Header.h file where I added #import "date.h" In my App.swift file, I called the function for getting the date and time let dateTimeStr = String(cString: get_current_datetime()) print("Current Date and Time: \(dateTimeStr)") After doing all the steps above, I am met with the error - Cannot find 'get_current_datetime' in scope Is there any other method to use static c libraries in xcode?