Title: Why I Transitioned Away from Xojo - A Developer’s Perspective
For more than two decades, I wore the badge of a Xojo developer with pride. I passionately blogged about the product, created over 200 training videos, spoke at numerous Xojo developer conferences, and even developed popular developer tools for reporting and database connectivity. My commitment to this platform went beyond professional; I started a professional developer group and co-organized two developer conferences. I was so deeply invested in Xojo that even my daughter, now a master’s graduate in computer science, began her coding journey with Xojo at the tender age of seven or eight.
However, the decision to stop consulting and pursue a full-time job was a challenging one. Building your business feels a lot like raising your children; you invest your heart and soul, hoping for its success. It was at that point when I couldn’t trust in the future of my business due to concerns about Xojo.
For those of you unfamiliar with Xojo, you’re not alone, and that’s part of the problem. Despite more than two decades in the commercial software development world, Xojo remains relatively obscure. In a nutshell, Xojo is a Rapid Application Development (RAD) tool used to create applications for Mac, Windows, Linux, iOS, Android, and the web. The language, while resembling Basic, compiles into native code and employs native controls wherever possible. Xojo’s integrated development environment (IDE) aims to help new users become productive quickly. But as I’ll explain, there are multiple reasons why I decided to part ways with Xojo.
1. A Shrinking Developer Community
Xojo’s developer community was never massive, and it’s not showing signs of growth. The issue? Many companies don’t adopt Xojo because they’ve never heard of it. It’s not listed in the Tiobe index, and a Google search yields scant information about it. In stark contrast to well-known languages like Java, C#, Go, Rust, Python, or PHP, Xojo remains in relative obscurity. The lack of third-party training classes and books for learning further compounds the problem.
2. Lack of Marketing Efforts
Xojo’s marketing strategies have been questionable at best. It’s unclear who their target audience is, and their efforts to attract new developers seem ineffective. As a consultant, I keenly felt the impact of this. 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.
3. ‘Citizen Developer’ Focus and Its Limitations
Xojo seems to emphasize catering to ‘citizen developers,’ individuals who build applications for personal or in-house use rather than for commercial purposes. However, these developers are often price-conscious, as they may be paying for licenses and libraries out of their own pockets or fighting with corporate IT for budgets. This leads to a limited third-party market, making it challenging to find suitable solutions.
4. Frequent Bug Issues
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. I can vividly recall chasing new versions of Windows technologies for nearly a year before stability was achieved. With the transition to API 2, there are only bug fixes for new classes and controls and not the older classes and controls. For those who worked on Web 1 projects, there are no bug fixes in sight as the company abandoned version 1 users.
5. Exclusive Reliance on Xojo
Xojo often promotes the idea of using their product to develop their product. While commendable, it results in them not using Xojo in the same way as the developer community does. This lack of empathy for developers’ daily challenges hampers the improvement of the product. The IDE lacks crucial features like a full-featured Rich Text control/library and dynamic reporting tools that business users require. Consequently, businesses may hesitate to invest in Xojo licenses.
6. Ignoring Customer Feedback
Despite receiving feedback from the community regarding the Xojo IDE, Web 2, API 2, iOS, and Android, Xojo often dismissed the input, stating that it didn’t represent the entire community. This approach frustrated professional developers and eroded their trust in the platform. Many of the most vocal evangelists have moved on to other languages.
7. Falling Behind the Technological Curve
Xojo lags behind in terms of features when compared to other languages. It struggles with concepts like concurrency, making its threading system subpar. Despite introducing the Worker class, the overhead of launching a Xojo console application is significant. Xojo’s limited support for concurrency leads to performance issues. The absence of Generics and inadequate integrated Git or Subversion support further limits the development experience.
In summary, my experience with Xojo led me to realize that the platform no longer met my needs. The transition from Xojo to other languages, such as Go and React, was challenging but enlightening. I’ve discovered that Xojo’s IDE is slow and outdated compared to modern development tools. As I adapted to Go, I encountered a more efficient, agile, and well-supported ecosystem that starkly contrasted with my Xojo experience.
My advice to my last Xojo consulting clients was clear: begin the search for a Xojo replacement sooner rather than later. The future of the platform appears uncertain, and it’s unclear whether the company will survive in the next five to ten years.