Not Only Swift - 🔗 URLs, Property Wrappers, and a Fireplace 🔥 - Not Only Swift Weekly

Comment

Hi everyone 👋🏻

This will be the second-to last issue of Not Only Swift Weekly before I take a much-needed end-of-year break. Some of which will be dedicated to another project I hope to be able to publicly announce in the new year, so stay tuned!

In this issue, I’ve got a bunch of exciting topics ranging from passwords (or how to get rid of them), URLs (and how to improve them) to some lesser known SwiftUI property wrappers and a virtual fireplace to make your workplace (or home) a little bit more cosy.

So, read on to learn what’s new, and don’t forget to share this newsletter with your friends.

Thanks for reading,

What I am working on

As I mentioned a couple of days ago in a reply to Donny’s Monday tweet, I started to migrate my blog. I’ve been in the industry for quite a while now, so I’ve used a bunch of different technologies to run my blog: Typo3, Joomla, Ghost, Jekyll, Gatsby (and probably a few others I’ve forgotten about).

The current version makes use of Gatsby, a JavaScript-driven static site generator. It’s pretty powerful and has a lot of plugins, and a vibrant ecosystem with a ton of resources.

Still, I decided to migrate to Publish - why?

First (and probably foremost) I was curious to see how well John’s approach to write a SwiftUI-like DSL to not only describe the HTML code for the individual pages, but for the entire site would work. Secondly, although I am happy to write JavaScript / Typescript code, writing Swift feels a lot more natural to me. I have a lot of ideas for features I want to implement on my blog, and I’ve put too many of them to the side just because the idea of having to implement these in JavaScript didn’t really sound too exciting to me.

So I decided to see how difficult it’d be to migrate everything from Gatsby to Publish.

And the result is pretty compelling - can you spot the difference between the old (left) and the new (right) version?

Using Publish and Plot (the DSL for writing HTML) has been an absolute pleasure, and the fact it is modelled after SwiftUI certainly helps. John even implemented SwiftUI’s Environment concept, which made it super easy for me to define the accent color for individual articles and then access the color in the subcomponents like the header and footer, without having to drag them through all the intermediate components.

Once I’ve finished the implementation, I will publish (🥁) the code for my site on my GitHub profile so you can take a look for yourself, and maybe use a thing or two for your own site.

Firebase

Looking for a quick and easy way to make your workplace more cosy? Well, the Firebase team has you covered! Here’s our Firebase-themed fireplace - random Sparky appearances included! Oh, and when the video ends you know it’s definitely time to call it a day - you really shouldn’t work more than 10 hours.

Firebase Apple SDK Roadmap

On a more serious note, we have updated the “roadmap for the Firebase Apple SDK](https://github.com/firebase/firebase-ios-sdk/blob/master/ROADMAP.md).

Our top priority will be to modernise the SDK and make it more Swift-y. To make tracking easier, we’ve set up a dashboard here.

As you can see, it’s a bunch of work, and you can expect some exciting things in 2022.

Thanks to some contributions from the community, we’ve been able to add some really nice features already (such as support for Combine, or a property wrapper for Firestore that makes reading data from a collection a lot easier).

Codable to Firebase Cloud Functions

And there is more in the pipeline: for example, Morten has added support to Codable to Firebase Cloud Functions (well, the client-side part of it, anyway), so you will be able to call your Cloud Functions more easily when sending / receiving custom types. Check out the source code docs for an example of how to directly call a HTTP Callable Cloud Function using this new feature. This will become available in the next release of the Firebase Apple SDK in January 2022 (but if you build from master, you can start using it now). Check it out, and let us know how you like it!

Swift

Foundation URL Improvements

URL is one of the most used Foundation types, yet it has a number of shortcomings that make it cumbersome to use. Check out this proposal that proposes a number of really impactful improvements that will make working with URLs safer and more convenient:

SwiftUI

SceneStorage For Custom Types

SwiftUI has a bunch of property wrappers to allow us to handle state in our apps easier. @ObservedObject, @StateObject, @State, @Binding, and @Published are well well known, but @AppStorage and @SceneStorage are lesser known and don’t get the credit they deserve.

In this post, Keith digs into when you might want to use @AppStorage and @SceneStorage and goes on to show how you can use them to store custom types (thanks to Codable). It’s always good to know the tools you’ve got at your disposal, so why not spend 5 minutes to learn about this so you know how to use it next time you want to persist a search scope in your app?

Productivity

GitHub Lists

GitHub stars are a great way to bookmark repositories that you want to come back to at a later point in time. Which - let’s be honest - almost never happens. I’ve starred more than 1.1k GitHub repos, and there is just no way I am ever going to go back to all of these and review / use them. In the past, third party developers have tried building apps for managing and cataloguing your stars, and Larder is definitely one of the more useful ones, as they send you regular digests of updates that happened in your starred repos.

GitHub just announced a tool of their own to manage stars - Lists (yeah, I know - very creative), and it seems this might not only fall into the category of all the changes they’ve made to turn GitHub into a social network, but might actually be quite useful for your own use. For example, here is Eli Perkins with an overview of all the tools and libraries they use in GitHub Mobile, and I was excited to see they also make use of Firebase.

Have you used the new List feature yet? Maybe you’ve created a list of tools and SDKs that you use in your app, or your tech stack? Reply to this tweet and I will retweet the most inspiring ones.

Authentication

Secure your site with two-factor authentication with a security key (WebAuthn)

I’ve written about passwords before in this newsletter (see issue #7), and briefly touched on the topic of WebAuthn. The Web Authentication API (WebAuthn for short) is a standardized phishing-resistant protocol that can be used for authenticating users. It allows servers to register and authenticate users by using public key cryptography instead of passwords.

Thanks to WebAuthn, passwords will one day be obsolete.

To learn more about this, and how to implement it in a web application, check out this code lab by my colleague Maud Nals.

Also, make sure to check out webauthn.guide - it’s got some great explanations and code samples. There also is a live demo at webauthn.io. Now, if you’re thinking “there is no way how everyone will buy a YubiKey to be able to use 2FA and WebAuthn to log into their services”, check out the Move beyond passwords session at WWDC 21, and you will change your mind.

Web

Web Browser Engineering

We all use web browsers on a daily basis, and it’s hard to imagine getting anything done without looking something up in the online docs, ask a question on StackOverflow, talk to your colleagues via chat, or download the latest version of Xcode. And - for all of these tasks you probably use a web browser!

But, have you ever wondered how a browser works?

I mean, beyond downloading the HTML source code (that’s probably the easiest part, although there still are plenty of things to keep in mind auth and all the different image formats). No, I am talking about how to actually parse the HTML and render it on screen…

If you’d like to learn how browsers are built, how to create the DOM from HTML, render it on screen and apply CSS, you should definitely check out Web Browser Engineering. This is an online book by two people who know their stuff: Chris Harrelson is Rendering Lead for Chrome, and Pavel Panchekha teaches programming languages and web browsers at the University of Utah.

Oh, and did I mention they’re building a real browser in just 1000 lines of Python?