Frequently Asked Questions about rules_xcodeproj

Why do I get a visibility or unexported files error with xcodeproj?

Even though you might have your xcodeproj target declared in the same package as your top_level_targets, internally rules_xcodeproj creates another target in a sub-package under the @rules_xcodeproj_generated repo. You’ll need to adjust your visibility/package_group to include "@rules_xcodeproj//xcodeproj:generated", and export any files used in xcodeproj.{associated_,}extra_files.

Does the Archive action work?

Currently no effort is put into making the Archive action work correctly. rules_xcodeproj’s primary goal is to support running and debugging of targets, and might make optimizations that break the generated .xcarchive that the Archive action produces.Instead of using the Archive action to submit to the App Store, you should generate an IPA with bazel and upload that.

Why are there multiple versions of some of my targets?

If the transitive closure of dependencies of targets specified by xcodeproj.top_level_targets has targets with multiple configurations, they will be included in the project with those various configurations. This can be useful/expected — for example, having multiple platform versions of a given swift_library. When possible, the generated project will consolidate these various versions of a target into a single Xcode target. When targets can’t be consolidated (usually because they are functionally equivalent from Xcode’s point of view), they will appear as separate Xcode targets.If you have multiple unexpected versions of some targets — usually with a hash after their name — that is unintended. Check whether your build is adding multiple configurations of the same targets to the build graph (e.g. app extensions or tests having different minimum OS versions than the app, which can possibly be fixed by using minimum deployment OS version instead). If you need help, reach out to us.One particular case to watch out for is accidentally including a watchos_application in xcodeproj.top_level_targets when it’s being embedded in an ios_application target. watchos_application targets should only be included in xcodeproj.top_level_targets when they are not being embedded by an ios_application target, since they will have a different configuration applied to them, resulting in multiple Xcode targets.

What is CompileStub.m?

If you have a top-level target, such as ios_application, and its primary library dependency is also directly depended on by another top-level target, such as ios_unit_test, then the library cannot be merged into the first top-level target. When that happens, the first top-level target has no source files, so a stub file (CompileStub.m) must be added to allow Xcode to link to the proper library target.If this setup isn’t desired (e.g. you want the target merged to enable Xcode Previews), there are a couple of ways to fix it:

For tests, setting the first top-level target as the test_host will allow the library to merge.
In other cases, refactor the build graph to have the shared code in its own library, separate from the top-level target’s primary library.

Why do some of my swift_librarys compile twice in BwX mode?

If you have header-based rules that depend on the Swift generated header (i.e. custom modulemap or hmap rules), then when BwX mode generates those files with Bazel, it causes Bazel to generate the Swift generated header by compiling the swiftmodule.Possible solutions are:

Refactor mixed-language targets to single-language targets, removing the need for the custom modulemap that references the Swift generated header.
Remove the use of header maps (hmaps), or don’t include Swift generated headers in them.
Use BwB mode instead.

Why does Xcode complain about stale files?

The generated project tracks Bazel-managed external and generated files. If you remove a dependency on one of those files, or the path of one of those files changes (e.g. because of a Bazel configuration change), and you regenerate the project without first closing and reopening it or performing a clean build, Xcode will warn about the old paths. This appears to be a caching bug in Xcode.

Why does "X" happen when switching between build modes?

The different build modes configure the project in different ways. Because of this, if you switch the build mode of a project that has already built something, the artifacts in Xcode’s Derived Data might cause warnings or errors on subsequent builds. rules_xcodeproj does not officially support this use case, and recommends declaring a different xcodeproj target for each build mode if needed.

Why do I not see any simulators after generating the project?

This can happen if you have opened Xcode using Rosetta. The solution is to get native ARM simulator support for your app and disable Rosetta.

Why do I get an error like "Provisioning profile is Xcode managed, but signing settings require a manually managed profile"?

This error should no longer happen — please report it as a bug.The provisioning_profile you have set on your top-level target (e.g. ios_application) is resolving to an Xcode managed profile. This is common if you use the local_provisioning_profile rule. If that is desired, use the xcode_provisioning_profile rule to tell xcodeproj that this is an Xcode managed profile:

ios_application(
   ...
   provisioning_profile = ":xcode_profile",
   ...
)

xcode_provisioning_profile(
   name = "xcode_profile",
   managed_by_xcode = True,
   provisioning_profile = ":provisioning_profile",
)

Also, the :provisioning_profile target must be a rule that returns the AppleProvisioningProfileInfo provider (such as local_provisioning_profile), and the team_id attribute on that provider must be set — or team_id must be set on the :xcode_profile target.

Why do I get: Xcode could not find provisioning profiles matching TEAM_ID/PROFILE_NAME?

This error should no longer happen — please report it as a bug.The provisioning_profile you have set on your top-level target (e.g. ios_application) is resolving to a provisioning profile that hasn’t yet been installed to ~/Library/MobileDevice/Provisioning Profiles. This is common if you use the local_provisioning_profile rule and specify fallback profiles, or if you specify a profile in the workspace.Copying the profile to ~/Library/MobileDevice/Provisioning Profiles will resolve the error.

Get Started

Guides

Reference

Resources