We are using TensorFlowLiteC XCFramework and encountering an issue. Download link: https://dl.google.com/tflite-release/ios/prod/tensorflow/lite/release/ios/release/30/20231002-210715/TensorFlowLiteC/2.14.0/883c6fc838e0354b/TensorFlowLiteC-2.14.0.tar.gz Whenever this framework is linked, Previews fail with the following error: == PREVIEW UPDATE ERROR: FailedToLaunchAppError: Failed to launch cg.Xcode16TensorPreviewsRepro ================================== | [Remote] JITError | | ================================== | | | [Remote] LLVMError | | | | LLVMError: LLVMError(description: "file too small to be an archive") Since Xcode 16 will soon be the IDE for all our devs, it would be great if the community or Xcode Previews team could share any workarounds or solutions for this issue. FB(reproducer + additional diagnostics): https://feedbackassistant.apple.com/feedback/15084788 Thanks

This can be easily reproduced in a vanilla Xcode 16 beta 3 project. Steps Create a new project. By default, previews work fine because default SWIFT_COMPILATION_MODE is Incremental. (aka Batch Mode) Now, change it to WMO, and notice the previews crash with the enclosed crash report. Feedback filed with reproducer + diagnostics + crash report: https://feedbackassistant.apple.com/feedback/14268698 We have observed that enabling Whole Module Optimization (WMO) improves build times in our project. Therefore, if Previews can be compatible with WMO, it would be highly beneficial. Otherwise, it would be helpful to provide a warning or feedback to developers, as many projects are likely utilizing WMO, and identifying issues solely from crash reports can be challenging. Note: This works all fine with the Legacy Previews Engine in Xcode 15/16.

We have been seeing a dyld loader crash when trying out the new Previews engine in Xcode 16 beta 3. Feedback filed with reproducer + diagnostics: https://feedbackassistant.apple.com/feedback/14323960 Investigation: Running nm -a on the debug dylib reveals duplicate SO entries pointing to SomeStatic.swift. One entry originates from the LibAStatic module, while the other comes from the LibBStatic module. Local workaround - 1 Providing unique file names resolves the issue. However, these files are in different modules, so ideally, this shouldn't be necessary. Our codebase is extensive, and many code-generated modules have the same file names. Therefore, renaming files to ensure uniqueness is not a simple solution for us due to various complexities. Local workaround - 2 Making these dependencies dylibs instead of static libraries also resolves the issue. However, we can't pursue this direction because a significant portion of our pre-build setup, foundations, and vendor linkages are statically linked. Note: The same flow works with "Legacy Preview Engine in Xcode 16/15" but dynamic replacement has other issues, which we are super happy that the new engine doesn't make use of. This issue is currently a blocker for us in trying out the new Previews in our project, it would be highly beneficial if this problem could be resolved soon.