diff --git a/docs/faq.md b/docs/faq.md
index 76e7facb1..b61070e6b 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -13,6 +13,7 @@
 * [After running `//:swift_update_pkgs`, I see a `.build` directory. What is it? Do I need it?](#after-running-swift_update_pkgs-i-see-a-build-directory-what-is-it-do-i-need-it)
 * [Does the Gazelle plugin run Swift package manager with every execution?](#does-the-gazelle-plugin-run-swift-package-manager-with-every-execution)
 * [Can I store the Swift dependency files in a sub-package (i.e., not in the root of the workspace)?](#can-i-store-the-swift-dependency-files-in-a-sub-package-ie-not-in-the-root-of-the-workspace)
+* [My project builds successfully with `bazel build ...`, but it does not build when using `rules_xcodeproj`. How can I fix this?](#my-project-builds-successfully-with-bazel-build--but-it-does-not-build-when-using-rules_xcodeproj-how-can-i-fix-this)
 <!-- MARKDOWN TOC: END -->
 
 ## Why use Gazelle and Go?
@@ -25,7 +26,7 @@ plugins for other languages](https://github.com/bazelbuild/bazel-gazelle#support
 Letting Gazelle generate and maintain Bazel build files is a real game changer for developer
 productivity.
 
-## Why split the implementation between Go and Starlark? 
+## Why split the implementation between Go and Starlark?
 
 As mentioned previously, the easiest way to implement a Gazelle plugin is to write it in Go. This
 works great for generating build files in the primary workspace. However, there is a chicken-and-egg
@@ -33,7 +34,7 @@ problem when it comes time to generate build files in a repository rule. The rep
 to generate files during the [loading phase]. The Go toolchain and the Gazelle framework defined in
 the workspace are not available to the repository rule during this phase. So, one needs to either
 perform some gymnastics to build the Gazelle plugin (see below) or use a language/runtime that is
-guaranteed to be available during the loading phase.  Since Starlark is available during the loading
+guaranteed to be available during the loading phase. Since Starlark is available during the loading
 phase, the build file generation logic for the repository rules is implemented in Starlark.
 
 ### How does the Gazelle plugin for Go handle this?
@@ -72,7 +73,7 @@ Yes. Just omit the `//:update_build_files` target that is mentioned in the [quic
 
 The `//:swift_update_pkgs` target runs the Gazelle plugin in `update-repos` mode. This mode
 resolves the external dependencies listed in your `Package.swift` by running Swift package manager
-commands.  These commands result in a `.build` directory being created. The directory is a side
+commands. These commands result in a `.build` directory being created. The directory is a side
 effect of running the Swift package manager commands. It can be ignored and should not be checked
 into source control. It is not used by the Gazelle plugin or the Starlark repository rules.
 
@@ -89,8 +90,24 @@ the source files that exist in your project to generate the Bazel build files.
 Yes. The [vapor example] demonstrates storing the Swift dependency files in a sub-package called
 `swift`.
 
+## My project builds successfully with `bazel build ...`, but it does not build when using `rules_xcodeproj`. How can I fix this?
 
-[loading phase]: https://bazel.build/run/build#loading 
+tl;dr Add the following to your `.bazelrc`.
+
+```
+# Ensure that sandboxed is added to the spawn strategy list when building with
+# rules_xcodeproj.
+build:rules_xcodeproj --spawn_strategy=sandboxed,remote,worker,local
+```
+
+This can happen with some Swift packages (e.g. `firebase-ios-sdk`). [rules_xcodeproj removes the
+`sandboxed` spawn
+strategy](https://github.com/MobileNativeFoundation/rules_xcodeproj/blob/6c186331c82f3cbc82e2e7fdfacb4873e409e094/xcodeproj/internal/templates/xcodeproj.bazelrc#L66-L68)
+in their default build configuration due to slow performance of the MacOS sandbox. The above bazelrc
+stanza adds it back. [An issue](https://github.com/cgrindel/rules_swift_package_manager/issues/712)
+exists tracking the work to allow these Swift packages to be built using the `local` spawn strategy.
+
+[loading phase]: https://bazel.build/run/build#loading
 [quickstart]: https://github.com/cgrindel/rules_swift_package_manager/blob/main/README.md#quickstart
 [rules_spm]: https://github.com/cgrindel/rules_spm/
 [rules_swift]: https://github.com/bazelbuild/rules_swift