2 min read

Issue #24

Hi there,

As promised, today's issue is a special one, and I'm really excited to bring it to you. I wanted to spice things up a bit and invite a guest curator to create this issue. Because why not?

Say hi to Bas Broek - he will be curating the collection today. Bas had been authoring Swift Weekly Brief (sadly discontinued) for 2 years before joining the accessibility team at Apple. Now he's back to the community and shares his favourite bits of wisdom with us below 👇 😌


This is Bas; I'm a friend of Marina's. As she reached out to me asking if I'd be up for writing an issue, I immediately said yes!

Having curated a newsletter before, I know it can be quite a bit of work; having the community help out was always a highlight of writing the newsletter, so I'm always happy to return that favor.


Accessibility hints

This thread is not about the literal API, but rather a bunch of things that are good to know and be aware of when building accessible products. I would love to know — how do you review code for accessibility?

Speaking of accessibility hints, here's Dani sharing an insight every day for the WHOLE YEAR. So great to see this topic being put in the spotlight. Check out his twitter and/or follow him for the daily accessibility tips.

Attributed Strings

As Marina mentioned in the last newsletter, it seems she's not the only one excited to see Natalia being back to blogging. Before she joined the SwiftUI team at Apple, her blog posts were a fresh breeze with amazing insights. Now, after leaving Apple, she's back to it, taking all the experience from her time at Apple with her — and it shows.

The new AttributedString API is type-safe and powerful, and can be used not only in SwiftUI, but also with UIKit and AppKit. The type-inference going on is quite complex though. Check out the full article offering a deeper understanding on configuring the new attributed strings: AttributedString Attribute Scopes

Equal sizing in SwiftUI

In this short article Matthias shares a clean approach to making all elements in a VStack as wide as the widest element (but not take up the entire proposed width):

SwiftUI equal and ideal sizes

One of the more common sentiments towards SwiftUI you’ll come across on the Internet goes something like this: It’s magical until it isn’t. Meaning: SwiftUI let’s you write UI code so quickly that it sometimes feels like a superpower. But suddenly you hit a wall and there’s seemingly no way around it. One example that illustrates this quite well is when you want to make all children of a VStack as wide as the widest child. Sounds like it should be straightforward. But it’s not. It’s a surprisingly hard problem.

Beyond code

Paris shares an insight on something we may overlook; sometimes it's not only about code.

WWDC Preparation

Here's a couple of helpful tips on preparing for WWDC, when it comes to audits and labs:

Thanks for reading! Enjoy WWDC next week, and see you around!

- Bas



Alright, that’s it for today.

Did you enjoy this issue? Let me know by pressing the buttons below.

Do you want to see other guest curators on the newsletter? Tell me who you'd like to hear from by replying to this email 🙌