Let's explore couple of atypical Sourcery use-cases.
How often have you wanted to change some small setting in your application? Let's build a generic solution.
Exhaustivity in the context of TCA tests means every test you perform has to replicate all the actions, state changes, and effects steaming from the first trigger you want to verify. It leads to a code that has a lot of TDD anti-patterns. Let’s get into the details.
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
Subscribe to premium membership plan
Get access to all premium content and enjoy reading without any distraction
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
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
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
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