iOS Rules for Bazel
rules_ios
is community developed Bazel rules
that enable you to do iOS development with Bazel end to end.
It seamlessly Bazel builds iOS applications originally written under Xcode with
minimal-to-no code changes. It often re-uses ideas and code from rules_swift
and rules_apple
and it isn't tied to untested or unused features. It generates
Xcode projects that just work and makes using Apple Silicon with Bazel a
breeze.
Learn more at bazel-ios.github.io
it supports all the primitives like apps, extensions, and widgets
load("@build_bazel_rules_ios//rules:app.bzl", "ios_application")
ios_application(
name = "iOS-App",
srcs = glob(["*.swift"]),
bundle_id = "com.example.ios-app",
minimum_os_version = "12.0",
visibility = ["//visibility:public"],
)
Bazel optimized Xcode project generation that's tested and works end to end with open source remote execution and caching
load("@build_bazel_rules_ios//rules:xcodeproj.bzl", "xcodeproj")
xcodeproj(
name = "MyXcode",
bazel_path = "bazelisk",
deps = [ ":iOS-App"]
)
projects are optimized to build with Bazel and optionally fallback to building with Xcode
static frameworks with Xcode semantics - easily port existing apps to Bazel
# Builds a static framework
apple_framework(
name = "Static",
srcs = glob(["static/*.swift"]),
bundle_id = "com.example.b",
data = ["Static.txt"],
infoplists = ["Info.plist"],
platforms = {"ios": "12.0"},
deps = ["//tests/ios/frameworks/dynamic/c"],
)
rules_ios builds frameworks as static or dynamic - just flip
link_dynamic
apple_framework(
name = "Dynamic",
srcs = glob(["dynamic/*.swift"]),
bundle_id = "com.example.a",
infoplists = ["Info.plist"],
link_dynamic = True,
platforms = {"ios": "12.0"},
deps = [":Static"],
)
easily test iOS applications with Bazel - ui and unit testing rules
load("//rules:test.bzl", "ios_unit_test")
ios_unit_test(
name = "Unhosted",
srcs = ["some.swift"],
minimum_os_version = "11.0",
deps = [":Dynamic"]
)
- Automatically run legacy deps on Apple Silicon - it just works by running arm64-to-sim and more.
- Testing mechanisms to easily test in ephemeral VMs
Add the following lines to your WORKSPACE
file.
It pulls a vetted sha of rules_apple
and rules_swift
- you can find the
versions in
repositories.bzl
.
load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
git_repository(
name = "build_bazel_rules_ios",
remote = "https://github.com/bazel-ios/rules_ios.git",
branch = "master",
)
load(
"@build_bazel_rules_ios//rules:repositories.bzl",
"rules_ios_dependencies"
)
rules_ios_dependencies()
load(
"@build_bazel_rules_apple//apple:repositories.bzl",
"apple_rules_dependencies",
)
apple_rules_dependencies()
load(
"@build_bazel_rules_swift//swift:repositories.bzl",
"swift_rules_dependencies",
)
swift_rules_dependencies()
load(
"@build_bazel_apple_support//lib:repositories.bzl",
"apple_support_dependencies",
)
apple_support_dependencies()
load(
"@com_google_protobuf//:protobuf_deps.bzl",
"protobuf_deps",
)
protobuf_deps()
_See the tests directory for tested use cases.
Debugging does not work in sandbox mode, due to issue #108. The workaround for now is to disable sandboxing in the .bazelrc file.
Bazel version required by current rules is here
Xcode 13 and above supported, to find the last SHA
with support for older versions see the list of git tags.
Click here for the documentation.
LTS is a concept in Bazel for versions and we currently support 5.x.x only for a brief time. The rough ETA for removing Bazel 5.x.x LTS support is end of Q2 2023 and if it's an issue we can correct course sooner.
Because rules_ios
should be loosely coupled to a given Bazel version, we can
often handle several Bazel versions concurrently on HEAD
without significant
change and without having to have CI and review for LTS branches. Because we
want to keep running on HEAD
, LTS support is added with branches where
necessary. The idea is paralleled to other to large scale migrations or python
code which supported 2.x.x and 3.x.x concurrently.
We have a Bazel 5.x.x CI job which is the source of truth for vetting this.
For rules_apple
we attempt to achieve multi versions and smoothing over
maintainer velocity issues on a patched tag. For instance we may back-ported
some features to our tag like framework_import_support
We may shim APIs, back port patches from rules_apple
to add features and
smooth over integration. The unstable tag rules_ios_1.0
has it all. If you're
just bumping rules_apple
for Bazel 6.0 you shouldn't need to worry about the
LTS support if it passes CI. The burden to be an outlier should fall on the
outliers here - if you've got an issue we can look into it together.