:: Plug-in Architecture in ios ::

Let me get this out of the way: I am not an App developer. I have a very basic working knowledge of the ios SDK, and am aware some of Apple’s unique/arbitrary policies for submission to the App Store. I have a question about App development though, and was wondering if anyone else had the same question, or was thinking along the same lines.

Is there any possibility of creating a Plug-in architecture in the current App Store framework? Most people would say definitely not. But, I can point to one example where a model already exists, the In-App purchase. In any number of Apps, you can use the in-app purchase to buy additional instrument samples, additional functionality (like multitrack recording for Amplitude) or additional effects, seen in any number of amp qnd effects modelling amps.

I realize that there would be innumerable hurdles, from proprietary knowledge to splitting App store revenue multiple ways, but, this should be a doable idea. Numerous Apps are created using Creative Commons frameworks. Sonoma and Intua both make their ACP SDK available to developers. What would be the restrictions from say, Moog licensing some of their App functionality to the developers at Multitrack DAW? I can think of numerous instances where I would spend $10 on a $5 App if it meant I had that functionality from within another App. And don’t say it can’t be done, I would point to the current crop of free Apps making a profit from in-app purchases. Maybe all it would take is the seeding of the idea, some communication, imagination, and most difficult, some cooperation. Put your heads together, great ideas often come from collaboration – see Wikipedia as a prime example.


1 Comment

Filed under Uncategorized

One response to “:: Plug-in Architecture in ios ::

  1. RichardL

    There are many barriers in place that prevent any sort of audio plug-in architecture on iOS.

    Apple specifically prohibits apps from installing code plug-ins.

    Specifically Apple does not allow apps to download, install and run code. And there is also no documented mechanism or API in the software development kit to dynamically load code modules, and apps are not allowed to use undocumented APIs.

    Additional functionality that is enabled through in-app purchase must be bundled in with the app as approved by Apple and distributed exclusively via the App Store. Thus when you enable a feature through in-app purchase you are just buying a license to use a feature that was already built into the app. A developer may only add new features (whether for in-app purchase or just for free upgrades) by updating the app and pushing that update out through the App Store review and distribution system.

    There is no inter-application communication system on iOS that would allow two or more simultaneously running apps to talk to one another. Nor would one be allow by the current rules. Plus Apple imposes restrictions on multi-tasking which would not allow such a system.

    The only system I can think of that would be allowed under the current rules and with the current tools would be to use some sort of networked audio streaming protocol to allow multiple iOS devices to send and/or receive audio signals between one another with each device performing an audio processing function.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s