Issue 418

23^rd August 2019

Written by Dave Verwer

Comment

For many years, filing a bug with Apple through Radar was a frustrating experience for external developers. It wasn’t even that the software was clunky, it was the process, and lack of meaningful communication that made it so infuriating. It was so bad that it’s a running joke in the community.

So when WWDC this year brought with it a brand new bug reporting tool, my hopes were high that it wasn’t just another new skin on Radar. It had brand new bug numbers, a completely different name, and new apps. It looked promising. Unfortunately it has become clear since June that Feedback Assistant is nothing fundamentally new, and that the processes behind it are just as broken as ever.

It was this tweet that made write about this today, although I could have picked from a huge number of other recent tweets like it. The specific point about being able to re-download attachments isn’t the main issue (in fact, it already seems to be fixed). It’s the process that I want to talk about.

The message that Apple sends to external developers about bug reporting is loud and clear. We know they want us to file bugs, and we know that it’s hard for a problem to get any traction internally without a bug number. As developers, we understand that and ultimately we want to help. But the experience of filing bugs is so poor that even the most diligent of people have given up.

When was the last time you felt like a bug report you made was valued in the responses you received from that team at Apple? The reply in that thread is a particularly bad example, and I’m sure it was someone just having a bad day, but I can’t remember the last time a response to a Radar made me feel great about filing it.

If Apple care about this problem, and they definitely should, bug reporting software isn’t the problem. It will take organisational change.

What if that team were incentivised differently? What if it felt like they were on our side when we file a bug? We can’t advocate internally for our own bugs, but what if it felt like that team was doing that for us, and communicating with us about it? What if the responses from that team were friendly and encouraging, rather than cold and made of boilerplate?

Some aspects of the process will never be able to change of course. For example, it makes perfect sense that internal communication on bugs can’t be seen, and that we can’t see duplicates, or other people’s bugs. I’m also not saying that bugs reported externally should be prioritised over internal ones, it’s Apple’s software and they should set the priorities.

But if we felt that our feedback and bug reports were being treated with care and respect, I believe the positive effects in the developer community would be huge. Apple’s CSAT matters to them, what about some DSAT? 😀

Dave Verwer

Sponsored Link

Vettery is an online hiring marketplace that’s changing the way people hire and get hired. Ready for a bold career move? Make a free profile, name your salary, and connect with hiring managers from top employers today. Get Started.

Tools

Build utilities, written in pure Swift (not that that really matters for build utilities) from Khoa Pham. Obviously it’s not as comprehensive as something like fastlane, but this does look promising.

Whether you’re prepping your new library for release, or working on internal packages this tip from Keith Harrison is going to speed up your development process when working on a package in the context of an app.

Relive the glory days of Xcode 8 extensions with this really clever ligature hack from John Scott.

Code

Just imagine it… data flows in from the web, through a beautiful stream of cleanly described operations, ending up in a perfect table view on your user’s screen. They’ll never know the beauty of what just happened, but you will if you read this piece on DataTaskPublisher from Tibor Bödecs. 😀

Matt Gallagher had me hooked at the opening paragraph of this article:

I wrote some experiments around Combine, Apple’s reactive programming framerwork, to gain insight into how Combine handles edge cases that have caused problems for me in other reactive programming frameworks.

Even though this is just part one of a planned three part series, I couldn’t resist linking it this week. Go read it.

Kyle Bashour promises a comprehensive guide, and delivers more than that. Not only a guide, but sample code showing everything demonstrated. I really love the new context menus in iOS 13, so please go use this guide and put them everywhere! 👍

User facing error handling code is always hard to get right. Do you want to handle them silently, show a subtle message somewhere in your UI, or present a huge alert to stop users in their tracks? Once that decision gets made, how do you apply it consistently? That’s where this library from Stefan Renne comes in.

Design

I think this article published over on the official documentation site is really interesting for a couple of reasons. First, it shows how to adapt a symbol from the official font for use in your own app, and support multiple weights, just like the font itself does. But also, the fact that taking and adapting SF Symbol icons is at the core of this article is a great sign that this technique is not only allowed by Apple, but encouraged. This can only be a good thing.

There was also a new release of SF Symbols this week, with less icons listed in the “Symbols for Use As-Is” (specifically the icons for mail, phone and books) which is also great news! 🚀

Business and Marketing

Carissa Lintao with a great article on ethics in app development. Apparently 35% of developers have been asked to implement something they felt was unethical. That’s both shocking, and actually lower than I thought it would be! 😂 It’s worth reading the whole piece, it’s good.

Videos

Conference videos time! This set is from the Swift TO conference that happened just last week in Toronto! I saw plenty of tweets about it as it was happening, now it’s time to catch up with the content. 🚀

Jobs

iOS Engineer @ Karbon – Join our dedicated, all-remote agency and help us build amazing iOS apps for amazing clients. We’ve spent the past 10 years helping companies ship apps to millions of users—join us as we focus on the next 10 years. – Remote or Portland, OR

Senior iOS Developer @ Mindgrub – As a Senior iOS developer at Mindgrub, you will be given the opportunity to work with industry-leading professionals on a variety of native and cross-platform apps. The culture is collaborative, fast-paced, and fun. Apply today. – Baltimore, MD

iOS Developer @ Shape – If you are passionate about making state-of-the-art iOS apps, why not work together with some of the best designers and developers who share this passion? You will work together with other smart iOS developers in a fun and relaxed environment at our offices in Copenhagen. We also like to host social events, morning runs (and swims), Friday bars, board game nights, LEGO days and much more. – Copenhagen, Denmark

Swift Engineer @ WillowTree – At WillowTree, Swift Engineers have the freedom to create products people love. You’ll collaborate with a cross-disciplinary team to build large-scale products for well-known brands. We look for team members who advocate for software engineering best practices and inspire their team to continuously learn and improve. – Charlottesville, VA

iOS Developer Trainee Program @ The App Academy – Boost Your Career In Mobile Tech. Apply For The iOS Developer Trainee Program At The App Academy Now! – Amsterdam, NL

Last week, there was a big change to iOS Dev Jobs and as expected, there was a spike in the number of jobs being posted. Check out the full list of over 35 open positions.

And finally...

This may be unfamiliar to those of you outside the UK, but don’t worry. You’ll still find it both fascinating and hilarious in equal parts, especially when they cover entering the double height characters. 😂 I know France had a similar system, but did the US?