Moving on From Xojo
Since 1998, I’ve built every single Mac app with the Xojo development tool (Aka Real Studio and REALbasic).
Over the last ¾ of a decade, Xojo started ignoring bugs, feature requests and industry trends. New features felt rushed, incomplete and sometimes unusable. Dark mode support and concurrency are two prime examples. Something is clearly wrong.
Xojo had embarked on a multi-year project of “2.0 All The Things™”. All Xojo customers must now experience learning a new programming language.
[…]
In a few short years, Xojo turned their most evangelical, enthusiastic, knowledgable, experienced and loyal customers, into enemies.
One of the topics that I brought up was that these issues (the new Event names and marking anything from API 1.0 Deprecated – even though they’ll be around for a many years to come) were brought up early and often in the beta program. I said that honestly, it made us feel that our input is not valued.
[…]
I’ve been around a long time and have remained friends with some of those former Xojo developers. Some leave because of long-term bugs. It is disheartening to report a bug that affects your app that gets ignored for years on end.
[…]
Some leave because there is a lack of capabilities in the product. iOS (but also true for all targets) is painfully lacking in capabilities that force you into learning complex declares. There are no built-in controls for Date, Time, Timestamp, or numbers only Text Fields, exporting to PDF, no ability for applications to have a report editor, a good grid, etc. Some of this is because Xojo is the lowest common denominator between Mac, Windows, and Linux (for desktop) and doing these things cross-platform is really hard.
When I first started this blog, I was a huge fan of RB. The familiar VB6 syntax was what me attracted to it in the first place. I had a VB6 background, and with Microsoft abandoning it, RB was a nice alternative.
[…]
But because of Xojos decision a couple of years ago to start using a new syntax framework, most of these projects won’t work anymore without a major overhaul. So I feel it is time to let them go.
Previously:
- Mail Extension Postmortem
- Why Do People Still Use VBA?
- Feedback Through an Intermediary
- Code by Kevin Leaves the Mac App Store
Update (2023-11-28): Patrice Calligaris:
Good points, I think their mistake is to support all platforms. Too big for a small team. They should just focus on macOS and Windows, desktop apps where there is a market. Now for Windows apps, you need a specific project to support new UI items, ridiculous!
I initially didn’t want to write anything more about Xojo. However, this thread reaffirms my decision to learn new tools nearly two years ago and ultimately part ways with Xojo.
[…]
In my opinion, Realbasic’s former strength of having a visual designer is increasingly overshadowed by various functional shortcomings and the prevalence of a 4-digit number of bugs.
Most notably, you purchase the “Layout Manager” at a steep cost. Naturally, it only functions within the Xojo IDE, which is significantly outdated. Not only is the autocomplete feature slow and prone to errors, but we don’t even want to discuss the absence of GIT integration. The Xojo IDE simply lacks everything that modern (and mostly free) IDEs provide in 2023.
Of course, the days when you could easily develop for multiple platforms from Realbasic / Xojo are long gone. The mobile modules require (no fault of Xojo) that you deal with XCode, Android Studio, certificates, CSS, JavaScript injections. If you don’t use the overpriced but secure Xojo cloud, you will also have to deal with server configuration for the web or you will have to use a third-party software solution like “LifeBoat” (in addition to the plugins that you need to be able to work properly with Xojo). The same applies if you want to get mobile solutions into the stores. Then there is hardly any way for the hobbyist to avoid third-party software like “App Wrapper”.
A decade ago, people would explore Xojo, but they soon realized that building a robust application required more effort than they could invest. Consequently, they often sought professional developers, like myself, to create or fix their applications. However, the demand for consulting work gradually declined, leaving fewer opportunities for developers. The viability of the Xojo ecosystem is intricately linked with the consultants who support it.
[…]
While Xojo introduced its Rapid Release Model years ago, the results have been less than stellar. Instead of large, more stable releases with occasional bug fixes, we received frequent but less substantial updates. These updates often fixed some bugs but introduced new ones, creating frustration.
The parallels to macOS are obvious.
See also: If Not Nil, Could it be Saved?.
4 Comments RSS · Twitter · Mastodon
I moved on from Xojo (then RealBasic) in the early 2000s. I spent an abnormal amount of time dealing with bugs and creating polyfills (or using 3rd party plugins) for OS X features or missing cross-platform things. I filed bug reports that got ignored. The platform owner gave little to no care about the interface or user experience for the generated apps. I sensed the direction and focus would not improve in these areas and threw in the towel and learned ObjC and Cocoa.
Modern Apple dev now feels the same. I spend an abnormal amount of time dealing with bugs and re-implementing things to get little customizations or things working correctly. I file bug reports that get ignored. The platform owner gives little to no care about the interface or user experience for the generated apps, even in most of their own apps. Apple's direction and focus is 100% opposite of what I want or care about.
> All Xojo customers must now experience learning a new programming language. Does this new language make Xojo generated apps faster, more stable, less buggy, more capable, more compatible, more secure, more memory efficient, require less resources or less code?
> Each step of the way, customers were argued with, dismissed and some insulted. Criticism and suggestions were ignored.
This is how I feel about Apple with Swift and Swift UI. Neither improves my dev experience nor generated apps like how moving from Xojo to ObjC and Cocoa did. For a couple of nice features, Swift gets in my way with more complexity, wastes my time on dumb things, has awful tooling, slows down my dev cycle, and I'm constantly gaslit that it's the best and the future and the only way to have "safe code" (say "safe code" as pretentiously as possible for the usual Swiftie dismissal).
The day Apple forces me to dev with C+++ and create UIs by typing Xib files, they can have the platform. It's the wrong direction and I think it's more about everyone saving face than to admit it was largely a mistake. How far we've come from things like ObjC Garbage Collection, when something could be tried and canned quickly when it didn't work as expected, without loss of ego or face.
I'm wondering why I shouldn't jump ship to Electron or similar. If most platform owners don't care about user interface or user experience (outside of demos), and have largely trained users as such, and if shipping bloat has become a standard practice, and if I'm forced to use a language I hate, why not embrace all of the suck and at least get some cross-platform benefits for it? Ironically, if Xojo worked as expected it could have pulled me back.
Best of luck to the Xojo devs who threw in the towel. If you find the right thing, retraining can be rewarding. Avoid cults pursuing language perfectionism and architecture astronauts and you should be alright.
@Captain Hammer You read my mind. I feel the exact same way as you about SwiftUI and the direction of Apple platforms.
>This is how I feel about Apple with Swift and Swift UI. Neither improves my dev experience nor generated apps like how moving from Xojo to ObjC and Cocoa did. For a couple of nice features, Swift gets in my way with more complexity, wastes my time on dumb things, has awful tooling, slows down my dev cycle, and I'm constantly gaslit that it's the best and the future and the only way to have "safe code" (say "safe code" as pretentiously as possible for the usual Swiftie dismissal). [..] The day Apple forces me to dev with C+++ and create UIs by typing Xib files, they can have the platform. It's the wrong direction and I think it's more about everyone saving face than to admit it was largely a mistake.. [...] I hate, why not embrace all of the suck and at least get some cross-platform benefits for it?
100% agree. As Swift adoption rises, Apple software quality declines. I don't think I've ever had the compiler crash when using Objective-C. Swift has been out for 10 years it's not in Beta. I think you're right. It would take an absurd amount of courage for them to admit it was a mistake at this point but I'd give them a lot of credit if they did.
Thank you for the mention. I've been using it for two years now, but I still discover new features every day that the Xojo IDE (independent of the language and framework) simply cannot offer.
When it comes to modern concepts like AI, I would say that the train has definitely left the station. AI doesn't often write the complete code for me, but it provides more targeted information than any Google or forum search. The 10 EUR per month is a steal compared to investing in Xojo. However, new challenges, such as the updated guidelines from the Google Play Store (https://jeannot-muller.com/google-play-requiring-20-testers), may make it even more difficult for someone to invest in a development tool for Android when the original tools are available for free.
This is just one example among many.
