Thi Doan

> the textual interface may be broken by project issues or a compiler bug I was able to build it by removing `import GCDTimeManager` from the swiftinterface files. It failed...

@sanju-naik Does it solve your issue?

> however same xcframework works fine on Xcode build system though Do you have a repro? > BazelDemo/ViewController.swift:9:8: error: failed to build module 'TImeManager' for importation due to the errors...

My suggestion is, instead of allowing adding `.metal` files to `data`/`resources` (how it works today), we move that `MetalCompile` action to a new rule `metal_library` (in which you can pass...

Are you building with `local` spawn strategy? It's because Bazel adds the read-only bit to all outputs after finishing the action.

I'm not sure if it's related but you can try to debug the state of the output directory by adding your debug code here: https://github.com/bazelbuild/rules_apple/blob/96fa885dd8310ddc65289e590f31d1f3b25f46d9/apple/internal/partials/apple_symbols_file.bzl#L78-L80

> Would adding an `execution_requirements` with `no-sandbox` be an option here? I wouldn't recommend doing so until we understand the issue here. > you can try to debug the state...

I noticed this in your log: `XXXXXXXXXXXX.framework-intermediates`, but `include_symbols_in_bundle` only exists in `{i,mac}os_application`. Are you building with a non-standard rule?

I think `umbrella_module_map` is the correct one, otherwise an `objc_library` won't be able to see the interface of the underlying Swift module. (I forgot to add an example to check...

Edit: It was the Obj-C umbrella header import statement in the Swift generated header, not the Swift generated header import statement within itself. Updated the above comment as well.