Solution that works fine 😁 OK, it works fine now, thanks to Xcode team! Successfully tested with Xcode 13.2.1, 13.3.1, 13.4.1 and 14 beta 5. Here is the sample code. Technical explanation is detailed in the WWDC22 session Debug Swift debugging with LLDB. Short solution, in many cases. Static framework Use a Debug.xcconfig file dedicated to DEBUG configuration. // Xcode 13.3+ OTHER_LDFLAGS = -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalFramework.framework/Modules/InternalFramework.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-$(SHALLOW_BUNDLE_TRIPLE).swiftmodule // Xcode 13.2 OTHER_LDFLAGS[sdk=iphoneos15.2] = -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalFramework.framework/Modules/InternalFramework.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-ios.swiftmodule OTHER_LDFLAGS[sdk=iphonesimulator15.2] = -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalFramework.framework/Modules/InternalFramework.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-simulator.swiftmodule Static library Use a Debug.xcconfig file dedicated to DEBUG configuration. // Xcode 13.3+ OTHER_LDFLAGS = -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalStaticLibrary.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-$(SHALLOW_BUNDLE_TRIPLE).swiftmodule // Xcode 13.2 OTHER_LDFLAGS[sdk=iphoneos15.2] = -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalStaticLibrary.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-ios.swiftmodule OTHER_LDFLAGS[sdk=iphonesimulator15.2] = -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalStaticLibrary.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-simulator.swiftmodule CocoaPods with static linkage Update Podfile with this code. post_integrate do |installer| xcconfig_path = installer.sandbox.target_support_files_root.to_s + '/Pods-App/Pods-App.debug.xcconfig' xcconfig_content = File.read xcconfig_path xcconfig_original_ld_flags = xcconfig_content.match(/OTHER_LDFLAGS = ([^\n]+)\n/)[1] xcconfig_new_ld_flags = <<~CONTENT // Xcode 13.3+ OTHER_LDFLAGS = #{xcconfig_original_ld_flags} -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalPod/InternalPod.framework/Modules/InternalPod.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-$(SHALLOW_BUNDLE_TRIPLE).swiftmodule // Xcode 13.2 OTHER_LDFLAGS[sdk=iphoneos15.2] = #{xcconfig_original_ld_flags} -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalPod/InternalPod.framework/Modules/InternalPod.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-ios.swiftmodule OTHER_LDFLAGS[sdk=iphonesimulator15.2] = #{xcconfig_original_ld_flags} -Wl,-add_ast_path,$(TARGET_BUILD_DIR)/InternalPod/InternalPod.framework/Modules/InternalPod.swiftmodule/$(NATIVE_ARCH_ACTUAL)-apple-simulator.swiftmodule CONTENT xcconfig_content.gsub! /OTHER_LDFLAGS = ([^\n]+)\n/, xcconfig_new_ld_flags File.open(xcconfig_path, 'w') do |f| f.puts xcconfig_content end end

I found a potential answer. The sample source code (see above) has been updated. In fact, -add_ast_path with module is not required with Xcode < 13.3 and Xcode >= 14. But .swiftmodule path changed between Xcode versions. Is this a bug from Xcode or Swift 5.6? That's the question.

Forever the same problem. Sample code has been updated with a default static library included to project: https://github.com/florentmorin/Xcode13LLDBBug The same problem occurred with static pods and command line (in sample code)

Same problem with macOS 12.5 + Xcode 13.4.1. Feedback FB10426841 from end of June, taken in consideration since beginning of July. Shared sample code: https://github.com/florentmorin/Xcode13LLDBBug Issue opened to CocoaPods repository: https://github.com/CocoaPods/CocoaPods/issues/11470 Seems to be difficult to solve. If anyone has a solution, don't hesitate. 😅

I shared a sample code on GitHub if someone is ready to help... https://github.com/florentmorin/Xcode13LLDBBug

This bug can also be reproduced with CocoaPods, with use_frameworks! linkage: :static in Podfile.

When adding manually -add_ast_path and using -Wl on app target, I have an explicit message: building for iOS Simulator-arm64 but attempting to link with file built for unknown-unsupported file format ( 0xE2 0x9C 0xA8 0x0E 0x01 0x08 0x00 0x00 0x5D 0x0B 0x00 0x00 0x07 0x01 0xB2 0xC0 ) But it works fine without this on Xcode 13.2.1 and Xcode 14.0 beta. It fails only with Xcode 13.3.1 and Xcode 13.4.1. (not tested with Xcode 13.3.0 or Xcode 13.4.0)

Works on Xcode 14.0 beta 1. Works on Xcode 13.2.1. But same issue with Xcode 13.3 and Xcode 13.4.

Now available since iOS 15 😁

Currently in active review. Will arrive with a future Xcode 13 seed.

First, your data should be manipulated threw a Swift package. An internal Swift package is OK. You can use repositories for your data using protocols: a repository linked to a web service / a database a repository linked to memory and mocked data. Once you can run all the tests on your data, you can go to app stack. On your app, you can use dependencies inversion (or injection, as you want). A container will store repositories for all your app, but repositories type will be generic, based on protocol. If you run your app in tests mode (ProcessInfo provides environment variables to configure it), you can use repository with mocked data. It can also be useful with Xcode scheme with a "Preview" scheme that run the app in mocked environment. Your views (or view controllers) will have associated models. MVVM principle. The model for view transforms specific data in UI data (ie. Date -> String). View is initialized with a model as parameter. And view model is initialized with a generic repository. View model will access to data without knowing kind of source. Finally, container that store repositories will build the view model and view by injecting repositories in view models, and injecting configured view models in view and return configured view. With that, you will have an easy way to test your UI and a good separation of concerns. And, if you need to create an extension (Widget, Siri) or an other app (iOS, macOS), you will be able to reuse Swift package. Final advice: use security groups to share content between app and extensions. Even if it's not necessary while you build your app.

Go to your Apple Developer Account app groups list Select the group you want to remove Click on [Remove]

Finally done

Finally working with this solution, also used with SwiftUI: #if (arch(arm64) || arch(x86_64)) #if canImport(Combine) // Combine code #endif #endif

I think you can use SwiftCoreMLTools package. If it doesn't work, Core ML format is open-source and based on Protocol Buffer. And Protocol Buffer support for Swift has been open-sourced by Apple as a package. Information you need is here. /** * A Core ML model, * consisting of a specification version, * a model description, and a model type. * ... **/ message Model { int32 specificationVersion = 1; // ... }