Decision to Migrate from LiveCode to PureBasic

Previously, I only used LiveCode Classic, but I purchased LiveCode Create. There’s an option to use LiveCode Classic. I’ve been using LiveCode for about three years; before that I used PureBasic and SpiderBasic. In the latest version, 1.dp8, you have to use the Create login, which appears to be a webview. I have to sign in with an email and password, whereas previously offline activation was possible. I tried to log in and kept failing. In my country, access to certain destinations is restricted, so I used a VPN—and then I was able to log in.

Then I tried making a simple app—a basic button that, when clicked, displays uuid(). There are three publish options: web, Windows, and Mac. I chose to build a Windows standalone. To my surprise, when I ran the standalone app there was outbound traffic to an AWS server IP. I checked this using TCPView. Before running the app, there’s a login form that asks for my LiveCode account email and password.

If I don’t use a VPN, the login dialog doesn’t appear—the app seems to freeze. I have to use a VPN. This tracking process only happens when using a standalone built with LiveCode Create. If I build a standalone with LiveCode Classic, the app runs as expected. But LiveCode Classic will end in 2027.

I assume this is what LiveCode calls tracking users to collect a 5% royalty on software sales. I object to this approach. I’ll keep using LiveCode, but the lighter Community version. However, I will gradually port all my software to PureBasic.

I’m going to move from LiveCode to PureBasic, because LiveCode charges 5%, while PureBasic is a one-time purchase. I’m happy to keep sending donations to PureBasic—an amount even greater than 10% of my software sales.

In my view, LiveCode’s decision to charge 5% is a mistake, and it involves adding some kind of tracking or telemetry. There are still many options for building cross-platform apps—Tauri, Flutter, and Electron. Even PureBasic can build modern UIs with a WebView while using very little RAM.

I’ve always disliked development platforms that use a royalty based pricing model.

Originally that’s why I liked Xojo, because a license was a flat-fee. But now that fee has gotten out of hand (read: too expensive)

You’re wise to seek out a community popular option like Purebasic (read: affordable).

Or go the extra mile and adopt a free language like Swift, Go, Java or .NET (read: free, but with a learning curve).

I can’t help but wonder if all these recent price hikes are driven by greed, or the fear of AI threatening the low-code solutions?

There’s a third option, desperation. Xojo has lost a lot of customers over the last 5 years and the way I see it is that the price increases are to help rake back some of what they’ve lost. Sadly I think it will go the other way and actually cause them to lose more customers.

10 Likes

oh, look, now notnil is a home for LC refugees, too.

welcome from a very, very longtime LC dev/fan/contributor

3 Likes

I emailed support to ask for confirmation about “phone-home” for all standalone apps. They said standalone apps built with LiveCode will “phone home” to check the license, and if you stop subscribing, your standalone app won’t work. This is really surprising. Time to switch to PureBasic… I hope LiveCode isn’t making the wrong decision.

4 Likes

LIvecode and Xojo are shooting themselves in the head with these insane licensing schemes/prices.

4 Likes

Thats like charging a homeowner each year for every nail in the house, because the carpenter licenced their hammer…

8 Likes

surprising? No. Not in their reality. That’s something I am not accepting anymore. The reason why for me Java is the right home: no license stress, no phonehome, no lock ins in the code. Code reliability since 3 decades. Think about another situation: Livecode dies. And then? The standalone will not run anymore while the license can not be accepted anymore cause the server is n’t there. No chance to get in a trap like this.

Yes, I am trapped in my IDE (IntelliJ). At least in the comfort and functionality. Cause I can switch. To Eclipse. To Netbeans. To VScode. And: If I am not paying subscription for my all products pack anymore I am allowed to use the last payed version for ever. Or the open Source version IntelliJCE.

The same problem will come up with Xojo. If they die you will be at the end of your Sourcecode. Okay, you could download your license file. But it is not always working. And a mixup between 2019 and 2024 makes always license troubles. Not a nice view in the future. At the end you may have no license anymore without the chance of renewing the license.

And so it is like all of this Software packges saled like this. You have only the chance to use it as long their license servers existing. And when your license dies you casn’t compile. With LC your app stops working. not even better.

2 Likes

Well, stopping apps running at clients computer is a way bigger issue than a price hike for Xojo!

I am sad hearing that livecode would do that.

Even FileMaker’s perpetual licenses run, even if you don’t pay maintenance.

6 Likes

Yes, that’s the point of being locked in a code cage. Better using XCode/Swift/SwiftUI, KotlinMultiplatform, Java. Locked In is the point of interest. Being locked into code of an entirely proprietary platform kills the ability of workng with your code.

And often this is happened. Not the first time that some companies are at their end of life. So it is the decision of the developer to choose the right platform.

And yes, LC and also Xojo suggesting they are low code or at least platforms easy to use. But they are not really. And yes, using Java is also not without problems. In CodenameOne or also in Vaadin you may find errors. But in many cases you can correct them in the source and do a pull request. Or somebody else finds it also. So you can correct the Bug and it’s running as it should.

You may not have this chances when using Xojo. Or LC. Or other solutions like that.

It is the same problem when using UI toolkits for C# which are not open source. Why? While the vendor can die. And your UI sourcecode dies with it. Exactly that is the problem.

1 Like

Making the dev tool stop working because your subscription slips is one thing, but to remotely kill any apps you made is sometimes else entirely. I can’t imagine that it goes down well with their community.

5 Likes

A built & deployed app does this ???
OMG !

2 Likes

I’m a solo developer, and freelancing is my main job. I don’t work for a company, and I’ve loved LiveCode since the RunRev days. I’m a loyal customer, although I’ve paused my Business subscription a few times because of my health issues.

I’ve built many libraries myself using LiveCode Builder (LCB) to create functions/APIs that don’t exist in LiveCode, and now I’ve been forced to leave LiveCode and continue developing LiveCode Community on my own.

LiveCode’s decision to raise prices is understandable. Asking for a 5% royalty is still acceptable, because developing software with a small team is very hard. I can accept all those changes—but making applications stop working after the subscription ends is another matter.

This is similar to the SaaS concept, and I dislike SaaS. Everything depends on the service provider. The development of LiveCode Create is also slow; “vibe coding” is moving faster. I’m worried about LiveCode’s long-term viability.

English isn’t my first language. I used ChatGPT to write this message, and this is an email to LiveCode Support. I might have misunderstood parts of their email.

Thank you, LiveCode, for helping me build many applications long before the no-code era, and now that the vibe-coding era has begun. I hope LiveCode can endure.

1 Like

wow :hushed_face: Brutal… Forcing your clients to keep giving you money or their apps stops working. Toxic programming environment to be working with. The overpriced subscription model of Xojo Inc. is bad, but this …

4 Likes

well to everybody, who is in contact with toxic bullshitters like LiveCode, Xojo, vmware powered by Broadcom, Microsoft er else here is a good old advice:

1 Like

If one has some applications out in the wild - and gets retired… ouch! That’s a no-go. FileMaker is much more reliable, with all its strengths and flaws!

(I personally stopped using FileMaker and moved away for several reasons. First to Xojo, now I’m on Xcode/Swift/UI;

3 Likes

If only on Apple devices that is in my eyes the best alternative and the best hardware functional couvering you can get. Only cross platform is not possible for example to Windows and Linux or Android.

1 Like

now you know why I objected loudly, and why I’m moving on.

the annual deploy cost per device was, in the case of an iPad (which we use extensively), more than the cost of replacing the iPad. Even 4D, which is expensive, does not charge those fees per year.

3 Likes

Looking on this I have a customer which has the same problem with LC. I am rewriting his Software and this “magic” will end up. Not only per divece fee, also the risk that a company wil maybe one day die or it will be sold and switched off. This scenario would also bring the same result: nothing would run anymore. Nobody can rely on a Software development system like this. But many are doing that.

1 Like

Similar with me FileMaker to Xojo to PHP due to corporate greed.

1 Like