Newsletter: January 2020
I’m super excited about 2020, and to continue to evolve Swift by Sundell in many different ways this year. I’m also really happy that I managed to survive my first year as an indie, working full-time for the Swift community. The fact that I’m able to share almost all of my work with the community, while also supporting myself and my family, is something that I’m incredibly happy about — and I couldn’t have made it this far without all of your support and encouragement, so thank you so much for being a subscriber and for following my work, it really means the world to me.
This year you’ll see lots of brand new projects launching on Swift by Sundell, as well as a new season of the podcast (coming January 15th), weekly articles all throughout the year, content for both beginners and experienced developers, and much more.
I also managed to accomplish my goal of open sourcing all of the remaining tools that I use to build Swift by Sundell before the end of 2019 — following up the release of my Markdown parser Ink with the HTML templating tool Plot, and finally my Swift static site generator Publish.
More on that, and all of December’s new tools and content, in this month’s edition of the newsletter — so let’s get started.
For 150 weeks (🎉), I’ve been publishing a new article about Swift every Sunday. These articles were added during the past month:
Let’s take a look at a few different ways to add plugin support to a type or library, and how doing so can enable a system to become a lot more decoupled and flexible.
Predicates can enable us to filter various collections in ways that are incredibly flexible. In this article, we’ll take a look at how we could construct powerful, type-safe predicates using closures, generics, and operators.
A look at how we can improve the internal consistency within each of our core data models, and how doing so can let us establish a much stronger foundation for our codebase as a whole.
This article is about one of the core aspects of object-oriented programming — initialization. What characteristics should an initializer ideally have, and what sort of techniques could be useful in order to keep our initializers simple and predictable?
For the 150th weekly article on Swift by Sundell, and the last one of the past decade, let’s look back at how Swift has fundamentally changed the way apps for Apple’s platforms are built, and where things might be going from here.
Apart from my work with Swift by Sundell, I occasionally also write guest articles for other websites and publications. This article was published last month:
Building custom developer tools and automating certain tasks can be a great way to speed up a team’s overall development workflow — and with Swift, it couldn’t be easier to get started, since the exact same language that we use to build apps can also be used to write scripts and tools as well.
This guest article that I wrote for the Bitrise blog is about doing just that, and how our custom tools and scripts can then be deployed on a continuous integration service, such as Bitrise.
The Swift by Sundell podcast is a bi-weekly show featuring special guests from all around the Swift community. You can find it in your podcast player of choice, for example Apple Podcasts or Overcast. These episodes were published during the past month:
Kate Castellano joined me to discuss how views and UIs can be made more dynamic and data-driven, and how that could even enable certain views to get their entire layout configuration from the server. Also, view models, handling loading states, and much more.
iOS developers and bloggers Donny Wals and Antoine van der Lee joined me to wrap up the third season of the show with the yearly Holiday Special. How has Swift changed in 2019, and where might things be headed in 2020? Also, wishes for Xcode Santa, blogging and open source, and much more.
👍 Make 2020 a bug-free year with Instabug
No matter how well we structure, write and test our code, there’s no doubt that at one point or another we’ll discover bugs in it. But the question is, how do we find out about those bugs, and how do we gather enough information to be able to reproduce and fix them?
Enter Instabug, a powerful, yet easy to integrate SDK that helps you resolve bugs, crashes and other errors so much quicker. Instabug gives you instant access to reproduction steps, environment info, stack traces, and so much more — all while keeping all of that data private and secure.
Try Instabug for free, and start working towards making your app bug-free.
Checking out the above sponsor really helps support my work.
Quick news about my open source projects, such as new releases and major versions, or interesting new features.
Plot is a DSL (domain-specific language) for writing HTML, RSS and XML using native Swift code, and it’s the templating tool that I use to build every single page on Swift by Sundell. It’s also what powers the site’s RSS feed, as well as the podcast feed.
When designing Plot, my goal was to fully utilize the Swift compiler and type system to validate all of my HTML and RSS at compile time, and to enable easy type-safe templating — without having to resort to techniques like string replacement, or having to place tokens and logic inside of raw HTML files.
Publish is the static site generator that powers all of Swift by Sundell (including this very newsletter). It orchestrates the entire process of building, generating and deploying a static website, and offers a great degree of flexibility since almost all aspects of that process are configurable using native Swift code.
This tool took me the better part of the past year to build, so I’m incredibly excited to now be able to share it with all of the Swift community. If you happen to use Publish to build your site, then please let me know about it, it’s always super inspiring for me to see people use the tools that I’ve built.
More on the design of Publish right below, in this month’s Behind the scenes section.
One thing that I’ve learned from the past decade of designing developer tools and open source projects is to always try to make the tools that I build as configurable as possible. By not making too many assumptions about the context in which a given tool will be used, chances are so much higher that more people will be able to use it, without first having to modify the tool itself.
However, making projects really configurable also tends to make them very complicated — both to build and to use — so there’s most often a balance to be struck between configurability and complexity. When it comes to Publish’s API in particular, I knew that I wanted to build a static site generator that offered a really high degree of code-level control. I didn’t want to use text-based configuration files, raw HTML templates, or other kinds of external data — I wanted every single aspect of each website to be completely configurable using native, compiled Swift code — to enable entire websites to be built using just Xcode and a web browser.
To make that happen, I decided to use the same high-level design that I used for Splash (my Swift syntax highlighter), and use a rule-based approach — by enabling each website to form its own publishing pipeline through a series of either built-in or custom steps. That way, I had to build all of Publish’s functionality as separate, independent building blocks — which both made things very configurable by default, and also helped steer the project towards a more composable and decoupled overall architecture.
So that solved the flexibility and configurability part, but I also wanted it to be as easy as possible to get started with Publish, so I knew that I had to build a comprehensive suite of convenience APIs on top of that more lower-level publishing pipeline system.
To do that, I introduced a Website protocol to enable each website to be defined as a Swift type. That way, I now had a lot of information about the website being generated available right within the type system, which in turn let me give Publish an incredibly simple starting point — that ended up looking like this:
try MyWebsite().publish(withTheme: .foundation)
While I’m really happy with the design that I came up with for Publish, I’m sure that now that it’s open source, it’s going to need to continue to evolve as more people start to use it — and as other developers start contributing their own ideas and improvements to the project. Either way, I’m quite sure that this is going to be an exciting year for Swift-based static site generation.
That’s it for this edition! I hope you enjoyed this newsletter. Like always, I’d love to hear your feedback — so feel free to either email me, or contact me on Twitter @johnsundell. I read every single piece of feedback that I get, and I try to reply to as many people as I possibly can.
Thanks for reading! 🚀