As far as I know you cannot use the same library for arm64 iPhone and iPhone Simulator and instead you have to link each one based on the platform you're building. The best way I've found to do this is using the Other Linker Flags and then add an option for "Any iOS Simulator SDK" and "Any iOS SDK." Then you use -lname_of_library to specify if you want to use an iPhone version or an iPhone Simulator version. I use a .xcconfig file to accomplish this. Here's a working example of linking to fmod for either simulator or device: OTHER_LD_FLAGS_SIMULATOR = $(DEFAULT_OTHER_LD_FLAGS) -lfmodL_iphonesimulator OTHER_LD_FLAGS_DEVICE = $(DEFAULT_OTHER_LD_FLAGS) -lfmodL_iphoneos OTHER_LD_FLAGS = $(DEFAULT_OTHER_LD_FLAGS) OTHER_LD_FLAGS[sdk=iphoneos*] = $(OTHER_LD_FLAGS_DEVICE) OTHER_LD_FLAGS[sdk=iphonesimulator*] = $(OTHER_LD_FLAGS_SIMULATOR) Hope this helps. References: https://developer.apple.com/documentation/xcode/adding-a-build-configuration-file-to-your-project

Thank you. We did manually remove the extended attribute but these were .json files and only contained data. Eventually I was able to poke IT enough and they found there were settings in there managed profiles from Jamf that were too eager to quarantine these files from git. Hopefully the problem will not reoccur after they adjusted the policy.

Thank you, we write a lot of C++ and will gladly take any safety we can get.

The link on the developer.apple.com downloads page has been updated as well.

I figured this out. It was related to Dead Code Stripping.

Correct, just obfuscating the details a bit. The class that the plugin used wasn't used outside of the plugin so after the static linking and dead code stripping it was no longer in the symbol table. It took a lot of digging to find this, at least for me.

I think I figured it out, because of course after I make a post I do. I turned off dead code stripping along with modifying the strip behavior to not remove global symbols on strip. The plugins now seem to load successfully.

It seems to be trailing off after 94 minutes and I am now able to load when previously I was not. We changed nothing on our end. Seems to be Unity Ads related and not Apple.

Just a guess, but since this is an iOS 18 feature and that is supported in Xcode 16, I imagine you'd have to use Xcode 16 to see those options.

iOS 18 is in beta and has to be used with Xcode 16 beta.

Define _LIBCPP_ENABLE_EXPERIMENTAL and you should get it. See <__ranges/join_view.h> for the explanation: // Note: `join_view` is still marked experimental because there is an ABI-breaking change that affects `join_view` in // the pipeline (https://isocpp.org/files/papers/D2770R0.html). // TODO: make `join_view` non-experimental once D2770 is implemented. #if _LIBCPP_STD_VER >= 20 && defined(_LIBCPP_ENABLE_EXPERIMENTAL) Funnily enough, the URL in the header file appears to be incorrect, but P2770R0 https://isocpp.org/files/papers/P2770R0.html correct.

std::pmr::get_default_resource is available in C++17 and later, but I'm not sure when / if it was fully supported by Xcode. You might want to double check your C++ version in your project to make sure you're linking to a new enough version of libc++.

You're using Beta software. Xcode 14.3.1 isn't supported on Sonoma and Xcode 15 isn't out of beta yet. Neither is Sonoma for that matter.

I see ld: warning: ignoring duplicate library '-lc++' along with ld: warning: ignoring duplicate library '-lz' in my project in Xcode 15 Beta 5. I've double checked and I'm not including them anywhere explicitly. I am getting less of them than I got in previous Xcode 15 beta builds.

You have to use Xcode 14.2 to target 16.3 on a connected device. If you build an archive build you should be able to side load it to your device, but it isn't a great debugging experience.