Secret Environment Variables not used in Xcode Archive & Export

I’m successfully building and running tests for our iOS app that uses environment variables to set things like API secrets/keys. Some of these tests access these secrets, so it seems like at test time, they exist.

However when added the “Deploy to iTunes” step, the app is flagged as crashing. In our crash logs, I can see that our asserts are firing b/c environment variables are missing.

I’m not at all sure why the environment variables appear to be used during testing, but are not included during archive.

I’m very new to Bitrise, having come from Buddybuild and using this exact same setup there. Any guidance about where to start debugging would be very appreciated!

1 Like

Hi @rnystrom,

The environment variables you set on bitrise.io are available in the build / during the build as environment variables. That’s all, those are just env vars (including secrets).

It’s the same as if you set some env vars on your own Mac then run a build (e.g. with xcodebuild from your terminal). The env vars can be used during the build, but whether those will be built into the app depends on your build scripts.

We do not modify your project in any way, the Xcode steps just run Xcode actions (e.g. Xcode Test runs Xcode’s Test action). So whether the env vars will be included in the generated app depends on your Xcode configs.

I’m not 100% sure but I suspect you use(d) buddybuild’s SDK, or maybe they did modify your project, and that’s why those are included in the final .ipa. But in general environment variables are environment related, those exist in the environment they are defined in.

The usual solution to build any variable into the final .ipa / app is to have a script somewhere which writes the variables/secrets into a file, and then compile that file into the project. This can be e.g. a plist or json file, as long as it’s compiled/built into the .ipa/app.

I hope this helps, if you’d have any questions just let us know! :slight_smile:

1 Like

Aha! Good to know. We weren’t using the BB SDK, but I’ll pull their build logs and see if they were doing something special at the xcodebuild step.

It sounds like that at the very least I can use our secret env vars and pass them along to the build step? Seems doable.

Sure! That definitely works! :slight_smile:

Great idea, keep us updated, I’m interested! :wink:

Quick question: how do you define those variables locally on your Mac, e.g. if you’d want to or do create a test/ad-hoc .ipa?

One of the screenshots above is from my local Xcode project file settings, which are ignored from the repo.

1 Like

Thanks! But those are not used for Archive, right? Only for running directly from Xcode, but not if you do an Archive, generate an .ipa and install that on a real device. Though I might be wrong… :thinking:

1 Like

Oh nope, you’re right. Sorry! We setup this Secrets.swift file and also have a build phase script to replace the contents of the secrets on build.

I think this is where our issue is. We should be making env vars available to Bitrise in this build phase.

1 Like

Indeed, you can e.g. generate this Secrets.swift file with a script, or with a tool like https://github.com/krzysztofzablocki/Sourcery

1 Like

Is there a way to debug why build phase script echo output isn’t appearing in the Bitrise logs? I can see output like:

Running script 'Validate API Keys'

But then none of the echo, which there must be at least one, is showing up in logs. That’d help w/ debugging where things are missing.

1 Like

The output of those scripts is most likely not included in the build’s log, as that’s formatted by xcpretty by default.

Do you use our Xcode Archive step? If you do and you also have the Deploy to Bitrise.io step in the workflow (by default it should be included) then the raw xcodebuild output log is also available, attached to the build as an artifact:

That should include the script outputs, it’s the whole, raw output of xcodebuild.

Running the build locally via our CLI can also help with debugging / experimenting on the config: