Let's talk about hot reloading in Swift

Introduction

The year is 2040 and our latest MacBook M30X processor can compile large Swift projects in a split second. Sounds amazing, right? But besides, compiling the codebase is only part of our iteration cycle. This includes:

• Restart it (or deploy it to a device)
• Navigate to your previous location in the app
• Regenerate the data you need.

That sounds fine if you only need to do it once. But what if you're like me and you iterate over your codebase 200 - 500 times on a particular day? It adds up.

There is a better way, accepted by other platforms, and implementable in the Swift/iOS ecosystem. I've been using it for over a decade.

Would you like to save up to 10 hours of work per week starting today?

Hot Reload

Hot reloading is about getting rid of compiling the entire application and avoiding the deploy/restart cycle as much as possible, while allowing you to edit the running application code and see the changes immediately.

This process improvement can save you hours of development time every day. I tracked my work for over a month and for me it saved 1-2 hours a day.

Frankly, if saving 10 hours of development time per week doesn’t convince you to give it a try, I don’t think anything will.

What are other platforms doing?

If you only use Apple platforms, you’ll be surprised how many platforms have adopted hot reloading for decades. Whether you’re writing Node or any other JS framework, there’s a setup that uses hot reloading. Go also offers hot reloading (this blog uses it)

Another example is Google's Flutter architecture, which was designed from the beginning for hot reload. If you talk to engineers working on Flutter, you'll find that their favorite thing about the Flutter developer experience is the ability to write their apps in real time. When I wrote a Scrabble game for The New York Times, I loved it.

Microsoft recently launched Visual Studio 2022 with hot reload for .NET and standard C++ applications, which is not surprising considering Microsoft has been killing it in terms of development tools and experience over the past decade.

What about the Apple ecosystem?

When it was introduced back in 2014, many people were in awe of Swift Playgrounds because they allowed us to quickly iterate and see the results of our code, but they didn’t work very well because they had issues with crashing, hanging, etc. They didn’t support the entire iPad environment.

Shortly after they were released, I started an open source project called Objective-C Playgrounds that ran faster and more reliably than the official Playgrounds. The idea was to design an architecture/workflow that leveraged the DyCI code injection tool that I had been using for a few years and that was already made by Paul.

It’s been eight years since Swift Playgrounds existed, and they’ve gotten better, but are they reliable? Are people using them to drive development?

In my experience: not really. Playgrounds tend not to be very reliable or applicable in larger projects.

SwiftUI came along and it’s an amazing technology (although still buggy), it introduced the idea of ​​Swift Previews which are very similar to Playgrounds, are they any good?

Similar story, it's great when it works, but in larger projects it works unreliably and tends to break more often than they work. They don't provide you with the ability to debug your code if you make any mistakes, so adoption is limited.

Do we need to wait for Apple?

If you’ve been following me for a while, you already know the answer: absolutely not. After all, I’ve made a career out of building problems that can’t be solved by normal Apple solutions: from language extensions like Sourcery, to Xcode improvements like Sourcery Pro, to LifetimeTracker and many other open source tools.

We can leverage the same approach I originally used in Playgrounds back in 2014. I’ve been using it for over a decade now and have used it in dozens of Swift projects with great success!

Many years ago, I switched from using DyCI[1] to InjectionForXcode, which works much better by leveraging LLVM interop instead of any swizzling. It's a completely free, open source tool that you can run in your menu bar, and it was created by a prolific engineer, John Holdsworth. You should check out his book Swift Secrets[2].

I realized that the Playgrounds approach might be too clunky, so today, I open-sourced a very focused tiny library called Inject that, when paired with InjectionForXcode, will make your Apple development much more efficient and enjoyable!

But don’t just take my word for it. Check out the feedback from Alexandra and Nate, who were already well-versed in this workflow before I introduced it to The Browser Company setup, which makes it even more impressive.

Inject

This small library is completely generic and you can use it whether you use UIKit​, AppKit​, or SwiftUI.

You don't need to add conditionals or remove the Inject code for production applications. It becomes a no-op inline code that will be stripped by the compilation process in non-debug builds. You can integrate it once per view and keep using it for years.

Please refer to the instructions for configuring your project in the GitHub repo[3]. Now let’s look at your workflow options.

Workflow

SwiftUI

It only takes two lines to make any SwiftUI live-coding enabled, and when you do, you’ll have a much faster workflow than using Swift Previews while being able to work with actual production data.

Here’s an example of my Sourcery Pro[4] application with all of my actual data and logic loaded in, allowing me to quickly iterate across the entire application design on the fly without any restarts, reloads, or anything like that.

Look how fast this development workflow is, and tell me you’d rather wait for Xcode to rebuild and redeploy every time I touch code.

UIKit / AppKit

We need a way to clean up state between code injection phases for standard imperative UI frameworks.

I created the concept of Host and it works well in this case. There are two of them:

 - Inject .ViewHost
 - Inject .ViewControllerHost

How do we integrate it? We wrap the class we want to iterate over in a parent, so we don't modify the type to be injected, but rather change the call site of the parent.

For example, if you have a SplitViewController that creates PaneA and PaneB, and you want to iterate over the layout/logic code in PaneA, you modify the call site in SplitViewController.

 paneA = Inject .ViewHost (
 PaneAView ( whatever : arguments , you : want )
 )

That's all the changes you need to make. Injection now allows you to change anything in PaneAView except its initialization API. The changes will be reflected immediately in your application.

A more specific example?

• I downloaded the Covid19 App
• Add -Xlinker -interposable to Other Linker Flags
• Swapped line Covid19TabController.swift:L63

From this sentence:

 let vc = TwitterViewController ( title : Tab .twitter .name , usernames : Twitter .content )

Replace with:

 let vc = Inject .ViewControllerHost ( TwitterViewController ( title : Tab .twitter .name , usernames : Twitter .content ) )

Now I can iterate on the controller design without restarting the application.

How does this work?

Hosts leverages autoclosures, so every time you inject code we create a new instance of your type with the same parameters as originally, allowing you to iterate over any code, memory layout and everything else. The only thing you can't change is your initialization API.

The changes to Host can't be fully inlined, so these classes are removed in Release builds. The easiest way to do this is to make a separate commit, swap this single line of code, and then remove it at the end of the workflow.

What about logic injection?

With standard architectures like MVVM/MVC you get free logic injection, recompile your classes and when methods are re-executed you are already using the new code.

If, like me, you like the PointFree Composable Architecture[5], you might want to inject reducer code. Vanilla TCA doesn’t allow this because reducer code is a free feature that can’t be directly replaced with injection, but our fork at The Browser Company supports it.

When I first started consulting with TBC, the first thing I wanted was to integrate Inject​ and XcodeInjection into our workflow. The company management was very supportive.

If you switch to our TCA branch (which we keep up to date), you can use Inject on both the UI and TCA layers.

How reliable is it?

Nothing is perfect, but I've been using it for over a decade. It's much more reliable than Apple technology (Playgrounds/Previews).

If you invest the time to learn it, it will save you and your team thousands of hours!

References

[1] DyCI: https://github.com/DyCI/dyci-main

[2] Swift Secrets: http://books.apple.com/us/book/id1551005489

[3] GitHub repo: https://github.com/krzysztofzablocki/Inject

[4] Sourcery Pro: http://merowing.info/sourcery-pro/

[5] PointFree Composable Architecture: https://github.com/pointfreeco/swift-composable-architecture

[6] Demo source code: https://github.com/krzysztofzablocki/Inject