I now get the error:
xcrun: error: unable to find utility "ibtool", not a developer tool or in PATH.

I assume that mac_toolchain.SetToolchainEnvironment() is not getting called. In the GYP path, I think it gets called at build/gyp_environment.py. It's not clear to me how it's supposed to be called in the GN path, and/or how to pass the GYP_DEFINE force_mac_toolchain to gn. 
https://cs.chromium.org/chromium/src/build/mac_toolchain.py?q=mac_toolchain&sq=package:chromium&dr=C&l=9

I feel like I've managed to make this work before...Justin, thoughts?

Looks like this logic never made it into gn:
   https://codereview.chromium.org/1806733002

dpranke@ sdefresne@ any suggestions?

Add a GN build argument to pass in the path to xcode?

No, this logic never made it to GN, however, all Xcode tools invoked from the build should go through xcrun that respect the selection made with xcode-select.

This does not allow to use DEVELOPER_DIR to select the version of Xcode per checkout though, but it is error prone (as ninja will not detect that it will need to re-run gn gen if DEVELOPER_DIR changes, though we also have the same issue with xcode-select).

In my opinion, a better alternative would be to define a "xcode_path" variable in GN to allow the developer to select a specific version of Xcode. If unset, the build is the same as it currently is, but if set, DEVELOPER_DIR is set in the generated ninja project when invoking tools that depends on Xcode path (libtool, ibtool, ...).

I was already asked something similar by rohitrao when we were doing the migration from Xcode 7 to Xcode 8. This is already tracked by https://bugs.chromium.org/p/chromium/issues/detail?id=619921. I can try to have a look if this blocks the effort to work with Xcode 8 on Mac.

However, regarding #1, I think the problem is that ibtool is not part of the command-line tool and requires a real install of Xcode. But, why is ibtool required to build mac?

This is blocking hermetic toolchain on Mac, which in turn is blocking
updates to Xcode/SDK.

we have xibs

Environment variables should be passed as is to commands by ninja, so what happens if you do the following:

$ export DEVELOPER_DIR=...
$ gn gen ...
$ ninja -C ...

Adding DEVELOPER_DIR=...build/mac_files/Xcode.app fixes the issue. It seems like everyone is on board with adding a GN variable to select the xcode path. Can we raise the priority of 619921?

I tested two build configurations on the 10.12 machine:
debug + component +symbols and release + static + nosymbols. Chromium ran fine in both cases. I tried running some tests (unit_tests, browser_tests, content_unittests) and they seemed to work fine. I did not run all tests.

So everything seems to work % GN + hermetic.

If using DEVELOPER_DIR works, I would think we can lower the priority of 619921 (or leave as is) as this mean the build can work for bot. Using DEVELOPER_DIR is inconvenient for human (as they don't remember what is the value of the variable in a given shell) but fine for bots. The GN variable to configure the version of Xcode to use would be better for human and I agree that we should have such a variable, but I don't agree that it should be a priority (after all, using DEVELOPER_DIR is supported by the Apple command-line tool and is there to override the XCode selected by xcode-select).

I would prefer to avoid having any builder relying on environment variables where possible. It's usually not that obvious when env vars are different from the defaults on the bots, and that makes things harder to debug. Adding a GN arg for this should be trivial ... 

I'll look into making a GN arg for macOS.

GN + hermetic wasn't working, but the combination of macOS 10.12, Xcode 5.1.1, 10.10 SDK does.