Apple DPLA Updates 6/4/18

Apple released an updated version of their Developer Program License Agreement “DPLA” last night (6/4/18). The most interesting changes are the ones that reflect what’s on the mind of Silicon Valley execs. Based on this latest DPLA, privacy is certainly front of mind for Apple’s leadership post-Cambridge Analytica, and a lot of the changes seem intended to create additional disclosure and protections around how end user data is used. Tim Cook doesn’t want to end up testifying in front of Elizabeth Warren.

• Apple placed a bunch of additional user protections in this latest draft, making it clear that any app that captures image, video, or audio needs to make it clear to the user that they’re capturing it. Whether it’s saved to the cloud or on the device. If you previously obtained consent to capture data and decide to expand what you capture, you will need to go back to the user for additional consent. Also, no more linking to your privacy policy; it needs to live in the App description.

• They also expanded the definition of Face Data. I suspect that we’ll see lots of tweaks to this language over time. Apple is likely still trying to figure out how to manage this data contractually since (i) we’re only at the very beginning of figuring out what facial recognition can do, and (ii) people get really touchy when you say you’re going to make a digital map of their grill

• There are additional clarifications and obligations regarding health records, location, and other categories of data that tend to be more sensitive.

Unrelated to privacy concerns, they’re pushing Apple Pay Cash – looks like Apple is trying to make a real business out of it. They’re also trying to maintain a fair and safe environment. No deceiving customers or unfairly competing with other developers. The management of competition between developers is interesting. Does that extend to the companies they represent? Is Apple in a position to manage the competitive landscape of industries. Probably not.

The “Apple-Tax”

The Apple App Store is the second largest app store globally, but for developers of apps in the United States, maybe the most important. The agreement that governs the App Store, Apple’s Developer Program License Agreement (or “DPLA”), is high-profile in it’s own right because of the way it impacts corporate decision-making, customer experiences, and the economics of the internet.

Of the nearly 100 pages worth of provisions that make up the DPLA, the only one that has gained public notoriety is the provision outlining the 30% share that Apple retains on any sale made in-app. The Google Play Store and other platforms have similar provisions, and these commissions should be a key strategic consideration. Will you simply sacrifice 30% as the cost of doing business with giants like Apple and Google? Do your margins allow it? Will you charge your customers 30% more for the convenience of purchasing through your app? Is there a demand for your product at that price? There’s no right or wrong answer to these questions, only what’s right for each app developer, CEO, or strategist.

In 2015 Spotify famously decided that it would charge its customers a premium for the convenience of being able to subscribe to its music streaming service on an Apple device. They were very open about it, going so far as to provide instructions on how to sign up at a lower price, or switch a more expensive subscription to a less expensive one. Generally it’s not a good idea to answer the question “how much does your service cost?” with, “it depends what device you buy it on,” but Spotify had already established a loyal fan base of millions, and could afford to muddy its marketing message a bit.

Spotify also has real costs. If you sell additional features in your dating app, or virtual currency in your game, the 30% commission probably won’t kill your business. If you sell subscriptions to a music service, and have to pay music labels for their artists’ most popular content, 30% might put your business underwater. An alternative to consider is building a companion website where your customers can transact and manage their accounts. While a companion website is great for avoiding the Apple tax, it adds a considerable amount of friction to any purchase flow. Attention spans are short, and if your slot machine gamer just spent his last virtual dollar and is jonesing for another pull, taking him out of your app to enter credit card information on a website will result in less money spent.

The moral of the story is to carefully consider your app’s user experience, margins, and brand loyalty before deciding whether to accept in-app purchases and pay the “Apple tax,” or not.

Screen shot 2018-06-03 at 7.39.55 PM