Pricing: downgrade macOS an alternative?

[ElZitouni]

Hello
I have coded several solutions for my research lab with the community version of live code, which was for free. The fact that it was free drove the decision to use it, but also because I had experience with HyperCard.

Since the company abandoned the community editions, pricing became more and more expensive, and just now I realized that the current cheapest option is around 400 USD, which gives me access for only one year, although the compiled stacks will continue to work beyond that.

It is painful to pay that price simply because I have to only recompile existing stacks because the standalone broke with a macOS upgrade, and then not use the IDE anymore because after all these years of debugging, my software is basically sufficiently bug free that it runs without issues.

I am now considering my options. For some computers in my lab, it is not important that they run the latest macOS — I thought to maybe downgrade to an macOS that ran the latest community edition of liveCode.

I have some questions:
1. What OS version would that be? And what would be the latest community edition of liveCode?
2. Is the company that produces LiveCode at risk of bankruptcy? And if so, what are your plans to deal with such an event?
3. I started porting one of my liveCode solutions to SwiftUI. It is not that straightforward, but after some struggling, I am getting there. ChatGPT is very helpful as it knows SwiftUI and can produce code examples and partial solutions, but also it seems to have an idea of LiveCode, which helps with porting. Anybody else on that journey? What are your recommendations/thoughts?

Cheers,
ElZitouni.

[stam]

Hi ElZitouni,
To answer your questions:
1. The latest community version was 9.6.3 and that has been taken up by an opensource developer who has kept it going. You can google for this.

2. No one knows the financials of the company (only they do) and it's not appropriate to discuss in an open forum - my impression is that they are not currently at risk, but who knows. There is always that opensource effort if the world caves in.

3. From your complaining about cost: As you obviously found out, other languages are much more work - that is why we use LiveCode.
But: There Is No Such Thing As A Free Lunch.


I was curious so I rechecked the pricing page - to my surprise things have changed (a bit) for the better. The starter plan is gone and seems to have been replaced with the student plan (aimed at students in higher eduction); you get 1 platform on purchase and if you prove you're a student you get all 7. The surprise now is that the standalones do not expire when the subscription lapses, making this a low-cost and feasible, if limited, alternative.

This means you have some options
1. For the cost of 3 Starbucks coffees/month: Use the student plan at £11/month (~ £132/year). For students in higher education (which sounds like may be your case) you can get access to all 7 platforms with this, otherwise it's limited to 1 platform. Standalones do not now expire when sub lapses.

2. Subscribe to standard edition - unfortunately the website is changed and not providing pricing for standard edition anymore - apparently you have to fill in a form which I can't be bothered to do. But what you say sounds about right, at least of the recent prices I had seen (about $400). It may be less now.

3. If you truly can't afford the price of 3 Starbucks coffees/month: Use the opensourced version of 9.6.3 - either the community version or the ongoing opensourced effort that is now under a slightly different name but runs in modern OS's I think .


General comments
Personally, I do not think it's reasonable to expect a software business to spend £££ to create an excellent product and expect them to absorb all the cost so you can have a free lunch - if all users insisted on this the company wouldn't be viable. They're not a charity, or a loss-leader for a massive corporation; they are a business and have employees to pay.

It is therefore a little bit ironic that in the same breath you
a) express concern that the company may go bankrupt and
b) complain that you cannot get their one product for free
This is the cognitive dissonance i find puzzling... but is not an uncommon sentiment here.

I can code in other languages - and to be clear, there are nice alternatives like Swift, but I don't have the time to build apps I need or for use in my department with these. Both learning curve and development time are vastly longer in any language compared to LiveCode.

So I'm more than happy to support a reasonably priced product, if it makes me productive
(my only issue is the definition of reasonable price)
The equation is simple:
If you don't want to waste your time by saving money then save your time by spending money.

Or I guess in LiveCode:

Code: Select all

if the cost of time > the cost of money then
   subscribe
else if the cost of money > the cost of time then
   if wantToStickWithXTalk = true then
      use community 9.6.3 or use opensourced product
   else
      learn a "free" language and pay in time
   end if
end if

Joking aside, only you alone can decide which is more valuable to you but pay in some way you will...

[ElZitouni]

Thank you for these thoughts.

To be clear -- yes, for **students** and those teaching programming, the pricing is reasonable. For hobbyists or NGOs, I doubt that they will readily shell out 400 USD to continue using this for one year or simply to recompile existing solutions. I doubt that this group is LiveCode's target market to keep a sustainable business model. I am not an economist, just a neuroscientists using LiveCode in my non-profit lab to produce knowledge that will be freely available to everybody (without requiring a subscription and thus LESS than the cost of a Starbucks coffee) and my work is financed by the tax payer. If I could subscribe monthly, I would have done that, even if that would be at a much higher cost than the yearly subscription (e.g., 100 USD for a month would be totally fine). I think they may potentially loosing money, and the pricing is now more obscure than before because you have to ask them for a quote.

Also, I think that Starbucks is obscenely overpriced and I don't understand why someone would pay that kind of money for that kind of product. But that is up to you of course how your spend your disposable income. Maybe Starbucks is not the best analogy.

I also would like to point out to those who are interested that while SwiftUI is difficult in the beginning, it has a lot of advantages and once you get your head around the idea that you describe the user interface instead of "draw" it by hand, it is actually a very elegant solution. I also like a lot that you can bind variables to interface elements such that when you change the variable, the associated interface element updates automatically. I am currently porting one application I wrote with LiveCode to SwiftUI and am impressed how little coding the interface needs in the end.

the LIveCode company should do what they feel is right to best support their continued existence. I understand not enough about the market to criticize their decisions. I have to think how to best spend the available funds I have, and even though I could afford the Starbucks prices, I wouldn't buy their coffee because to me that is wasted money as there are other, better and cheaper options available. Or equally priced but better coffees. I wish LiveCode the best of futures; yet I am not sure whether they are doing themselves favours with their new pricing models.

[stam]

Absolutely agree - Swift / SwiftUI are wonderful in their own right. if I had the time (and didn't need cross-platform solutions), I would really delve a lot more into these. And if the point is learning computer science then it's a great choice.
If the point is build apps quickly then LiveCode will usually be much better and much less of a headache.

Your frivolous fascination with my Starbucks example aside, cost is key issue here:
If you find it 'unfair' that a company changes money for a product that makes your life easier, then there are free solutions.
Some choices can involve older community versions or the more modern opensource effort to maintain the community version.

Other choices are to switch to a new language - be it Swift, C#, Flutter and so on, but these will invariably be much more time-consuming.
For crossplatfrorm IDEs the ones that spring to mind are Flutter, J4X, XOJO and Qt, to name a few. Flutter and J4X are largely free (J4X will produce Windows, MacOS, iOS, Android and Linux binaries ,but it needs a Win OS for the IDE, but happy to run on virtualised OS - the only cost is a low cost 1-off fee for iOS). XOJO is not free but is probably a bit cheaper than LC although quite far behind on the Android front. Qt (C++) is free for opensource but incredibly more expensive for commercial apps.
Any of the above options comes with a long learning curve and much longer development cycles even if experienced.
And if you're looking to build a solid solution with complex language, you may need to consider cost of hiring an external developer as well.

Your comments on Starbucks are amusing, though I'm not quite sure how commenting on value for money of a Starbucks coffee advances your point of view (I mean other than commenting on coffee more generally, which we are not doing here). As a reminder, this was to put he cost of the student version in a practical context (which is far less than "$400 per year").

How about a 1 cinema ticket per month (in the UK that would be more expensive than £11 usually), or how about 2 large twix bars per week (comes to about £12/month in the UK). Or perhaps a Netflix subscription. Are these a more palatable choice of comparators?
Not quite sure how many more ways putting £11/month in practical terms is helpful to you.

if you really don't want to pay any money and/or if you want to use lower level languages, you have options - but the tradeoff is time.
You alone can judge what is more valuable to you.
Maybe your time is cheap, mine certainly isn't and there is never enough of it.



PS:
Finally, if you don't want to pay developers for their hard work bringing an IDE to you, don't want to use a non-xTalk language and don't want to use the old community versions:
Use Google or whatever search engine you believe in and search for "opensource" and "xTalk", since you obviously haven't taken the hint.

[ElZitouni]

I assume I did not express myself correctly. I have no problems with developers charging for their work at all — this point does not need further elaboration. As I said, this company should do what they see fit to stay afloat. I simply have the impression that adding some more options to what you can buy from them might get them more income. I am not ready yet to pay 400 USD for using it once to recompile something that was also heavily built with the community open source version that was crowd funded, but suddenly abandoned by this company. Luckily, searching around a bit I found a temporary fix for the Sonoma problem so I can continue to use the last open source release.

Sorry to say that whatever you listed there as alternative — this is not how I spend my money, so as comparators they are not working for me, but we do not need to get into another round of comparing something as useful as liveCode to frivolous companies and consumables. I do understand what you are trying to say, and I agree in principle with the view. In my present situation I made the choice to live with a temporary fix to continue my operation for the time being, and see how fast I can get into SwiftUI. Thanks to these new AI copilot systems, learning a new coding language became so much more simpler than it used to be, and I am quite pleased that within the last week I have made sufficient progress to continue porting one relatively simple data preprocessing app that I once wrote. So maybe for others here facing similar problems — SwiftUI + some coding AI is a valid option to try out (if macOS, iOS et al are you targets and you don’t care about life outside the Apple garden, which might be the case for hobbyists and niche developers, but of course not a viable option for people trying to make an income with their apps).

A perspective that might work: I have been using Adobe products for years, mostly InDesign, Illustrator. And then they were hiking their prices for the one year subscription even more, and I had enough of this nonsense. There are alternative companies with different business models, such as Affinity and I paid once, and am happy to pay again for a significant upgraded version. So instead of paying >400 USD for the pleasure to use Adobe, i paid around 150 USD for using the other product for as long as it works on the operating system. Sadly, that company has been bought now and I fear the new owner might go down the misguided path of subscription. Again, I don’t have problems paying for software, but I am not so happy to overpay.

I do not agree with your point that coding in LiveCode does not have a steep learning curve. While it is really easy to get going in LiveCode, much easier than Swift for absolute beginners, if you have experience with coding, this advantage is not so big compared to other languages. Also, I wrote some quite advanced applications with LiveCode and while it is true that the language offers truly impressive simplicity for certain tasks, I found, for example, coding a video-processing app quite difficult, as well as customised UI development. I found it also not that easy to learn how to efficiently use DataGrids. Here, I do not see differences with SwiftUI/Swift.

[stam]

Luckily, searching around a bit I found a temporary fix for the Sonoma problem so I can continue to use the last open source release.

Hopefully you came across the opensource project created to maintain 9.6.3 going forward.

I do not agree with your point that coding in LiveCode does not have a steep learning curve.

Well, we'll have to agree to disagree on that.
Learning liveCode vs learning Swift are two very different ballgames. Granted, if you're already experienced in other C-style languages it's not that hard to learn the very basics - but the API to learn is vastly larger and more complex that LC.

Swift is a much more capable language, and can do many things better than LC or things LC simply cannot do - but I'd have to disagree that development time is similar as well. The bits you can do with LC are very quick to code indeed. A head-to-head comparison of how quickly you could generate an app that is suited to LC (acknowledging that LC is not the right tool for everything) would be interesting.

Let's not even talk about the convenience like the 'each' keyword.
To sort lines of comma separate values by the last element is a 1-line affair in LC:

Code: Select all

sort lines of tText descending by last item of each

What is the shortest code you could produce in Swift to do this?

I use LC mainly for creating clinical decision making tools, various database-centric apps such as apps facilitating multidisciplinary meetings, data collection for multi centre trials, image processing, all with cloud database backends and with full set of authentication specific features (eg resetting passwords with OTP via email etc) and user friendly enough for my IT-troglodyte colleagues to use without a tutorial.
Creating a full polished app takes time but that's mainly because it needs polish if others are to use - the coding itself is very quick.
I am convinced it would have added literally years of development time to be as productive in Swift, since my only opportunity to write any code is usually late at night if I'm not on-call).

I found it also not that easy to learn how to efficiently use DataGrids. Here, I do not see differences with SwiftUI/Swift.

Erm.... no. I have to strongly disagree with that. DataGrids have an API that needs learning but having done that you have access to every single control in the IDE or homegrown to add in a column or row. UITableView and UICollectionView are not remotely as straightforward, flexible or easy to use.

Each to their own - I'm not suggesting Swift isn't the way to go for you. If it's the right tool for you, it's the right tool.
I am however responding to your comments: I disagree that Swift is a comparable to LC in terms of learning curve or development time, although it is a more capable (Apple-only) language.

Ultimately your issue is the cost - I would agree that the chosen price points are an obstacle to uptake, since LC occupies a weird space where the largest volume of potential users are those who would/could not not pay for these price points.

This is why I had previous brought up more user-friendly cost structures, like that of the Panorama DB: http://www.provue.com/#pricing
I think having something like this would be much more inviting for old users to rejoin and new users to test.
But I have no say obviously...

[ElZitouni]

Thanks for the Panorama DB link -- that is indeed a pricing model that I thought might work for LC, but maybe they calculated their expected returns and decided to do what they did.

I am impressed that you coded this cloud based solution with LC -- something I always thought about to do but in the end never did for my lab.

Your question about sorting lines made me curious, because I agree that the handling of items/strings/texts is very easy in LC.
But in SwiftUI, this seems to be also not a big problem: Here is a function that sorts the lines of a field

func sortLines() {
let lines = text.split(separator: "\n").map(String.init)
let sortedLines = lines.sorted()
text = sortedLines.joined(separator: "\n")

So that is not so bad, you need only one built in command.

I managed to use dataGrids in the end, but it was a struggle and they remain my least favourite aspect to code with LC.

[dunbarx]

Hi.

I managed to use dataGrids in the end, but it was a struggle and they remain my least favourite aspect to code with LC.

DataGrids are powerful and relatively complex. Have you experimented with the much simpler table field? Or perhaps the very nice and simple polyGrid?

And I could not help myself here:

func sortLines() {
let lines = text.split(separator: "\n").map(String.init)
let sortedLines = lines.sorted()
text = sortedLines.joined(separator: "\n")

So that is not so bad, you need only one built in command.

Still, you must admit that:

Code: Select all

sort lines of fld "yourField" by sortkey

is rather simpler.

Craig

[ElZitouni]

Yes, no contest with the one-liner sort command. But SwiftUI is pretty nice, i spent much less time setting up the interface elements with it than with life code. It is great at automatic layout of the UI elements. I do not doubt that LC is easier to start with, but for people knowing how to code, SwiftUI is really not a bad platform to invest into.

Never tried polyGrid — I’ll check it out, thanks for the tip.

[stam]

Agreed - dynamic layout is superior in Swift and is one thing I miss in LC.

The existing layout tools are almost OK but a bit buggy (often having to script it instead). There is a new external library (paid) called responsiveLayout and is very reminiscent of web design responsive layouts but currently I don't think this is usable, at least not the last time I tried this. Presumably this will get fixed at some point and will change the way we do things in LC and make perform on a par with something like Swift.
But I'll be honest - last time it tested it, it was not quite there.

As for grids, there are two new widgets:
The polyGrid which is a a table-style grid. Fast, elegant and easy to use, but only has a subset of data grid features.
Then there's the polyList which is more of a form-style grid but which can have multiple columns of forms. Again a subset of features of DG but the columns feature is the one thing DG doesnt' have.
These are both widgets rather than groups like the dataGrid and fully encapsulated.

I use these both prolifically and while the API can be a bit different from what one expects, they are good.

You can view all of the above and other new widgets here: https://livecode.com/tag/widgets/

[dunbarx]

Stam, ElZitouni:

I have never tried any of these gadgets. I do use CAD software, though, where one can manipulate and lay out objects pretty well. What does "dynamic (or automatic) layout" do? I assume one can take bunches of controls and, er, lay them out? What does it do that the "Align Controls" pane on the PI does not?

Craig

[ElZitouni]

What I mean by dynamic layouting is that when the UI changes in response to user interactions, such that new elements are added, or elements change in size, the UI layout, often in toto, needs to be changed. In LC, this requires often some nifty scripting, but in SwiftUI the framework does that for you. It has significant degrees of freedom, so in order to prevent that re-layouting results in an UI that is "ugly" or otherwise problematic, you have to give it often some limits. But in most cases the decisions taken by SwiftUI in such situations are quite good.

Here is an example:

Code: Select all

                    HStack{
                        Text("Processing:")
                        TextField("0/0", text: $myCurrentFileNumber)
                            .frame(width:40)
                            .padding(.trailing, 8)
                            .multilineTextAlignment(.trailing)
                        Spacer()
                    }

This tells SwiftUI to show the Text "Processing:", a TextField (can be edited by the user), and both should be next to each other (HStack). The Spacer() tells SwiftUI to push both controls as much to the left as possible. So you don't tell SwiftUI where exactly this should be located within the current displayed window, it decides that by itself.

This is faster than arranging these elements around with LC, and you don't have to worry if the window resizes -- they will always be rearranged according to the SwiftUI embedded "aesthetics"

[stam]

Yeah, this is more or less what the responsiveLayout library is meant to do.
It works at container level (ie group or card) and rearranges everything for you depending on rules you set - the main issue is that the options are many, cryptic and not documented, so making effective use of this difficult. It's mainly for resizing but adding controls to a group will affect them directly without extra work needed as I understand it.

It includes 'breakpoints' which is a term from webdesign - when resizing you want things to change, but at certain 'breakpoints' you want the layout rules to change drastically (for example reduce the number of columns to 1 if using on a phone, but multiple when using various size screens)

I imagine there is ongoing effort to improve any bugs with this, but without deeper documentation - or until an enthusiastic expert user posts a detailed guide, this will likely not be used by many - too much of this doesn't make immediate/intuitive sense and results can be... unsatisfactory.
I do plan to delve a bit more into this at some point, but simply not possible at present... but it is promising.

[PaulDaMacMan]

"more modern open-source effort to maintain the community version"
Eh... as someone familiar with the open source effort I thought I'd chime in since it's been proposed as an alternative here.

The free Open-Source fork has only minimally more compatible with newer OS (darkMode support efforts for example) than LC CE 9.6.3 had. There's no AppleSilicon version of the Open-Source engine yet, mobile device deployment is too out-of date for AppStore/PlayStore. There is a patch fix for the menu-crashing issues on MacOS Sonoma. Where it has mostly advanced is the IDE with bug-fixes, additional content (Widgets, Libraries, SVG Icon Glyphs, etc.). A lot of initial work that was done was in making 'un-branded', that work is done and recent efforts are now geared more towards moving forward with improvements. The Linux version engine has recently been recompiled too.

To sum up, if mobile app store deploy is not a concern for you, and you aren't worried about Native AppleSilicon support (though I've been told it runs well under Rosetta 2 ), then yeah that particular Open -source xTalk interpreter may be an viable option.

I just don't want anyone to have any unrealistic expectations. That open-source effort only has 2 to 3 hobbyists working on it in as free time allows, purely out of love for xTalk / xCard. There are few other open-source xTalk/xCard implementations around (and one or two other commercial ones too), but I would say none of those are as 'bare-metal' capable.

These days you could probably even write code in COBOL and compile is to WebAssembly so that it runs on virtually anything, and have ChatGPT AI write it for you hahah, so it's definitely an interesting time to look around at what's happening with coding languages.

For layouts LC also has that older 'Geometry Library', often times that's good enough for my auto-re-layout needs and it's just a few clicks in the property inspector to try out, no scripting required.

[PaulDaMacMan]

"more modern open-source effort to maintain the community version"
Eh... as someone familiar with the open source effort I thought I'd chime in since it's been proposed as an alternative here.

The free Open-Source fork has only minimally more compatible with newer OS (darkMode support efforts for example) than LC CE 9.6.3 had. There's no AppleSilicon version of the Open-Source engine yet, mobile device deployment is too out-of date for AppStore/PlayStore. There is a patch fix for the menu-crashing issues on MacOS Sonoma. Where it has mostly advanced is the IDE with bug-fixes, additional content (Widgets, Libraries, SVG Icon Glyphs, etc.). A lot of initial work that was done was in making 'un-branded', that work is done and recent efforts are now geared more towards moving forward with improvements. The Linux version engine has recently been recompiled too.

To sum up, if mobile app store deploy is not a concern for you, and you aren't worried about Native AppleSilicon support (though I've been told it runs well under Rosetta 2 ), then yeah that particular Open -source xTalk interpreter may be an viable option.

I just don't want anyone to have any unrealistic expectations. That open-source effort only has 2 to 3 hobbyists working on it in as free time allows, purely out of love for xTalk / xCard. There are few other open-source xTalk/xCard implementations around (and one or two other commercial ones too), but I would say none of those are as 'bare-metal' capable.

These days you could probably even write code in COBOL and compile is to WebAssembly so that it runs on virtually anything, and have ChatGPT AI write it for you hahah, so it's definitely an interesting time to look around at what's happening with coding languages.

For layouts LC also has that older 'Geometry Library', often times that's good enough for my auto-re-layout needs and it's just a few clicks in the property inspector to try out, no scripting required.