Dear Ed Ford, We've managed to achieve reproducible builds! We're not using the dSYM files, we're actually checking the executables. Here's how we did it: Sample App `-- Frameworks |-- Baseframework1.framework (Embed & Sign) |-- Baseframework2.framework (Embed & Sign) |-- Baseframework3.framework (Embed & Sign) `-- MiddlemanFramework.xcodeproj (Embed & Sign, Mach-O type=dynamic) `-- Frameworks |-- Baseframework1.xcodeproj (Do not embed, Mach-O type=dynamic) |-- Baseframework2.xcodeproj (Do not embed, Mach-O type=dynamic) `-- Baseframework3.xcodeproj (Do not embed, Mach-O type=dynamic) Accomplished with: Main App References Middle Layer Framework by .xcodeproj and .framework References base frameworks by .framework Embed setting set to Embed & Sign (both base frameworks and middle layer framework) Middle Layer Framework Mach-O type set to dynamic References base frameworks by .xcodeproj and .framework Embed setting set to Do not embed Base Framework: Mach-O type set to dynamic Since compiled libraries (xcframework) have to be of type static, we couldn't get it to work, but by having all frameworks be of type dynamic and reference them the way you said with Do Not Embed and Embed & Sign, we actually managed to compile an IPA with every framework as a dynamic executable and main application executable, which complies with the dwarfdump --uuid. I want to express my deep appreciation for your kindness and willingness to help us out, it truly has been a great help. Without your guidance, we wouldn't have been able to make it! Thank you very much! Kind regards

Any news on this? Still an issue on iOS 18.2 simulators 😕.

@DTS Engineer Any update on this? Kind regards.

Hi! Thank you so much for getting back to us! I've attempted to implement your suggestions, but with limited luck (although I feel like we're getting closer!). Instead of compiling each library and adding them as a dependancy to each other, I'm now just adding .framework files to the main project, compiling and extracting the DWARFDUMPs from the compiled Apps dependancies all at once (see script attached at bottom). Adding the frameworks as .framework (not compiled) to the App, results in the IPA frameworks folder only containing one instance of each framework (as siblings). I've also made sure CameraHandlingFramework is dynamic and not embedded in MiddlemanFramework. The result is not quite as expected, please see table: Runs Change Sample App Sample App/Middleman Framework Sample App/Camera Handling 1.1 return "String from bottom package! 1" (change in CameraHandling) DE644B74-0A0A-31DF-8BDA-DA08CEC35770 01EC531B-9669-3CDF-8027-95D6903B81E5 6F5D51D9-6EBD-3145-890C-B08A349F9FDB 1.2 return "String from bottom package! 2" (change in CameraHandling) DE644B74-0A0A-31DF-8BDA-DA08CEC35770 891DACF9-A25C-3D64-83E3-0617063F93C5 FFFE9A73-86F8-38B4-B58E-1FAF88FE6798 1.3 return "String from bottom package! 1" (change in CameraHandling) DE644B74-0A0A-31DF-8BDA-DA08CEC35770 8017A92D-3016-3426-80EB-574F23BF075C 6F5D51D9-6EBD-3145-890C-B08A349F9FDB 2.1 return StringGenerator.generateStaticString() (change in Middleman) DE644B74-0A0A-31DF-8BDA-DA08CEC35770 8017A92D-3016-3426-80EB-574F23BF075C 6F5D51D9-6EBD-3145-890C-B08A349F9FDB 2.2 print("hello")\nreturn StringGenerator.generateStaticString() (change in Middleman) 20159395-93F7-3E7D-8849-B1B72ABF3E20 578F83DD-FEC8-31F3-822F-32A5550979B3 6F5D51D9-6EBD-3145-890C-B08A349F9FDB 2.3 return StringGenerator.generateStaticString() (change in Middleman) DE644B74-0A0A-31DF-8BDA-DA08CEC35770 428E2617-034A-38DE-85A9-4838200DEDD2 6F5D51D9-6EBD-3145-890C-B08A349F9FDB The first attempts (1.x), we change a simple string in the camera handling framework without any other changes. Sample App dwarfdump remains the same (great), but the Middleman framework dwarfdump changes every time the camera handling framework is changed (unexpected). The second attempts (2.x), we add a simple print statement in the middleman framework. It behaves more strange than when changing camera handling, as it doesn't revert back to its original dwarfdump when changes are reverted back to original. Sample App dwarfdump also changes upon change of middleman framework, but at least reverts back to normal, when changes in middleman framework is reverted back to normal. Camera Handling in this instance does not change at all (great!). Please see the updated project and updated script in the following links: Script: https://biometricdk-my.sharepoint.com/:f:/g/personal/jsa_biometric_dk/EpF2-PKqyfJEhuDu9iNA7ZAB6tAm1USEMj6hoJqcF8kFSQ?e=WQlnCE Project(s): https://biometricdk-my.sharepoint.com/:f:/g/personal/jsa_biometric_dk/Er2vL6tLsA9GvA_LD_vCq_MBiBFyiAmfScyWIx9p39963A?e=4Eoz34 Paths in projects and scripts are defined absolutely, you have to fix this (fyi). It would be great if you could tweak the projects so we could get the desired result, which is: When Camera Handling Framework is changed (not interface, but internal code that doesn't require adaptation from hosts), that Sample App and Middleman Framework dwarfdump UUIDs persisted. When Middleman Framework is changed (not interface, but internal code that doesn't require adaptation from Sample App), that Sample App and Camera Handling framework dwarfdump UUIDs persisted. When Sample App is changed, Middleman Framework and Camera Handling Framework dwarfdump UUIDs persisted. Thank you so much, You've been a great help so far improving our understanding. I feel like we're close! Thanks again, Kind regards!

Dear Apple Engineer, Thank you very much for getting back to me. Absolutely, let me share everything. https://biometricdk-my.sharepoint.com/:u:/g/personal/jsa_biometric_dk/Eb_vXDZPslhOuctfHhWky28BX9NVymf5rGDGHZbE1GZg_Q?e=M3GqXn Use this link to download all the sample projects. Mind you, in this context, CameraHandlingFramework = LibraryB, MiddlemanFramework = LibraryA SampleApp = App https://biometricdk-my.sharepoint.com/:u:/g/personal/jsa_biometric_dk/ES_QjOarp1JKp93sKAE6BNwBl1ilMenTmWxHW2QxsFcYeg?e=mo9q7h Use this link to download a script I've built, which builds alle the projects, archives the frameworks and converts them to xcframeworks, archives the App to an IPA and dwarf-dumps all the executables in the IPA file. All the paths in the script are absolute, so please place the projects somewhere on your machine, and alter the script so the paths match you project destinations. Run the script, which should fail. CameraHandlingFramework.xcframework should have been created in the final_frameworks folder. Open MiddlemanFramework project, and reference the CameraHandlingFramework.xcframework in Middleman Framework project. Run the script again, it should fail. MiddlemanFramework.xcframework should have been created in the final_frameworks folder. Open Sample App project, and reference both CameraHandlingFramework.xcframework AND MiddlemanFramework.xcframework, which now should be available from final_frameworks folder. Run the script one more time, and you should see the UUIDs of the frameworks and App. Now change the string in generateStaticString() in CameraHandlingFramework project Run the script one last time. You will now experience the issue, where UUIDs are not behaving as they should (described in my previous comment). Hope that made sense, let me know if there is anything else you need from me. Kind regards, Johan

Unfortunately it does not seem to work exactly as intended. I've switched from Swift Packages to Xcode Frameworks. When I arhive and export the IPA and run dwarfdump on the following files, I get the UUIDs: Dwarfdump for App executable UUID: 828B8C63-D5CC-3923-A94F-668DF5823512 (arm64) /Users/jsa/Documents/Repositories/App/IPAs/Payload/App.app/App dwarfdump for LibraryA of App.app/Frameworks/LibraryA.framework UUID: 76C2661C-6145-3E40-B476-29A000FFA3EA (arm64) /Users/jsa/Documents/Repositories/App/IPAs/Payload/App.app/Frameworks/LibraryA.framework/LibraryA dwarfdump for LibraryB of App.app/Frameworks/LibraryA.framework/Frameworks/LibraryB UUID: A21C3BA2-4D81-3970-8D15-A21CCCAF78CD (arm64) /Users/jsa/Documents/Repositories/App/IPAs/Payload/App.app/Frameworks/LibraryA.framework/Frameworks/LibraryB.framework/LibraryB dwarfdump for LibraryB of App.app/Frameworks/LibraryB.framework UUID: AB28D8FB-B918-3AD0-AAEA-DE28007E0E3F (arm64) /Users/jsa/Documents/Repositories/App/IPAs/Payload/App.app/Frameworks/LibraryB.framework/LibraryB If I then change one print statement in LibraryB, I would expect only the UUID of LibraryB to change, but it seems both LibraryA and LibraryB changes. (Mind you LibraryA depends on LibraryB, but no code was altered in LibraryA) Dwarfdump for App executable UUID: 828B8C63-D5CC-3923-A94F-668DF5823512 (arm64) /Users/jsa/Documents/Repositories/App/IPAs/Payload/App.app/App dwarfdump for LibraryA of App.app/Frameworks/LibraryA.framework UUID: E971D17E-507F-303A-8E5B-4FEFB745CEDB (arm64) /Users/jsa/Documents/Repositories/SampleApp/IPAs/Payload/App.app/Frameworks/LibraryA.framework/LibraryA dwarfdump for LibraryB of App.app/Frameworks/LibraryA.framework/Frameworks/LibraryB UUID: A21C3BA2-4D81-3970-8D15-A21CCCAF78CD (arm64) /Users/jsa/Documents/Repositories/SampleApp/IPAs/Payload/App.app/Frameworks/LibraryA.framework/Frameworks/LibraryB.framework/LibraryB dwarfdump for LibraryB of App.app/Frameworks/LibraryB.framework UUID: 52CDA880-EADD-3B1C-BD3F-21996878F6F9 (arm64) /Users/jsa/Documents/Repositories/SampleApp/IPAs/Payload/App.app/Frameworks/LibraryB.framework/LibraryB Thank you vey much for your previous response, hope to hear from you again. Kind regards!