We learned how to add actions to our Fastfile and how they can help truly unlock the full power of fastlane. Today we'll check out a few more actions and look at why we might want to use them. Let's get started!
First up is clear_derived_data. This action does what it says on the tin. (We learned about the DerivedData directory and why clearing it can workaround issues in Xcode in Bite #208). Super handy!
Next, it's ensure_xcode_version. This is great when working on a team, (or for our own sanity) to make sure everyone is on the same, known version of Xcode. We can use it like this:
One action that can be quite versatile is update_info_plist. We can specify a .plist path, (perhaps our app's "main" Info.plist), and modify just about anything inside, here's an example for changing the name depending on how we're deploying:
Bitcode is awesome. It lets our users download much smaller versions of our apps, containing only the bits they need to run it on their devices.
Unfortunately, it creates a few challenges for using third-party crash-reporting services.
Not to worry, fastlane has our backs. Today we'll look at a new built-in fastlane action (Bite #140) that can automate all of this.
The issue is that Crashlytics (or any service analyzing our crash logs) needs our dSYMfiles to convert raw crash logs to ones that containing line numbers and function names and all the other useful information we'll need to actually fix the bug causing the crash.
We'll begin by making sure we have the latest version of fastlane. (A quick gem update fastlane will do the trick).
Then, we'll add a new lane:
lane:refresh_dsymsdodownload_dsyms# Download dSYM files from iTunes Connectupload_symbols_to_crashlytics# Upload them to Crashlyticsclean_build_artifacts# Delete the local dSYM filesend
Now we can just run fastlane refresh_dsyms at anytime and everything will be synced up to Crashlytics. Apple seems to recompile our apps at will, and whenever their systems need.
For these reasons, it's probably best to toss this command into a CI server or some other system that will run it once or twice a day.
It's another fastlane Friday! Today we're looking at frameit, an awesome fastlane tool that helps us take our screenshots to the next level. We can display our screenshots on devices, and even add some marketing text. Let's dive in.
We'll start by installing frameit:
gem install frameit
Next we'll need to perform some initial setup. We'll head into our project's directory and run frameit to kick things off:
frameit will guide us through downloading the high quality frame images from Apple's marketing site and moving them into place.
Now, we can run frameit anytime to find all screenshot files and create versions of them placed inside device frames. Neat!
Code Signing. The very mention of certificates or provisioningprofiles can send chills up an iOS engineer's spine.
We've all been there. Just finished up a great first pass at a new feature, or finally ready to submit to the App Store and BAM! We're stopped in our tracks by a confusing error related to code signing.
Today's fastlane Friday is a big one. Yesterday, a new fastlane tool launched. It's called match, and it fixes code signing. Yes, really. Let's do this. 🚀
Most iOS teams have separate code signing identities for each member. This means most iOS teams have tons of provisioning profiles, probably lots of duplicates, invalid ones, etc.
Adding new devices or renewing certificates can be a huge hassle, and only makes on boarding new team members slower.
With match, we can avoid these issues entirely. match allows us to share one single code signing identity across our development team.
We keep this single identity (and it's associated provision profiles) in one central location.
match automatically syncs our iOS keys and profiles using a simple git repository. It handles everything (i.e. creating certificates and profiles), while we retain complete control.
Let's setup match for a project. We'll start by creating a new Github repository to hold our certificates, profiles, etc.
We'll call it certificates and make absolutely sure it's set to be private!
Next, we'll go into our project's main directory and run:
We'll be asked for the URL of the repository we created earlier, then a Matchfile will be created to hold a few settings.
Next we'll run:
match will create a new certificate and provisioning profile, and store them in our Github repo. They'll all be encrypted using openssl! 🔐
In the future, when we get a new machine for example, we will only need to run that one command to pull down everything and install it all locally. Incredible. Setting up new machines or team members has never been easier (or faster 🚗💨)!
This is only a small taste of how helpful match can be! Check out the incredibly well done complete guide that covers everything from start to finish at codesigning.guide
It's another fastlane Friday! Last week in Bite #135, we covered how to install and setup fastlane and an initial Fastfile. Today we'll look at how we can take our fastlane skills to the next level and customize our Fastfile using actions. Let's get started.
We briefly mentioned fastlaneactions in Bite #135. Let's start by taking a closer look at them.
Actions are essentially build "steps". fastlane organizes these build steps into sets called lanes. Each action is responsible for a very specific part of the lane's larger task.
Let's add an action to a lane:
By simply adding the increment_build_numberaction, we'll never need to manually bump our build number again!
It's another fastlane Friday here on LBOC! We've covered a few of the individual fastlane tools so far, but today we'll look at fastlane itself. It gives us a single command that brings together all the various tools in the suite like gym, snapshot, deliver, etc into one streamlined workflow. Let's get started.
We can of course continue to use each of the fastlane tools individually, but using fastlane allows us to use just one tool that connects not only each of the tools in the suite, but also integrates with other third-party tools like CocoaPods and xctool.
fastlane provides a fantastic in-depth Getting Started guide, but to get things going quickly here's the basics:
We'll begin by installing fastlane, this will install all the fastlane tools, including all the ones we've covered here, wrapped into one simple tool.
gem install fastlane
Then, we'll simply run fastlane init in the root directory of our project.
fastlane's setup assistant will ask us a few questions about our app, then it will create all the configuration files for us, where we'll be able to customize each the tools default settings as well as define our “lanes”.
After completing the intial setup process, we can start to customize our new Fastfile (which was created for us automatically). fastlane is built around the concept of “lanes”. Here's one that deploys to the App Store:
We can run all of these tools now, each one after another by simply running fastlane appstore. Nice!
Notice commands like cocoapods and slack are here. These are some of the third-party actions mentioned earlier.
This is where fastlane's awesome community really shines. There's already 120+ actions ready to use for services like s3, slack and crashlytics, as well as commands for things such as bumping the build number, or even collecting input from the user. Neat!
It's another fastlane friday here on LBOC. Today we'll be looking at another awesome tool in the fastlane suite called scan. It provides an easy way to run the tests of our iOS or OS X app. Let's dive in.
Before we begin, let's look at why a tool like scan can be helpful.
Xcode ships with a great command line tool called xcodebuild that allows to do all sorts of interesting things to our projects from the command line. It can be a bit verbose to configure though, and its output isn't very readable at a glance.
There's other tools like xcpretty that can help improve this output, but they take a fair amount of configuration as well.
That's where scan comes in. It takes care of all of this (plus a lot more) in one simple command: scan.
This is all we need for basics usage. scan will auto-detect things like our workspace, but we can always configure things as well:
scan --scheme "app-store"
Like other fastlane tools, we can run scan init to generate a new Scanfile, where we can store all our configuration options:
📃 Displays nice output, stores original xcodebuild log in ~/Library/Logs/scan
📄 Can generate HTML, JSON or JUnit reports
📣 Can send well-formatted test results to Slack. Check out the slack_only_on_failure configuration option to only report failed tests.
scan also helps with resolving common Xcode oddities like duplicated simulators or simulators that stop responding. Finally, scan works great with tools continuous integration tools like Jenkins and services like Travis. Happy testing!
Today we're continuing our look at the Fastlane suite of tools with gym. It can help us build and package our app into an .ipa file ready for submission to Apple, or some other kind of distribution. Let's get started.
We'll start by installing gym:
gem install gym
Now we can build and export an ipa like this:
Alright, have a great weekend everyone! Just kidding, while gym is great about asking for answers to things we don't specify such as what Xcode Scheme to use when building. It also allows us to specify just about any option we can imagine when running it on the command line. For example, let's build our app using its Workspace and the app-storescheme:
Simple enough, we're telling gym to build using our desired Workspace and Scheme, and that we'd like to do a clean build.
gym has options for just about everything: bitcode, codesigning, provisioning, team id, and much more. It's extremely flexible but including all those command line options each time can be drag. Let's unlock more of the power of gym by creating what's called a Gymfile in our project's directory. This is just a plain text file, and looks like this:
scheme"Spaceships"sdk"iphoneos9.0"cleantrueoutput_directory"./build"# where to put the ipaoutput_name"Spaceships"# what to call the ipa
Now we can run gym again from the command line and we don't need to specify all those options each time, nice! More info about gym can be found at git.io/gym
It's another Fastlane Friday here on LBOC. Today we're looking at deliver, another awesome tool in the Fastlane suite. It can save us tons of time and effort when it comes to uploading our app'smetadata, screenshots and binary to iTunes Connect. Let's take it for a spin:
We'll start by installing deliver:
gem install deliver
Then we'll setup deliver for our project by cd'ing into its directory and running:
We'll be asked for our iTunes Connect login and then our app's App ID. What happens next it down-right magical .
deliver will download all our app's metadata (name, description, keywords, release notes, icons, etc.), by language, from iTunes Connect as text files. Then it will organize them into text files inside a new metadata directory. Now we can edit these anytime and run deliver to update iTunes Connect with the edited values. Nice!
In addition to our app'smetdata, deliver will also download all our app'sscreenshots (by language and device) and organize them into a new screenshots directory for us. Again, we can change/update them on disk then simply run deliver again and they'll be uploaded to iTunes Connect.
It gets better. Why don't we just do everything at once and update our app's metadata and screenshots, upload its binary and submit it for review all at once? With deliver, all it takes is:
Believe it or not, deliver can do even more. We can pass in tons of options for configuring things like automatic release vs. manual, price tiers, add pre-defined answers to all those compliance questions we're asked during submissions, and more. We can also create a Deliverfile to easily reuse our options every time.
Starting new projects can be incredibly fun. Performing all the tasks that aren't building our app can be incredibly not-so-fun. Today we'll continue our look at the Fastlane suite of tools (from Bite #110) by checking out Produce, a command-line tool for creating and managing apps on iTunes Connect andthe Developer Portal. Let's take a look.
Let's make a new app. Before we do though, we'll install produce:
gem install produce
Now, let's create our app, we'll run:
Then we'll be asked for 4 values. We'll enter each when prompted (We could also specify these as arguments to the produce command).
Your Apple ID Username: **hidden**
App Identifier (Bundle ID): com.magnus.littlebitesofcocoa
App Name: Little Bites of Cocoa
Initial version number (e.g. '1.0'): 1.0
Produce will work its magic and when it's done, our app will have been completely created and setup on both iTunes Connectand the Developer Portal. Very cool.
Produce can also help us easily enable (or disable) things like Associated Domains, iCloud, Passbook, etc. Let's enable CloudKit for our app:
produce enable_services --icloud cloudkit -a com.magnus.littlebitesofcocoa
Nice! So much quicker than clicking around the Developer Portal.
Last but not least, we'll be creating extensions for app that share data so let's create a new App Group and put our new app into it:
produce group -g group.littlebitesofcocoa -n "Little Bites of Cocoa"
produce associate_group -a com.magnus.littlebitesofcocoa group.littlebitesofcocoa