SwiftUI
Variable colors in SF symbols
I've included articles about SF Symbols a couple of times in the past few weeks. Here is an impressive demo by Sparsh Paliwal that also makes use of CoreMotion.
Adding scroll offset tracking to a SwiftUI ScrollView
Last week, I linked to an article by John Sundell about Observing the content offset of a SwiftUI ScrollView, so you might imagine my surprise when I saw yet another article about the very same topic.
While both articles cover the same topic, they do take different approaches. John exposes the ScrollView
's content offset via a Binding
, whereas Daniel chose to use an action (onScroll
). His reasoning:
I find using a binding confusing when it’s not possible to change the value to scroll to a certain offset. Since the binding is thus in fact read-only and writing to it would lead to bugs, I decided use an action.
This makes a lot of sense to me, and I think it would be a great idea to compile a list of SwiftUI design patterns like this.
As an added bonus, Daniel released a Swift package which allows implementing sticky header views and other scrolling-related effects: ScrollKit
Adding a stretchable header to a SwiftUI ScrollView | Daniel Saidi
I think this is the first time I link to two articles by the same author in the same week, but it's totally worth it. In this one, Daniel describes how to replicate the stretchy header known from apps like Spotify. Conveniently, this is part of ScrollKit, so you can easily integrate it your own apps.
Software Engineering
5 Tips to creating a (good) pull request
Writing a good pull request is an important skill, no matter if you're contributing to an open source project, a client project, or even an app for a hackathon.
Danijela has a couple of great suggestions for writing good pull requests.
The only thing I would add to Danijela's list is "remove any boilerplate template from the comment". Many open source projects (Firebase included) use pull request templates to make sure contributors provide the context that maintainers need to process the PR. Often, these templates include instructions how to use them. You should remove those instructions, as they're only intended to guide the PR author. Leaving them in will create a lot of noise for anyone reading the PR either online or in their email inbox.
GitHub's beta launched without Pull Requests
GitHub's beta launched without Pull Requests, but we did have private messages, since we were a social network. So when we first added Pull Requests, they were just special DMs: "Please pull from my fork at this branch." They sure have come a long way.
The blog post Chris Wanstrath is referring to is actually 14 years old now, and it dates back to a time when GitHub was still in its infancy. Can you imagine using git without pull requests? No? That's how much GitHub has changed the way how we collaborate on code.
Productivity
Xcode Templates
Xcode supports creating your own templates for new files and new projects. In the past couple of years, there have been a bunch of articles explaining how to create your own templates.
This article is a nice write-up that cuts right to the chase. Thanks, Manu!
Writing
En dash | The Punctuation Guide
In a conversation on of of our chat rooms, a colleague said something along the lines of "this is why we have en dashes" (I'll leave it to your imagination what the nature of this conversation was), and I initially thought they meant em dash.
But it turns out there actually are both en and em dashes!
Podcasts
Inside the global battle over chip manufacturing
As readers of my newsletter know, I am a huge fan of The Verge's Decoder podcast with Nilay Patel.
This episode about the global battle over chip manufacturing has it all: foreign policy, high-powered lasers, hotshot executives, monopolies, the fundamental limits of physics, and, of course, Texas.
If you have any devices with chips in your home and are remotely interested in geopolitics, this episode is a must-listen.
Comment
Do you have déjà vus?
Today's issue contains two articles that cover a topic that I already included in the previous issue. One reaction to that might be to say "why did the author decide to write about a topic that has been covered before", and I have to admit that was my initial reaction, too.
However, different people have different perspectives with which they look at any given topic. In this specific case, the authors chose different approaches for exposing the inner state of a SwiftUI component (something I covered in my video series about Building Reusable SwiftUI Components).
I really enjoyed reading both articles, and thinking through the implications of the different approaches. It even inspired me to think about putting together a list of SwiftUI patterns.
So if you ever find yourself thinking "surely someone else has covered this topic before", don't let this thought keep you from creating a video, talk, article, or library about this topic. You will bring your own perspective to the table, and there will be enough people who will benefit from your creation. Maybe it's your unique way of writing that will make it easier for them to understand a complicated topic. Or your wit that makes them remember a particular concept in your video. Or your enthusiasm that helps them relate to some little know aspect of an API in your talk.
No matter what you do - bring yourself and your unique perspective - and all else will follow.
Peter 🔥