How did Spotify ship that iOS payment app update so fast?
A judge ruled that Apple violated her previous order. The next day, Spotify shipped an update linking to their external purchase flow, among other things. But how did they do it so quickly?
On April 30th, a district judge ruled that Apple violated a 2021 injunction to loosen restrictions on alternative payment methods.
The next day, Spotify submitted a new release of their iOS app for consideration.
Once Apple approves our update, U.S. consumers:
Can finally see how much something costs in our app, including pricing details on subscriptions and information about promotions that will save money;
Can click a link to purchase the subscription of choice, upgrading from a Free account to one of our Premium plans;
Can seamlessly click the link and easily change Premium subscriptions from Individual to a Student, Duo, or Family plan;
Can use other payment options beyond just Apple’s payment system—we provide a wider range of options on our website; and
Going forward, this opens the door to other seamless buying opportunities that will directly benefit creators (think easy-to-purchase audiobooks)
First, let’s reflect on the absurdity of this. These were not allowed by Apple before a week ago. Spotify refused to use in-app purchases for their premium accounts. Accordingly, they could only show the text “You can’t upgrade to Premium in the app. We know, it’s not ideal” in addition to the name of your current plan. The user had to deduce that they should visit in a browser. They weren’t even allowed to say how much it cost! That’s egregious! I get a little angry just looking over Spotify’s list of what their app update does.
That’s all well and good.
However, I’m super curious about one facet of this news article: how did Spotify turn around their release in 24 hours? Corporations aren’t supposed to move quickly.
Let’s think about the naive option: that they wrote it from scratch in under 24 hours. It’s some links, it uses their pre-existing branding. How hard could it be?
But now let’s think about what would be necessary to get a project started and completed in a corporation:
A product manager specifies behavior and goals.
A designer produces a mockup or prototype of the change.
A separate branding person either produces or reviews the copy in the design.
A developer needs to implement the change.
The change needs to be “QA”d in a number of scenarios: large system fonts, other languages, etc.
Someone in the manager chain ensures that all of the resources are available.
Someone in Legal needs to review to make sure you stayed within the bounds of what the injunction permits.
Someone reaches out to the relevant backend teams to ensure that they have the capacity for you to deploy your change.
And then someone needs to actually build and deploy the change to Apple.
And don’t forget that everyone needs to be available and working at top speed. And note the fact that many of these steps must be done serially.
Is it possible that they were able to slash through the red tape and have one or two people crank out new screens of the app that required minimal testing, minimal legal review, and Just Worked with no problems? Sure, it’s possible. But it’s unlikely.
Okay, so that option is out. What about the next option: they are using React Native or Electron or something. What if they are simply able to remove all of their iOS-specific flags within the application code and push a new update to users after some testing?
This one is trivially easy to debunk if you look at open job listings for iOS engineers at Spotify. Here are three bullet points from a listing open at the time of this writing:
You know how to write readable, idiomatic, and maintainable Swift and are willing to follow already defined coding guidelines and workflows.
You are experienced with a variety of iOS frameworks.
You have a deep understanding of Cocoa design patterns and API design.
What does this mean? iOS engineers are expected to understand the iOS platform. And this means that they are writing their native applications from scratch instead of using a framework like React Native to produce the mobile apps1.
So that only leaves the final option, which is frankly the most impressive: they built this in anticipation that it would be used at the conclusion of the court battle, and they’ve been potentially maintaining it for years.
If so, this is an impressive amount of foresight for a corporation, especially a public one. The original injunction was issued three years ago. What would need to happen? Sometime between then and now, an executive mandated that this iOS paywall would be built. Between then and now, some team has been thanklessly cultivating this garden, just waiting for the moment that it would finally be ready to deploy.
It doesn’t cost that much to keep a feature on life support once it’s written. But it does cost some small amount of engineering effort! You’d expect that most pieces of the app are updated at least every few months, and some pieces would be updated multiple times a day. They were surely working in this area of the app, performing other work and maintenance. So they’ve been putting up with the annoyance for potentially years, all in exchange of being able to produce this update a week earlier than they would have otherwise.
It does appear that Spotify uses web views for their Desktop apps.