The biggest problem with subscription licensing something like this, where LiveCode will terminate your ability to sell already written software, is that it becomes a pyramid scheme with LiveCode at the top.
You must pay every year, even if you stop using LiveCode for development, simply because the software exists. If you stop, your customers lose access to the software they already paid you for: now you must also use a subscription model yourself, or hope you can expand your base endlessly.
If you talk to them, they can make exceptions. But, theyāve gone back on a lot of things in the past, so itās impossible to tell how long those exceptions will last, beyond having their word. And itās impossible to know that theyāll keep their own software current, so much of my experience with paying them has been waiting for an update, and not actually using the product.
If this works for your business model, great, I guess. But when you work for niche non-profits that believe in their cause, it becomes much more difficult. They are on budgets. They donāt want to sell at a high cost and their customers donāt have the money to pay the higher cost. None of this is stuff like HL7 engines or enterprise database software that gain important benefits from subscriptions (not like livecode can handle either of those).
So yea, I move software away from LiveCode. Itās far cheaper to pay me once to come up with a solution and build it, (and pay occasionally for a requested update) than it is to have a subscription.
But the end result of LiveCodeās subscription is that, while they say you own the software you build, in a practical sense, you donāt. And that makes any pricing they put out incredibly undesirable from the start.
iām trying to figure out what my companies are going to do. iām not sure if youāre saying that all of those are options that should be considered, or if you are saying that lc compares favorably to them.
right now, iām looking hard at dart + flutter (and considering xojo, of course).
My approach would be different views. You would have DesktopWindow, WebView, and MobileView in the same project, because they all have different needs. So all your GUI work would still need to be replicated, but your backend would be common.
However, this presents a challenge. What if you needed something like:
MainWindow
-> DesktopMainWindow As DesktopWindow
-> WebMainWindow As WebView
-> MobileMainView As MobileView
Butā¦ Xojo canāt do something like this. DesktopMainWindow can be either a MainWindow or DesktopWindow. It canāt be both. You could make MainWindow an interface, but thatās barely helpful in this case, because the goal is something common you can stick code into without duplicating it. Extension methods on the interface can help, but youād still have properties to deal with and those properties would need to be public. Plus, raising events would be impossible. To make this approach work, Xojo needs to allow anything in an interface, and/or implement Traits.
The alternative is responsive design, where some controls get hidden/moved/changed depending on view size. This presents other challenges, like making the designer not WYSIWYG since youād need controls off screen to be swapped in for various screen sizes. I think this would be a mess, especially since not all controls are available for all types, and even when they do, what they support is wildly different.
see @yogiyangās post, above. the pricing is changing. they just announced it, and it may well change, depending on feedback. i would imagine that they will also post a new pricing page, after they settle on what the model will be.
i have not messed with react native, but part of the pitch, for that framework, is that you can do most, or all, of the work with just one. can you? i donāt know.
Just be insanely careful. Xojo cost me years of progress by not fixing bugs promptly. Then Xojo killed off Web 1.0 with no upgrade path to Web 2.0. Thereās also the API 1.0 to 2.0 fiasco.
Those things might not ever happen again. Who knows though. If Geoff gets an idea, it could all happen again.
I used Xojo for shareware apps for decades and used FileMaker for database apps. FileMaker got greedy like LiveCode and jacked up the pricing, so I thought, Xojo rocked for my shareware, why not for database apps!
Except it was total nightmare. Now I use PPH/MySQLā¦
You can, but itās using web technologies to build and maintain those views. They may be native controls, but thereās no layout editor. Youāre still doing everything with web technologies.
It wouldnāt come close to helping. Itās part of the solution, but not all of it.
I would not try Livecode. Is that clear enough? It is far away from fair pricing. Selling apps for internal company use you pay a monthly fee per user and for store apps one small monthly fee and 5% of your app revenue. Not from interest. Building codenameone locally for mobile is for free. Javafx for desktop and java swing for desktop are free. Vaadinfor we apps is for free. You can buy services and components. But you donāt have to
Iām sure there are LOTS of options as to how it might be made to work
It could be that there IS no ācommon UIā
And thereās an App instance for desktop, console, web etc all in a single project with properties appropriate for each (much like today) and you CAN edit several āappsā in the same project
Iād suspect a lot of users would never have more than one target in a project and would work exactly like today
And those who do need to produce an iOS & Android app might have those two build targets in one project
Share common non-UI code and then UI is unique
sorry to say this but I use xojo for database apps (desktop and web) and it fully suits my needs. it took me some time to make my own framework and tools, but now I have all I need to quickly make almost any database appā¦
it might just be the kind of database software they are trying to make. Perhaps something handling several million requests would be painful?
The threading issues that keep getting brought up come to mind. Working with medical software in the past that didnāt handle threading, and even with thousands of records it would lock up and be borderline unusable. Itās not the kind of thing anyone would like to see today I think.
my listbox use caching, queries only the displayed rows, and I have databases with a few millions rows that display with no problem. I did this with desktop apps, not (now) with my web apps because I donāt need to.
the heart of the problem is to maje the sql query right to handle big amount of records, or it will get slow once the record number growsā¦
Iām quite good at finding workarouds so it helped me with xojo.
to say the least, I began my web apps with the rising of web 2, so there were more bugs than working things ā¦ the websdk is perfect to build the web objects the way you want.
Thatās likely the trick. Iām not willing to spend time looking for workarounds anymore after a bug is found. I did for a while, but it got to be too often. Stability is key.
so it helped me with xojo.