I want to create two separate apps (a “Lite” and “Pro” version of the same app) that will have predominantly the same codebase. The “Pro” app will simply have some additional features. What’s the best way to do this with Xojo? Do both apps need to contain the same code, but just have soft checks for whether it’s the Pro or Lite version, or is there something like a pragma that can prevent the “Pro” code from being a part of the Lite distribution?
The #pragma is a compile time check, so I don’t think that’s appropriate for this situation, but you can certainly set a Boolean blue at app start and then use conditionals to enable or sable parts of your code.
Is there something to prevent you from creating and compiling two separate versions? I mean you could do the Boolean thing, but that could lead to bugs and issues later on. With my games I always created two separate versions, and never had issues.
Otherwise you could just disable or only display certain menu options based on a Boolean check.
Definitely use the #pragma build conditionals. Separate versions causes consistency headaches.
Use a constant boolean for Pro, and #pragma build conditionals to enable features.
Anything soft can be hacked. Pragma will insure the Lite cannot be patched to become Pro.
It’s been a while since I worked on my pro version. As far as I remember I had problems with changing the bundle identifier in the build script. But at this time I was using Xojo2013.
Don’t understand. Read documentation on #Pragma, that did not make it any clearer.
Could someone show me of how you could use Pragma to make a Pro and a Lite version?
[quote=143632:@Jim Smith]Don’t understand. Read documentation on #Pragma, that did not make it any clearer.
Could someone show me of how you could use Pragma to make a Pro and a Lite version?[/quote]
A simple example:
#if App.FULL_VERSION // we check the boolean FULL_VERSION
// Full version code goes here
#else
// Limited demo code goes here.
#end ifOn compilation you change the FULL_VERSION boolean to True, to compile the full version, or to False to compile the demo version. The demo version will NOT have the full version code compiled, and vice versa.
Concur on the use of #if
In addition, use build scripting to automatically build 2 different versions.
(Optional) If the lite and full version are substantially different, you may want to use a text-based (version control) format : share the source code files, but have different project files for the two versions.
I did this for an app where the “Pro” version builds for both Mac and Windows, but the lite version was for the Mac App Store only. Enough differences that two separate project files was a good move.
Doesn’t this mean that he will then have two compiled versions of the application?
If that is the case, doesn’t prevent someone from easily upgrading from “lite” to “pro” without downloading and installing a new app? I suppose if that is the intent it would be okay but some might find that somewhat of an inconvenience, especially if he is business model is focused on getting people to easily upgrade to the “pro” version. Most software applications I have used that have varying feature sets simply do it with a licensing schema (including Xojo).
Am I missing something?
I believe what you are missing (unless I totally misunderstand) i
is the fact the with the suggested #PRAGMA
Anycode the is between a FALSE condition at compile time, is not included in the APP, and therefor cannot be hacked to become active.
Where if you used a simple boolean, its internal value could be hacked, because the full code for both condtions are included in the complied result
[quote=143648:@Dave S]I believe what you are missing (unless I totally misunderstand) i
is the fact the with the suggested #PRAGMA
Anycode the is between a FALSE condition at compile time, is not included in the APP, and therefor cannot be hacked to become active.
Where if you used a simple boolean, its internal value could be hacked, because the full code for both condtions are included in the complied result[/quote]
I agree this would definitely provide a defense against someone hacking it and converting it, but it would still require two compiled versions which would require someone who wanted to upgrade from lite to pro to download and install a new version, correct?
I guess it is a trade off, but I wouldn’t want my users to have to download and install a new version just to upgrade, but his business model might be different this might be perfectly acceptable to him.
How does Xojo do it? They have various features that are activated based on a users license level, which does not require a new download. This server based solution seems like a much better option from a user standpoint.
[quote=143651:@Joseph Evert]I agree this would definitely provide a defense against someone hacking it and converting it, but it would still require two compiled versions which would require someone who wanted to upgrade from lite to pro to download and install a new version, correct?
I guess it is a trade off, but I wouldn’t want my users to have to download and install a new version just to upgrade, but his business model might be different this might be perfectly acceptable to him.
How does Xojo do it? They have various features that are activated based on a users license level, which does not require a new download. This server based solution seems like a much better option from a user standpoint.[/quote]
Yes, Pragma will generate a different executable altogether, so upgrading to Pro would require downloading a new app. That said, a lot of apps today routinely do it for updates and nobody minds.
This has been discussed one thousand times : unlocking can be patched whatever the precautions by an adept hacker, and will eventually be no matter what. My personal point of view is that I will not lose sleep over that as long as sales are maintained to a profitable level. But I do not want to make it too easy for crooks and spandrels. So the minor inconvenience to download a new executable does not seem terrible, if that prevents the app to end up on torrent sites.
The Lite/Pro thing is not unlike the shareware model, and is a valid commercial system, though.
Agreed, I understand now. I just was thinking about it differently in that in all likelihood even with two compiled apps it will be the PRO version that ends up on the torrent sites instead of a “cracked” lite version converted to pro. Once the pro version is out in the world it will be the one that crooks steal and put on the torrent sites.
In the end he is going to require 100% of his users the inconvenience (small) of having to download a new version which in all likelihood have no real impact on the piracy of his product. But, of course that’s just my opinion.
I just wanted to make sure I understood what he was trying to do and the suggested solutions to see if I missed something I could use… Good info.
Quite honestly we looked at the previous successful hacks and figured out what we’d need to do to invalidate those.
So over the years we’ve changed license key systems.
And we’ve put in place code that was hard to follow when disassembled.
When hackers finally figured out how to get past it we put in place code that if bypassed renders the much of what hackers want useless. You can’t compile. So you HAVE to execute certain code to compile an app.
So far thats not been broken. But its by far the most ugly code and hardest to follow even in source code and in a disassembler its, and I think I quote Joe, “Horrendous”.
Its obtuse and extremely hard to follow in source and far far worse when all you have is the machine code.
But, one day someone may invest the time to hack that and if so then we have other things we can do.
Like I said - ongoing war of attrition until it just isn’t worth it for hackers.
(off topic)
I nearly thanked you for introducing me to another new word/insult (someone else enlightened me to “peon” this week), until I looked up
spandrel
Was that a misspelling or does it have another meaning?
[quote=143663:@David Wylie](off topic)
I nearly thanked you for introducing me to another new word (someone else enlightened me to “peon” this week), until I looked up
spandrel
Was that a misspelling or does it have another meaning?[/quote]
I meant scoundrel. But that was an interesting mistake 
Back to topic, the Lite vs Pro thing is just a very good scheme to bait with Lite and sell Pro. People who know about torrent sites are considered lost for any kind of business anyway. So the best hope is that the Lite version is spread as widely as possible to new users not yet rotten.
The best protection scheme will eventually get defeated anyway. So the most important, I feel, is to maintain the commercial momentum with new versions, an excellent service, and the best exposure possible. And not lose sleep over the thieves who will always steal your software. They are just like taxes. Inavoidable.
Wow, lots of good feedback in a short amount of time! Thanks to everyone!
In my case the Lite/Pro thing isn’t really a way of handling the trial vs registered thing. The “Lite” version is meant for home/personal use, while the “Pro” version will include features specific to use in enterprise environments (automation, faceless operation, etc). The Lite version is donationware, while the Pro version will be licensed. So the #if sounds like the right way to go.
How would I use build scripts to create the two different apps in one build, as Michael Diehr suggested? Would this be best done through IDE scripting, or through build automation?
We use the Lite/Pro thing on the App Store, so that the Lite basically becomes a ‘trial’ version (with limited features).
I have an app constant dictating which build the application is, then an IDE script that will set the bundle identifier, app name before it builds.
Then all I need to do is to switch the constant and build.
@Sam: can you post your script for changing the bundle identifier? I’ve had problems with this (the script did nothing).