Swift 5.8 Released
Swift 5.8 has been released (did you download the latest version of Xcode yet?), and it includes a number of really cool new features.
I wrote about one of the biggest new features last week: piecemeal adoption of upcoming features, and I still think this is one of the coolest things I've seen in a long time. Being able to try out upcoming features with the current version of the toolchain? Priceless!
There are many other new features, like an improved Result Builder implementation (and don't you wonder what that might be good for), a bunch of updates for DocC and Swift Package Manager.
I was particularly impressed to see that the team has started replacing the C++ based Swift parser with a Swift-based parser, and has started using the new parser in SwiftSyntax as a test-drive before replacing the old parser entirely.
SDK conditional code
Wouldn't it be nice if we could use all the latest and greatest features that Apple releases in all of our apps? Unfortunately, things are not as easy as that, and often, we have to resort to conditional compilation to ensure our apps (or SDKs) work on all the target platforms and operating system versions.
In this article, Marco discusses the versioned
canImport compilation statement, and its alternatives.
How to use custom names for Swift properties when decoding JSON data
Decoding and encoding data is one of the most common programming tasks - it is hard to imagine an app that doesn't process data that it got from the internet in some form.
Thanks to Swift's
Codable protocol, having to write your own JSON parser is a thing of the past, and most of the work is done for you.
But sometimes you need to customise how data is mapped. In this series, Natascha covers the basics and some advanced use cases of mapping JSON to Swift using Codable.
If you want to dive deeper, Mattt's excellent book Flight School Guide to Swift Codable is now available for free.
You might also be interested to hear that Firebase supports Codable for several parts of the SDK:
- Firestore (see the documentation)
- RTDB (see this article)
- Remote Config (see this discussion)
Improving multiplatform SwiftUI code
SwiftUI aims to use reasonable platform-specific defaults, but more often than not, you will end up writing a lot of conditional code when targeting more than just one platform.
Jesse Squires came up with an interesting approach to making this slightly more bearable by adding platform-aware extensions to some of Swift's basic data types. If that doesn't cut it for you, he also shows how use platform-specific versions of the
body computed property.
Sharing content in SwiftUI
Sharing is caring, they say, and being able to share information from one app to another is one of those features that seem like a small detail, but have a huge impact on the utility of an app.
Apple introduced the
Transferable protocol and the
ShareLink SwiftUI view in iOS 16, making it much easier to share information from your app in a structured way. For example, you might want to share a highlighted text passage as plain text, rich text, markdown, or even a rendered PDF, so that the target app (or the user) can decide which format they prefer.
Majid's article is a one-stop shop: it's got all you need to understand and use this feature. Great stuff, as always.
Apple Passwords Deserve An App
It's not really a secret that you can add a shortcut to Apple's Passwords password manager to your home screen, but even despite Ricky tweeting about this on a regular basis, most casual users probably don't know about this.
Cable makes the point that "passwords are productivity, not preferences.", and suggests Apple should ship Passwords as a standalone app, and provide a baseline, secure, experience for managing passwords for every Apple user.
I couldn't agree more. I also agree with Cabel that this would not sherlock the likes of 1Password - they are truly cross-platform, and have even more features that power users care about.
Should you highlight code on your slides?
Building great presentations is hard work, and most, if not all, speakers I know put a lot of time and effort into preparing their slides and demos (be sure to let them know after their talk if you liked what you saw!).
When talking about code, one of the most important questions is how to present code.
I've been using Keynote for my presentations for a very long time now, and have developed a technique based on animations like Magic Move, Keyboard, Dissolve, and a couple others that allows me to build code slides that almost look like someone is actually typing the code. It looks fantastic, but it's also a lot of work (see this tweet to get an idea of what I mean).
Tunde shared a video by Daniel Steinberg in which he talks about Syntax Color - How and why I present code the way I do, and I found it super intriguing.
Daniel is a gifted teacher (as everyone who has had a chance to attend one of his talks or workshops can confirm), and he clearly has thought long and hard about how to present the material he teaches in the best and most easily understandable way. The fact that this also is a very efficient way of creating the slides is just the icing on top.
Last week, I wrote that the tech industry seems to have gone into AI overdrive, and this week something unexpected happened: a group of people called for a temporary halt of AI research (specifically, training LLMs more advanced than GPT-4). Other claimed that this doesn't go far enough, and called for a complete shut-down of AI.
Of course, the conversation is more nuanced than that, and it eventually led to Google's CEO Sundar Pichai being interviewed by Kevin Roose and Casey Newton of the Hard Fork podcast.
We're living in exciting times, and I can definitely relate to people's concerns of being made redundant or having parts of their job replaced by AI - but, like most of the people who answered my Twitter poll, I don't think that AI will enable us to work less.Peter 🔥