Mastering Fastlane: Overcoming Challenges in Passing Build Properties to Native Layers

Fastlane is a popular set of tools created to simplify monotonous tasks for developers. It is widely used across numerous application development processes because it offers a wide range of preinstalled plugins called lanes, which can be customized to automate various tasks.

This article will specifically discuss the handling of plist updates in iOS projects and the management of property passing in Android builds. Please note that this is a targeted exploration and does not cover all the interactions Fastlane has with these build systems.

The update_plist action in iOS

Fastlane's ^update_plist action offers a convenient way to modify the values of keys in plist files. As per the official Fastlane documentation, the syntax for the ^update_plist action is as follows:

While this syntax generally works as intended, there have been instances where it didn't yield the expected results. In our experience, we encountered situations where only some of the values in Info.plist were updated, despite the code appearing correct.

After investigation, we found that an alternative syntax could offer more reliable outcomes:

The key distinction here is in how we're referencing hash keys: we're using strings (plist['CLIENT_ID']) rather than symbols (plist[:CLIENT_ID]).

This is not an isolated observation. We found that others in the Fastlane community have encountered a similar situation, as evidenced by open tickets regarding this issue. It's important to note that while the symbol syntax works in many scenarios, using strings instead could potentially improve reliability when updating multiple values.

The gradle action in Android

Fastlane's ^gradle action offers a way for developers to pass custom properties to Gradle builds. For example:

In our experience, we faced issues with Gradle not recognizing certain properties during the build process. To solve this problem, we found it was necessary to define these properties beforehand in our project's ^{gradle.properties} file. This file is situated in the root directory of your project, and it's read every time a Gradle command is invoked.

Once these properties have been passed to the Gradle build, they can be accessed within your ^build.gradle file. Here's how you can access these properties:

In this block, the ^CLIENT_ID and ^{GOOGLE_APP_ID} properties are passed as string resources to the Android application, and they can be used within the application's code like any other string resource.

Conclusions

When working with Fastlane, paying attention to certain details can lead to more efficient application development.

For iOS, being mindful of the possible issue with using symbols instead of strings in the ^update_plist action can save valuable debugging time. On the Android side, specifying properties in the ^{gradle.properties} file and adhering to the correct syntax can streamline the build process, reducing the risk of unexpected errors.

These nuances may seem small, but they play a vital role in the overall development experience.