Could Xojo come back to professional Level Development? Yes it could!

What can we do to bring Xojo back to PRO

The story behind it is simple: it wasn’t a genius but a good Salesman. And a nice product Vision which is showing that there was a fundamental goody for buying the product in history. And even today the Scene behind looks really good. Mobile, Web and desktop projects in one IDE and one Language are making the life easy.

Hence Xojo needs for Desktop, Web and mobile different UI Designs we need only to build the App once and the different UI Designs. Sad is that it is not possible to write a deep implemented Model-View separation which would help with the needed UI Logic which you always have but with this simple Model it would be able to write Applications with Xojo for this cases. Another way of building this up is to build a view abstraction means that there is inside of Xojo an abstraction which allows all of this job be done. Beside the needed Workarounds and the problems Xojo has with it’s technology there is a possibility for getting that Job done.

If they would take care that the Platform would not be in that desolate condition Xojo would still be a nice platform for Beginners,Citizen Developers and also valuable for semi-professional Developers like it was for long time before. The entire point is that the Company is still not able to fulfil that need. While that needs much more manpower and that needs a totally different release Model. it is not so that the Product itself is bad.

Man Power will help to reduce the problems

That shows up what is needed. Developers for the Xojo, inc and especially a CTO with the leader quality and the technical understanding and knowledge of programming. That can’t be somebody working now in the company while nobody now is able to fulfil that Job with the needed qualification. Sadly they don#t have the chance to change that fast. For that a few decisions from history are in charge. First of all: going away from a C++written IDE and second going away from an own Compiler to compile from LLVM intermediate Code.

And there is the Master question in this quiz: will that change? And there is my simple answer: no. Because the Company has no interest to change this environmental questions. And that has a simple foundation: they have a simple problem with the financial float. they need to get people as customers. New Customers which are starting to implement their Ideas as their next Software Project with Xojo.

Every company needs paying Customers also Xojo

if there is no new Customer and more and more Customers are not paying the Renewing there will be no chance for holding the company in the market. That is a simple calculation. The bigger question is: how we came to this point. And there we are at the Point Jeannot tried to describe with that what he said about the CEO of the Company. while he is not the technology Leader but a good marketing leader he decided simply not to be focussed on pro users but on citizens.

What is the Change? That is simply described. When focussing on pro users my Product needs to be reliable, sustainable, consistent and last but not least: long time api consistent. All of that was Xojo for a long time. In that times there was a focus on professional Software Developers. First on Mac, later also on windows. All of this is the result of blowing up the platforms and loosing in the same moment all important employees like for example the Compiler programmer. But with the years Xojo added more Platforms like IOS and Web. Also Android is in Beta already.

What could be a solution

That would need a massive Change in the Management strategy. First of all: the Release Cycle needs to be changed. Changes of a Release Cycle. The Release Cycle they use now is misleading the Development away from Bug Fixing. Fixing the Bugs would need to have one LTS Version. That could be - for example like it is with Microsoft Dotnet - for three years. Means every three years there is a new LTS Version. With a consistent API for at least three years.

Within the Development there can be always an unstable Version. That Version get`s changes and new Features. But new Features are not deprecating old ones to the next Version: they lead only to a deprecation Warning in the upcoming LTS Version and will end up in deprecation three years later. That makes it possible to have a consistent api on one Side and on the other one there would be the right way for long term development for professional users. The unstable one can be used even for production by citizen users if they want to. The LTS is the way for professional users. so Features and API’s having a life of at least 6 years. A Deprecation is warned long time in front, minimum three years before it will be deprecated in the on the deprecation warning following LTS Version.

Following to this Release Model there is always an LTS Version which is leading to a 6 years consistency. Deprecation Warning can only be done when the new replacing it already active. So new Features which are replacing old ones will have a long period until it is needed to use the new one.

Versioning for all tastes

Really new Features can be implemented every time but have to be in the Short time Supported Version. This one should have a Support Time of one year. So Xojo has only for Showstoppers to build up an Upgrade or even a Patch.

The next Part: coming back to an own true Compiler, a C++ tool chain. Works also cross platform but needs an Abstraction for UI building. Why? simple. While all of the OSses having own UI sets and this own UI sets are not working one like the other. So there has to be an abstraction which the Compiler can do. This abstraction makes it easy while you have your shared properties and abstract them to the native UI when compiling. So you can even have an Abstraction for Mobile and for Web. Look on JavaFX: it can do that. If they are able to do that, Xojo can also do that. And even more while working on it as an Abstraction for the native Desktop UI Toolkits.

Less stresses and Bugs

Since the Compiler would be available it can give us a modern Doe completion. that makes it simple to use any IDE Core, even the Open Source Core of Netbeans could be used for building Xojo Code. And yes, it is no problem to build that Code in a Xojo like IDE. And also no problem to build up a UI designer for all Platforms. That Xojo is able to do even now. Why should that be a problem? So we have a complete set of possibilities and a blazing fast code completion and we could use also the open Source Github Connectors (yes, they are also under MIT License so no problem).

When doing that we have to think about what we want: a native mobile framework for Android and IOS or a not native UI framework with nearly native look through CSS. Why I am asking that? because the first makes headaches. Even Kotlin Multi platform Mobile has not an abstracted UI Building. That is critical. CodenameOne has. And also that is: under MIT License. Yes, it is Java but also yes, it generates Xcode Projects which are native compiled. But this is only a decision we have to make. There is no mantra inside, we have this alternatives.

Cross Platform in best practices would be able with Xojo

So Desktop would be still Cross platform, mobile would be cross platform. And the nice part: when and if we have the View abstraction, we can build it for Kotlin Web. That would make the web application possible also. While the rest we have to do anyhow shows up the need to write a code transpiler. that would be the nice part using Kotlin. Beside the fact that we could even use the native IOS Xcode tool chain and Kotlin only for Android. What ever we do: we can not do anything wrong.

As I was already building a System like this I know: that is a big amount of work. many tasks have to be done. But it would be worth of it. While the Result would be a nice and new Xojo. Would I pay for it? I guess. While it would be a new perspective that Xojo can exist the next two decades.

Why I am thinking about? While it is always good when the makers getting some impulses for new solutions. They are not looking for alternatives and spending time to do framework changes without a target behind. That makes such incredible changes like msgbox is messagebox and then msgbox again but only in Desktop. In web it is still messagebox. I doubt that it was urgently needed to do. More important would be a strategy how Xojo should run in the next decades and not how it could be bug free. We can’t do that I would say.

Back to an own Compiler

One of the big goals of coming back to own compilers would be that we have a technology which we can form for the future. Nobody knows what will be with the LLVM tool chain within the next decades. But with an own compiler and not LLVM we would come to a fast and nice Story.

and while the UI would be still native AND the Compiler would be optimised we would not have all the problems we have now. And Bug fixing would be more easy. And yes: even the change to Apple Arm CPU would be nicer. While the Compiler is nice to port. With the LLVM Compiler we have always to hope that they will build up that target. If one day not anymore than there is not the next platform.

Would this cost a big amount more?

It is so that we would have to wait for new Features for a time. But for that price we would get also something: a Xojo with a better possibility of Bug Fixing and with a higher platform strength. Lie we all know: use Xojo for Linux and you can see what I mean. The performance decreases. Best Performance Xojo has on MacOS. For sure it is not the fault of Xojo, inc by the way. It is the fault of the LLVM tool chain. Therefore we would get a big amount of Speed on all platforms and a complete optimisation of the compiled code. Better.

Also we would get because of the UI abstraction a faster implementation of new UI systems like it was already needed by Apple MacOS. And also mobile Systems would be in a better environment. When deciding also IOS to compile with the tool chain of Kotlin MultiplatformMobile we would also get a complete abstraction of the Hardware layer of the OSses. So we could have less needs of declares which are anyhow a problem when programming for more than one platform. Everything would work from one project target. All needed side functionality would be builded up in one single tool chain. Except Desktop we would compile directly with the Kotlin compiler. That would make sense while we would have a top notch modern structure which is open source behind.

If we do all of this we can have a Xojo which is in a much better condition and which is able to fit also professional Developer needs. While the needed technology is behind with the Kotlin libraries and functions mobile and web are no problem anymore, even transpilations to Javascript are possible. And that would be the result of two years of work. Maybe three.

How can Xojo reach that?

They can reach that with stopping their policy of today, freezing the todays version as long term support version and starting to develop the new platform. That includes also languages changes and syntax changes, nothing should be forbidden, paradigms are not the most needed. To transpile that from old to new is the next thing they should / could do. And the result would be: for show stopping Bugs they do changes in the LTS Version but there NO NEW FEATURES. That reduces the amount of work for the LTS Version to a minimum. And within the time there can come an incubator Version which helps to optimise the technology behind.

When the new tech stack is ready they can release a prerelease. When it is one day stable and accepted then they can change this to the next LTS Version. And after that they would have never again the same problems and n top: the freedom for developing which feature they ever need. In the LTS they fix always Showstoppers and implementing no new functionality. But the Customer has a higher security that the Bug fixes for Showstoppers are coming (not like today) and that they would have immediately the security that they even know when they have to rewrite while a version goes out of Support.

The rapid Release model is exchanged to Rapid release with LTS

And the rapid Release model looses it’s dangerousness immediately while there is always a still maintained and security updated and running LTS. If this does not sound familiar: this concept is in the market for a long time. Made for Java. There is an LTS Version which you can use for Release. Version 17 is the current LTS release. Next coming LTS Release is 21. The Version 17 is supported until 2030, the Version 21 is supported until 2032 and so on. There is always when code breaking features where changed an LTS Version of the old version longer supported, in this case Java 8 until 2031 starting 2014. 17 years of security Support and Updates for new OSses is possibly enough for rewriting an old App.

Exactly that Situation takes care that if you develop an Application today means 2023 and let’s say you release 2024 you can choose to use Java 17 with Support until 2030 or Java 21 which releases in September this year and release 2024 with a JDK with Support until 2032. That is calculable and has low risks for your code. While you have that amount of time you can even say: okay, let’s look for the next upcoming LTS and refit your Project to it (that is what I am doing) or using all time the actual JDK and refitting your application all time for it (what is not much work for example I had between Release 11 and Release 17 nearly nothing to change for my old Software Packages but I had to update many Libs what was also not a real problem and I was even changing all Java 8 and older Packages migrating to Java 17 this year).

So following to this principles will help both: the Developer which wants to have all time the new features with the risk that something will need a rewrite after Version change and also the professional Developer which needs reliability. For the Version between the Changes (let’s say 2023R10) and 2027.1lts there would be a longer Support time needed. Means that the company would have to take care of the old Version for three years more (Showstoppers get fixed, security updates get done). Would be a Code reliability for the next 6 years from now on. And that would result in the possibility to migrate to the new Xojo blend of 2024.x.

Software Development for professionals and Citizen Developer

That would make projects possible and it would help to release the Software without the panic that the next change in versioning will change anything. While this panic nobody needs even the newbies not. Using Kotlin as Language behind for Web and Mobile would result for mobile in both Cases (Android and IOS) in native UI’s and for Web in a secure App generation for webApps as we know them (server driven Web Apps) and in pure javascript Webapps which we can transpile with the technology Stack behind from a written Web App. That would be a big technological step and Xojo would become a product even I would like to use.

1 Like

Wow… @thorstenstueker that’s quite detailed.

We all agree with you in that Xojo could easily become a massively more successful development tool.

I suspect Xojo’s been witnessing sales decline and fading interest for many years. Massive price increases (some are now 50% more expensive), abandonment of annual sales (no more Black Friday) and dropping of user conferences, paints a picture of a company cutting costs and expenditure, not a company that’s gained a boatload of customers recently.

The trouble is; the CEO. Has no intention of “changing” course. My guess is he makes enough cash at the end of the month, customer satisfaction is irrelevant.

1 Like

Sorry, another senseless, pagelong “thought on xojo”

Please accept it, Xojo is dead. It will become another PowerBASIC.
Open Source it with GPL now! That’s the only and last thing they can do.

But our “stable genius” won’t do this. He considers Xojo as his baby. Like with PowerBASIC it may eventually happen after his death. But nobody will wait for this.

To our “stable genius”: For Steve Jobs it was a healing process when he was once pushed out of Apple. He wouldn’t become the Steve Jobs in his later years without this experience.

1 Like

Oh I agree with you. It is senseless. While he will not change. That is okay. But it shows another thing. I am not against Xojo. I am only realist. And I spended 30inites for an analysis what could be done.

Powerbasic went the same way but earlier. That’s true. It is a good example. Java is a good example how a language can be developed even when it is all open source.

1 Like

It is not on us to say or decide who it is that does the problematicak decisions. It is on us to say what’s possible. For me that ended exactly at this point. Because I done an analysis and therefore I see that nothing is done b the company to rescue it. End of story for me. It would be worth of waiting for it. But not like it is drive. Now.

1 Like

While technically possible it is highly unlikely that it will happen. Not under current leader and ownership. And it will take a years-long effort of more than 6 or 7 people. I don’t see highly qualified developers lining up for voluntary work that would ultimately fill the pockets of the current owner and help the current (mis)management to survive.

1 Like

sigh when referencing PowerBASIC I remember how its Debugger could create Stop Conditions on values of a variable e.g. when x is set to 1 the debigger stops and you could check the stack or other variables. I’ve never seen this in VB6, .NET, Xojo and I really missed this function many years.

having written this I found FreeBASIC and will check it this weekend.

This IDE for FreeBASIC is written in Scintilla and looks quite modern on Windows

FreeBASIC runs under Linux as well and there should be GTK binding for it…

yep, a debugger w/o watchpoints is more or less useless, otherwise you have to write your break points in the code anyhow. At least the stable genius agreed on this one a while ago => open a feature request.

i’ve written this as request in old feedback 13 years ago… I was never heard


Kind of a harsh statement, isn’t it? In any case, I wouldn’t like it if I had taken all the trouble to compile my thoughts - But I do agree with all of you other statements in your answer :wink:

Crazy as it sounds, there was a time when there would have been enough “crazy people” who would have helped Xojo for free.

MBS, Einhugur would have helped out of their own interest.

Sam, Bob, Tim had a lot of ideas, that’s the first people that come to mind. Of course, Norman should be mentioned, even if there are apparently issues between the Inc and him that would have made it more difficult/impossible (we don’t have to understand that, but we have to accept it - that’s business). Hal, Dave, Thorsten and others would at least have remained loyal customers if the Inc. hadn’t completely ignored them (to be polite).

This list is unfair because there were many more people that I don’t remember anymore, also because many are long gone from Xojo.

In addition, one could have relieved the developers or the boss. E.g. by helping with documentation, internationalization, tutorials, getting rid of the grotesque, unstable and ineffective feedback app (that was a decade overdue) as such that the core team could have concentrated on the main product.

But really every initiative, every single one without exception, was nipped in the bud.

1 Like

Xojo’s management has an amazing capability of repulsing people and making enemies. They’re very efficient at it. Now all these fine people who once suggested to help are gone. This is beyond recovery, there is no way back.
Coding in Xojo is riding a dead horse.


Exactly, only the flies and maggots are still happy for a while, but unfortunately it looks very finite. Life punishes those who come too late.

1 Like

sigh just opened xojo feedback to search for my decade old issues finding some still open and not fixed… wanna see?

  • Printing multiple pages in Webview on Mac (#14363)
  • No Cue Text in Inputfields in Linux (#27364)
  • Inspecting Listbox Values/ Rowtags/ Celltags in Debugger (#27588)

I am missing many more and started to laugh at this one:

  • WebMenu Positioning wrong when collapsed to Hamburger-Menu (#453707)

It was verified, there was an convrsation with Robin Lauryssen-Mitchell. I’ve thrown my time on this issue with screenshots and sample project … and it was closed due to “no activity in the past 2 years”.

Yes this is the proper way how to treat paying Pro Customers.

I need to stop to deal with Xojo it makes me only more sad…


Yeah we had this seemingly quite basic debugger functionality in FoxPro too, and I have lived without it for way too long. It’s odd, because the .NET debugger is without peer in every other respect; between it and the ability to modify running code without restarting, it’s fantastic.

Later today I will investigate this with .NET 7, I haven’t even bothered to check. Last I looked was on the old framework and they seemed to have some vestigal ability in the works but it was clunky and not worth the effort. Maybe it’s improved.

The Policy they have with their Customers at the moment is driving everybody with too many incidents mad. And I believe that it is better in that case to leave. While there are platforms like Dotnet Core and Java there is no need for Xojo. You can build all the Software you need with one of these alternatives. And run it.

Ob top you have more Code security. So I would not wait but learn the platform I selected. That makes just more sense than waiting. Within that time you can maintain your code and later you can do rewrite along your existing code. That is - I have done that with Java and a big Xojo project - no problem to get that job done. I guess with Dotnet Core it is not less simple to do.

Don’t get me started on this one. It’s indeed a slap in the face when you make the effort and then nothing happens on their site, or it is just closed, or it says “unreproducible”. I would even accept the truth “we don’t have time, other prios, thank you anyway”, but no, nothing happens or you get at max stupid comments, if at all.

Dont’ :wink:

.NET - been there, happy I am not in need of this :wink:

Not rue, VB6 can do it adding an ispection (watch) to the variable (All the .Net have this feature since the beginning). Not only that, you can change the value of variables without stopping execution and the debbuger was really fast.

After VB6, the Xojo debugger always loked like just another half baked feature.