This might be too general a question, give that it probably depends on the app and what it is doing, but I’m wondering how one would go about building an app that also has plugins which can be installed to it at a later time.
For example, if you have a base version of an app, but want to offer a PRO version, or just generally have feature packs, folks should be able to download the base application then add the feature packs they are interested in.
Is this possible, and/or how difficult would it be? Is it completely dependent on the app in question, or is there a basic formula for setting something like this up?
Would love to know if there is an example or tutorial out there that walks through the basic steps.
Swapping plugins after installation would break the code signing.
You can certainly have an app that includes all the features and disable some of them based on preferences, licence keys and the like.
I handle this by using compiler directives to include or exclude the actual code at compile time.
Upgrading from lite to pro is a question of installing a new app or exe, and using the relevant licence key.
Without that , it probably wouldn’t be hard to enable missing features by hacking the app.
(My demo version doesn’t actually hold the code that does ‘saving’ at all. No amount of hacking can turn the demo into a full version, but thats a problem as well as a benefit when you get a customer used to enabling all features just by typing in a key)
Helper apps can fill some of this need: You can detect the presence of a helper app and send it some data for working on, the retrieve the results afterwards.
feature packs could be something as simple as extra graphics or sounds, in which case dropping the new data files into the application support folder for your app may be all you need to do.
Like you say, a bit general for a specific response.
On OS X you’ll have to use the Application Support folder as modifying the contents of the Application package after code signing will break the code signature).
The easiest way (in theory) is to indeed have one code base and some checking code. Have everything included in the one application, but enable/disable functionality on their serial number or how many times they’ve purchased something.
If you’re targeting the App Store, you’ll want to look into In-App-Purchase as this the Apple approved way, alternatively in the App Store you can use constants to build a ‘lite’ or ‘pro’ version.
i.e.
#if app.isProVersion then
~
#endif
It’s possible and depending on your application design it could be really easy or really difficult. The easiest route is to build multiple versions of your application, but the easiest for the consumer is to use In-App-Purchase.
We’ve tackled both options with different products, but I can’t say that either one is better, although In-App-Purchase should the better option because you only have one copy of the application and enabled functionality when they purchase the options, Apple’s In-App-Purchase isn’t exactly the easiest thing to set-up or even test!
Thanks for the suggestions all. I found that article, Norm, but I wasn’t sure if it would still apply to the Xojo world. I never considered the In App Purchase option, but it sounds like the easiest route for what we’re looking at doing.
Once again, thanks to all for your suggestions and discussion. I’ve been lurking on the forums for a while, and I really enjoy most of the discussions that are happening, even if I don’t have anything meaningful to add on my own yet.