Xojo in 2017: A Review [Part 5: When To Use It]

This is the fifth and final part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3

The fourth part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part4


Xojo is a significant product.  Targeting Windows, macOS, various Linux distributions, iOS, and Raspberry Pi from one language is an undertaking.  Xojo also sells a web product compatible with modern Internet browsers.

The goal here is to allow you to focus on your application versus the wide variety of platform differences. In my experience Xojo is one of the best options when considering a cross platform solution.

However, there are disadvantages to Xojo and you should know when not to use it:

  • When maximum performance is required. Xojo console applications can be quite fast but desktop applications do suffer from a large framework. Application safety features can be disabled and compiler optimizations toggled to speed it up but you are certainly never going to beat bare metal.
  • When maximum concurrency is required. Xojo applications can only use one CPU core at a time. There are numerous reasons for this and it is not likely to change. I demonstrate in earlier parts why the story around accessory applications to utilize more cores needs serious revisiting.
  • When you are using platform specific features. Xojo’s promised “interop” capabilities should deliver better availability of platform specific features. However even then out of the box Xojo has few platform specific features. The ones they do have tend to be bare bones and not widely updated or enhanced. Xojo delivers a lowest common denominator approach. You can overcome this with extensive work.
  • When you are deploying to a single platform. The lack of platform specific features makes this a sub-optimal approach. Programmers tend to be optimistic and believe that deploying to a new platform is “coming soon” so you should prepare now. If you know that you will be on a single platform for 12+ months you should focus on using the tools for that platform.

There are some great advantages to Xojo and here are some cases where you should use it:

  • When you are building a line of business application. These days company staffers are using all kinds of devices. You do not want to prevent someone from working because a company utility does not run on their platform.
  • When you need to build a quick and dirty prototype. Xojo is really fantastic at building working mockups that evolve easily with your ideas. Mockups and design concepts are helpful but a functional prototype helps users conceptualize their needs and delivers better results.
  • When you do not have time to rewrite your prototype in a “real language”. Xojo provides full object-oriented capabilities such as classes and interfaces to allow you to build complex software. There is nothing stopping you from turning your prototype in a high-quality application.
  • When you are concerned about your software documentation and architecture. Xojo with its IDE keeps every project organized in very similar ways. Excellent built in search and navigation of the code hierarchy allows for great code discovery. Its basic syntax is easily read and understand. Xojo programs are not difficult to share with others.
  • When you want to share code between target platforms. Xojo through the use of modules and platform conditionals makes it very easy to share the same platform-independent logic across all targets. It is really great to write some REST API code or PDF code and have it work on all targets with little to no additional effort.
  • When you want a central location for documentation, community and support. Xojo’s commercial nature is a strength for many customers. They prefer the official documentation and support channels that Xojo provides. While I advocate for the open sourcing of a subset of Xojo’s functionality I do believe in Xojo as a commercial entity and product.
  • When time is of the essence. I do not think there is a faster or easier way to compile a working desktop application for this many targets anywhere. It may certainly be doable by Java and others but it is nowhere near as efficient or fun.

I personally enjoy using Xojo for every project where appropriate but it is not always the best tool for the job. I hope this series has given you some indications as to where I think Xojo is, where it could go, and why you should consider it. 

If you were discouraged about Xojo I hope this series demonstrated that a lot of people rely on it daily and it is a good product. If you are encouraged about Xojo and concerned there may be lurking problems well I hope I have presented the most challenging ones to overcome.  If the tradeoffs sound agreeable to you then you should consider it for your next project.

I will continue writing here my experiences and feelings about Xojo. This however is the end of my 2017 review series. I have some big open source and commercial add-ons being released soon so I want to focus on writing great documentation and example projects for them.

Once we get into 2018 it will be XDC time and I am very excited to meet more of the this community in Denver. Thanks for tuning in and don’t forget to sign up for our mailing list.

Thanks for reading.

Phillip Zedalis

Xojo in 2017: A Review [Part 4: The Community]

This is the fourth part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3


Bob Keeney writes in his latest piece that “software development is fluid” [1]. Always changing, evolving, and not easy to schedule around. It is a nice analogy and I get the underlying message. There has been a current on the forums that maybe Xojo does not do enough to resolve bugs. Perhaps they are too focused on new stuff that important issues do not get addressed. Bob is writing a piece here defending Xojo, their development style, and the complexity of what they are trying to achieve.

I think like most in this niche of software consulting we rely on Xojo being a reliable product. Our success in some ways is tied to theirs. Let me rephrase that a bit: Xojo consultants would prefer to stay Xojo consultants versus primarily using other tools. He wants to promote the tool he likes so much and so do I. Most in the community are like minded in that way.

Many of his arguments I suspect are valid and reasonable. I think for the most part you see this throughout the Xojo community. We all recognize how challenging it is to run a small software company. Some part of us appreciates Xojo on a fundamental level. We also become have become proficient with it and it enables us to get more done.

However, there are times when it holds you back. A new release breaks something or a new feature does not work as expected. The community lights up then and the argument remains:

  • Why do you not give us more heads up on what you are doing?
  • Why do we not get more time to test?
  • Why are there not more testers?
  • Why do bug reports take so long to get fixed?

It can get pretty excited at times and it is not unheard of for a thread or two to get locked shortly after a release. I love this part of the community because everyone is so invested in the product.

When you look at issue trackers and forums for open source languages it is rather dull. Many times there are few that are invested in a language because you are only one console command away from installing an entirely new development stack. The questions are highly abstract and technical and the responses are typically slow and methodical.

I comment aggressively on the Xojo forums that I wish the (Xojo) engineers would tell us more, show us more, give us more. Sometimes they fire back and have told me that being on the forums is not in their job description. Nonsense. If the Xojo engineers left the forums the community would be harmed. The Xojo engineers are not just part of Xojo they are also part of the community. They would miss us as well.

We all want to enjoy where we work. We push Xojo pretty hard and that is healthy but we also have to make sure we are not making it intolerable to work at Xojo. Like Bob said we need to do our part with bug testing, writing open source code, and helping others in the forums. However, the community is not to blame when regressions hit and progress slows. Some part of it is due to the enormous nature of what Xojo is trying to accomplish. The other part is the secretive nature in which they do it.

This is why in Part 2 of this series I suggested open sourcing the standard library; The mish mash of libraries and classes in either Xojo, C++, or third-party libraries. When bugs are encountered in the “framework” it can force you to use a different version of the product. The sad truth is regardless of the difficulty of a bug report it may not lead to a timely resolution. Often times you will get a confirmation and then wait several releases. You have no idea if they have even scheduled to start fixing it.

I feel like if Xojo is not going to commit to fixing something in a reasonable timeline then that would be a great opportunity to ask the community to attempt it. Let us earn badges or points or something. Give the top 5 every month a coupon for example. I am thinking bug bounty board meets achievement points. We don’t need any cash or prizes but recognition to the community for being involved. Most importantly let us help you chisel away at the issue list.

If there is a problem with Bob’s piece I would say my only nitpick is I don’t think software development is fluid at all. In fact, I think it is solid. Solid like a giant rock that has remained stationary for millions of years.

Software development is like sculpture as you chisel 0’s and 1’s into a rock face. You spend so much time planning and considering the subject matter and problem at stake. You design and architect the database, storage, and architectural nuances of how messages get from one method to another. You consider deployment strategies and security concepts to protect your users and not leak your database to Reddit. You do all of this in the hopes perhaps you will achieve something great. “Something great” more often than not is a tool or utility to create more software to manipulate even more 0’s and 1’s. 

I say solid as a rock because even with source control, undo, snapshots, checkpoints, auto-saves, and screen recording you can’t save a bad program. It takes too much work and the amount of effort to resolve the plumbing job of a poorly planned program is terrifying. You start dreaming up ways to convince your client or boss that it would be best to start anew. As you mature you realize this is not always a practical strategy and so you are going to have to do surgery more often than not. You are desperately hoping not to chisel the last bit of support that keeps the rock standing up.

I am not convinced software is fluid at all.

I am convinced Xojo makes for a great chisel.

I also believe the Xojo community is part of the value proposition of the product. For example I search the forums before I search the documentation. Thank you forum.xojo.com. 


[1] = http://www.bkeeneybriefs.com/2017/08/software-development-is-fluid/

Serving static content from Xojo Web

Now available on GitHub is open sourced code to help you serve static files from your Xojo Web application. This is especially useful if you are running standalone or load balanced apps and do not want to depend on another web server.

Check it out here: https://github.com/1701software/XojoWeb_StaticContent

For example at ServerWarp we host many load balanced applications for customers. Many will produce PDF reports for users. In order to serve those PDF reports they have often relied on writing those PDF files to another directory of another domain or subdomain because Xojo Web could not natively serve those files. Technically the "WebFile" class works for this purpose but the user and development experience is a bit subpar especially for mobile clients. You can only access files that way if you have an active Xojo Web session. What if you want to email your user a link to the download?

The problem at ServerWarp is we isolate your apps and domain web servers from each other to protect from vulnerabilities and provide the most secure environment. So it requires extra configuration to get your Xojo standalone app to be able to write to a specific folder of another domain. The other obvious downside is you now need a secondary web server and domain/sub-domain to serve these files. It would be great if you could simply write your static files to a sub-folder inside of your app directory and serve those files directly. That is exactly what we deliver here.

The code we are presenting on GitHub today allows you to easily map folders to the Xojo Web application to be served as static content. It is a drop in module that extends the 'App' object of your Xojo Web project making integrating it super simple.

The example project demonstrates two distinct static folders with a PDF, image, and text file. It demonstrates how to map the folders and the Xojo Web app presents links to test the functionality very quickly. To give you an idea of how it is to integrate check out this screenshot of the 'App.HandleURL' event handler: