Keith Smiley
Keith Smiley
With this BUILD file: ```bzl load("@build_bazel_rules_apple//apple:apple.bzl", "apple_static_xcframework") apple_static_xcframework( name = "foo", ios = { "simulator": ["x86_64"], "device": ["arm64"], }, minimum_os_versions = {"ios": "15.0"}, public_hdrs = ["no_header.h"], deps = ["no_target"], )...
This is change 1 of _N_ to migrate the Swift build rules to use new-style Bazel toolchains. This change: * Updates the toolchain configuration rules to wrap the `SwiftToolchainInfo` provider...
This is the same as https://github.com/bazelbuild/rules_apple/pull/1381 but for macOS
I've been looking through bazel/rules_apple/apple_support/rules_swift and it appears that there's a decent amount of integration for supporting code coverage that could work for iOS. But it seems like some critical...
With the attached sample project if you run `bazel test app:hosted_test --test_output=streamed`, the tests never complete. Adding `--strategy=TestRunner=local`, or setting `tags = ["no-sandbox"]` works around it. In the console logs...
Many 3rd party dependencies in the iOS ecosystem expect to be consumed as a framework and therefore setup their `#import`s in a way that expects that. Today if you build...
The key here is the module_name of the test source lib is the same as the test name so the ProductModuleName in the xctestrun file matches the module name
ld64 automatically codesigns binaries in some cases, like when building on a M1 machine, this can be duplicative if we separately sign the binary right afterwards, we should investigate if...
This is more complicated than just changing the binary path because the way we use it it expects relative paths inside of Xcode, so we have to duplicate those details...