turing complete with a stack of 0xdeadbeef
One of the most important parts of software development is tracking changes. Documenting what is going into a release is necessary not only to simply know what changed and inform your users by writing good release notes, but also to track down issues when something goes wrong. If there’s a new bug or a new crash in your latest release, you need to be able to quickly find the change that introduced the problem.
If you are using fastlane to automate your release process, you might be using the increment_version_number and increment_build_number actions to bump your version and build numbers, respectively. However, if your Xcode project is configured to use xcconfig files, then you are out of luck. Shockingly, fastlane does not seem to support projects that use xcconfig files and there is a surprising dearth of information online about how to make fastlane work with Xcode build configuration files.
A typical release process for Git workflows involves creating a release branch, performing various tests on that branch, and applying any necessary fixes or changes to that branch. Once stable and ready to release, you create a build from the release branch, create a git tag, and finally merge the release branch changes back into your main branch.
In last week’s issue of iOS Dev Weekly, Dave linked to this tweet from Mohammad Azam, which linked to this StackOverflow post on resetting your app between UI tests by completely deleting it. It’s a very clever idea! This post offers an improved version of the code and some thoughts on when to use this.
This post continues from my earlier post on label-based GitHub Actions workflows. A common and tedious task in a typical pull request workflow is updating your branch with changes from the default branch of your repo. In many scenarios, you may want to rebase your pull request on the main branch or merge the main branch into your pull request.
My current team has started using GitHub Actions to automate some tedious tasks for pull requests. In particular, we use labels on GitHub to categorize pull requests or highlight important metadata about them. Most of the time, a machine can figure out which labels are appropriate to add or remove. This is a great use case for GitHub Actions.
Xcode’s UI testing framework has had its ups and downs over the years. Most recently, it has been much more robust and reliable in my experience. However, tests still tend to flake sometimes. Here are some ways that I have been able to reduce flakiness in UI tests.
This is a quick follow-up to my previous post. The client project I’m working on is also using Bitrise for CI, which I must say is quite good. If you are looking for a hosted CI service I would highly recommend checking them out.
I have started using GitHub Actions for CI for my newer open source projects. I recently setup Danger for the first time on GitHub Actions and it was quite easy. Here is how to do it.
I recently discovered that unit tests and UI tests for a macOS Xcode project will fail with obscure error messages if the hardened runtime is enabled. It took me awhile to realize what the actual source of the problem was, because the error messages led me in the wrong direction. Hopefully this will save you some time.
I have started using GitHub Actions for CI on a new project as a replacement for my usual setup on Travis CI. It generally seems to be much faster and more reliable so far. It also has an equivalent feature set, as far as I can tell. But one issue that I have run into is selecting a specific Xcode version, which is a bit cumbersome and not fully documented.