We've been idly following fastlane since it was just deliver, and it has had a lively lifespan indeed from obscurity to Twitter to Google and all; so it's reasonably sure it's approaching industry standard status at this point, which would make a canonical introduction to it handy indeed. And, why, look what we have to review today, a shiny new copy of Continuous Delivery for Mobile with fastlane.

"Competitive mobile apps depend strongly on the development team's ability to deliver successful releases, consistently and often. Although continuous integration took a more mainstream priority among the development industry, companies are starting to realize the importance of continuity beyond integration and testing...

Orchestrate automated build and deployments of new versions of your app

Regulate your TestFlight users and on-board new testers"

It's actually not 100% accurate, that title; a more accurate one would be "The Complete Beginner's Guide to How to Ship an iOS App With fastlane Making It Suck Less." That wasn't quite as buzzword-compliant, we suppose.

If you do happen to be an iOS-focused complete beginner at dealing with iTunes Connect and all, and you intend to follow the common path of Crashlytics and/or TestFlight for beta distribution ... then yes, we believe we can recommend this unqualifiedly as the most coherent introduction out there, go buy it and you can stop reading now!

If you've already got this distribution thing sussed, and you're just curious about whether this fastlane thing that all the cool kids are into these days is worth adopting ... hmmm, we'll give it a three out of five. It's worthy of explaining what it does explain, but to make it five-star for the more accomplished developer, we'd need two star-worthy things:

1. Documentation on the Android setup and shipping process as thorough as there is for iOS. There's about six pages worth here, which is pretty thin compared to the iOS coverage.

If you couldn't care less about shipping for Android, of course, then this is not a valid criticism.

2. More thorough examples of how to integrate with CI and testing services other than the selected ones, to actually deserve the Continuous Delivery label. As a specific omission we were looking for, the book promises

"The next step in this beta lane is to distribute our app via two popular testing platforms: TestFlight and HockeyApp."

... and then goes on to not deliver on this promise for HockeyApp. Since that was, in fact, the main thing we were looking for in this book, how to set it up with a HockeyApp-centric workflow, we were disappointed. So we figure that we'll take another point off for not being an encyclopedic reference. Yes, we're brutal. Again, if you are a complete beginner and/or you do use the standard tools that the book does cover, this is not a valid criticism either.

Should you be teetering, here is the publisher's page and you can check out the TOC and all; plus the code repo for the examples - adding fastlane to Firefox - is here on GitHub.

But definitely, if you know anyone who's just getting into iOS development, we'd rate this the best introduction there is out there without question!

We had GitLab and we couldn't find any reason for using something else. So, we decided to use it, why not? As for me, the GitLab-CI/CD is more developer-oriented than Jenkins. At least because it is aimed at the pipelines, tags, and branches, unlike Jenkins with jobs. And we have to use those things to get the necessary job instead of configuration without code. GitLab-CI/CD seems like a tool for running scripts on a remote machine; no more, but enough.

Some time later, we realized what it doesn't matter what to use if we use Fastlane. Because it was able to do all what we needed. As the result, we got freedom from other tools. So I can strongly recommend using Fastlane instead of manual scripts or other approaches..."

And, of course, we do find several mentions of "Hockey" over at fastlane/examples: "A collection of example fastlane setups," so it's not as if their omission is a crippling lack in any way. We just figure a book like this should aim for canonical completeness!