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:
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.