As an ancient Java developer, I’ve learned to use a set of annotations to bring meta programming in my projects.

Meta programming can be considered as an orthogonal thing to your code, you can inject code to log things, to wrap execution in a transaction or simply provide some context to your fellow developer.

One of my favorite context providing annotation at this time was brought by Google-Annotations package : @VisibleForTesting

Its goal is rather simple: provide the context that the visibility of the variable / method is not as restricted as it should be, but this is for the sake of testing.

When going back to my loved XCode (just kidding), I miss these kind of useful information.

Of course you can add a comment, that maybe someone will read if he begins to wonder why the visibility is too important.

// this method should be private but we want to access it from unit test code  
func doStuff() { }

You can also play with the deprecation annotation to trigger a warning (one more to add and parse with your eyes…)

@available(*, deprecated, message: "This is visible for testing")  
var myState: State

But one thing I was really missing is the ability to really set the proper visibility on my fields while keeping the testability.

Recently, Swift 5.9 had added Macro support. Macros can be seen as ways to generate code based on specific instructions (this brings back old Java-apt memories).

Macro types

There are multiples macro types, whether they can attach to fields, and depending on what they can do:

• Providing accessors
• Generating code alongside the annotated field
• Generating code “in-place”

There are two ways of calling macros :

• Attached ones with @MacroName
• Freeform ones with #MacroName

I will not enter the details of each type and implementation, you will see more on this later here and can scout on GitHub repositories for inspiration.

Attached macros are written with a leading @ and can generate code alongside some of our declaration. This allowed me to introduce my own @VisibleForTesting for swift implementation.

The idea behind this is really simple, generate specific code with public visibility that wraps call to the “non-exposed” real method.

This way we get the best of both worlds, we keep our fields private, we tell our colleagues that this field is available for testing and we are able to test it properly.

What does it look like ?

To use this library, you need to add an SPM dependency on this repository: https://github.com/CedricGatay/SwiftMacroUtils

.package(url: "https://github.com/CedricGatay/SwiftMacroUtils", branch: "main")

Then, let’s say you want to give access for testing to the name var of the Dog struct to your testing code, you simply need to do the following

struct Dog {
    @VisibleForTesting
    private var name: String?
}

Under the hood, the macro will generate a public accessor that you will be able to use in your tests

public var __test_name: String? {
    get {
        self.name
    }
    set {
        self.name = newValue
    }
}

The same goes for let, func, and init . The only specific thing to keep in mind that if you annotate a class initializer, you need to mark it as required, otherwise the build will fail (but a nice comment will tell you why).

Dark mode support

As you might know, iOS supports Dark mode since iOS 12. It is pretty straightforward to implement it by using dynamic colors. Either system provided ones or adjust them using trait collections.

Dynamically switch

At times, we can not rely on default colors but we have to listen for traitCollection changes in order to do what is appropriate for adapting the UI to the mode being active.

It is easy to do by checking current traitCollection :

override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
    super.traitCollectionDidChange(previousTraitCollection)

    let userInterfaceStyle = traitCollection.userInterfaceStyle 
    // Either .unspecified, .light, or .dark
}
 

App switcher tricks

One thing that I was not aware is that iOS switches back and forth between active mode and the complementary when the app goes to the background :

To have proper representation in application switcher, if the trait collection is changed, the OS takes a screenshot of your app using light and dark schemes.

Consequences

This can lead to subtle problems, in my case, I was loading a specific stylesheet for MapBox, that, when loaded, was registering / refreshing elements on map. Thus, when the app was put to the background, a lot of things were happening, without a clear explanation (and the app was sometimes crashing due to the very fast switching between map stylesheets).

The workaround is rather simple : if the app is in the background we prevent loading the stylesheet, the trade-off is acceptable : the app can display an invalid preview in application switcher, but, it is nicer on CPU / Network.

Git daily usage

If you’re like most developers nowadays you make an extensive usage of git across a large number of repositories.

The now-classic branching model that consists in using a branch for every fix / feature / experiment before creating a merge request is perfect for collaborating efficiently. However it comes with one downside, local branches can quickly become messy and removing stale branches is not that easy

Removing remote branches

git is a really well designed tool and removing remote references from your local repository is easily done by

git remote prune origin

This will remove local references to non existing branches, however it is not useful to remember this command, we can configure git so that it prunes automatically on fetching :

git config --global fetch.prune true

Removing local branches

This is where things can be quite messy, as local branches might have been merged, rebased, or squashed, and “classic” commands allowing to detected merged branches are not always working as they ought.

If you search how to clean up local branches, you might find a lot of commands involving git branch --merged with grep and xargs all the way.

I found out a little neat tool to do so, called git-gone (github/lunaryorn/git-gone), written in Rust 🧡

Install it

As all rust project, it is packaged and easy to install using cargo

cargo install git-gone

List branches to prune

Before doing anything silly, we can list the branches that are candidate to removal (the -f flag forces fetching remote)

$ git gone -f list
feature/asciidoc
fix/imageCompress

Prune’em all

And finally, you can remove them (the -f flag is still here to sync with remote)

$ git gone -f prune
Deleted feature/asciidoc (restore with `git checkout -b feature/asciidoc 8f007a`)
Deleted fix/imageCompress (restore with `git checkout -b fix/imageCompress af523b`)

git-gone is even clever enough to give you the command to restore a branch if change your mind (as long as you did not git gc the revision is still available locally, so you can restore it)

Welcome to the mac world

Wether you’re new to macOS or an user coming from different machines, the tools we tend to use is very important to be productive.

Here you’ll find my list and what I install on a fresh machine to get started.

System tools

First and foremost, I start with brew to handle all my packages, but instead of doing so manually, I use my dotfiles and my “magic” install script that does all the heavy lifting for me.

Keyboard tools

I use a TypeMatrix with a Colemak layout and also the internal keyboard of my laptop with its default layout. Colemak layout is available on a fresh macOS install but it is far from perfect as there are a lot of missing dead keys (to type accented letters mainly), so I start by installing the layout provided on this page: Colemak mac

To easily switch between the two and get almost the same feeling, I use Karabiner Elements.

Everyday tools

• sdkman: to manage installation of various sdk (mainly Java based)
• iTerm: nice terminal app with profiles
• tmux: multi terminal in one window, switching terminal with a keystroke
• zsh: Z-Shell
• starship: fast shell prompt
• ripgrep: faster grep
• bat: nice cat alternative (with paging / highlighting)
• exa: replacement for ls
• Alfred: Spotlight with more features, this is my main app launcher / switcher
• SetApp: App subscription service, use many tools from this (BetterTouchTool, iStat, BarTender…)

Now that iOS13 is available for more than year, we can start to set it as a lower bound for our deployments.

This allows us to play with all sugar that Apple put in it, one of the biggest thing is the arrival of SwiftUI to supercede UIKit (write cross platform UIs and so on).

Bridging the two worlds

Using SwiftUI from UIKit

The first thing we might try to do, is embedding a SwiftUI View inside our UIViewController based application. To do so, Apple gives us UIHostingViewController which is a simple bridging controller, straightforward to use.

struct MyNewView: View {
    var view: some View {
        Text("I'm in SwiftUI")
    }
}
class MyNewViewViewController: UIHostingViewController {
    init(){
        super.init(rootView: MyNewView())
    }
}

UIViewController in SwiftUI

However, at times we still need to reuse our good old UIViewController, either because we can not afford a full SwiftUI rewrite, so we want to keep old code and migrate pieces by pieces or because we are using something not yet adapted to SwiftUI.

In my case it was using the camera to scan a QRCode.

Non elegant solution

I faced a few issue with examples I found out, most of them are adding an extension to the UIViewController that makes it conform to UIViewControllerRepresentable.

class MyViewController: UIViewController{
    var cancellable: Cancellable?
    // classic stuff
}

extension MyViewController: UIViewControllerRepresentable {
    public typealias UIViewControllerType = MyViewController

    public func makeUIViewController(context _: UIViewControllerRepresentableContext<MyViewController>) -> UIViewControllerType {
        self // don't .init() please, class instance is already available
    }

    public func updateUIViewController(_: UIViewControllerType, context _: UIViewControllerRepresentableContext<MyViewController>) {}

    static func dismantleUIViewController(_ uiViewController: UIViewControllerType, coordinator _: Coordinator) {
        uiViewController.cancellable?.cancel()
    }
}

struct MyView: View {
  var body: some View {
    MyViewController()
  }
}

I find this not easy to read, as we’re doing weird thing by returning self from a function named makeUIViewController. Some example are telling to return MyViewController() instead of self. Please don’t do this otherwise you’re creating the UIViewController twice for each call !

I also had a leak when using Combine (more to come about this great framework), my Cancellables were never freed, leading in a memory cycle that kept the UIViewController living even though it was no longer presented.

It is important to do proper house keeping in the dismantleUIViewController method if you don’t want to use too much memory and slow down your app.

Nice looking way of doing

You will find a working example below, basically we need to implement a UIViewControllerRepresentable struct to represent be the container for our UIViewController in the SwiftUI world.

class MyViewController: UIViewController{
    var cancellable: Cancellable?
    // classic stuff
}

struct MyGreatView: UIViewControllerRepresentable {
    public typealias UIViewControllerType = MyViewController

    public func makeUIViewController(context _: UIViewControllerRepresentableContext<MyGreatView>) -> UIViewControllerType {
        MyViewController()
    }

    public func updateUIViewController(_: UIViewControllerType, context _: UIViewControllerRepresentableContext<MyGreatView>) {}

    static func dismantleUIViewController(_ uiViewController: UIViewControllerType, coordinator _: Coordinator) {
        uiViewController.cancellable?.cancel()
    }
}

struct MyView: View {
  var body: some View {
    MyGreatView()
  }
}