The Plugin Market: An Open Letter to Apple

Hi Apple,

Today I’d like to propose a change to your revenue model:

Build a "Plugin Market" to sell external app extensions (also called Plugins).

Developers should be able to build "Extensible" apps and capitalize by selling "Plugins" (like Wordpress).

These "Plugins" should be able to dynamically (and drastically) change existing functionality.

This has been possible on the web for ages, and I feel it’s time to fully support Plugin Oriented Design (POD) on mobile.

The Problem

Imagine I build an "extensible" native app and sell "Plugins" using an in-app store. I take a cut of the profits, and so do the Plugin developers.

Today, I'd expect this app to be rejected as per sec. 3.3.2 of the Apple Developer Agreement:

Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS. - https://developer.apple.com/terms/

I’d certainly be in violation of (b), possibly (a), and perhaps (c), depending on the implementation. Let’s focus on (a) and (b):

I'm sure you (Apple) like getting paid for "Apps" in your store. You take a cut of the sale, and it’s a big part of your revenue. So, if everyone started selling there own "Plugins", you'd lose money.

All those “Plugins” might have otherwise been registered as new “Apps”. Each of which comes with a set of developers paying for Apple Developer accounts. All that revenue would be re-directed to the App / Plugin developers.. which you (understandably) want a cut of.

So... as much as you want to allow innovation and extension on your platform, you're concerned about losing control and money.

Current Solution

I could build a web-app... but I won't get your nice native features.

I understand you're getting pressure from competitors to close the gap between web and native, but that’s a problem for another day.

For now, let's say I really want the newest native features and my app in your "App Store".

We could keep the iOS App clean of any store-like interface and have users buy / register plugins on the web, but I'm not sure you'd like that... I wouldn't be surprised if my app was rejected or removed.

So, how can we make this work for everyone?

Proposed Solution

You already have first-class support for OS extensions, but not iOS App Extensions.

Introduce first-class support for "iOS App Extensions" (Plugins).

Here are the benefits (edited after comments):

• Profit: This could be an untapped greenfield opportunity for mobile. Nested Plugins produce a natural, exponential fanout of charge points. Coupled with technical advantage and demand, this should increase revenue.
• Momentum: People are doing this anyways (think Expo). It only benefits you to capture this revenue instead of fighting it. It takes time and money to filter apps that break these terms. If you adapt these concepts, those resources can be repurposed.
• Employment: Look at all the jobs created from Wordpress alone. Now imagine extensibility as a commonplace feature of mobile / web systems.
• Competition: Your competitors are already adapting. Google Play supports dynamic feature delivery. I don't yet believe they support external developer injections or nested features. There's also dynamic module loading on the web. Plus, you're getting pressure from other players (like Google) to continue bridging native features (and vice versa).
• Innovation: The current agreement is technically limiting. By removing (or lessening) these restrictions, developers have more freedom to innovate.
• Low Cost: It should be possible to leave the existing deployment framework and retrofit support for Plugins. This could be an optional feature devs use. It's a low cost, high reward feature for you.
• Clarification: The current agreement leaves room for interpretation. Specifically part (a).
• Control: This gives you touch-points to assert control.
• Security: By limiting the set of APIs available to Plugins, they have a subset of the security profile of the base application.

Demand for extensive dynamic code interpretation is increasing. It may just be a matter of time before it's more advantageous to accept it than to fight it.

Implementation

Registration

Allow developers to register their Apps / Plugins as “Extensible”. Plugins should be able to extend both Apps and other Plugins. Have developers express which Apps / Plugins their Plugins can be installed into.

Require a Developer Account to register a Plugin, and take a cut of the profits from the sale (whether it be one-time, subscription, etc…)

Instead of "Plugins" you may also consider charging by "Feature", "Module", "Element", etc...

Start by getting the registration / billing in place, and then work on the technical tools.

Technical Tools

Start by helping with hosting and code-signing. Eventually, consider helpful tools to manage dependencies, check API impedance, custom rules, etc...

While you may eventually build a UI in the App Store (including nested Plugins), allow developers to build custom store-fronts conforming to your design standards.

Loosen Restrictions

Now that you're capturing the lost revenue, allow Plugins which are inconsistent with the original App intent. If classification is the issue, you can derive the classification data from the fanout of statically assigned Plugins. Consider support for dynamic assignment in the future.

Conclusion

The details can be sorted, but the idea is to convert a gray area of the License Agreement to a greenfield opportunity.

There are other issues to consider, like security, but given the language of the agreement, I tend to believe revenue loss is the biggest hindrance.

Thanks for reading, and I hope you'll re-consider first-class support for Extensible iOS Apps.

Also, thanks for building these cute metal boxes with all these bright little lights. They're pretty useful.

Cheers,
CR

I'm building a Plugin Market for the Web and React Native. For more, follow me on Github, Dev, Twitter, Reddit

Acknowledgments

Thanks to the Reddit users who responded to my recent post. This feedback helped identify these License Agreement concerns.

I'm just a random guy with some thoughts, and nothing in this post is meant to be construed as legal advice.