“CI cope poorly with mobile development requirements”: interview with fastlane creator Felix Krause

Many mobile developers love the fastlane tool , which automates tasks when releasing the application (generating screenshots, code signing in the case of iOS, deploying to the store or beta testing system). For a long time fastlane could only be used on macOS, but now this project is being made partially cross-platform. And its creator Felix Krause the other day loudly announced a new project: the fastlane.ci CI system .

And we interviewed Felix, asking about both topics: we started with questions about the CI novelty, and then moved on to the “usual” fastlane.

- In connection with the advent of fastlane.cisomeone might say, "There is already a bunch of CI systems, why one more." How do you see the main goals of fastlane.ci not yet covered by other products?

- Fastlane.ci puts mobile developers at the forefront. Many CI-systems are very generalized, but in the end they do not cope very well with the requirements of mobile development. A good example is when teams use different versions of Xcode when migrating to a new version of Swift.

Therefore, fastlane.ci is an “opinionated” project that makes life easier for mobile developers. The idea is for the CI system to automatically recognize your project, for the most part set up for itself, and be ready in a few minutes.

- It is clear that fastlane and fastlane.ci will work perfectly together, but how closely are they related? Will support of other CIs in fastlane become less priority now? Is fastlane.ci supposed to be used without fastlane?

- The last question has not yet been finalized, but so far my vision is to run fastlane.ci only for working with fastlane. It is likely that over time this restriction will weaken, but when working on the first version, it will allow us to focus on the most important thing.

But work on fastlane.ci, of course, will not affect the integration of fastlane with other CI services. Everyone has the right to use any CI system they want :)

- Now fastlane.ci supports exclusively mobile development, but a “so far” reservation has been made. In the future, do you want the mobile to remain the main one, but not only it is supported?

- Here, as in the previous answer: first we need to focus on the most important thing, and then we can gradually expand the range of activities.

- As far as we understand, fastlane.ci can be run on different OSs ...

- No, fastlane.ci is not cross-platform, it is for macOS.

- Wait, the system requirements say “Requires Ruby 2.3.0 or higher. macOS and Xcode are required when building iOS projects. " That is, it will be more accurate "Requires Ruby 2.3.0 or higher and macOS"?

- Yeah, I’ll update README to clarify this issue. So far, everything is designed only for macOS.

- Fastlane.ci plans to support both iOS and Android. Do you assume that in the Android world the demand for CI will just increase due to the termination of Android support in BuddyBuild?

- I think the use of BuddyBuild will decrease in both Android and iOS, because now it is hardly worth waiting for active development from it in the coming months / years.

- Let's move from fastlane.ci to fastlane. First, let's clarify the situation for those who are far from the topic. Fastlane has a tricky story: first an independent project, then fell under the wing of Twitter, becoming part of Fabric, then, along with Fabric, switched to Google. This may raise questions such as “Do I need to use Fabric to use fastlane”. How are things really?

- At the moment, fastlane is an independent project on Google. You do not need to use either Fabric, Firebase, or Google services to use fastlane. The project is open source , supported by us together with the community.

- The latest news about the project is the announcement "We are actively working on Linux and Windows support for individual parts of fastlane" ...

- Well, I personally do not do this actively. However, in the team of contributors there was a person who took up the support of other platforms. And in recent months, work has really been going on so that more and more fastlane components cease to require macOS.

- Does the unwillingness of regression in this work limit the higher priority main version?

- Yes, this is the risk of expanding the number of supported platforms: you are always afraid to break something on another platform.

- Since iOS developers are sitting at the Mac, the demand for cross-platform fastlane arose solely because of Android, or is it also on the iOS side?

- I have not seen high demand in iOS, with the exception of cross-platform developers like React Native.

- When Android developers, when installing fastlane, see “Make sure you have the latest version of the Xcode command line tools” as the first item, does it cause them cognitive dissonance? :)

- Well, Android developers on Mac to install fastlane inevitably need Xcode command line tools to install Ruby and OpenSSL.

- And does it complicate the work on a project that supports Android, the fact that you have the background in iOS?

“Yes, definitely.” I have been doing iOS applications for 7 years, so I know a lot about the platform and ecosystem. So I personally don’t really deal with the Android part, we have a group of contributors focused on this.



- The main page of fastlane.tools greets us with the counter "how many hours fastlane developers saved." What do you think of this watch? :)

- When fastlane checks for updates, it at the same time sends us very basic metadata: mainly the time spent in a running state, the Xcode version and the OS version.

“But after all,“ fastlane run time ”may not at all equal“ time that a developer would spend on the same tasks without fastlane. ” Is this counter designed as a very rough approximation?

- Yes, that's right. In fact, probably fastlane saved developers a lot more. For example, in the case of generating localized screenshots manually, it can take much longer.

- An entire ecosystem of plugins has grown around fastlane. Do you have a personal favorite among them?

- I personally previously used the “badge”, which allows you to easily add the version number to the “beta” icon on the icon right before compilation.

- Does it happen that something starts as a plug-in, but ends up in the main fastlane?

- Yes, this happened with several plugins - the main such case was the disable_code_signing and enable_code_signing plugins. In Xcode 8, Apple added a new option for code signing, and people wanted to control it with fastlane. Helmut (plugin author) kindly agreed to integrate the plugin into fastlane when we contacted him.

- Have you seen any functionality that surprised you in the plugins?

- I liked the plugin that received the current review deadlines for iOS applications.

- It is surprising that such a popular tool was not created by a large company, but arose as your student project. Did he have competitors then? What helped them get around?

- When I started, there was no analogue. The only similar tool was Shenzhen from Nomad Tools, but its development was then discontinued. But it’s even easier to start such a project alone, there are no dependencies.

- When the project hit Twitter, it allowed you to work on it fulltime. But would you like instead to somehow monetize it in order to get the same opportunity, but at the same time maintaining complete independence?

- I do not see a big advantage in complete independence if the company that allows you to work on the project acts in its best interests. In the case of fastlane, both Twitter and Google allowed the project to develop in the direction that was most meaningful for the community of mobile developers, we listened to the desires of users and worked on them. Actually, before Twitter, I even offered fastlane sponsorship and contract work related to fastlane, but it was difficult - it was very stressful and distracting. I definitely prefer the current state of things to what I did before Twitter.

- In your case, the work itself grew out of a student project. And if this did not happen, what would they do? Are you concerned about privacy and security - would you head this way?

- Probably, I would work on iOS-applications - and, perhaps, this would be due to privacy, yes.



- Your site has a whole section on privacy issues that are right under your nose, but go unnoticed - do you think this is a problem for the industry as a whole?

- I think that the iOS community is especially lacking awareness of security and privacy issues. I understand that this is not the most fascinating topic for most people, and it can slow down the development of the project. But it is necessary.

Minute of advertising. In April, Felix will speak at our Mobius conference in St. Petersburg with the report “Trusting iOS SDKs”, where he will address the topic of security. And if after this interview you still have questions to Felix, it will be convenient for Mobius to ask them personally: each speaker after his report will go to the discussion area, where he can be properly questioned.