Issue 467

31^st July 2020

Written by Dave Verwer

Comment

“My new project is 100% written with …”

I see this phrase everywhere in the iOS/Swift community. Most recently the ellipsis is replaced by SwiftUI, but it has been many other things too. It may seem like a positive statement, but I don’t see it this way. It’s the “100%” (or sometimes “Pure”) that bothers me.

I don’t think we should be striving to have the things we make be 100% anything! The world is full of incredible technology, and if we seek to exclude anything that isn’t Swift, or SwiftUI, or whatever else it is, then we’ll miss out on so many ideas, techniques, and people from other areas of software development.

This community has always been a friendly one. I remember when I first started dipping my toe in Objective-C development, many years ago, one of the things that made me stick around was how welcome I felt. Our current community is still friendly, but I see issues with how inward-looking we can be, and I see it getting worse over time. If someone familiar with another language peeks into this community and sees a “SWIFT IS EVERYTHING” mindset, they’re less likely to stick around, and that’s a loss.

I know that when people say this, their heart is in the right place. I know it’s just that people are excited about new technology and want to share that excitement. I just fear that if we focus inwards too much, we’ll lose something special, and be seen as a less welcoming community than we think we are.

—

Note: I want to be clear that I’m not trying to subtweet (sub-newsletter? 😂) any particular people with this comment. This isn’t about any specific individuals, it’s everywhere.

UPDATE: I had a couple of people email me thinking that I was suggesting that we shouldn’t use Swift, or SwiftUI, or other new technology. That was absolutely not my intention, so I wrote a few clarification tweets!

Dave Verwer

News

Improving fairness and viability of the App Store for developers

I’ve deliberately not written anything about this week’s big story of the US congressional hearing. I have got a draft of some thoughts in progress, but it wasn’t quite in good enough shape for this week. While I didn’t quite agree with some of the opening statements in this post from Aleksandar Vacić, he does make some good points about the guidelines in this post.

Tools

Setting a developer directory environment variable

This little tip from Sven A. Schmidt (and Ankit Aggarwal) is incredibly useful if you need to run different tasks with older (or non-beta versions of Xcode) and don’t want to do the xcode-select -s dance. Setting a DEVELOPER_DIR environment variable switches everything, just like Xcode select does.

This came up during the development of a new feature coming “soon” to the Swift Package Index. I won’t spill the beans just yet, but we’ve been downloading lots of versions of Xcode recently. 😬

Code

Impossible Grids with SwiftUI

SwiftUI grids are not as capable as UIKit collection views in terms of layout, but that doesn’t mean you can’t produce some fabulous custom grid styles with them. I love this idea (and implementation) by Javier Nigro. It’s beautiful.

Creating custom .redacted effects

Like Federico Zanetello, you might have been a little disappointed to see that the list of redaction reasons that accompany the new .redacted SwiftUI view modifier totals just one. Can you create your own? Of course you can! 🌈

Create your first HTTP endpoint with Swift on AWS Lambda

I linked to the announcement of Swift support on AWS Lambda a few weeks ago, but if you haven’t tried it yet, you’ll want to read this post (and this introduction, too) from Fabian Fett.

Setting up a Core Data store for unit tests

At first glance, the idea of an in-memory data store for Core Data might seem reasonably useless. It’s a data persistence framework, after all. There are a few uses for it though, but by far the most useful is for unit testing. Donny Wals tells us more.

Business and Marketing

Price Testing for Subscription Apps

You’ll find lots of advice on the internet to run pricing experiments with your products (whether it’s an app, or anything else) but implementing them takes time, effort and persistence over a long period. I’d bet most smaller developers don’t do it, and that’s a shame. I love the sound of this new feature from RevenueCat that promises to manage the process automatically. The bad news is that it’s not currently available on anything but their most premium plan, which means that the people who probably aren’t doing these experiments will need to wait a little longer until they can give it a try.

For full disclosure, Revenue Cat has previously sponsored iOS Dev Weekly, but their sponsorship did not influence my decision to include this item. I just read the blog post.

Up to Speed

When do you need to report your app’s use of encryption?

Have you filled in an export compliance form for your app? Did you know that if you ship an app that uses HTTPS, even as a client, that you need to? Did you know that the process of filling it in isn’t anywhere near as onerous as you might think? This is great advice from David Olesch, whether you’re just getting your first app ready, or whether you’ve just been putting off this important task.

Jobs

Senior iOS Engineer @ DuckDuckGo – Rather than rely on interviews, we base our hiring decisions on demonstrable work performance. We achieve that through asking our candidates to complete paid projects, which largely resemble the type of challenges they would be solving at DuckDuckGo every day. – Remote (anywhere)

Senior iOS Software Engineer @ WillowTree – As a Senior Software Engineer at WillowTree, you’ll have the opportunity to impact teammates throughout various stages of their careers. You’ll have clear oversight of how engineering runs day-to-day and will influence project outcomes. This is not a remote position and may require some travel. Currently, all team members are working from home until our offices reopen. – Charlottesville VA

And finally...

Yes, it’s the full thing. I’m sorry. 🤯