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!