rules_apple

The rules_apple repository provides specialized Bazel rules for building watchOS applications, bundles, and dynamic frameworks. The primary rules available for watchOS development are:

• watchos_application: Used to define a watchOS application.
• watchos_build_test: Used for building and testing watchOS targets.
• watchos_dynamic_framework: Used to create dynamic frameworks specifically for watchOS.

The rules_apple repository provides specialized Bazel rules for developing, building, and testing applications targeting Apple's visionOS platform. Key rule types include:

• visionos_application: Used to define a visionOS application and its associated bundles.
• visionos_build_test: Used for running build tests specifically for visionOS targets.
• visionos_dynamic_framework: Used to create dynamic frameworks compatible with visionOS.

hmaptool is a utility used to create binary headermaps. These headermaps enable angle bracket imports (e.g., #import <Header.h>) for headers when building with Bazel.

It is required when your project relies on Xcode's default behavior of generating headermaps, allowing you to mimic that behavior within a Bazel build environment.

Bazel uses Output Groups to signal which specific files should be built. While bazel build targets the default group, rules_apple provides additional groups for debugging artifacts.

Note: To actually generate these files, you must also pass the corresponding generation flag (e.g., --apple_generate_dsym for dSYMs).

# To build dSYMs and linkmaps for the top level target AND its dependencies:

bazel build --apple_generate_dsym --objc_generate_linkmap --output_groups=+dsyms,+linkmaps //your/target

Providers are used to communicate information between custom rules that interact with rules_apple. While most users building standard Apple targets will not need to interact with them directly, they are part of the public API for anyone writing custom rules that consume or propagate Apple bundling information.

Important Note for Rule Authors: Always load providers from @rules_apple//apple:providers.bzl rather than internal paths. This ensures you are using the stable public API.

The following providers are used as "marker" providers to indicate that a target is a specific type of tvOS bundle. They do not contain fields of their own, but rule authors can use them to enforce requirements that a dependency must be a specific bundle type.

• TvosApplicationBundleInfo: Indicates a tvOS application.
• TvosExtensionBundleInfo: Indicates a tvOS application extension.

load("@rules_apple//apple:providers.bzl", "TvosApplicationBundleInfo")
TvosApplicationBundleInfo()

When using rules_apple, be aware of Apple's bundle size constraints for App Store distribution. rules_apple does not support building zipped archives that exceed these limits:

• iOS and tvOS: Maximum bundle size is 4GB.
• watchOS: Maximum bundle size is 75MB.

If your build outputs (such as test bundles) exceed these limits, you must reduce the number of dependencies or split your targets into smaller pieces to ensure the output size remains within the allowed threshold.

Bazel Apple rules track resource ownership based on the dependency graph. A resource is packaged into the same bundle that contains the binary that links the library code.

• Static Linking: If MySharedLibrary is statically linked into MyApplication, its resources are placed in MyApplication.app/.
• Dynamic Frameworks: If MySharedLibrary is a dependency of MyFramework (a dynamic framework), its resources are packaged inside the framework bundle: MyApplication.app/Frameworks/MyFramework.framework/.
• Duplication: If multiple libraries depend on the same resource, but those libraries are linked into different bundles (e.g., one in the App and one in a Framework), the resource will be duplicated in both bundles. To avoid this, ensure that all libraries requiring the resource are linked into the same target (e.g., the framework).

Info.plist

macos_framework requires the infoplists attribute, which takes a list of .plist files. These files are merged to create the final Info.plist for the bundle.

Localization and Strings

Use the strings attribute to include .strings files (often used for localization).

• If the file is in a directory named *.lproj, it is placed in a directory with that same name within the bundle.
• Otherwise, the files are converted to binary plists and placed in the root of the bundle.

When using ios_framework, you can control how the bundle is identified and named using several attributes:

• bundle_id: The full bundle ID (e.g., com.example.myframework). Use this if you are not using a base bundle ID.
• base_bundle_id: A base bundle ID rule used to compose the final bundle ID.
• bundle_id_suffix: A string appended to the composed bundle ID from base_bundle_id following a . separator. Defaults to "bundle_name".
• bundle_name: The desired name of the bundle without the extension. Defaults to the target name if not set.
• executable_name: The name of the executable within the bundle. Defaults to bundle_name if set, otherwise the target name.