If you’ve been following my blog for the past few months, then you know that I’ve been in search of a development environment that will complement FileMaker. I’m by no means giving up on FileMaker. Instead, I’m looking for a way to develop truly native apps, and mobile apps in particular.
Last week, I finally decided on Xojo. In this post, I’ll explain why I made that decision. But before I do, I want to review the development environments that I looked at.
The FileMaker Platform
As a FileMaker developer, I would be crazy not to consider FileMaker Go for my needs. Put simply, FileMaker Go is an iOS-based FileMaker client. It was released in July of 2010 as part of the FileMaker 11 platform, and it has come a long way since then. It is a feature-rich FileMaker client that brings the FileMaker experience to the iOS platform. It also allows FileMaker developers to take advantage of many of the capabilities of iOS devices, including the camera (which can double as a barcode reader), signature capture, and more. It’s also a pleasure to develop for, as it makes it very easy for FileMaker developers to use their skills and knowledge of the platform to make mobile solutions quickly and easily.
However, FileMaker Go is a FileMaker client. It’s a native iOS application. Nothing more, and nothing less. The FileMaker platform does not provide you with the means to create native apps of your own. Your solutions essentially "sit on top of” FileMaker Go.
In many cases, that’s all you need. A simple way to take a FileMaker solution and make it available for iOS users. But if your goal is to create true native iOS apps of your own, then FileMaker isn’t the answer.
And thus began my quest for a development environment that would enable me to develop native apps…
On the advice of Hal Gumbert of Camp Software, I first looked at Xojo. Hal’s been using Xojo (formerly REALBasic ) for years, and has had a lot of success with it. He’s developed native OS X-based apps, and recently had his first iOS app (which was developed entirely in Xojo) accepted into the App Store.
Xojo clicked with me. I immediately took to the IDE, the language, and Xojo’s development workflow and methodology. It’s a very powerful object-oriented language, but not overly complicated either. It combines ease-of-use with power, and that’s always a winning combination.
Had I been a wise man, I would have stopped right there and just ran with Xojo. But, well, I’m not. Here’s why…
For whatever reason, I had it in my head that I needed an environment that would support targets that included Windows, OS X, iOS, and Android. Don’t ask me why, because I don’t know what I was thinking. And while Xojo supports Windows, OS X, Linux, and iOS, it does not support Android, and as far as I can tell there are no plans for it to do so.
Update: Although Xojo has not publicly announced a release timeframe, they are currently evaluating extending Xojo to the Android platform, and are very interested in supporting it as soon as they can.
So I scrapped Xojo. A foolish move, as you will soon see...
Next up was LiveCode. LiveCode is a modern take on HyperCard. It uses the HyperTalk programming language, has a nice IDE, and it’s open source. It supports a compile-free workflow (thus the "Live” in "LiveCode), which is quite interesting and somewhat unique. But best of all, it supports targets that include Windows, Mac OS X, Linux, iOS, and even Android. Sounds great, right? I thought so, and so I dove headfirst into it.
When I originally blogged about LiveCode, I wrote, "So, what's the catch with LiveCode? I have yet to find one.” That was nearly two months ago, and since then, I have found a few catches.
First there’s the language. LiveCode is a high-level, English-like scripting language, which you would think would make it easy to learn. But for whatever reason, the language never did resonate with me. I found myself constantly having to look things up and try to work through the syntax and nuances of the languages, which significantly slowed my development.
The other "catch” with LiveCode is that, as a result of trying to support so many targets, it doesn’t seem to support any one of them particularly well. For example, the controls for iOS don’t look or feel native to me. (They might to others.) There are plug-ins to help address this, but they are confusing, somewhat expensive, and in general not well documented.
It took me awhile to come to this conclusion, but ultimately I realized that LiveCode, while very nice, wasn’t really the environment that I was looking for. It just didn’t "feel” quite right. And if I’m going to be living and breathing in that environment for awhile, it needs to feel right. It needs to be comfortable, friendly, and powerful.
So, I scrapped LiveCode, and moved on to…
Swift is Apple’s new programming language, which they announced at the 2014 WWDC. Apple developed it by combining the best aspects of many of today’s popular programming languages - and it has done so without creating the programming equivalent of Frankenstein’s monster. It is a beautiful, powerful language. And if you’re looking to develop for the Apple ecosystem, Swift is a great option.
By this point in my journey, I began to realize that my goal of finding a single environment that I could develop solutions for Mac, Windows, iOS, and Android wasn’t practical. I figured that with Swift, I could at least develop for Mac and iOS, and I would worry about the other platforms later.
So I spent some time with Swift, which also means spending time in Xcode (Apple’s IDE). I say right off that Xcode just never worked well for me. It’s an okay IDE, but it feels disorganized and clunky. There’s nothing intuitive about it. And worse, I found it unstable. At one point, after compiling an app and running it in the iOS simulator, the app crashed, bringing down the app and Xcode. Upon restarting Xcode, I found that the objects that I had placed on the main storyboard of the app were completely gone. I had no idea why. And sure, I could have reverted to a backup, but this was the final straw for me. Swift just wasn’t a good fit.
Hybrid Apps / PhoneGap
I’m not going to say much about this, because it still feels like I went insane for a few days. I had decided that I should also look at developing hybrid apps - a combination of a native app that was essentially a wrapper for a Web app. Specifically, I looked at PhoneGap.
I went down that rabbit hole, saw some frightening things, and quickly climbed back out. My advice: Just don’t go there. I’m not going to say anything more on the matter, and if pressed, I’ll deny that it ever happened.
Back to Xojo
And so I’m back to Xojo - and I’m feeling really good about that decision. Of the three environments that I looked at, Xojo was the one that felt the most comfortable to me. It has a nice, well organized and reliable IDE. The language is powerful and easy to learn - and the IDE’s code completion makes the process even easier. Its support for iOS is top notch. Sure, there are a few things missing, but there doesn’t seem to be anything that you can’t do using declares.
Another thing that makes Xojo appealing to me is its community. There’s a strong Xojo community, with a well organized forum. The Xojo developers are friendly and knowledgable. There’s even a Xojo Developer Evangelist. How cool is that?
So, what happened to my desire to develop for Windows and Android? It’s gone. When I really thought about it, I realized that I have no interest at all in developing apps for those platforms. I despise Windows, and have absolutely no interest in supporting users of it - or Android for that matter. I’m a Mac guy. It’s that simple.
In the past few days, I’ve gone deep into Xojo, and I’ve nearly got my first iOS app ready to go. It’s an app that complements the ICD-10 Web site that I released this morning, and if all goes well, I hope to submit it to the App store shortly. I’ll post about that experience as it unfolds.
I’ve also been working on ways to make it easier for FileMaker developers to develop using Xojo. I’ve been developing a Fireball class for Xojo, which is the realization of the Fireball technique that Hal Gumbert and I have been working on. It allows us to easily integrate non-FileMaker based apps with hosted FileMaker databases. I’m using the class in my app, and it’s working very well.
Hal and I are also working on a library of FileMaker-to-Xojo translation functions. It’s similar to the FileMaker-to-PHP function library found in FM WebFrame. The goal is to make it easy for FileMaker developers to develop in Xojo using the FileMaker functions that they are familiar with. For example, we’ve got an "fmSubstitute” function that is the equivalent of FileMaker’s "Substitute” function.