I loved this recent tweet from Russ Shanahan, and it inspired me to write about why I agree with him.

I vividly remember when I started feeling this way. It was caused by me regretting rushing something into Curated before we launched. We were deciding the initial feature set, and one feature I had on the list was a sponsorship scheduling system. I had written some thoughts on how it might work, and it was a feature I needed to run this newsletter, but I hadn’t put enough thought into how it’d affect the product. We rushed in a primitive implementation, but I felt uneasy about it as soon as we finished it. I should have put it behind a feature flag and re-thought it after release, but I didn’t. I shipped it.

The reasons I regretted it weren’t all technical either. Yes, it was a fairly rough, half-baked implementation, but it also fundamentally changed the external perception of the product. Instead of primarily seeing it as a tool they could use to make a great newsletter, many people started to see it as a tool to make money. That wasn’t my intention at all. Making money with a newsletter is about so much more than just having a sponsorship scheduling system! 😱 If we had launched that feature more carefully, I think we could have avoided that being the focus.

That experience permanently aligned me with Russ’s thinking, and I now err on the side of caution when releasing features. For example, there are two enhancements to search in the Swift Package Index (#1228 and #1320 specifically) in progress right now. Filtering package search based on metadata and expanding search to include keywords and author results. Both features are working but are disabled in production because they’re not quite right. I held back the metadata filtering feature because even though it works, I wanted people who use it to understand what they’re doing with visual feedback. Same with author and keyword search. It works but currently only matches one author or keyword result and doesn’t support partial matches.

I’m confident that both of those features are good ideas, and you can certainly make the argument that both could ship as is without hurting the product. But I’d much rather enable them with a bit more polish.

It’s not just about what the feature does either. It’s about momentum. Shipping something gives us a dopamine hit, and if you’ve completed the fundamentals of a feature, it can be hard to get motivated to tweak it afterwards when you could move on to something entirely new!

The best time to stop development on a feature is before writing any code, of course. You can also make a good argument that shipping features early for feedback is worthwhile, but there have been more times when I’ve regretted shipping something I wasn’t happy with than regretted not releasing something.

Dave Verwer

The Essential Guide to Mobile App Quality

Learn about the factors that affect the quality of your iOS app and the costs of releasing low-quality apps. Discover the industry benchmarks you should target and how you can improve your mobile app quality to meet and exceed them. Read it now.

instabug.com

Black Friday Deals for Developers

Last year, I said that linking to this repository created by Marius Landwehr with Black Friday deals for developers was becoming a tradition. This year, as the fourth time I've done it, it's definitely achieved that status!

This year is a little different because the community created the whole page while Marius enjoyed a vacation. That's the sign of a great project!

Get yourself a great deal before they end, and happy thanksgiving to those that celebrate it!

github.com

Adding DocC to an existing swift package

There are some great tips on using DocC in this article from Joseph Heck. Whether you've already started documenting your packages with it or still haven't checked it out yet, you'll learn something.

rhonabwy.com

Using Xcode Cloud

I finally got access to the Xcode Cloud beta about an hour ago, so there's no better time for me to read this article from Batikan Sosun, which goes through the basics of getting a project configured to work with the feature.

I'm looking forward to testing it out, but I remain sceptical about Xcode Cloud being broadly successful. I think there will be no better CI/CD system if you have an app that uses only first-party tools and only wants artefacts to go through TestFlight or the App Store, but that as soon as you stray too far from that happy path, it seems like it might run out of steam. I fear that the number of companies able to use it will be pretty small. I'm interested in testing it for myself, though!

devgenius.io

Developing a SharePlay Game

It's been about a month since SharePlay launched, and since I asked if anyone had experience working with it. I'm delighted to say that Greg Gardner accepted that challenge and has put together a fascinating article about his experience implementing it in his latest App Store game. Fascinating, and as I expected, full of challenges!

wordpress.com

How do Swift actors work, and what kinds of problems do they solve?

I enjoyed this look at actors from John Sundell. It takes a real-world situation where an actor would be helpful, demonstrates the problem, provides a solution, and then reminds us that they are not a panacea! Great article.

swiftbysundell.com

Web API Client in Swift

I love this well written and thorough guide to one of the most common tasks when building an iOS app: Interacting with a web API. Alex Grebenyuk uses the GitHub API as an example and makes a modern, async/await enabled API client.

kean.blog

Detecting Broken Constraints in Swift

Ever wonder what's happening when your app tells you that your Auto Layout constraints are unable to be satisfied? Bruno Rocha takes his usual look behind the scenes to fill us in.

swiftrocks.com

Were unicode glyphs in source code a good idea?

I agree with Nick Lockwood on this.

twitter.com

Designing the Finder App Icon with Photoshop

Michael Flarup knows a thing or two about icons, so when he records a video re-creating the Finder icon in Photoshop in ten minutes, it's worth watching. OK? OK. 😂

youtube.com

Software Engineer @ Runway – We're a team of former mobile engineers, now building a tool that makes mobile teams' lives better. If you're up for changing stacks to build the future of mobile tooling, working closely with awesome mobile teams across the industry in the process, you'll fit right in! – Remote (within US or European timezones)

iOS Mobile Core Engineer @ FAIRTIQ – FAIRTIQ offers a great company culture, and you get the chance to work on the core product and have a real impact. Your co-workers are smart and fun too! And we offer flexible working hours and remote work in the countries where we are based. – Remote (within European timezones)

Lead iOS Developer @ Loop – We believe there are accessible, impactful mental health solutions outside of therapy & medication. We are building just that, starting with a focus on Social Anxiety, a condition with no dedicated solutions impacting some 25 million adults in the US. – Remote (Anywhere)

iOS Engineer @ sengaro GmbH – We offer an exciting position in the heart of the Alps (Innsbruck) with technical responsibility and conceptual refinements of our long-term products. They are used in the medical field by paramedics and doctors to help saving lives every day. Become part of it and support people in emergencies! – On-site (Austria) with some remote work (within European timezones)

iOS SDK Developer @ Stream – You will write and maintain our open-source SDKs that are used by hundreds of our customers and consumed by hundreds of millions of their users. – Remote (within US timezones)

iOS Developer @ Kiva Microfunds – Our organization combines the culture and technological passion of an internet start-up with the compassion and empathy of a non-profit to create impact and opportunity at a global scale. Our team is growing as we pursue exciting new opportunities to create a financially inclusive world. – On-site (United States) with some remote work (within US timezones)

Senior iOS Developer @ Komoot – We love Tech. We love Nature. We work hard to make it easy for everyone to explore the world’s most beautiful places. Today, millions of people explore nature with our apps. Their experiences are what drive us and make us smile every day. – Remote (within European timezones)

iOS Engineer @ Fjorden – We are a small team and you would be our first iOS engineer, next to Florian our CTO. Together we will build & ship our camera app (around 60% done today), and design an SDK other camera apps can integrate to take full advantage of the Fjorden grip. – Remote (within European timezones)

iOS Engineer @ Branch – Branch is on a mission to help working Americans grow financially. We do this by helping companies accelerate payments and empower working Americans with accessible, fee-free financial services. We’re committed to building and delivering more inclusive and transparent financial products. – Remote (within US timezones)

Senior iOS Engineer @ onX – Are you an iOS developer who loves the outdoors? Join onX! If you’re passionate about writing great software, love playing outside, and believe in protecting access to public lands – then join our team, where we empower millions of outdoor enthusiasts to explore the unknown! – Remote (within US timezones)

Are you hiring? Let's keep this simple. You should post your job for free over at iOS Dev Jobs.

What if you didn’t need a realrubber duck to explain your problems to? 🦆