Hi, I'm struggling to understand using Swift-C++ in the same project. I have an existing code-base that makes heavy use of Swift-Objective-C interoperability. We make use of swift classes in our project. When I enable swift-objective c interoperability I am running into numerous build errors in the generated bridging header. I'm trying to understand why these errors exist and what to do to get around them. I have a project that I've set up with some test code, and I'm running into an error here: public class Foo { let name: String public init(name: String) { self.name = name } } public class Bar { let name: String public init(name : String) { self.name = name; } public func getFoo() -> Foo { return Foo(name: self.name); } } In the header file: Unknown type name 'Foo' SWIFT_INLINE_THUNK Foo getFoo() SWIFT_SYMBOL("s:13ForestBuilder3BarC6getFooAA0E0CyF"); This error goes away if I use structs, but for the purposes of porting my codebase, I'd prefer to use classes. Do classes not play nice here? Or am I misunderstanding something. Thanks.

I have an M2 Mac Mini with Apple Clang 16.0.0. Under certain circumstances, the SIMD code generated by an unrolled loop is incorrect. I have a short example program which reproduces the bug, on my machine and someone else's with the same Clang version. The core operation is this: for (size_t i = 0; i < count; ++i) { c[i] = a[i]*std::conj(b[i]); } This loop gets unrolled to process 4 elements at once, and when count=15, the first 12 results have the wrong sign for the imaginary part. The final 3 elements are correct, since those are processed in a different code path. Is this an known error? I suspect it might be present in other Apple Clang versions as well (because I found this while chasing down an extremely unpredictable bug) but so far this is the only setup where I've cleanly reproduced it. Minimal test program (43 lines): https://signalsmith-audio.co.uk/tmp/argh.git/ - just run make. The expected output is a bunch of error=0, or small values from floating-point errors. I'm getting results like error=0.229711, and you can see it's because the "actual" results have a ± error.

Hello, I am trying to read debug symbols from a binary obtained from simple "hello world" C code. I use default gcc (Clang) on macos15, then try to install gcc-14 with hombrew $ gcc -g program.c -o program then run $ dsymutil program I got : warning: no debug symbols in executable (-arch arm64) I am doing something wrong here. My final objective is to be able to use my binaries in total view for debugging. Without debugging symbols, I can debug properly . Thank you

Below copied from my original post here: https://forums.swift.org/t/xcode-16-2-beta-seems-increase-the-min-deploy-to-16-0-for-swift-cpp-mixed-project/76221 Our games are set to min deploy of iOS 12.0. When building with the Xcode 16.2 beta3, the Xcode 16.1 build-able project will have errors for those static libs that has swift mixed with C++: Compiling for iOS 12.0, but module 'Cxx' has a minimum deployment target of iOS 16.0: /Users/trout.zhang/Documents/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/Cxx.swiftmodule/arm64-apple-ios.swiftmodule Change that static lib min deploy to 16.0 can make the build succeed, while maintain the exe target still use iOS 12.0. I am not familiar with how the min deploy works, is it: choosing the highest of exe and its dependencies, thus effectively set the final product has min deploy of iOS 16.0 or maintaining exe's iOS 12.0 and actually crash in runtime if the iOS is less than 16.0, when reach the code in that static lib. Apparently, non of the above is what we want. Use cat in cmdline, for Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/Cxx.swiftmodule/arm64-apple-ios.swiftdoc with both Xcode.app(16.1) and Xcode-beta.app(16.2 beta3), I found the different lines: Xcode 16.1 has: Apple Swift version 6.0.2 effective-5.10 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)Cxx?arm64-apple-ios11.0 Xcode 16.2 beta 3 has: Apple Swift version 6.0.3 effective-5.10 (swiftlang-6.0.3.1.8 clang-1600.0.30.1)Cxx?arm64-apple-ios16.0

I am using DuckDB as an external dependency in my project. The package is basically a Swift wrapper around C++ code. If I run my app in Debug mode, then the performance of the library is an order of magnitude slower than when I run it in Release mode. In Release mode it is really fast, but compilation times are too slow. I am a complete beginner to Xcode's build system and was wondering if there was any way to have the best of both worlds? For example, by compiling my SwiftUI code without optimizations but having it linked to a static and optimized version of the library.

I have a SwiftUI app that I've been working on in XCode 16.1. The project builds and runs in the simulators, on my mac and on my iPhone/iPad without any issues. I'm also able to build my unit test project and run them without any errors. The project has zero warnings in it. When I go to the Edit Schemes options and change the Run scheme to be a Release build with the Debug Executable unchecked I get a compiler error: Command SwiftCompile failed with a nonzero exit code I've attempted this Release Run with the following target devices in XCode: My iPhone 15 Pro Max (iOS 18.2 Beta 3) MacBook Air (M1) (15.2 Beta) iPhone 16 Simulator (iOS 18.1) Any iOS Simulator Device (arm64, x86_64) All 3 of these target have the same issue. Normally I would just debug the error from the logs but when I look at the build output I can't see any information in the log to tell me what happened. It looks like the source files are sent into the SwiftCompiler and the compiler fails without bubbling up the issue. I've provided the full error log export as a Gist HERE due to it's size. Is there anything in the log I'm missing? Is there a way for me to turn on more verbose logging during compilation of a Release Build? I created a brand new Multiplatform App in XCode and I added all of my source files to it. No project configuration settings were changed. I could build it successfully with the debug configuration. I then changed it to the Release configuration and experienced the same error. I can create another fresh project and make the same release configuration with none of my source files in it and get a successful build. I t seems there is something wrong with my source files and the release configuration but the compiler doesn't indicate what. I'm lost at this point as I can't figure out how to get a release build and can't seem to find any indication as to why.

when trying to build wireshark I'm getting the following, any idea how to solve it? [ 13%] Building C object wsutil/CMakeFiles/wsutil.dir/os_version_info.c.o In file included from wireshark/wsutil/os_version_info.c:23: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:54: /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:676:195: error: expected ',' 676 | void *CFAllocatorAllocateTyped(CFAllocatorRef allocator, CFIndex size, CFAllocatorTypeID descriptor, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:679:211: error: expected ',' 679 | void *CFAllocatorReallocateTyped(CFAllocatorRef allocator, void *ptr, CFIndex newsize, CFAllocatorTypeID descriptor, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:682:165: error: expected ',' 682 | void *CFAllocatorAllocateBytes(CFAllocatorRef allocator, CFIndex size, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:685:181: error: expected ',' 685 | void *CFAllocatorReallocateBytes(CFAllocatorRef allocator, void *ptr, CFIndex newsize, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ In file included from wireshark/wsutil/os_version_info.c:23: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:73: /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFNumberFormatter.h:144:147: error: expected ',' 144 | CF_EXPORT const CFNumberFormatterKey kCFNumberFormatterMinGroupingDigits API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); // CFNumber | ^ 5 errors generated. make[2]: *** [wsutil/CMakeFiles/wsutil.dir/os_version_info.c.o] Error 1 make[1]: *** [wsutil/CMakeFiles/wsutil.dir/all] Error 2 make: *** [all] Error 2

I have a relatively unique project layered with file types (top to bottom) SwiftUI, Swift, Objective C, and C. The purpose of this layering is that I have a C language firmware application framework for development of firmware on custom electronic boards. Specifically, I use the standard C preprocessor in specific ways to make data driven structures, not code. There are header files shared between the firmware project and the Xcode iPhone app to set things like the BLE protocol and communication command/reply protocols, etc. The app is forced to adhere to that defined by the firmware, rather than rely a design to get it right. The Objective C code is mainly to utilize the Bluetooth stack provided by iOS. I specifically use this approach to allow C files to be compiled. Normally, everything has worked perfectly, but a serious and obtuse problem just surfaced a couple days ago. My important project was created long ago. More recently, I started a new project using most of the same technology, but its project is newer. Ironically, it continues to work perfectly, but ironically the older project stopped working. (Talking about the Xcode iOS side.) Essentially, the Objective C handling of the C preprocessor is not fully adhering to the standard C preprocessing in one project. It's very confusing because there is no code change. It seems Xcode was updated, but looks like the project was not updated, accordingly? I'm guessing there is some setting that forces Objective C to adhere to the standard C preprocessor rules. I did see a gnu compiler version that did not get updated compared to the newer project, but updating that in the Build Settings did not fix the problem. The error is in the title: Token is not a valid binary operator in a preprocessor subexpression. The offending macro appears in a header file, included in several implementation files. Compiling a single implementation files isolates the issue somewhat. An implementation with no Objective C objects compiles just fine. If there are Objective C objects then I get the errors. Both cases include the same header. It seems like the Objective C compiler, being invoked, uses a different C preprocessor parser, rather than the standard. I guess I should mention the bridging header file where these headers exist, as well. The offending header with the problem macro appears as an error in the bridging header if a full build is initiated. Is there an option somewhere, that forces the Objective C compiler to honor the standard C processor? Note, one project seems to. #define BLE_SERVICE_BLANK( enumTag, uuid, serviceType ) #define BLE_CHARACTERISTIC_BLANK( enumTag, uuid, properties, readPerm, writePerm, value) #define BLE_SERVICE_ENUM_COUNTER( enumTag, uuid, serviceType) +1 #define BLE_CHARACTERISTIC_ENUM_COUNTER( enumTag, uuid, properties, readPerm, writePerm, value) +1 #if 0 BLE_SERVICE_LIST(BLE_SERVICE_ENUM_COUNTER, BLE_CHARACTERISTIC_BLANK) &gt; 0 #define USING_BLE_SERVICE ... #if 0 BLE_SERVICE_LIST(BLE_SERVICE_BLANK, BLE_CHARACTERISTIC_ENUM_COUNTER) &gt; 0 #define USING_BLE_CHARACTERISTIC ... token is not a valid binary operator in a preprocessor subexpression refers to the comparison. BLE_SERVICE_LIST() does a +1 for each item in the list. There is no further expansion. One counts services. The other counts characteristics. The errors are associated with the comparisons.

Around a month back, developers of the OpenJDK project, when using XCode 16 to build the JDK started noticing odd failures when executing code which was compiled using the clang++ compiler shipped in that XCode 16 release (details in https://bugs.openjdk.org/browse/JDK-8340341). Specifically, a trivial for loop in a c++ code of the form: int limit = ... // method local variable for (i=0; i<limit; i++) { ... } ends up iterating more times than the specified limit. The "i<limit" returns true even when it should have returned false. In fact, debug log messages within the for loop of the form: fprintf(stderr, "parsing %d of %d, %d < % d == %s", i, limit, i, limit, (i<limit) ? "true" : "false"); would show output of the form: parsing 0 of 2, 0 < 2 == true parsing 1 of 2, 1 < 2 == true parsing 2 of 2, 2 < 2 == true Notice, how it entered the for loop even when 2 < 2 should have prevented it from entering it. Furthermore, notice the message says 2 < 2 == true (which clearly isn't right). This happens when that code is compiled with optimization level -O2 or -O3. The issue doesn't happen with -O1. I had reported this as an issue to Apple through feedback assistance, more than a month back. The feedback id is FB15162411. There hasn't been any response to it nor any indication that the issue has been noticed and can be reproduced (the steps to reproduce have been provided in that issue). In the meantime, more and more users are now running into this failure in JDK when using XCode 16. We haven't put any workaround in place (the only workaround we know of is using -O1 for the compilation of this file) because it isn't clear what exactly is causing this issue (other than the fact that it shows up with specific optimization levels). It's also unknown if this bug has wider impact. Would it be possible to check if FB15162411 is being looked into and any technical details on what's causing this? That would help us decide if it's OK to put in place a temporary workaround in the OpenJDK build and how long to maintain that workaround. For reference, this was reproduced on: clang++ --version Apple clang version 16.0.0 (clang-1600.0.26.3) Target: arm64-apple-darwin23.6.0 Thread model: posix InstalledDir: /xcode-16/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I have a few questions on build options. Deployment post processing - is this for Mac apps? Or is it a setting for Xcode ? Does "Symbols hidden by default" set to yes enable symbolicated crash dumps? Can "Product name" and "Product module name" be different from bundleID component? Generate_Info_Plist is set to no. Will the Application Category value be reflected if there is no Info_plist file generated? I notice in my tests that the category is always wrong and defaults to team name. Privacy - GameKit Friend List Usage Description should this be yes or no if I am using Apple suggested privacy preserving scoped identifier gamePlayerID? Install Group/Permissions/Owner are these referring to setting in Dev environment or are these Mac App Only settings? ( I was not sure if iOS like Unix, has system users exposed at this high level anyway ) How do I export copy of existing build settings to a xconfig file? There was talk of a tool not sure if it is still available. For my TestFlight build for stress testing , what options would you recommend to help debug and trace easily ? Note I have tested the build with various Address Sanitizer, Memory Sanitizer, Guard malloc etc. options enabled to prep but haven't turned any of those on for the test build. Should I be enabling some? ( Some do not work together ) Alternately, if there is a document or video that addresses all of the above please let me know! Thanks in advance!!

Hello, It appears that clang version provided by Xcode 16 brings this compilation error seen in previous LLVM version : https://github.com/llvm/llvm-project/issues/91362 Fixed in : https://github.com/llvm/llvm-project/pull/90760 #include <type_traits> template <typename T> struct class_tmpl { template <bool B> static int call_e() { return 0; } template <bool B> static int call_ne() noexcept { return 0; } template <bool B> static int call() noexcept(std::is_nothrow_copy_assignable<T>::value) { return 0; } }; int main(int argc, char *argv[]) { using function_ptr = int (*)(); function_ptr f1 = &class_tmpl<int>::call_e<false>; function_ptr f2 = &class_tmpl<int>::call_ne<false>; function_ptr f3 = &class_tmpl<int>::call<false>; return 0; } $ clang -std=c++17 main.cpp main.cpp:15:24: error: address of overloaded function 'call' does not match required type 'int ()' 15 | function_ptr f3 = &class_tmpl<int>::call<false>; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ main.cpp:7:34: note: candidate template ignored: substitution failure [with B = false] 7 | template <bool B> static int call() noexcept(std::is_nothrow_copy_assignable<T>::value) { return 0; } | ^ 1 error generated. Compiler informations : clang --version Apple clang version 16.0.0 (clang-1600.0.26.3) Target: arm64-apple-darwin24.0.0

This is one of the worst errors you can encounter while developing with Xcode. It looks like it's related to a problem inside the compiler itself: when there are lot of lines of code, it becomes unable to identify them all and start asking you to break down the code in smaller pieces. Sometimes you can, sometimes not. First of all, in your code there is FOR SURE an error, so in case of the second option, begin commenting entires sections of your code: this can lead to two options: You commented a section that contains the error: Xcode give you the preview and you check the commented section to find the error You commented enough code to let the compiler do its job, and you'll have the normal error reported in your code: again, fix it! Once errors have been fixed, normally you can uncomment what you excluded and all will go up and ok again. The most common errors that can lead to this behavior (but it's just a hint) are those involving parameters got or passed to other SwiftUI objects: parameters label (mistyped, missing, exceeding) parameters values (not $/& present, $/& present but not required) parameters types (you passed a wrong type) Well, I hope that this post could be useful to others that, like I did, are struggling a lot to understand the exact nature of this peculiar error. Code well and Prosper!

I'm running on xcode 16, the project archives just fine on the local machine. However, with xcodecloud. It's running into exist code 70 on the following command xcodebuild -exportArchive -archivePath ..... #output Showing All Errors Only Build Archive Export archive for ad-hoc distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70 Export archive for development distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70 Export archive for app-store distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70

I am developing a simple camera JNI interface program in Objc. I managed to compile. But I get the following link error. I use the following command. Is there anything I can add to solve this problem? Note that I use Intel MacMini. g++ -framework Foundation -framework AVFoundation CameraMacOS.m Undefined symbols for architecture x86_64: "_CMVideoFormatDescriptionGetDimensions", referenced from: _openCamera in CameraMacOS-517c44.o _listWebcamNamesAndSizes in CameraMacOS-517c44.o "_CVPixelBufferGetBaseAddress", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferGetBytesPerRow", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferGetHeight", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferGetWidth", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferLockBaseAddress", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferUnlockBaseAddress", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

With Xcode 16 I cant make the Final Cut Extension Workflow work. I am quite sure I was able to add the Workflow Extension target a couple of months ago in Xcode 15 and did successfully build it, but in Xcode 16 it wont build and it fails with this error: clang: error: unknown argument: '-e_ProExtensionMain' I have installed multiple times Workflow Extensions SDK 1.0.2 and even disabled Library validation like its described in the release notes but I dont think thats the problem here. Seems like clang doesn't have the arguments for it, I guess the SDK should add these but seems like something got messed up - the template shows up fine in Xcode. I reinstalled Xcode and command line tools but that didnt help. Checking clang it really doesnt have the argument. But where does the SDK add this? Xcode seems to be using internal clang and /usr/bin/clang doesn't have it either. Any tips what could be the problem here? I was not really able to locate the SDK to remove it before trying to install again - any ideas? Steps to reproduce Create new project Add FCP workflow extension target Build -> it fails Same behaviour with 16.1 Beta. I am running Sonoma 14.7. Thanks in advance for any ideas!

Hi there! Was there a change in Xcode regarding incremental builds / updating an active Simulator with a new build? We use xcodebuild to manage our internal build framework and out of the sudden, incremental builds are not launched anymore and the Simulator is stuck waiting for the new build to be launched. This was not happening for the last 10+ years. If there is an xcodebuild flag and/or guide of this new behavior, it would help a lot. Thanks everyone!

I suppose this is a bug in compiler. Xcode 16.0 (16A242d) - AppStore release version When building a project from Xcode 15 in Xcode 16, an error occurs: appintentsmetadataprocessor[12633:13677489] error: At least one halting error produced during export. No AppIntents metadata have been exported and this target is not usable with AppIntents until errors are resolved. AppShortcut phrases may have at most one parameter, but found phrase, "Set Dark Mode ${darkMode} for Widget ${widget}" with more than one parameter: darkMode, widget Apparently this is an Xcode bug because I have a production app with this AppShortcut and it works fine in Apple Shortcuts. Everything is made according to the official WWDC video about AppShortcuts https://developer.apple.com/videos/play/wwdc2022/10170

after updating to macOS sequoia C++ compiler on vscode is not working is it just me or it is a common issue ?

Hi i am currently using XCode 15 to build a Swift command line application. But when I try to build & debug my project, it throws an error saying that it could not launch the executable. It does build but as the error suggests, the Build dir does not have a executable in it. I have messed around with DerivedData & Build location settings for quite a bit with no luck. Currently both of them are at default settings as I cleared XCode caches from ~/Library/Caches & created a new project. I tried compiling the basic Hello World but that seems to "build" but with no executable. I have attached the report for the Could not launch error Error report Am i missing something with respect to build location / configuration? Thanks for any assistance.

Hi, I have a workspace with a couple of modules, and now I'm making a Swift package. It's great. However, i have this SwiftUI View extension you can see at the end of this post. My Swift package needs to have the target set to IOS16, so i have added #available where I need, like I've done in the past. When i had this extension in my Widget extension target, it worked fine. However, i am now trying to move that into my new Swift package, with the Swift package declaration you can also find below. When moved, i get an error from the compiler: Type 'ContainerBackgroundPlacement' has no member 'widget' It seems that my #available is ignored? I'm at a loss as to why this happens, so if anyone has any ideas i'm all ears. Otherwise guess i'll have to move it back to the Widget extension target :( My extension code: extension View { func widgetBackground(_ color: Color) -> some View { if #available(iOSApplicationExtension 17.0, *), #available(iOS 17.0, *) { return containerBackground(color, for: .widget) } else { return background(color) } } .....more stuff } Swift Package (i renamed and cropped some stuff for simplicity): import PackageDescription let package = Package( name: "MyPackage", platforms: [ .iOS(.v16) ], products: [ .library( name: "MyPackage", targets: ["MyPackage"] ) ], targets: [ .target( name: "MyPackage" ), .testTarget( name: "MyPackageTests", dependencies: ["MyPackage"] ) ] )