The project navigator in my project keeps collapsing for no apparent reason. I've hunted high and low but can't find a setting to keep it expanded. This is not a new project and the issue began recently after an Xcode upgrade. I am currently using Xcode 15.3 release candidate. If anyone knows how to fix this I'd be very grateful if they could let me know.

My application targets iOS 15+. Attempting to build and run it on my iPhone SE (orphaned at iOS 15.6) results in "Failed to prepare the device for development." I'm building with Xcode 15.2. What is the expected procedure here?

I got a new MacBook and set it up as a new one, not transferring any data from the old one. But now the Apple Watch (Series 6) paired with my iPhone (14 Pro Max) ist not shown in Xcode. iPhone and Watch are using the latest RC and also Xcode is the latest RC. But in Xcode I ca only see my iPhone, not the paired Watch. See Screenshots. The first shows the new MacBook and the second the old one. I already tried a lot, but nothing helps: Unpair Watch from Phone and then pair it again Plug the iPhone to different USB ports Restart Watch, iPhone and Mac Delete the iPhone from Xcode Enable and disable Developer Mode on iPhone and Watch What else can I try to get the Watch back?

Unable to discover swiftc command line tool info: Could not parse Swift versions from: Swift/ErrorType.swift:200: Fatal error: Error raised at top level: Error Domain=NSCocoaErrorDomain Code=4 "The file “swiftc” doesn’t exist." UserInfo={NSFilePath=swiftc} how to fix ?

When using Instruments in Xcode 15.3 on macOS Sonoma 14.3.1 symbols from system frameworks are not displaying. I've tried creating a template "App" project and running it on the iOS 17.4 simulator without any code changes and still am not seeing symbols so I can be sure it's not unique to my real-world project build settings. If I install Xcode 15.0 and run the same build in the same 17.4 simulator using Instruments 15.0 it shows thread names and symbols for UIKit and other frameworks but is still missing SwiftUI symbols. Instruments 15.3 Instruments 15.0 I've spent 2 days trying to narrow down why I couldn't debug my app and even deleted all my partitions and reinstalled macOS which didn't fix the issue.

Since Xcode 15.3 it has become impossible to build our project more twice in a row without encountering a batch of "internal inconsistency error: never received target ended message for target ID …". This issues appeared a few months ago (15.0 i think, but i'm not sure), but xcode 15.3 makes it almost unusable. We're a team of 3 iOS devs, and we're all having the problem. Our project involves a lot of SPM packages, a few cocoa pods, a few iOS Frameworks, and a bit of swiftgen. Nothing particularly special for a large project, and no custom build steps that does anything fancy. It is now to the point where we're looking for alternative to xcode, because we can't decently kill xcode and restart every time we have to build our code...

I have latest version Xcode-15.1 & Mac-os version Sonoma-14.3.1 - while running particularly UITest target Xcode not launching the simulator, even after build succeed & test's completed without any errors. I tried cleaning project, re-starting Xcode, restarting system(Mac) - no luck It would be helpful if I get any suggestion on resolving the issue.

When running a SwiftUI Multiplatform app in Xcode Cloud I'm getting the following error: CIWatcher encountered an error in CIWatcherTests failed with: Failed to install or launch the test runner. (Underlying Error: Could not launch “CIWatcherTests”. Runningboard has returned error 5. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn’t be completed. Launch failed. (Underlying Error: Launchd job spawn failed))) This runs fine on iOS and all those tests pass. The SwiftUI app on Mac is a menu bar app so I'm not sure if this could be the issue as it's not launching for some reason on the Xcode Cloud system? Maybe I need to add some run option to make this work? When run locally both iOS and macOS pass all the tests successfully

With the latest release of Xcode, my obj c++ project is now giving compile errors like this. No code has changed. Reverting to Xcode 15.2 solves this

We had Xcode Cloud working with our project. We needed to re-auth the repo which failed and ended up needing to remove the config to reset it up as new. When on AppStoreConenct it shows its now not configured and to setup, which is good but when launch Xcode, press setup Xcode cloud it just gets stuck on loading source code repositories.

We use a local swift package in 6 of our app extensions. The product from the local package that we link to each app extension is a dynamic framework. And while the dynamic framework is copied into the final app bundle once, the resource bundles of each target that comprise the dynamic framework is copied into each app extension. I'd much rather have the bundles be copied into the dynamic framework once to prevent app bloat. Here is a visualization of the issue: . └── MyApp.ipa/ ├── MyApp (executable) ├── MyDynamicFramework_TargetA.bundle ├── MyDynamicFramework_TargetB.bundle ├── MyDynamicFramework_TargetC.bundle ├── Frameworks/ │ └── MyDynamicFramework.framework/ │ ├── TargetA │ ├── TargetB │ └── TargetC └── PlugIns/ ├── Widgets.appex/ │ ├── MyDynamicFramework_TargetA.bundle │ ├── MyDynamicFramework_TargetB.bundle │ └── MyDynamicFramework_TargetC.bundle ├── Intents.appex/ │ ├── MyDynamicFramework_TargetA.bundle │ ├── MyDynamicFramework_TargetB.bundle │ └── MyDynamicFramework_TargetC.bundle ├── IntentsUI.appex/ │ ├── MyDynamicFramework_TargetA.bundle │ ├── MyDynamicFramework_TargetB.bundle │ └── MyDynamicFramework_TargetC.bundle ├── NotificationContent.appex/ │ ├── MyDynamicFramework_TargetA.bundle │ ├── MyDynamicFramework_TargetB.bundle │ └── MyDynamicFramework_TargetC.bundle ├── RichPushContent.appex/ │ ├── MyDynamicFramework_TargetA.bundle │ ├── MyDynamicFramework_TargetB.bundle │ └── MyDynamicFramework_TargetC.bundle └── NotificationService.appex/ ├── MyDynamicFramework_TargetA.bundle ├── MyDynamicFramework_TargetB.bundle └── MyDynamicFramework_TargetC.bundle Notice that the resource bundles of Target A, B, and C are copied multiple times causing an unhealthy app size. I'd either like the resource bundles to be copied into MyDynamicFramework or copied once into the app bundle and let the app extensions reference them. Given the SPM + Xcode linking is a black box for the most part, how would I accomplish this?

Hi guys, I tried to build my app using EAS but got ✖ Failed to register bundle identifier com.fitlinez.pt Received an internal server error from Apple's App Store Connect / Developer Portal servers, please try again later This request can not be processed right now - Service not available because of maintenance activities, please try again after some time. I've checked the System Status https://developer.apple.com/system-status/ and everything seems green! but the problem persists. Does anyone know how to fix it?

It's not possible to merge a framework with resource into an iOS app target because the resource are not included in the app bundle. Steps to reproduce: Create an Xcode Project with iOS App Template Add a Framework Target (make sure to "Embed in Application") Add an Asset Catalog to Framework Target Add an Color Resource (or Image Set, or any other Resource) Reference the Resource in App Target (I have used a SwiftUI View) Run on Device (!) to make sure everything works as expected Change "Create Merged Binary (MERGED_BINARY_TYPE)" build setting of app target to "Automatic (automatic)" Change app target settings to link, but not embed framework target (e.g. change from "Embed and Sign" to "Do Not Embed" in "Frameworks, Libraries and Embedded Content" section in "General" tab) Run again (on Device!) and observe how the resources framework resource cannot be found anymore (using SwiftUI you will see a "No image/color named '...' in asset catalog for ..." error message in console logs) Note: Everything works fine in Simulator Same behavior for Release and Debug configuration Same behavior for manual and automatic merging Same behavior for resources which are not bundled in Asset Catalog When archiving the app, an "Assets.car" file is never present (even when creating archiving for Simulator target, when "Allow archiving for Simulator" is enabled) Reported as FB13716505 Test Project: https://github.com/iteracticman/MergeableResources/

I'm building a Unity application for ios that also communicates with Firebase (and GDrive, if it makes a difference, as well as some other servers). When running it through Unity Build Automation with fastlane, this is what it's failing on. Help? inline-code[2024-04-10T09:53:11.680Z] - 7.4.1.2.7.4 - [0;36mINFO [0m: SwiftCompile normal arm64 Compiling\ AsyncAwait.swift,\ Result.swift,\ Storage.swift,\ StorageComponent.swift,\ StorageConstants.swift,\ StorageDeleteTask.swift,\ StorageDownloadTask.swift,\ StorageError.swift,\ StorageGetDownloadURLTask.swift,\ StorageGetMetadataTask.swift,\ StorageListResult.swift,\ StorageListTask.swift,\ StorageMetadata.swift,\ StorageObservableTask.swift,\ StoragePath.swift,\ StorageReference.swift,\ StorageTask.swift,\ StorageTaskSnapshot.swift,\ StorageTaskState.swift,\ StorageTokenAuthorizer.swift,\ StorageUpdateMetadataTask.swift,\ StorageUploadTask.swift,\ StorageUtils.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/AsyncAwait.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Result.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Storage.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageComponent.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageConstants.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageDeleteTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageDownloadTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageError.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageGetDownloadURLTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageGetMetadataTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/F... [2024-04-10T09:53:11.680Z] - 7.4.1.2.7.4 - [0;36mINFO [0m: torageTokenAuthorizer.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageUpdateMetadataTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageUploadTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageUtils.swift (in target 'FirebaseStorage' from project 'Pods') [2024-04-10T09:53:11.680Z] - 7.4.1.2.7.4 - [0;36mINFO [0m: (2 failures)

We have been using a Supervision Identity successfully over the last few years to allow us to Xcode debug on managed devices. Something has changed in the last few months which we are finding it hard to find a consistent solution to. We can't determine whether it's Xcode 15/iOS version related. Behaviour we see documented below All Macs with the Supervision Identity installed can open the device in Apple Configurator without need for trust acknowledge on the device. Configurator can open and stream the device console. All problematic devices are also registered as a development device with Apple. We have hit and miss connectivity in Finder, On failure it indicates that the trust prompt on the device needs to be accepted. No trust prompt is displayed Developer Mode on the device can't be enabled until we attempt to connect to Xcode Devices that pair successfully in Xcode do so almost immediately. If a device pairs in Xcode it is also visible in the native macOS Console application If a device fails to pair in Xcode we get a spinner and the message "Xcode has already started pairing with 'iPhone-X'. Select Trust on iPhone-X to complete pairing". The macOS console app reports "The user has not responded to the pairing request on 'iPhone-X' In neither case is a trust prompt displayed on a device. We are not able to Xcode pair any managed device running iOS 17.x. This includes devices that were successfully paired on iOS16.x then upgraded iOS16.x devices that pair with one Mac successfully will not pair with another Mac with the same Supervision Identity installed. The same behaviour is seen on Ventura and Sonoma Macs Clearing Trusted Computers in IOS Developer Mode has no effect None supervised iOS devices pair successfully on iOS 16 and 17 Has anyone else witnessed similar issues and found a work around ?

https://developer.apple.com/documentation/xcodekit/creating_a_source_editor_extension I created new MacOS project and added a Xcode Source Editor Extension target to the project. I run the extension in debug mode with extension target, but the extension is not show up in Editor menu debug mode Xcode. Xcode version is 15.3(released) MacOS version is 14.4.1 Sonoma

■Confirmation My post on the Apple Developer Forums is not published even though it have been reviewed. Does any work need to be done at the time of submission or after review in order to be published? ■Background of the question I posted one on the Apple Developer Forums yesterday. Immediately after posting, a message saying "It will be published if it passes the review" was displayed on the screen. This morning, that message disappeared, so I thought the post had been published, but my post was not displayed on the post list screen. I tried searching for the post title, but it doesn't appear for a while.

Recently a bunch of folks have asked about why a specific symbol is being referenced by their app. This is my attempt to address that question. If you have questions or comments, please start a new thread. Tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining Why a Symbol is Referenced In some situations you might want to know why a symbol is referenced by your app. For example: You might be working with a security auditing tool that flags uses of malloc. You might be creating a privacy manifest and want to track down where your app is calling stat. This post is my attempt at explaining a general process for tracking down the origin of these symbol references. This process works from ‘below’. That is, it works ‘up’ from you app’s binary rather than ‘down’ from your app’s source code. That’s important because: It might be hard to track down all of your source code, especially if you’re using one or more package management systems. If your app has a binary dependency on a static library, dynamic library, or framework, you might not have access to that library’s source code. IMPORTANT This post assumes the terminology from An Apple Library Primer. Read that before continuing here. The general outline of this process is: Find all Mach-O images. Find the Mach-O image that references the symbol. Find the object files (.o) used to make that Mach-O. Find the object file that references the symbol. Find the code within that object file. Those last few steps require some gnarly low-level Mach-O knowledge. If you’re looking for an easier path, try using the approach described in the A higher-level alternative section as a replacement for steps 3 through 5. This post assumes that you’re using Xcode. If you’re using third-party tools that are based on Apple tools, and specifically Apple’s linker, you should be able to adapt this process to your tooling. If you’re using a third-party tool that has its own linker, you’ll need to ask for help via your tool’s support channel. Find all Mach-O images On Apple platforms an app consists of a number of Mach-O images. Every app has a main executable. The app may also embed dynamic libraries or frameworks. The app may also embed app extensions or system extensions, each of which have their own executable. And a Mac app might have embedded bundles, helper tools, XPC services, agents, daemons, and so on. To find all the Mach-O images in your app, combine the find and file tools. For example: % find "Apple Configurator.app" -print0 | xargs -0 file | grep Mach-O Apple Configurator.app/Contents/MacOS/Apple Configurator: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64] … Apple Configurator.app/Contents/MacOS/cfgutil: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Extensions/ConfiguratorIntents.appex/Contents/MacOS/ConfiguratorIntents: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Frameworks/ConfigurationUtilityKit.framework/Versions/A/ConfigurationUtilityKit: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64] … This shows that Apple Configurator has a main executable (Apple Configurator), a helper tool (cfgutil), an app extension (ConfiguratorIntents), a framework (ConfigurationUtilityKit), and many more. This output is quite unwieldy. For nicer output, create and use a shell script like this: % cat FindMachO.sh #! /bin/sh # Passing `-0` to `find` causes it to emit a NUL delimited after the # file name and the `:`. Sadly, macOS `cut` doesn’t support a nul # delimiter so we use `tr` to convert that to a DLE (0x01) and `cut` on # that. # # Weirdly, `find` only inserts the NUL on the primary line, not the # per-architecture Mach-O lines. We use that to our advantage, filtering # out the per-architecture noise by only passing through lines # containing a DLE. find "$@" -type f -print0 \ | xargs -0 file -0 \ | grep -a Mach-O \ | tr '\0' '\1' \ | grep -a $(printf '\1') \ | cut -d $(printf '\1') -f 1 Find the Mach-O image that references the symbol Once you have a list of Mach-O images, use nm to find the one that references the symbol. The rest of this post investigate a test app, WaffleVarnishORama, that’s written in Swift but uses waffle management functionality from the libWaffleCore.a static library. The goal is to find the code that calls calloc. This app has a single Mach-O image: % FindMachO.sh "WaffleVarnishORama.app" WaffleVarnishORama.app/WaffleVarnishORama Use nm to confirm that it references calloc: % nm "WaffleVarnishORama.app/WaffleVarnishORama" | grep "calloc" U _calloc The _calloc symbol has a leading underscore because it’s a C symbol. This convention dates from the dawn of Unix, where the underscore distinguish C symbols from assembly language symbols. The U prefix indicates that the symbol is undefined, that is, the Mach-O images is importing the symbol. If the symbol name is prefixed by a hex number and some other character, like T or t, that means that the library includes an implementation of calloc. That’s weird, but certainly possible. OTOH, if you see this then you know this Mach-O image isn’t importing calloc. IMPORTANT If this Mach-O isn’t something that you build — that is, you get this Mach-O image as a binary from another developer — you won’t be able to follow the rest of this process. Instead, ask for help via that library’s support channel. Find the object files used to make that Mach-O image The next step is to track down which .o file includes the reference to calloc. Do this by generating a link map. A link map is an old school linker feature that records the location, size, and origin of every symbol added to the linker’s output. To generate a link map, enable the Write Link Map File build setting. By default this puts the link map into a text (.txt) file within the derived data directory. To find the exact path, look at the Link step in the build log. If you want to customise this, use the Path to Link Map File build setting. A link map has three parts: A simple header A list of object files used to build the Mach-O image A list of sections and their symbols In our case the link map looks like this: # Path: …/WaffleVarnishORama.app/WaffleVarnishORama # Arch: arm64 # Object files: [ 0] linker synthesized [ 1] objc-file [ 2] …/AppDelegate.o [ 3] …/MainViewController.o [ 4] …/libWaffleCore.a[2](WaffleCore.o) [ 5] …/Foundation.framework/Foundation.tbd … # Sections: # Address Size Segment Section 0x100008000 0x00001AB8 __TEXT __text … The list of object files contains: An object file for each of our app’s source files — That’s AppDelegate.o and MainViewController.o in this example. A list of static libraries — Here that’s just libWaffleCore.a. A list of dynamic libraries — These might be stub libraries (.tbd), dynamic libraries (.dylib), or frameworks (.framework). Focus on the object files and static libraries. The list of dynamic libraries is irrelevant because each of those is its own Mach-O image. Find the object file that references the symbol Once you have list of object files and static libraries, use nm to each one for the calloc symbol: % nm "…/AppDelegate.o" | grep calloc % nm "…/MainViewController.o" | grep calloc % nm "…/libWaffleCore.a" | grep calloc U _calloc This indicates that only libWaffleCore.a references the calloc symbol, so let’s focus on that. Note As in the Mach-O case, the U prefix indicates that the symbol is undefined, that is, the object file is importing the symbol. Find the code within that object file To find the code within the object file that references the symbol, use the objdump tool. That tool takes an object file as input, but in this example we have a static library. That’s an archive containing one or more object files. So, the first step is to unpack that archive: % mkdir "libWaffleCore-objects" % cd "libWaffleCore-objects" % ar -x "…/libWaffleCore.a" % ls -lh total 24 -rw-r--r-- 1 quinn staff 4.1K 8 May 11:24 WaffleCore.o -rw-r--r-- 1 quinn staff 56B 8 May 11:24 __.SYMDEF SORTED There’s only a single object file in that library, which makes things easy. If there were a multiple, run the following process over each one independently. To find the code that references a symbol, run objdump with the -S and -r options: % xcrun objdump -S -r "WaffleCore.o" … ; extern WaffleRef newWaffle(void) { 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 ; Waffle * result = calloc(1, sizeof(Waffle)); 14: 94000000 bl 0x14 <ltmp0+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … Note the ARM64_RELOC_BRANCH26 line. This tells you that the instruction before that — the bl at offset 0x14 — references the _calloc symbol. IMPORTANT The ARM64_RELOC_BRANCH26 relocation is specific to the bl instruction in 64-bit Arm code. You’ll see other relocations for other instructions. And the Intel architecture has a whole different set of relocations. So, when searching this output don’t look for ARM64_RELOC_BRANCH26 specifically, but rather any relocation that references _calloc. In this case we’ve built the object file from source code, so WaffleCore.o contains debug symbols. That allows objdump include information about the source code context. From that, we can easily see that calloc is referenced by our newWaffle function. To see what happens when you don’t have debug symbols, create an new object file with them stripped out: % cp "WaffleCore.o" "WaffleCore-stripped.o" % strip -x -S "WaffleCore-stripped.o" Then repeat the objdump command: % xcrun objdump -S -r "WaffleCore-stripped.o" … 0000000000000000 <_newWaffle>: 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 14: 94000000 bl 0x14 <_newWaffle+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … While this isn’t as nice as the previous output, you can still see that newWaffle is calling calloc. A higher-level alternative Grovelling through Mach-O object files is quite tricky. Fortunately there’s an easier approach: Use the -why_live option to ask the linker why it included a reference to the symbol. To continue the above example, I set the Other Linker Flags build setting to -Xlinker / -why_live / -Xlinker / _calloc and this is what I saw in the build transcript: _calloc from /usr/lib/system/libsystem_malloc.dylib _newWaffle from …/libWaffleCore.a[2](WaffleCore.o) _$s18WaffleVarnishORama18MainViewControllerC05tableE0_14didSelectRowAtySo07UITableE0C_10Foundation9IndexPathVtFTf4dnn_n from …/MainViewController.o _$s18WaffleVarnishORama18MainViewControllerC05tableE0_14didSelectRowAtySo07UITableE0C_10Foundation9IndexPathVtF from …/MainViewController.o Demangling reveals a call chain like this: calloc newWaffle WaffleVarnishORama.MainViewController.tableView(_:didSelectRowAt:) WaffleVarnishORama.MainViewController.tableView(_:didSelectRowAt:) and that should be enough to kick start your investigation. IMPORTANT The -why_live option only works if you dead strip your Mach-O image. This is the default for the Release build configuration, so use that for this test. Revision History 2025-07-18 Added the A higher-level alternative section. 2024-05-08 First posted.

We are received the following error while uploading the application into TestFlight. **ITMS-90714: Invalid binary - The app contains one or more corrupted binaries. Please rebuild the app and resubmit. ** After sometimes we submit the same application without changing the configurations application submitted successfully into the App Store. We are using the Xcode 15.3 version.

Xcode 15 introduced official support for static frameworks. docs here This is presumably because there's quite a bit over overlap with the mergeable libraries feature. Static frameworks potentially give developers a nice option for bundling resources with a static library. This was previously only really viable if you explicitly packaged up a .bundle with your .a (static library) which could be cumbersome for both the creator and consumer of a library. Or you explicitly copied your framework resources into your main app binary when building your app. The release notes for Xcode 15 state: Embedding a static framework using a Copy Files build phase now removes the static archive from the framework when it is embedded in the target bundle. When inspecting the app target on disk this appears to be the case. In fact the behaviour is the same as with a mergable in release mode whereby a "stub" binary exists with no symbols. The release notes also state: The COPY_RESOURCES_FROM_STATIC_FRAMEWORKS build setting, previously used in the legacy build system to extract and copy the resources from a static framework to the target bundle, no longer has any effect with the new build system as the entire framework is copied instead This also appears to be the case when inspecting the files on disk as the frameworks appear to be present in the main app with their resources. So far so good. The issue arises when trying to access the bundle associated with this framework. The documentation doesn't mention any special access requirements to it's assumed that standard bundle access APIs should work. Using a class let bundle = Bundle(for: InfoCoreMain.self) This returns the main application bundle and therefore fails to find the correct asset. This can be rationalised by the fact that the InfoCoreMain class does now actually exist within the main app target binary due to being statically linked. It's worth noting however, that mergable libraries in release mode do seem to work in this way and can resolve the bundle fine*. Using an explicit bundle identifier let bundle = Bundle(identifier: "xxx.xxx.InfoCore") Using an explicit bundle identifier returns nil even though we can see the framework on disk. Using a path Using a path to access the framework also doesn't work. if let bundlePath = Bundle.main.path(forResource: "InfoCore", ofType: "framework") { let bundle = Bundle(path: bundlePath) // Now you can access resources in the framework bundle } else { // Framework bundle not found } All of the above is the same behaviour for release and debug builds. I have tried this on Xcode 15.2 and 15.3 *Mergeable libraries do seem to have issues in debug mode. See this forum post. https://forums.developer.apple.com/forums/thread/749818