Issue 390

Comment

You may have seen this Techcrunch article a few days ago on analytics frameworks that collect screen recordings as well regular event and usage data.

I'm generally not against analytics being collected in apps. The data can be really useful and I believe the vast majority of what gets collected does nothing to hurt end users. As developers, we can build better apps that are based on real data because of aggregated analytics.

But let me be clear, recording the screen of your users and allowing it to be watched goes way too far. I don't care if you hide a line in your privacy policy about it happening. I don't care if you "ask users to opt-in". I don't care if the screen recording masks passwords and other sensitive data. I don't care. That's way over the line in my opinion.

I've never talked about this before, but the only relevant sponsor who I've ever turned down for iOS Dev Weekly was a company focused on in-app screen recording analytics. It was a few years ago now and I had no idea this was even a thing at the time. I just couldn't believe that they were doing it and they were incredulous that I had a problem with it. It made me really angry. Looking at the client list on their site was shocking too. Your screen is almost certainly being recorded by some of the apps on your phone. I didn't want to support that, and I didn't take their money.

The irony is that in a past job I had, the company I worked for used one of these screen recording analytics tools and I was asked to look at the results as part of my job. I protested and made a case they they should remove it from their app, but I failed and as far as I know they continue to do it. The irony? To my annoyance, the data collected from that tool was incredibly useful, and I found at least one really hard to reproduce bug because I could watch it happen for a user. Even so, I never felt comfortable with it and was happy to put it behind me.

I originally wrote this comment yesterday and ended it with a call to action for anyone using this kind of technology. I called for you to remove it from your apps, if you were able to. Or for you to lobby for it to be removed, if you were not. However, last night Apple made a statement on the subject:

Our App Store Review Guidelines require that apps request explicit user consent and provide a clear visual indication when recording, logging, or otherwise making a record of user activity.

That's a fascinating statement. I'm incredibly happy to see the rules being tightened for screen recording, but does it also mean apps need to visually indicate when more traditional analytics data is also being collected? I hope it doesn't.

If apps start to show (for example) a red dot in the corner of the screen because they are talking to Google Analytics, I think most people are going to be comfortable with that. Once people are comfortable with it, they'll start to ignore it. Now, if that same app implements screen recording analytics and indicates it with the same red dot. They are perfectly following this new rule, but I think most people would not be OK with that. How do people know the difference? The statement as it stands has problems.

I'd actually love to get your opinions on all of this. If you've got 30 seconds I have just a couple of multiple choice questions for you. I'll report the results back here.

News

ABI Stability for Swift

This announcement post is worth reading if you're interested in the technical details, but for 99% of developers shipping to the App Store ABI stability will have no impact on the way you work. Your users will save some disk space but that's about it. All of that said, I'm not trying to downplay this milestone. It's a great step forward for the maturity of the language!

Oh and if you distribute a framework/library in binary form, this is huge news and you'll be able to finally start using Swift! 🎉

UPDATE Oops! 🙈 I made a mistake with my last comment about distributing libraries, read in the post about Module Stability for more information on this. Thanks to Fabian for pointing this out.

Swift 5 Exclusivity Enforcement

One change in Swift 5 that may have more impact on your code is this one. I'm not going to try and summarise this too much here because it's a complex subject and I wouldn't do it justice. But suffice to say that runtime exclusive memory access may require some code changes in your project, and may also slow your app's performance down a little.

Tools

DEPENDENCIES.md

I like this idea from Karol Mazur for adding a DEPENDENCIES.md file to your repository containing information on why each dependency was added. There's often lots of thought and discussion that goes into a specific dependency, so why not write it down? Also, if you're struggling to write something meaningful, it might make you consider whether you really need another library!

Project-Specific Command Line Shortcuts with direnv

I hadn't come across the direnv tool until I read this post by Joe Chrysler. It's an interesting idea, but the idea of the same command doing different things in different directories fills me with a reasonable amount of dread. 😂 I can see it being useful, but make sure you're very aware of what you're doing!

Speeding up your Swift tests

After last week's tip for speeding up unit tests, here's Paul Samuels with a potential way to reduce it further. After reading it, there's quite a few restrictions on the tests you can run but the technique of using Swift Package Manager to speed things up is still interesting.

Code

Swinject in practice

I was surprised to see that I had never linked to Swinject before, but I haven't! So let's fix that with this article from Pierre Felgines on how to get the most out of this dependency injection framework.

Using two-cased enums in place of a Boolean

I like this technique from Paul Hudson for replacing booleans. I've had a personal rule for the sake of code clarity with booleans for many years. Mine is that I never use the ! operator. It's too small and too easy to miss, but this technique is even clearer. It's the coding equivalent of using verbs instead of OK on buttons in your UI.

Progressive Core Data Migration

This is a comprehensive and well written look at the migration process for Core Data by William Boles. He covers everything from why you might want to disable automatic migrations, to why you need to care about Write-Ahead Logging. He also has a full example project that you can check out.

Withable

Ever want to make a copy of a struct, but also change a couple of properties as you do so? It's a common thing to do and I liked this technique from Nick Lockwood for solving the problem.

Design

The Design of Loopback 2

Last week we had the story of Agenda and this week it's the turn of Loopback to do a design retrospective. I always take away great tips from articles like this.

How Popular iOS Apps Have Changed in 10 Years

A fun post by Valia Havryliuk. I found myself surprised by how much some of these apps that I have used constantly since 2008 have actually changed. I guess incremental design changes over ten years add up!

Business and Marketing

Lyft Goes Swift

There is a very old, and very famous blog post from Joel Spolsky that states that the "single worst strategic mistake that any software company can make" is to rewrite an app from scratch.

I think iOS is a bit of a special snowflake when it comes to this rule though. When Apple dropped Swift on us, it was always going to mean disruption for app developers at some point. Do you stick it out with Objective-C and eventually get left behind? Do you struggle through the maintenance of a mixture of two languages? Or, do you bite the bullet and just sink the time into a rewrite/conversion? That's what Lyft did, and they seem to be doing OK! 👌

Up to Speed

Pattern Matching with case let

If you're just getting started with Swift, the pattern matching features of the language might have passed you by. Let Majid Jabrayilov bring you up to speed with this post.

And finally...

Can't Unsee

Half "spot the difference" game, half design challenge. I found myself just going with a gut feeling guess a couple of times when I couldn't actually see any differences.

Can you beat 7330 points? I think I did pretty well, but obviously not perfect!

Issue 390 February 8th 2019