Mastering Fastlane: Overcoming Challenges in Passing Build Properties to Native Layers
In short
Fastlane, a toolset for developers, streamlines tasks in application development through customizable lanes. For iOS, using string references instead of symbols in the update_plist action can enhance reliability, addressing potential issues with updating multiple values. In Android, defining custom properties in the gradle.properties file and ensuring correct syntax in the gradle action contributes to a smoother build process, emphasizing the importance of attention to detail in efficient application development with Fastlane.
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 <rte-code>update_plist<rte-code> action offers a convenient way to modify the values of keys in plist files. As per the official Fastlane documentation, the syntax for the <rte-code>update_plist<rte-code> 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 <rte-code>gradle<rte-code> 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 <rte-code>gradle.properties<rte-code> 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 <rte-code>build.gradle<rte-code> file. Here's how you can access these properties:
In this block, the <rte-code>CLIENT_ID<rte-code> and <rte-code>GOOGLE_APP_ID<rte-code> 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 <rte-code>update_plist<rte-code> action can save valuable debugging time. On the Android side, specifying properties in the <rte-code>gradle.properties<rte-code> 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.