Software development is full of trip-wires, broken processes, short-living projects and more which often times make a developer's life difficult. Most software being broken all of the time is a very common sentiment in the industry. Developer tooling is also very easily neglegted. Believe it or not, against all expectations, a short while ago I had a pleasant experience:

My iOS App PitBuddy is still on the AppStore, but I had last shipped an update more than two years ago. I don't actively develop it anymore; let's say it is in maintenance mode. However, in iOS 13 I believe, some change in the default iOS styling led to a placeholder text in one of the apps TextViews be difficult to read. Should be easy enough to fix, I thought. Thing is, I hadn't even checked out the repo on my current machine let alone built the Xcode project. The project is a mix of Objective-C, some Swift, Cocoapods for any app dependencies. Now that's where most would assume I would have run into a world of hurt. However, I didn't:

bundle install --path=vendor/bundle

just worked. After that

bundle exec pod install

just worked as well. That's where I started to feel like I'm in a dream. Opening the project via

xed PitbuddyApp.xcworkspace

and building it via Cmd+B ran into a couple of minor warnings, but it completed just fine and I was able to run it in the simulator. By that point there was only one thing left to do: run tests. PitBuddyApp has a number of unit tests which built and passed, so that box was checked. I also have a couple of "Acceptance Tests" in place, using the KIF ui testing framework. So those didnt 't pass. However, I simply bumped KIF to the lastest version, and alas, I was back in the green. All in all, from cloning the repo to a fully passing build and test suite it took me no more than 30 minutes. So what do we take away from this?

• Sometimes things just work
• Dependency pinning (both the Gems as well as the Cocoapods) is good
• The bump from Xcode 10 to 12 needed a bump of KIF

Thanks to everyone helping maintain bundler, cocoapoda, etc!

I have dabbled in iOS development, on and off, for many years now. Starting back when UIKit and Objective-C were still the only platform choices, continuing with exploring RubyMotion, slowly making the transition to Swift, playing with React Native and then seeing SwiftUI come to life ... it's been an interesting journey. For a variety of reasons, none of the opinionated options in building an app ever really caught my fancy. Sure, Apple leaves a lot of questions unanswered for architecting an iOS app, but generic patterns like MVVM or MVC can be applied to iOS development without selling your soul to any large third party framework. The smaller the app is, the easier it also is to kind of get away with not really following a specific pattern.

Let me take a second to advertise Planeton, the iOS game that I will talk about in this article. Planeton is a simple, turn-based strategy game you can play against your friends, or strangers, online. Each player starts out with a single planet and can send ships to conquer neutral or other players' planets.

Past fall I set out to explore SwiftUI, and there's no better way to explore a technology than to build something with it. So I chose to develop an iOS game based on the mechanics of one of my older memories of SUSE Linux: KDE Konquest. A new Xcode project was initialized and off I went. At this point I have to give a shout-out to John Sundell, whose website Swift by Sundell was an essential resource for finding quick and easy examples and explanations about SwiftUI features. As the app grew in size (user facing) and lines of code, I became more and more dissatisfied with the way things were shaping up. Clean, modular code and high test coverage are aspects of my work I value a lot. However, in growing the code base more and more, these aspects kind of fell by the wayside. Now granted, I fully accepted that and made a bit of an experiment out of the project to not care as much as I usually do. Still, deep down inside me I knew: if I ever wanted to release and maintain the game, I needed to find a sustainable way to add features and regression test the application. To make matters worse, the game is supposed to be played via Apple's Game-Center, which makes it notoriously annoying to play-test against yourself. I only own a single iOS device, so testing with my device and a simulator is the only choice I have. And believe me, Game-Center and the Xcode iOS simulators are not best friends!

Meet the Swift Composable Architecture

I had come across Pointfree a decent while ago and have been watching the videos Brandon and Stephen put out. They are excellent, you should subscribe! Amongst other topics, they introduced this iOS architecture they call The Composable Architecture. Now probably this immediately resonated with me because I am in a phase of preferring a functional, compositional style of programming by now, more so than wild mutations all over the place and OOP for the sake of it. Dabbling in React in the past probably also helped me in grasping the concept of unidirectional data-flow. In any case, after being annoyed by some horrible SwiftUI views I had produced, mixing state management, side effects, presentation logic and visual styling, I took the plunge and decided to adopt the composable architecture.

With 2020 coming to a close, the 2021 Monster Energy AMA Supercross season is right around the corner. The first round is scheduled to be held in Houston, Texas on January 16th. This gives us a couple of days to think about who will be coming out on top in both the 450, 250 East and 250 West classes. Actually, the 250 entry lists aren't public yet, so we can only try to predict the 250 field as a whole, not knowing who will line up on either the west or east rounds' gates. That sounds a bit too artificial, so let's focus on the 450 division.

Crystal, the programming language, does not yet provide a built in way of measuring the effectiveness of your test suite. So by running crystal spec you pretty much only have binary insight into the suite: it's passing or it's not. This lead me to build crytic in the first place. But while mutation coverage is a great tool to investigate the test suite, plain old code coverage is usually quicker to obtain and easier to glance at.

In this series of posts I want to explain and document the basic building blocks of building a mutation test framework in crystal-lang. For a bit more context on the working framework named crytic, make sure to check out the introductory post.