What you need to know about recent Apple ecosystem changes
Recent announcements from Apple about app distribution and payments are subtle on the surface, but it’s worth reviewing the details to understand the real business implications. In case you missed the headlines, Apadmi co-founder and CTO Adam Fleming takes a closer look.
Last week Apple announced changes to a number of parts of their ecosystem around iOS products which are now necessary under the EU Digital Markets Act (DMA). These changes are due to come into force in March 2024 with the 17.4 update to iOS (which is currently in Beta).
These changes affect iOS, Safari, the App Store - and the business conditions under which app developers create, market and sell apps for iOS devices. Of these, probably the most important are the changes in the terms of business.
It is critical to note, that these changes (currently) affect ONLY the EU - so not the UK (yet). Also, “developers” can CHOOSE whether to stay with the current terms of business.
iOS SDK changes
Alternative App Marketplaces for distribution
Frameworks for building Alternative App Marketplaces
Frameworks to allow for alternative web engines to be used within Apps
Interoperability Request Forum - allowing developers to request access to functionality that is not available through the published SDK
Notably, these will apply whether an alternative App Store is used or not.
Notarisation for iOS apps — A baseline review that applies to all apps, regardless of their distribution channel, focused on platform integrity and protecting users. Notarisation involves a combination of automated checks and human review.
App installation sheets — These use information from the notarisation process to provide at-a-glance descriptions of apps and their functionality before download, including the developer, screenshots, and other essential information.
Authorisation for marketplace developers — to ensure marketplace developers commit to ongoing requirements which help to protect users and developers.
Additional malware protections — to prevent iOS apps from launching if they’re found to contain malware after being installed to a user’s device.
New options to use external payment providers within the App-Store
Ability to “link out” for payment flows in external 3rd parties
Additional review and information processes for apps
Optional New Terms of Business
A new set of terms of business with the following implications:
Reduction in the commission paid to Apple for fees collected for download and 2nd year+ subscriptions - to 10% (up to 30% currently) and 17% of fees collected for “digital goods and services” - in app-purchases.
Use of the Apple payment services has a 3% transaction charge applied, but apps can use alternative payment providers if preferred.
A core technology fee of €0.50 per user over 1,000,000. This fee is applied annually and is levied per-user at the point of first download in any 12 month window. (There’s some fine-print, but basically for an app which is regularly updated and where the majority of users accept updates at least annually - it amounts to a rolling 12 month fee split across when users download).
These new terms are optional at this point, and developers can opt to stay on their current terms if they do not need to support external payment providers or alternate app marketplaces.
Apple has provided a calculator here.
Alternative App Marketplaces
We have come across cases where clients have wanted either to explicitly set up their own app-store, or have wanted functionality which would be supported by setting up their own app-store - notably, restrictions on app distribution etc.
Similarly, this may have implications and/or advantages for white-labelled, or large suites of associated apps, for example restaurants or eatery chains. Equally, this would also potentially support restricted use apps for things like resorts and/or cruise ships.
On the surface, it looks like Alternative App Marketplaces might support these use-cases.
New App Development
It is not currently clear whether or not new apps will automatically fall under the new regulation, or whether the regulations are accepted at a developer level.
Assuming there is an option to choose, it will be necessary to model the potential costs/benefits and make a decision on whether or not the new regulations are advantageous or not.
Apps currently being shipped in the EU will need to make a decision whether or not to remain on the current terms or move to the new terms.
Obviously, this has significant implications for apps with large numbers of downloads, and/or transactions through the app-store.
The key factor here is that the new terms are entirely optional, and only affect EU app-stores - so clients can assess whether or not it is to their advantage to accept the new terms or not.
There is likely to be some additional development load involved in working with the additional safeguards being introduced by Apple, but where possible you should be able to fold these into standard development and ongoing support practices.
At present, the new terms apply only to the EU, but the UK is currently in the process of ratifying its own DMA. At the point where this becomes law, it is likely that Apple will roll the same measures out to the UK.
This is very much an emerging situation. The EU Regulatory bodies haven’t been universal in their acclaim for Apple’s solution to how they comply with the DMA, so it’s entirely possible that the details will change. It’s also interesting that the response from the developer community hasn’t been universally positive either. As you’d expect, there’s a lot of analysis and thinking going on at the moment. I’d be a little surprised if the measures as presented are exactly what ends up being implemented.
If you'd like to explore what these changes could mean for you, contact our mobile experts today.