Github Actions CI for Swift Projects

Artem Novichkov
Aug 29, 2019 · 4 min read
Image for post
Image for post

Github introduced CI and CD based on actions. It allows you to automate how you analyse, build, test and deploy your projects on any platform, including Linux, macOS and Windows.

I was excited over this news and can’t wait to try it out. My idea was to automate building and unit testing of Swift projects.

There are two types of actions and we should know the difference before starting.

Docker container vs JS

Originally all actions were based on Docker and used HCL syntax for workflows. Actions based on Docker run only in Linux virtual environment. With CI/CD announcement Github released JavaScript based actions and new YAML syntax for workflows.

For iOS projects you can use only JS actions because they should be run on macOS. Moreover using a JavaScript action simplifies the action code and executes faster than a Docker container action.

Lights! Camera! Github Action!

As an example I will use Texstyle. It’s a framework for formatting attributed strings. Let’s start with a complete configuration and inspect it step by step:

Github Actions configuration for Texstyle

At first you should select an event to trigger the workflow. My workflow is triggered on any pull request in the repository. Optionally you can label the workflow with name.

Workflows must contain at least one job. My workflow contains only one job for testing. It is possible to run up to 20 jobs concurrently per repository across all workflows.

Jobs run on virtual host machines that are specified with runs-on. In my case it’s macOS-latest, because I want to use xcodebuild. It’s a standard Apple developer tool and works on macOS only.

Texstyle supports both iOS and tvOS, so I want to run xcodebuild with two destinations. To specify different variations, I used strategy.matrix. I added two simulators with actual OS versions.

And the last step is to adding steps 🙃. I used checkout action to access the contents of the repository. You can specify the version of actions after @ sign with a release version, branch or specific commit.

Everything is ready for testing. I added run with bash commands to change current directory, run xcodebuild and send code coverage data to Codecov. To use matrix variables, I added env with the required variable name.

To read more about workflow syntax, check the documentation.

Comparing to Travis CI, my configuration looked like:

Travis CI configuration from Texstyle

That’s it! Here is an example of live logs:

But that’s not the end, it’s just the beginning! Suppose that we want to reject pull requests if there are any linting warnings or errors. The most popular lint tool for Swift is Swiftlint. For now it’s possible to run it and see warnings in logs that is not enough. It would be great to see annotations from SwiftLint Violations via GitHub Checks API, or even have suggested changes. And actions allow to use this API easily.


As for me Github Actions CI is a game changer. It is deeply integrated into the service. And community-driven actions allow to reuse common scenarios.

Let’s summarise my experience with pros and cons.


  • Various triggers for workflows. Pull requests, staring repos, project card statuses, scheduled events etc.
  • Speed. According to logs for Texstyle, last builds were 2 min 12 sec on Travis CI and 1 min 8 sec on Github CI.
  • Preinstalled software. macOS images have fastlane, swiftlint, Cocoapods, Carthage etc.
  • Marketplace. There are plenty of actions developed by community. You can reuse any of them.
  • Pricing. Of course, it’s free for open source. The time limits look pretty good — 2000 minutes for free plan and 3000 minutes with a Pro plan including private repositories 😏.


  • Still in beta. First actions were written in HCL syntax. Support for it will be removed on September 30. And maybe it’s not the end, YAML syntax may be updated as well. So be ready to migrate your actions before public release.
  • Debugging. It’s hard to debug workflows as any CI service. You must trigger related event and wait for all steps. It’s not possible to test it locally, even validate workflow syntax.
  • Documentation. On of the goals of this article is to clarify Actions benefit for myself and give it a try on real project. I had many unobvious errors, official documentation and StackOverflow won’t help. For instance, a multiline run command won’t work without aname label. I believe open source workflows will help to avoid dump errors and handle edge cases in the future.

Thanks for reading! If you have any questions or ideas of workflows, feel free to leave comments or ping me on Twitter @iosartem.


Automating your workflow with GitHub Actions

Github Actions

Awesome Actions


Mobile app design and development insights

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store