Hi. Just recently (2 weeks) started out with Ionic and I must say that things are really great using this framework.
I am looking for some idea on how to create two versions of my application (a free and a paid one).
Free app would have limited amount of data it can access. Also, I would just have to state on the about page what the limits are for the free app and a link to the paid version.
For the paid app, I would allow full access.
I know it is not a good idea to maintain two separate projects, but what would you suggest to be the best course of action to tackle this.
Any tips, suggestions and relevant link/topics related to this question would be highly appreciated.
Hmm, maybe @gylippus would be able to shed some light on this.
i would try build the app modular as possible. maybe you can separate the premium code parts from the free parts.
Maybe you only need to manage some services twice. (so all necessary configs are done in services and so on).
After that --> create a build script, which can build both kinds of apps (only switching the services … like default the free version serviceName.js and premium serviceNamePremium.js --> the build script renames serviceNamePremium in serviceName)
You can have one app that runs a authentication service. Then if its an entire view that requires payment run the service in the resolve of the state that will redirect the user to another page. And if its certain functionality in a view then run the service again before completing the function. I would have multiple pop ups prompting the user why they cannot do something or navigate some where. Doing it this way mean you have one set of code, and you dont need to fork it,
This is what initially came to mind. I will try to implement this and see how things goes.
1 Like
would be nice to here form your progress… upcoming problems and so on
I’ve had some experience with this before. What I’ve done is went down the config approach. The application uses the same code base, means it’s easier to maintain and you aren’t building 2 applications.
Building your application in modules as suggested by @bengtler will help dramatically. Modules which are premium should only feature within the application when a constant is injected into the module, using https://www.npmjs.com/package/gulp-ng-constant will help you manage the config as a json file and inject it into your modules as a constant.
Where you have references, links, menu items etc for premium features you should perform a resolve or check to determine if the constant is available to allow it through.
If you are progressively enhancing a module based on it having premium features the same can apply.
If you are using a web services which restricts data endpoints your constant can contain the config for these services and can be consumed either as a provider in the .config block or when you init the service.
1 Like
I think this is overkill for this sort of thing. One service can handle it all. K.I.S.S
Depends entirely on how complex the application is, I would rather the user not be redirected elsewhere. It’s poor UX.
If a feature isn’t available for free it shouldn’t be shown to the user, end of. Regardless of whether they are taken to a payment screen. There’s cleaner ways of doing it.
It’s merely a suggestion take from the experience I’ve had and how we solved the problem.
It’s worth pointing out that instead of your service I’m suggesting a constant value that can be injected instead of the service.
Think they are pretty similar, I’m just advocating for hiding the premium functionality at build and runtime.
1 Like
Yeah, we currently have two separate apps for our Lite and Pro versions. Only because of a legacy code base, but those two apps are still in separate repos. I normally focus all of my attention on the full access version and then when I know it is ready I compare my changes to the last release and start the copy/paste process into the restricted version. The original reason for two was mainly because of Xcode settings, bundle names, and all of the other native things.
In hindsight, there would not have been two separate apps, but instead utilize in-app purchasing.
@davidfrahm recently created a few new apps using a single code base which utilize Cordova Hooks instead to go through and update that sort of information per build. This would be my recommendation having seen both options. You could include some global build variables which are then used in your JS to determine which version it is and provide logic to have different options available or unavailable.
Cordova Hooks Guide: http://cordova.apache.org/docs/en/edge/guide_appdev_hooks_index.md.html
@gylippus Do you put a market link in your free app to point to paid app ? How would you let the user that uses your free app, notify that a paid app is available to install ?