Xojo: VB For the Mac

Last week we asked the question “How Did You Find Xojo?”  A vast majority (60%) of the responses said web search of some kind was how they found out about Xojo (or REALbasic or Real Studio).  Some found Xojo via software discovery CD’s that were bundled with Mac specific magazines over a decade ago (that seems wrong to write it like that).

More than a few users had comments that they had been using Visual Basic (VB) and wanted something like it for the Mac.  Some even said that they searched for “VB for the Mac” and Xojo was one of the results.

I get it.  I spent quite a few years working on a big accounting application written in VB6.  It was big enough where we had to refactor the project because we couldn’t add any more modules or class objects to it.  It used many third party controls that helped in development (think text field formatting, fancy grids that could hold any other control, and multiple reporting tools).  

The project was only ever going to be on Windows so there was zero thought about a Mac version.  But that didn’t stop me from thinking about it.  Every now and then I’d try to do something in Xojo to prove that I could do it.  With the exception of the fancy grid there were few things I couldn’t get working in Xojo.

Even though VB6 and Xojo are BASIC languages there isn’t much similarity between them.  VB6 compiled applications that required the VB6 runtime while Xojo applications are compiled into self-contained packages.  On the Mac everything required by the application is in the bundle whereas on Windows and Linux libraries needed by the app are put into a folder right next to the executable.  Xojo Windows apps don’t need to use an installer but since Windows users expect an installer it’s easy enough to use.

VB6 is over fifteen years old.  It didn’t have much in the way of modern language features such as object inheritance.  You spent a lot of time and effort manipulating controls to do what we’d consider ‘normal’ things (I seem to remember ListBoxes being this way).  In Xojo you can extend and subclass practically everything.  Is Xojo a perfect language?  Oh heck no, but it’s light years ahead of the fifteen year old VB6 and it’s still evolving and improving.

Xojo doesn’t make perfect Windows, Mac, or Linux applications.  It’s often a compromise for something that works ‘well enough’ on Mac, Windows, and Linux applications.  So the fancy grid’s that you could purchase for VB6 don’t really exist for Mac and Linux and Xojo reflects that.  But you can certainly design a really good application that doesn’t need the fancy grids.  MacOS users tend to like ‘elegant’ solutions and, to be honest, the fancy grids aren’t an elegant solution but they certainly work (especially for accounting applications).

The third party community for Xojo isn’t nearly as big as the VB6 world.  Generally there are fewer options but the options are considerably less expensive.  We’d spend a couple of grand each year per developer on licensing for third party tools.  As a Xojo consultant we spend about that much for the entire staff each year.

We don’t get many requests for VB6 to Xojo conversions any more.  We used to get ten to twelve a year but it has definitely slowed down the past couple of years.  I suspect that any remaining VB6 applications are in maintenance mode and their owners don’t want to invest in a rewrite.  If they did, they would have already moved to a new development environment.

VB6 applications still work in Windows 10 and if memory serves Microsoft has said they’ll support the VB6 runtime for another ten years.  This means that there must be a LOT of VB6 applications still around.  Support for the VB6 IDE has disappeared and the last time I tried I couldn’t get it to install properly in Windows 10 so I just went back to my Windows 7 VM.  But now that Windows 7 support has expired it seems that those old VB6 applications might be on life support.

Many of us came in to the community looking for VB for the Mac.  We’ve been using it for nearly 20 years and have a stable of clients that are happy with a single code base for their commercial Mac and Windows (and occasionally Linux) applications.  I’d say Xojo has been more than good enough.

20 thoughts on “Xojo: VB For the Mac

  1. “VB for the Mac” is still a pretty accurate description if you focus on macOS only.
    But then so is “VB for Linux” if you focus on Linux.
    I’m sure there has to be a tag line that suits for Windows – certainly one that is more VB than VB.net for Windows. “This is not your grandpa’s VB” maybe 🙂

    When you consider all the other tools out there Xojo is, still, despite its bumps and warts, a tool that has very few real rivals when it comes to cross platform development.

  2. We come from Ms-Access background and have try out various cross platform tools until we found RealBasic which revolved to RealStudio and then finally to Xojo.

    Richard still using MS-Access for some of his old client and often wish Access can do some of the thing the xojo can do like subclassing various control

    • VB6 was not / MS Access is not Object Oriented Programming.
      Nowadays OOP is really a condition for being a good programming environment.

  3. Considering how many people looked for a “VisualBasic for Mac” equivalent you have to wonder if the rebranding to Xojo wasn’t an own goal …

    • I don’t think people would look that up today. The narrative that classic vb is dead and vb.net is c#’s crippled sibling have seen to that.

      • I didn’t say ‘is an own goal’, I said ‘was an own goal’. But I would still say it is an own goal even today. I know more people who know VisualBasic then people who know Xojo. In fact whenever I mention Xojo I get puzzled looks because nobody knows what it is. Never happened when I said “REALbasic” – people had at least an idea what that was (even if some of the ideas might have been wrong).

  4. Just a couple of points,1998 when vb6 came out is now more than 20 years ago!
    VB6 the program still installs and runs on Windows 10, there are a couple of minor tweaks required during installation but once those are done it works perfectly.
    I think part of the reason there is so little demand for conversions from vb6 programs any more is because there is a feeling that Microsoft will now never drop support for VB6.
    Also you don’t need to bundle the (it was only ever a couple of MBs) vb runtime any more as it’s now baked into Windows.
    The period of most apprehension was in the build up for the arrival of Project Longhorn (I think that was the codename for what became Windows Vista) and also around the same time the announcement of the ending of support for VB6 the program. Both came and went and the sky didn’t fall. More than ten years have passed since then and not only do VB6 programs continue to work but Microsoft regularly reaffirm their committment to this.
    One thing you have to credit Microsoft with is an obsession with maintaining the ability of software that was written for any version of Windows to continue to run on newest version of Windows.
    As for the perceived weakness of VB6’s object oriented programming capabilites, well the only pillar of OOP it lacked was inheritance and that’s now an almost dirty word!

    • I’ve used both VB6 and Xojo and inheritance is such a powerful tool. Honestly, I’d find it hard to go back to VB6 without it.

      It’s not really fair to compare a 20 year old IDE to the latest Xojo IDE, but, I feel that the VB6 IDE was considerably better in some ways than Xojo. I thought the code editor autocomplete and documentation tooltips are still superior to Xojo’s.

      • Well you can have inheritance in vb6 via delegation by declaring an instance of the class you want to inherit something from inside the new class. Not quite as clean or maybe as powerful but then not as dangerous either.

          • I think that there are many reasons but the one that springs readily to mind is where there is a temptation to alter the parent class in order to satisfy a requirement of a child class and this can have unexpected consequences for other child classes that relied on the unaltered parent class.

          • If you have different requirements for different subclasses then you should use an interface for that. Don’t blame the tool for the incompetence of the user.

  5. Markus Winter wrote
    “If you have different requirements for different subclasses then you should use an interface for that. Don’t blame the tool for the incompetence of the user.”

    Humans are fallible.

    • Yes. That still means they make the mistake, not the tool.

      You make decisions, you accept and live with the consequences. Whether it’s app design or driving a car.

      But the important thing is: it was YOUR choice. You WILL make wrong choices at times, and sometimes you can fix your mistakes, but sometimes you can’t and have to live with that.

      But I am aware that ‘taking responsibility for your actions’ is a concept somewhat lost nowadays.

    • P.S. And I’m speaking as someone who made more than my “fair share” of mistakes … but then the only real mistake is not learning from your mistakes.

      • I agree with your comments. Just because the programmer did something dumb with the tool doesn’t mean that the tool is inherently dangerous. Over the years I’ve done my fair share of dumb mistakes but I’ve also cleaned up a lot more mistakes from other people.

        If I had a choice, I’d have a new developer work on debugging and fixing other code for six months before ever letting them code anything new. It’s such a great way to learn what NOT to do in a language.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.