iOS

If you have your CI machine set up to run multiple jobs in parallel you might have encountered a problem. You cannot run multiple iOS UI tests in the same simulator at the same time. They will fail.

The problem

Imagine this scenario. You have one CI machine that allows two or more jobs to run in parallel. You have a UI tests job set up. Two of your developers push changes to their branches at (almost) the same time. The CI machine then tries to run two UI tests at the same time in the same simulator and at least one of them fails and has to be retried.

You can of course solve this problem by not allowing parallel jobs on the CI machine, but that slows down the CI process. There is a better way.

The solution

You can create a brand new iOS simulator instance for every job, run the UI tests in this new simulator instance and then delete it when you are done. This way no matter how many iOS UI tests jobs you run in parallel they will all use a separate iOS simulator instance and not affect each other.

Creating a new iOS simulator instance

The first step is to choose a unique simulator name for each job. You can generate some random guid for example. In Gitlab CI I just use the ID of the Gitlab CI job that is stored in the ${CI_PIPELINE_ID} environment variable

First you need to create the new iOS simulator instance at the start of the CI job

xcrun simctl create ${CI_PIPELINE_ID} com.apple.CoreSimulator.SimDeviceType.iPhone-11 `xcrun simctl list runtimes | grep iOS | awk '{print $NF}'`

This command creates a new iOS simulator instance with the given name using the iPhone 11 device and the latest simulator runtime. Using the latest simulator runtime makes sure that when you update Xcode on the CI machine you do not have to do any changes to you CI scripts.

Using the new iOS simulator instance

Now that you have a new iOS simulator instance created you can use it to run your iOS UI tests. You can simply pass the name to the xcodebuild command if you use it directly or use it instead of the device type when using Fastlane

How many times how you copied and pasted some code in your current codebase because there was no good way to abstract it? Maybe because it was some repeating code required by a framework or mapping of some data transfer structures.

Writing such boilerplate code is an error-prone waste of time, especially when there is a much better way: generating that code.

There are a few tools to help you do that, one of the most flexible of them being GYB.

What is GYB?

GYB is a lightweight templating system that allows you to use Python to generate text files. Those text files can be Swift source code files or anything else you need.

GYB is used in the Swift standard library codebase so it works well for generating Swift source code and it is a proven technology that works.

You can download GYB to your project from the Swift repository on Github

wget https://github.com/apple/swift/raw/master/utils/gyb
wget https://github.com/apple/swift/raw/master/utils/gyb.py
chmod +x gyb

I put it directly to the project directory and include it in the source control for simpler build and CI/CD setup.

Creating GYB templates

GYB templates for generating Swift source file look like Swift source files with some Python snippets for code generation.

This is probably best shown on an actual example. Let’s say you have a list of permissions that the app needs to support. Those permissions are then a part of a protocol and of a few structs.

Have you ever wondered how much time a day you spend waiting for Xcode to do your builds?

Working on a project that is almost entirely written in Swift I wonder that every day with a feeling that it is a non-trivial amount of time just wasted.

With Xcode build times you can actually measure it and know for sure.

Xcode build times

Xcode build times is a script that tracks all your daily builds and their duration.

You just set it up in Xcode to be called on build start, success and fail as stated in the project README.

It script is intended to be used as a plugin for BitBar. BitBar is a open source tool that allows you to show any script output in the macOS menu bar.

Just install BitBar and set the plugins directory to the directory with the Xcode build times script, as stated in the project README.

In the iOS application I currently work on the users can choose a video from the device’s gallery and that video gets uploaded to the backend.

This functionality has always worked fine but recently somebody tried to upload s slow motion video and the application was not able to handle it.

Turns out slow motion videos need a special case, they work a bit differently than normal videos.

When you pick a video from the device’s gallery you get a PHAsset of type .video. You can use PHImageManager to load it as AVAsset.

The application just tried to cast it to AVURLAsset and processed it as a video file stored at some url that can be converted to Data and uploaded to the backend.

A slow motion video is an AVAsset, just not an AVURLAsset but an AVComposition and it needs to be treated differently.

The best way to make it work for my upload to backend scenario was to export it to a standard video file

guard let exportSession = AVAssetExportSession(asset: asset, presetName: AVAssetExportPresetMediumQuality) else {
    Log.error?.message("Could not create AVAssetExportSession")
    return
}

let targetURL = dataPathProvider.uploadsDirectory.appendingPathComponent("\(UUID().uuidString).mp4")

exportSession.outputURL = targetURL
exportSession.outputFileType = AVFileType.mp4
exportSession.shouldOptimizeForNetworkUse = true

exportSession.exportAsynchronously {
    let exportedAsset = AVURLAsset(url: targetURL)
    self.processVideoAsset(asset: exportedAsset)
}

After the slow motion video gets exported it can be converted to an AVURLAsset and treated the same way as a normal video file.

In the last few months I have been working more intensively with MapKit, doing more advanced operations like clustering map annotations or animating annotation position changes.

I have encountered a few problem resulting in MKMapView quite unexpectedly crashing the whole application that I had to fix, or maybe better to say, work around.

MKMapView crashing the view controller on dismiss

During the application testing I noticed a very strange bug. Sometimes when I dismissed the view controller with MKMapView the application just crashed.

Debugging I noticed that it happened when the annotations on the map were updated just a short while before dismissing the view controller and the crash log pointed to mapView(_:viewFor:).

I guessed that MKMapView was processing annotation changes when the view controller was already deallocated. The MKMapView was still alive, tried to call its delegate, which was that deallocated view controller, and crashed.

The fix for this problem was setting the MKMapView’s delegate to nil in the view controller’s deinit method.

deinit {
    mapView.delegate = nil
}

Crashing when animating annotation position changes

The second crash I encountered was a bit more tricky. The application started crashing when I implemented animating the annotation position changes.

The way this works is you have a collection of your annotation objects, each has a coordinate property that needs to be @objc dynamic because MKMapView uses KVO to observe it. When you update this property the annotation changes its position on the map.

If you want to animate the position change on the map, you need to wrap the coordinate property assignment into UIView.animate. Doing this the application started crashing when the user moved the map, or zoomed it, or sometimes just after a while with the user not doing anything a all

The exception said

Collection was mutated while being enumerated.

but the annotation collection was not really mutated as a whole, some annotation in that collection was mutated by updating its coordinate property.

Theory about the crash

The circumstances of the crash led me to believe that there was some timing issue, my code updating the annotation at the same the MKMapView processes it in some way.

Which would make sense, when the user moves the map or zooms it there might be some processing needed to bring annotations into view or hide them.

The interesting thing was this only happened when using annotation clustering. It never happened with “plain” annotations.

With this observation it looked like MKMapView trying to recompute the clusters causing the crash.