Swift-Macros: A curated list of awesome Swift Macros
I want to write something more detailed about macros once I have a chance to dig into them more than watching the session videos (1 and 2), and maybe this new repository from Krzysztof Zabłocki is where I should start? It’s a rapidly expanding list that includes packages, macros, educational resources, and tools.
Krzysztof Zabłocki has open sourced his bootstrap iOS project this week. However, before you jump in with both feet I'm not completely convinced that iOS projects actually need a bootstrap. There are some good recommendations here though so what I would recommend is to take a look at this, spend some time understanding it and then pick bits that work for you. Blindly using someone else's defaults is only going to lead to surprises down the line.
Krzysztof Zabłocki on the Cocos 2D blog with an interesting article on not including a "brush size" tool in Foldify. The end result is an extremely effective way to effectively change brush size by zooming and avoiding problems like having a brush which is smaller than the user's finger. For me, Foldify was easily my favourite app of last year and I am very pleased to see it getting so much coverage.
Overlaying application version on top of your icon
While at NSConference this week, one of the stand out talks was from Evan Doll of Flipboard talking about the tools they use behind the scenes to build their iOS apps. One of the neatest tricks mentioned was a script they use to automatically overlay information about the build on top of the app icon. Krzysztof Zabłocki has written up a nice generic implementation of this ready to drop into your own projects.
Krzysztof Zabłocki with a cute idea to use Interface Builder as a simple level editor when building an iOS game. This also serves as a reminder UIKit/Core Animation is a perfectly acceptable framework for writing simple 2D games. You may not get every ounce of performance like you would with Cocos2D or OpenGL directly but you won't be as far off as you might imagine.
Using protocol compositon for dependency injection
Dependency injection is one of the latest trends in iOS development, for better and more reusable code, cleaner architecture, testability and others. But adding a new dependency to a component means you have to refactor its initializer and all its calls, and we all know Xcode still can't help with that. Krzysztof Zabłocki suggests using protocol composition to avoid the need for that refactoring. Personally, I'm very curious to try this approach, as this is a problem I've met before.
After talking about diffing XCTest failures last week, I had a few messages mentioning this package from Brandon Williams and Stephen Celis, so I thought I should give it a link! I also meant to include another link to Difference from Krzysztof Zabłocki, so let's fix that as well. 😅
I must say, though, I prefer solving this problem with an external tool rather than an extra dependency.
Sourcery: A tool that brings meta-programming to Swift
Krzysztof Zabłocki with an interesting code generation tool for Swift files which allows reflection over all of your types, and code generation from there. Obviously you wouldn't write your whole app using this, but you might want to save yourself some repetitive work by building some stuff this way. I'm personally not a big fan of code generation, but this does provide a workaround for some limitations we have in Swift at the moment.
Want to find all live instances of a class at runtime while debugging? Richard Heard has put together this small library that will allow you to do exactly that. It compiles into your app but is mostly useful from within LLDB for live investigation of objects. Also, this is the best named project I've seen in a while.
Update: Thanks to Krzysztof Zabłocki for pointing out that this code seems to have been taken from another project, Cycript by Jay Freeman. While the code remains useful, the disregard for the original code license is not good enough. Apologies, I would not have linked to it if I had noticed this.
I’m sure I’m not the only one who has a constant stream of ideas related to software I either work on now, or may work on in the future. The quality of my ideas varies wildly, and it’s often the worst ideas that shout loudest at me to drop everything and start working on them. 😅 You’ll never be perfect at knowing where to focus your attention, or at least I’ve resigned myself to the fact that I’ll never be perfect at it, but it’s an important thing to keep in mind.
I’ve been thinking a lot about the maturity of ideas this week, mostly because of this week’s release of Sourcery Pro by Krzysztof Zabłocki. Would this app be as good as it is without the years of thought, development, and iteration that went into Sourcery? Almost certainly not. That experience drove the feature set and workflow, and the app is much better for it.
But does every idea need to be deliberated on for years? Nope! Some ideas benefit from a quick MVP and experimentation. For example, this newsletter. I had the idea to do it, and around a week later I sent the first issue.
It’s hard to advise on this topic, but I think choosing what to pursue often comes down to how complex/significant the task is. I made the right decision to move quickly when deciding to start iOS Dev Weekly as the opportunity cost was small, and I took things much more slowly when considering whether to build the Swift Package Index.
The original idea for building a package search engine popped into my head around two years before the launch of the index site, and a year before the SwiftPM Library. I let the idea stew for a long while before starting as I knew the undertaking was significant.
What should you take from this? I think I might just have written the most obvious advice ever, but sometimes reading obvious stuff can still be useful. I’m also saying you should check out Sourcery Pro. It’s good. 👍
Note: For full disclosure, I helped beta test Sourcery Pro.
