Krzysztof Zabłocki

Hot Reloading in Swift

Mon, 04 Apr 2022 00:00:00 UTC

The year is 2040, and our newest MacBook M30X processors can compile large Swift projects perceivably instantaneously, sounds pretty amazing, right?

Except, compiling the codebase is just part of our iteration cycle. Other ones include: - restarting it (or deploying it to the device) - navigating to the previous location where you were in the App - re-producing the data you need.

It doesn’t sound too bad if you have to do it once. But what if you are like me and, on a typical day, do between 200 - 500 iterations on the codebase? It adds up.

There is a better way, embraced by other platforms and achievable in the Swift/iOS ecosystem. I’ve used it for over a decade.

Do you want to save up to 10h work per week, starting today?

Exhaustive testing in TCA

Mon, 21 Mar 2022 00:00:00 UTC

I’ve worked on 5+ apps using The Composable Architecture and I really like it but I’ve observed few issues that we can run into in bigger apps.

As you probably know I’m also a big proponent of TDD / BDD, so let’s start by talking about what I don’t like about the way TCA does testing.

Code-Review best practices

Mon, 21 Feb 2022 00:00:00 UTC

No matter how experienced we are, we are bound to make mistakes in our work.

This simple fact is one of the reasons why Code Reviews have become the cornerstone of software engineering processes around the world.

Part of my job is building teams and establishing best practices for them to operate efficiently and collaboratively.

But team practices shouldn’t just be coming from an individual, which is why I first interviewed a bunch of our engineers at The Browser Company around what is the goal of PR’s and Code reviews.

In the spirit of giving back to the community, we’ve decided to share those practices.

Leave your ego at the door

Mon, 08 Nov 2021 00:00:00 UTC

We define ego as a person’s sense of self-importance. It’s an attribute that contributes to building up your identity and figuring out what you want in life.

But left unchecked, ego can lead to arrogance and ignorance.

Improving Composable Architecture Debugging

Wed, 18 Aug 2021 06:43:04 +0100

I’ve been a fan of Point Free Composable architecture for a while now.

I’ve worked on TCA projects for more than a year on projects of all sizes: from smaller projects like my indie Sourcery Pro, through the New York Times project, to a truly large codebase, a completely new browser for The Browser Company.

TCA has been working great in all of them, but one thing that I was missing was an easy way to debug state changes, as the official debug higher-order reducer doesn’t play well with large app states.

So I thought: let’s create an interface that will not only deal with larger states, but also offer us a way to filter actions with ease:

.debugDiffing(allowedActions: .allExcept(.hoverActions, .windowVisibility))

Apple Treats interview

Wed, 05 May 2021 06:43:04 +0100

Yesterday I was interviewed by Apple Treats

You can watch the recording here:

Or listen in Apple Podcasts

Dear Xcode....

Tue, 20 Apr 2021 06:43:04 +0100

Two weeks ago I’ve released Sourcery Pro, the most powerful Xcode extension that exists.

If you still didn’t check it out, you really should as it can save you 100+ hours by letting you automate a lot of repetitive code in your projects, from writing mocks through SwiftUI and Snapshots.

Now let me tell you a bit about what Xcode extension offer and a couple of ideas for what Xcode team could add in future releases, to make tools like Sourcery Pro more powerful.

Introducing Sourcery Pro

Thu, 08 Apr 2021 10:43:04 +0100

Today I’m happy to announce a new mac app that extends Xcode features.

This is an effort of over 1000 hours, so if there was ever time to show your support for all the open source work I’ve done, it’s now.

Sourcery Pro

Wed, 07 Apr 2021 15:29:09 +0200

Sourcery Pro is a Mac App that extends Xcode with the ability to create your own live templates that understand your code structure. Do you hate writing same repetitive Swift patterns over and over again? Now you don’t need to, it’s just a shortcut away. Buy Directly! Popular use-cases: Create mock implementation from a selected protocol Add Codable support to enums with associated values Kickstart your Composable Architecture boilerplate Generate property level tests Generate test specs from your classes Generate SwiftUI view from a struct Create Prisms and Lenses for your data It comes bundled with 14 starting templates and features a powerful Template editor with code completion, inline documentation, and a built-in error checker/linter that makes writing your custom automation a breeze.

The Decade in Review

Mon, 15 Mar 2021 10:43:04 +0100

Lately, I’ve spent a significant amount of time thinking about my career: what I’ve done so far and what might lie ahead for me.

To gain some perspective, I’ve decided to journal some of the things I’ve done over the last decade, and to share that with you.

So below you will find some of my projects for the Cocoa community, as well as the highlights of commercial work I enjoyed and can talk about (NDA’s).

Improve build times by extracting 3rd party tooling to processing script.

Mon, 18 Jan 2021 00:00:00 UTC

A lot has been written about improving Swift compile times, but the compiler and linker are just part of the equation that slows down our development cycle.

Most projects leverage great 3rd party tools like SwiftLint, Sourcery, SwiftGen, SwiftFormat and many more. Leveraging those tools is the right thing to do but we have to be aware that all of those tools come with some time delay for our build -> run development cycle.

We often set those tools to run as build-phases which means they run each time you attempt a build but none of those tools need to be run each time we build.

Even tools that generate code we need for our projects like Sourcery or SwiftGen don’t need to be re-run unless we made changes in very specific parts of the application.

As an example New York Times main application leverages a lot of 3rd party and internal tooling, the total time all the tools take is 6s on my (powerful) machine.

Only 6 seconds or as much as 6 seconds? Let’s put this into context:

I build a project between 200-400 times on an average workday.
Let’s assume 90% of the time we don’t need to run those tools with each build.
We have 30 iOS developers working on the main app

Lower limit: 200 * 6s * 30 * 90* => 9 hours wasted per day

We are wasting 45 hours per week, if we can improve that it’s almost like hiring a new full-time developer, except it’s free.

Let’s look at how we can improve this with a process change a dash of bash shell programming.

Adding support for versioning and migration to your Codable models.

Wed, 10 Jun 2020 00:00:00 UTC

Codable is a great protocol for automating simple model persistence, but it lacks support for any kind of versioning or migrating the data from older versions.

You can, of course, implement custom Codable adherence and throw in a bunch of if statements and manual decoding to achieve this goal, but isn’t that kind of killing the main selling point of Codable?

Let’s look at an idea that adds Versoning yet still leverages derived Codable.

Straighforward Data Snapshots

Mon, 15 Jul 2019 00:00:00 UTC

If your app has a lot of content, chances are that by the time you get a chance to work on a bug report, the data that the bug appeared on will be long gone.

Here are some tidbits on how I created a simple solution for that problem at The New York Times, it’s based on a simple idea.

Finding exact difference between 2 instances

Wed, 18 Oct 2017 12:30:51 +0200

Have you ever written tests? Usually, they use equality asserts, e.g. XCTAssertEqual, what happens if the object isn’t equal? Xcode throws a wall of text at you:

This forces you to manually scan the text and try to figure out exactly whats wrong, what if instead you could just learn which property is different?

How to find retain cycles and memory leaks sooner

Sun, 01 Oct 2017 12:30:51 +0200

LifetimeTracker can surface retain cycle / memory issues right as you develop your application, and it will surface them to you immediately, so you can find them with more ease.

Instruments and Memory Graph Debugger are great, but too many times developers forget to check for issues as they close the feature implementation.

If you use those tools sporadicaly many of the issues they surface will require you to investigate the cause, and cost you a lot of time in the process.