DEV Community

loading...
Cover image for The Plugin Market:  An Open Letter to Apple 

The Plugin Market: An Open Letter to Apple 

codalreef profile image Oranda Updated on ・5 min read

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.

Discussion (2)

pic
Editor guide
Collapse
ben profile image
Ben Halpern

This is a cool idea, and also seems like one of those things that would only be rolled out if the iPhone's overall usability was improved. I.e. the home page modules seem like they are in this camp, but I can't imagine this is a road Apple would go down just for the sake of the benefits you're laying out.

Collapse
codalreef profile image
Oranda Author • Edited

Thanks for the thoughts Ben.

I updated the "Proposed Solution" with additional incentive for Apple. If you could elaborate it may lead to fruitful discussion.

Here’s my 2 cents:

Plugin Oriented Design has shown itself useful in most other computing contexts, including Web Apps and Desktop Apps.

Web apps already support this. It’s one of those rare instances where a use-case is supported on the web, but not native.

With dynamic module loading (i.e. in React apps), we're already seeing interest applying these techniques at the user / feature level.

I agree that the benefits originally mentioned (mostly monetary opportunity) are unlikely to result in change alone. It needs to be more advantageous for them to change than it is not to.

Once users start to expect these features, I believe it’s just a matter of time before tech companies change their revenue model. Perhaps due to pressure from the web, other tech companies, user demands, lost revenue, or any number of other scenarios.

Even if I'm wrong about the details, there seems to be something going on here. If I were Apple (or Google, etc.) I'd at least start thinking about the future, how this all comes together, and where I want to be in that picture.