Issue 469

14^th August 2020

Written by Dave Verwer

Comment

There’s no other way to describe what happened yesterday other than to say that Epic declared war on Apple. They pushed very specific buttons, with full knowledge of what would happen, and they carefully choreographed their video and lawsuit response for maximum impact.

I had planned to write about the App Store this week anyway, but last night’s shenanigans cemented it. I was going to write on this topic because of all the other high profile App Store related events recently. The antitrust investigation, the congressional hearing, Microsoft backing away from xCloud on iOS, and … the list goes on.

I’m not going to talk about any of those events though. Instead, I’m going to step back and give some thoughts on the fundamental problem which Apple has with the App Store guidelines and revenue model.

Back when Phil Schiller defended the “Hey.com” decision, he was widely criticised for his “have not contributed any revenue to the App Store over the last eight years” line. He was right to face criticism for saying it too. That statement was the wrong place to say it, but the point he was trying to make was valid.

In my opinion, we should all be paying something for the value we derive from such a well trusted and easy to use App Store. It’s the flat percentage based revenue model brings that brings so many problems though. Those issues so often end in awkward workarounds from companies trying to avoid the fee. That then leads to more rules from Apple trying to force their hand. It’s a mess. Worse, Apple still receives no revenue from the largest of companies who are (sometimes indirectly) making the most money from the App Store. Then, on the other end of the market, the smaller, developers who play by the letter of the rules effectively subsidise the big companies. It makes no sense.

I’m not going to attempt to determine how much Apple deserve to be able to take for running the App Store, but it’s certainly not nothing. What they created was revolutionary, and they deserve to earn money from it, not just cover their costs.

What’s clear to me is that what might have been a reasonable crack at a revenue model in 2008, does not work in 2020 and I think Apple need give both the guidelines and business model a thorough overhaul. However, what that overhaul might look like is far from clear to me. This is a more complex problem than you or I will ever have to deal with, and I do not envy the people responsible for it.

I wouldn’t hold your breath for any kind of changes quickly (even if it’s forced by legal action, changes take time) but I do hope that there’s a re-think in the works.

Dave Verwer

Sponsored Link

With Orka and MacStadium, moving your Mac build infrastructure to the cloud is just as easy and powerful as using AWS or GCP. Orka brings simplicity and scalability to developers building for Apple devices. Spend less time managing servers and more time building great apps. Give Orka a try for free.

News

An “App Store” for TestFlight? Airport itself is currently distributed via TestFlight, and what could possibly go wrong with that idea? 😅 When the inevitable happens, I suspect it might find a new home here. It’s beautifully designed and helps with a challenging part of app development, getting early adopters (I’m not going to call them testers, as that’s rare). Want more information? Here’s Jordan Singer, the creator with more details. Good luck Jordan!

This is worth your attention. We have seen hacked versions of Xcode before, but have we ever seen malware that targets an Xcode project? I’m not sure we have. It embeds a shell script inside an xcassets file inside a hidden directory in your project. The full report is worth a read, as well as this thread from Mark Villacampa.

Tools

This post from Ahmed Sulajman might look at first glance like a look at the standard features of simctl, but quickly turns into an adventure with dynamic libraries and method swizzling with Objective-C as the starring characters. I’m not sure how useful this technique is, but it’s a very interesting post.

Code

My money is still on Apple having some kind of persistence framework revamp in the works, but until then (if it even happens!) we still have Core Data. Here’s Donny Wals with a technique for abstracting Core Data persistence code so it fits better with SwiftUI.

Using GeometryReader can feel a little awkward, but knowing about it might get you out of a layout scrape, or two as you build your SwiftUI screens. Let Federico Zanetello give you a tour of what it can do.

I hadn’t heard of the farmers pattern before, and as Bram Huenaerts explains, you probably won’t have either since it’s something he made up! You should read about it though, there’s a great piece of advice in here.

I’m a big fan of crashing rather than coping with “this should be impossible” type situations in code, but my go-to has been to do the guard and preconditionFailure dance with a message rather than using a bang. After reading this piece from Wolf McNally however, I questioned whether it’s really any better.

Design

It’s common knowledge that too many fonts in design can be a bad thing, but a well-chosen pair of fonts can be a powerful combination. Which fonts go well together though, don’t just guess. Learn from Erik D. Kennedy instead.

Jobs

iOS Engineer @ Doximity – Doximity, the social network for doctors and healthcare workers, is hiring passionate iOS engineers (remote friendly!) with 5+ years of experience. You’ll get to be part of an amazing product team and work on an app that is used by over 70% of US doctors to help them deliver better patient care. Use your skills (Swift, Obj-C, FRP) to improve lives and make the world a better place. Apply today! – San Francisco CA, or Remote within the US

And finally...

This was @always @going @to @happen. 😂