Stay up to date with the latest iOS CI/CD news

Sponsored

Put your mobile releases on autopilot.

No more cat-herding, spreadsheets, or steady drip of manual busywork. Runway helps your team level up your release coordination and automation, from kickoff to release to rollout.

Hey everyone! 👋 Welcome to the nineteenth issue of the iOS CI Newsletter. Hope you’ve had a great couple of weeks!

This week I want to start the issue by talking about a topic I am passionate about and that I have been advocating for over the past few years: writing developer tools with Swift.

If you have a project that is used, built and maintained by Swift developers, it makes a lot of sense to write any accompanying tooling using Swift too. Doing so can have several benefits such as:

1. Making the tooling easier to maintain over time as it is written in a language you and your team are familiar with.

2. If your project is Open Source, it will make it easier to find contributors that can help maintain the tooling as it is written in the same language as the project itself.

3. Explaining how the tooling works to new members of the team is a lot easier as they are familiar with the language it is written in.

Furthermore, the introduction of Swift Packages and Open Source projects such as Apple’s Argument Parser, as well as the rapid growth of Swift on the server, has made full-stack systems and tools to accompany your apps so much easier!

There are some big companies out there that already take advantage of writing their tools with Swift. For example, my team at the BBC has a couple of scripts and command line tools that we use daily that are written entirely with Swift. Also, from speaking with Alberto de Bortoli, the Principal Software Engineer at Just Eat Takeaway, it looks like they write most of their tooling with Swift too!

🧰 Understanding mergeable libraries

A couple of weeks ago I wrote about a brand new feature announced in WWDC23: mergeable libraries.

In the article, I show you how mergeable libraries work and how a couple of simple build settings changes can dramatically improve the dependency graph of a modular codebase 👀.

📦 This GitHub Action helps you keep SPM dependencies up to date!

This week I came across this great GitHub Action by Marco Eidinger which processes your Swift Package’s manifest to detect out-of-date dependencies.

The action is highly configurable and you can make it fail the workflow run if outdated dependencies are detected or even automatically update such dependencies for you.

🤩 Ready to use build utilities for your Swift scripts

I recently learnt about a pretty cool open-source project called SwiftLane. SwiftLane, created and maintained by Khoa, is a collection of ready-to-use build utilities written entirely in Swift.

You can import SwiftLane as a Swift Package and use it directly in your Swift scripts and CLIs to perform common actions such as building or archiving an Xcode project, communicating with App Store Connect or sending Slack messages.

🔨 Modifying Xcode project files programmatically

In this article, Alexey Alter-Pesotskiy shows you how to manage and modify .xcodeproj files programmatically using a ruby gem called xcodeproj. This can come in very handy to apply patches and update build settings from scripts and tools.

As Alexey also points out in the article, if you write your scripts and command-line tools in Swift you must know that Tuist, a popular tool created by Pedro Piñera to automate and manage Xcode projects, have created a Swift version of Xcodeproj 🎉.

📱 An insight into ETTrace’s Cocoapods to SPM migration

Emerge Tools have recently made their project ETTrace, which provides a simple and reliable way of profiling iOS applications from the command line, available through SPM.

In this article, they explain the process of migrating from a CocoaPods-based project to an SPM one and share some of the challenges they have faced along the way. They also include a section on how they leverage the power of CI/CD to automate their signing and distribution process ❤️!