Is Xojo the Right Development Tool

Quite often prospective clients, and developers thinking of learning Xojo, ask my opinion of Xojo.  They are about to embark on a journey spending tens of thousands of dollars on a cross-platform tool and they want to know if Xojo is a right for them.  It’s a good question and I’ll share some of what I share with them in no particular order.

Xojo is pronounced “Zo Jo”.  I can’t tell you how many times I’ve heard it pronounced “Ex Oh Jay Oh” or something else.  They just don’t know and I think it spooks a lot of people as it doesn’t exactly roll off the tongue.  Xojo has been around under various names (REALbasic and Real Studio) for twenty years – all with the same company.  At that point it’s easy to name a dozen languages/development environments that were popular twenty years ago that either don’t exist today or been sold so many times that they’re now obscure tools.

This isn’t your fathers BASIC.  Xojo uses the BASIC syntax but this isn’t like the venerable Visual Basic or even older GWBasic or QBasic.  Xojo apps are NOT interpreted at runtime – they compile down into native code for each of the platforms.  The language itself is a modern object-oriented language that happens to use the BASIC syntax.  Xojo is updated three to four times a year and has undergone a lot of upgrades in the past two decades.  It first supported 68000 code, then PowerPC and Fat applications, Carbon, and now finally Cocoa on the Mac side.  They’ve added Windows, Linux, Raspberry Pi (Linux ARM), desktop and console application targets.  In the mobile space they’ve added iOS, and by the end of the year Android.  They’re also in the middle of the transition from 32-bit only applications to 64-bit applications.  For the most part things ‘just work’ and developers don’t experience too many issues (bugs happen but think about how many targets they’re supporting!).

Xojo applications are self-contained.  Take a compiled Xojo application and (with very few exceptions) literally copy the files to another computer and the application will just work.  Even Windows applications don’t need an official installer, however, it is recommended since most Windows users are comfortable and familiar with using them.  Most Mac applications are installed via drag-and-drop from a disk image but an installer can be used on the Mac as well.  This ease-of-installation is huge and it’s rare to have “DLL Hell” issue since all required libraries and resources are bundled together.  This does make the resulting output larger than some other development tools that depend on system libraries but I’ve rarely seen this an issue.

Xojo provides nearly everything you need in one tool (with some caveats).  The Xojo IDE has Code, Form, Menubar, Database, and Report editors (to name some of the big ones) in one tool so you never have to use another tool.  We’ve found the database editor to not be powerful enough so we prefer external database editors.  The built-in reporting tool also isn’t very powerful so we created our own reporting tool (Shorts) which has served us well in our consulting projects.  The nice thing is that all of the built-in tools work seamlessly with each other so the tools that are powerful enough for you ‘just work’ with few hassles.  The editors try really hard to protect your from hurting yourself while other tools are just a big text file that must be in an exact format.

The Xojo community is incredibly helpful.  The Xojo Forums are filled with some of the most helpful people I’ve ever met.  Some of the Xojo engineers respond to questions, but usually the community answers before they get to it.  Many other support forums are rude and condescending to newcomers to their language/tool.  The Xojo forum has even been known to answer questions about other tools.

Xojo is a cross-platform tool and because of this it has some compromises.  Controls are often the lowest- common denominator.  Grids especially aren’t as powerful as some are used to in the Windows world.  This is mainly because complex grids are not common in Linux and Mac environments.  Other controls have similar issues.  Things like automatic spell checking in TextArea’s are platform specific as on the Mac.  At times it is disappointing that there aren’t more control options for Xojo right out of the box (think date and calendar controls) but thankfully there is a third-party market for controls and libraries for Xojo that can often help.  Even though much is provided for you, it’s possible for a developer to use OS API’s using Declares that can significantly modify the appearance and functionality for some applications.

Xojo is a Rapid Application Development (RAD) environment.  Between the all-in-one IDE and the language creating applications in Xojo is fast.  This means that an initial investment can get your app developed faster and cheaper than many other languages.  Obviously some of this depends on the developers doing the work but it can make a huge difference.  We’ve always told clients that if they’re not happy with Xojo performance after the initial release they can use our code as the proof of concept to the developer in whatever language they choose.  There have only been a handful of clients that have ever switched languages after release and that’s usually been switching from desktop apps to web app.

The cost of Xojo isn’t very high compared to some tools.  For $699 per year per developer you can create web, console, and desktop apps for Mac, Windows, Linux, and Linux ARM plus iOS apps.  That’s all in the same environment and same language and with the exception of iOS applications (which requires a Mac) you can use Mac, Windows, or Linux to create everything.  Many developers use third party controls and libraries and even those are relatively inexpensive.  Plus, there are no royalty fees for your Xojo made applications.  All-in-All it can be a relatively inexpensive tool.

What considerations have I missed?

The Value of Rapid Prototyping (ie One of REALbasic’s Strengths)

Paul Buchheit (wikipedia entry) is the lead developer for Google’s Gmail.  In this blog post he talks about one of the things that he felt that Gmail did right and that was always have live (ie working) code.  Here’s the money quote:

The great thing about this process was that I didn’t need to sell anyone on my ideas. I would just write the code, release the feature, and watch the response. Usually, everyone (including me) would end up hating whatever it was (especially my ideas), but we always learned something from the experience, and we were able to quickly move on to other ideas.

If you’re still with me this describes the process we used last year on our big project for a Fortune 100.  In that project we used REALbasic as a prototyping tool and using the Agile process we spit out a major new release every three weeks.  Even in Sprint 0 (technically the planning sprint) we gave them a working prototype of our ideas.

In this regard, REALbasic excels.  Since the entire environment is integrated and the language is easy to use we were able to create incredibly complex user interfaces in a matter of days.  The end result is that we exceeded their expectations on creating a user interface that solved their problem.  This was, after all, why they hired our team because their internal groups had struggled for years to come up with something.

This company was used to web apps and we were obviously writing desktop apps with RB.  This was causing a ton of comments from them because they couldn’t think in anything other than a web app which we obviously were not coding.  So we took a sprint and took our desktop app and turned it into something that ‘looked’ like a web app complete with back/forward and home buttons.  This was easy to accomplish in REALbasic using Container Controls and a little bit of extra coding.  In the long run it accomplished the goal of creating a prototype that was more in tune with their expectations even though we never changed development environments.

Since the project was about prototyping a rather large and extremely complex user interface we had no real guidelines from the client other than this nebulous goal of fixing their problem.  One team member would do some layout sketches on paper (and later in OmniGraffle) and get preliminary approval from the client at the end of a sprint.  The developers would take the sketches and turn it into working code in week 1 of the sprint and turn it over to testing in week 2 and we’d do tweaks in week 3 for turnover to the client in the end of sprint review with what I (affectionately) called the developers “Dog and Pony Show”.

More than a few times we scrapped entire areas of code and completely rewrote it for the next sprint.  This meant that the clients gave feedback early and often and could get changes that didn’t mean anything to the developers, in terms of time, but helped them sell the project internally.  When the client goes into a meeting with a roomful of corporate vice presidents and during the obligatory PowerPoint demo they start chanting, “Demo!  Demo!,” you know you’ve accomplished something.

All in all, the project was a lot of work and what we gave them at the end of the project was only minimally what we showed them in sprint 0.  We could not have delivered as many fully thought out features without REALbasic.  It’s an awesome prototyping tool.