Xojo 2014 Release 3

Xojo 2014 Release 3 hit the public today.  It is, without a doubt, the most ambitious release we’ve seen in quite a while.  This release brings the much anticipated iOS target and while it’s a first release it seems pretty solid.  There are new licensing and pricing options and a new framework that is ambitious in scope and has long-term implications to all developers.  And, as with every Xojo release, there are bug fixes, changes, and additions to the IDE and all of the targets.  So let’s dig in!

New Licensing and Pricing

Xojo has changed the pricing structure to make it simpler.  Purchasing Xojo has moved to a single purchase price and upgrade pricing is gone.  The single-platform desktop license is $99 a year.  Console is $149, Desktop (with all 3 platforms) is $299, Web is $299, iOS is $299, the Pro license is $699, and Enterprise is $1999.    A new Pro license iOS but existing Pro licenses will have to be upgraded to get iOS.

Licenses are set to auto renew every 12 months.  You can turn this off in your Account settings page.  I can see this as a convenience and also a bummer for some folks.  The licenses, for some, are pricey enough that you probably want to turn off the automatic update.  For those corporate accounts it’s probably not a big deal.  I’m sure this will generate some controversy.

My opinion (since you asked):  When Xojo announced iOS they never promised that it would be in the Pro license.  With the amount of work they put into it, and that it’s essentially a new SKU, I would expect the Pro license to be more expensive.

Am I happy with the no upgrade pricing?  I’m ambivalent, at best.  Yes, it costs more for me, but it’s a lower cost for people new to Xojo.  More potential customers means more demand for my products and services.  I think the goal for Xojo is to grow as much as they can so hire more engineers and do ambitious things.  For us, we’re kind of a captive audience since we use Xojo for 99% of our business so for me it’s the price of business.  Frankly, coming from the VB world we were used to paying tens of thousands of dollars a year to stay current so the relatively minor price increase doesn’t phase us much.

iOS Target

R3 is the first release for iOS.  This is a huge undertaking and represents the culmination of many man years of work.  iOS is a completely different beast.  It required a completely new compiler (LLVM), new editors, new frameworks, and new ways of doing things.  I must give the engineers at Xojo major kudos for getting it done (yeah, I wanted it last year too but some things just take time).  As a first release, Xojo iOS is pretty solid.

Xojo has always been about hiding the ugly implementation details from users and iOS is a great example of that.  If you’ve done any iOS development you know that Apple really likes the MVC (model – view – controller) pattern.  Xojo does not necessarily fit that pattern (though it can).  So for the engineers to have it ‘just work’ like we we’re used to in console, desktop, and web applications is impressive.

Xojo for iOS uses the iOS Simulator that comes with Xcode so your are required to installed Xcode 6.1 and agree to its licensing terms to pretty much do anything.  After that when you run an iOS application in the debugger it creates a package that can run in the iOS Simulator, loads it, and starts it in the simulator.  For Xojo developers this is not a huge departure from what we already do (though the cycle time in the debug cycle is longer).

To deploy on your own device you have to join the Apple iOS Developer Program ($99/year) so you can create a Provision Profile and install the app via Xcode.  Joining the program also allows you to submit your app to the App Store for sale.  During the beta process several developers submitted apps to the app store but I’ve not heard if they have been approved yet (not that this was recommended during the beta process by Xojo, by the way).

Developing for iOS will require some new thinking for existing Xojo developers.  You’ll have to figure out the relationship between the application object, screens, and views – especially how screens and views interact given that screens can have single views, tabbed views, and split views and each of those content views are independent (one of the videos I added to our training library today goes into this).  Developing for iOS also uses the new framework so some things are different.

Screen Shot 2014-12-09 at 10.07.16 AMThe new framework has a namespace that might be confusing for a while.  For example, a timer is really Xojo.Core.Timer.  In the shared build settings if the Simple References is set to true, you can reference a timer as Timer and it can figure it out on its own that it’s using the new framework (mainly because that’s the only one it can use).  There is a new Using keyword that lets you choose which framework to use in a module or even in a method.  Another example of how the Simple References is convenient is RandomInt is really part of the Xojo.Math framework but with Simple References on you can simply use RandomInt rather than the full Xojo.Math.RandomInt.

Another thing that’s new for iOS is Auto Layout.  In the View Editor we no longer have the Top/Left/Right/Bottom lock properties.  It’s been replaced with Auto Layout and it can be confusing to use.  I promise you that it gets easier with use.  Auto Layout is not perfect in this release as it seems rather finicky.  I have no doubt it will improve with time.

Screen Shot 2014-12-09 at 10.07.35 AMPerhaps that hardest part of Auto Layout is coding the position of the controls since you can’t just say control.left = 10.  You have to add or change the Constraint of the control.  To understand the complexity of this, take a look at the UI in the Inspector.  Now translate that into code.   To say that this is going to take some adjustment by everyone is to be an understatement.  But, in the long run this will make complex UI easier and eventually it will be coming to the web and desktop targets.

For a first release, iOS is pretty solid.  To say that it’s 100% complete would be an incorrect.  There are a number of things missing in the first release that might make life hard for a while.  There are no built-in Date/Time pickers though you can add them via declares (there is an example of this in the iOS examples folder).  There is no picker control (the equivalent of popup menus) and there is no scrollable view yet.  No camera support.  No Location support, There is also not a Style Editor that allows you create an overall look and feel of your application though you can certainly set Fonts, colors, sizes, etc. via the Inspector and code.

Overall there is a lack of depth in supporting libraries.  During the beta process users figured out the declares to get the Date/Time pickers working via declares as well as several other useful things (check out the iOS declare examples that ship with Xojo).  I’m sure the community will come together to fill the needs we come up with and I expect the iOSLib project be birthed soon (if it’s not already in the works).  Check the iOS forum for news on this if and when it appears.

The New Framework

iOS requires the new framework, but you can start using the new, non-iOS, framework in the console, desktop, and web applications.  You are not required to use it in R3 or even in the near future.  I’ve heard that the existing framework will be around for a minimum of five years (forever in computer terms) so there’s no imperative to start using it this instant.

The new framework is very cool, though, because it adds some much desired consistency to the framework.  You’ll never have to remember if an index is 1 based or 0 based.  Everything is zero based.  Method and property names try to be explicit in what they do, and, in general, the new framework helps eliminate common mistakes in code.  One example of this is the Date class and with the current framework it’s often used incorrectly which leads to code that fails subtly (I know because I’ve  been the victim of this).  The new Xojo.Core.Date class is very explicit how it’s used and eliminates the most common mistakes.

There are two major data type changes to the new framework.  The first is the Text data type.  Really, it’s still just a string to us, but it makes a distinction about encodings and characters.  No longer is it byte-based but a character is now a ‘user-perceived character’.  This means that a user-perceived character in Japanese is one character but it’s multiple bytes in length and the various string methods will be able to work properly with them (there are no byte string operations now).

The major implication of this change is that sockets that used to bring things back as a string now bring things back in a MemoryBlock and you’ll have to extract the data from it.  This one change eliminates various issues that many people have had over the years with string data that has no encoding information and being able to decode the data properly.

The other major data type is the new Auto type.  This is the replacement for Variants.  Variants have always been weird because they implicitly convert data from one type to another.  This led to some subtle data errors (think double to integer and back again) that were hard to find.  The new Auto does zero implicit conversions.  It’s up to you to figure out what’s in the Auto variable (using Introspection this is pretty easy) and then you have to covert it yourself.  If you stick an integer into an Auto variable it will come out as an integer and if you want to convert it you’ll have to do it on your own.

Before you freak out about the Auto data type I spent 30 minutes coming up with my own Auto extends module that did a number of things.  First, it checked to see what was in the variable so if I wanted to convert it to an Integer I’d check to see if it already was an integer.  If it was the conversion is easy.  If it’s not, I then used the various conversion routines to convert it to an integer.  Example, if the Auto variable is set to “Bob”, the type check will come back as Text.  Then I can assign the integer value using the Integer.FromText shared method that’s in the Integer datatype.

So will this cause some heartache?  Yes, yes it will.  Will it cause a lot?  Nope.  Our ActiveRecord classes used a bunch of variants to hold data of any type.  I spent maybe 30 minutes converting it over to use Auto and Text and another 30 minutes or so testing.  The more complex your classes the more complex this conversion but I don’t expect it to be as awful as you think it is.

As a reminder, I did say that you don’t have to start using the framework immediately.  I highly recommend that you start working with it because I think you’ll find some gems that you’ll want to start using.  The drawback, of course, is that your code will not be backwards compatible with older versions of Xojo.

Web Apps

WebLabels had some work done on them to improve IE 9+ compatibility.  Unfortunately, this may have caused some other issues with WebLabels in dynamically embedded WebContainers.  Look in the forums for a temporary fix if you have this problem.

Web apps on Windows can now use Windows Service events.

Web apps now have a HandleURL event for handling any request that would normally results in a 404 Not Found error.  This should allow you to use almost any URL within your web app for whatever purpose you want.

Miscellaneous Stuff

The R3 compiler is now much pickier about some things.  Properties and structures that are defined in multiple modules will get flagged as being duplicates.  In one of my projects I found that I had two global db as SQLiteDatabase variables.  How did the compiler know which one to use and could some odd user bug reports point to this type of bug?  I don’t know but I’m glad the compiler is smart enough to figure this out now.  Users of MacOSLib will want to update to the latest version since it is a major offender of this particular issue.

The IDE has a slew of changes.  Obviously the addition of iOS is the biggest change but a lot of cleanup in the editors and Inspector has occurred.

The debugger received some love this release too.  No longer do you have to have over variables to get them to refresh.  Variants now display and behave the same as the data stored in them.

Yosemite is now fully supported in the IDE and in compiled applications.

Be aware of a possible behavior change if you use HTTPSocket or HTTPSecureSocket.  It no longer strips off user specified content-length or content-type headers if no post content was specified.

The desktop hierarchical listbox has two new methods.  The RowDepth returns the nesting level of a row.  The RowIsFolder allows the user to get or set the ‘folder’ status.

The SSLSocket class now has TLS v1.1 and v1.2 support.  This means that HTTPSecureSocket, Pop3SecureSocket, and SMTPSecureSocket support it as well.

The Currency data type received some love and should be more accurate in both Xojo and in XojoScript.


As always, check the release notes to see the complete list.  This release has more than normal list of new and changed things.

The addition of iOS is a huge deal.  For a first release it’s pretty solid and I expect that will generate some interest in the product.  The new framework is both exciting and frightening at the same time because it introduces some uncertainty of when to start converting over to it.  But, as I said earlier, you don’t have to start now and it’s advisable to start looking at it and become familiar with it.

What excites you?  What concerns you?  Anything big that I didn’t cover?

[Update] Change ‘upgrade’ to ‘renewal’.  You can upgrade from a lessor license to a better one still but the 50% off renewal pricing has been discontinued.

11 thoughts on “Xojo 2014 Release 3

  1. “One example of this is the Date class and with the current framework it’s often used incorrectly which leads to code that fails subtly (I know because I’ve been the victim of this).”
    Could you elaborate?

    • Sure. This is from Normans example from the beta list:

      dim d1 as new date
      dim d2 as date

      d2 = d1
      d2.totalseconds = d2.totalseconds + iSomeValue

      then wondered why it does not do what you expect?

      The new framework you can’t make this same error. I’m sure we’ll make others. 🙂

  2. Thanks for this detailed review. Glad to see your positive assessment of the major new features.
    It’s also nice to see the ongoing refinement of Cocoa. As someone who does a lot of work with graphics, things like [“DrawPicture no longer interpolates the image if the AntiAlias property is set to False”] are a big help.

  3. Thanks for the indepth review. However it’s obvious you have some sorts of financial interests in promoting Xojo. I think it breaks good ethics to use an ‘insider’ to write reviews for a product.

    At best it’s a bias review, never using any real critical or negative words about a deeply flawed development tool. I have time and time again submitted errors for the linux version and month, nearly a year later nothing is moving.

    You are too soft and friendly with Xojo.

    • Well, Vic. I am not really an ‘insider’ though I’ve used the product, successfully as a consultant, for 15 years. We have satisfied clients all over the globe.

      I invite you to look over the seven years of blog posts on this site and look at the many articles that I’ve been critical of Xojo. Do I have a vested financial interest in the company? Absolutely, since we are a 100% Xojo shop with multiple full-time developers.

      As far as your Linux issues, I can’t speak to them. Very few of our clients ask about a Linux version of their desktop apps. It might be true that the Linux version of Xojo is deeply flawed. We are a Macintosh shop, first and foremost, and do testing in Windows. Those platforms are pretty solid (though not without flaws). I still hate the Navigator but bitching about it every day doesn’t do any good. I said my peace and moved on.

      Submitting errors to Xojo should be as detailed as possible. If you give me 3 of your top bugs I’ll be happy to review the Feedback report to see if it’s a reasonable submission. Who knows, perhaps that will turn into a not so friendly to Xojo blog post.

  4. Bob,
    I believe You have come too close to Xojo Inc. This is not a review You’ve written it’s more like a promotion for the new release.

    How about comparing the new kid in town with, for instance, Xamarin and Corona?

    • Thanks for posting Dennis, but I think you’re wrong.

      I don’t think I ever claimed that this article was a review of Xojo, the product. I reported what was different in 2014 Release 3, talked a bit about the licensing changes, the new framework, some bug fixes and changes, and of course iOS.

      Now, if you had searched the site, I have done a comparison piece between Xojo and Xamarin a few months ago. I am critical of Xojo on many fronts (still hate the Navigator, and not sure if the new framework is good or not).

      Am I close to Xojo? Of course I am! I am a Xojo developer (15 years and going strong), using the product for clients that want Xojo written applications, writing on a site with a tag line of ‘Software Development Using Xojo’, what would you expect me to be writing about?

      It sounds like you have an axe to grind. Send me your top 3 Feedback reports and I’ll take a look at them. I’ll review or completeness and accuracy and write about them. How’s that?

  5. Thanks for a good review. As someone who tried to work through many of the changes during the beta, I think that you review is fair and unbiased.

    I think that the changes to the framework can certainly help remove some subtle bugs and the fact that the classic framework will be supported for sometime will help Xojo developers upgrade to the new framework without too much panic.

    I am eagerly awaiting the 64bit compilers.

    • I am looking forward to the 64 bit framework. It should eliminate some issues – especially in Linux web apps. I’ve spent WAY too much time debugging web app installations. The 64 bit framework should reduce that considerably.

  6. Nice review, Bob. I still have a certain affection for Xojo and particularly the community. I use it for some in-house tools but am working in multi-platform mobile so it’s not an option for me as a main platform.

    I have just been pushing 90 client apps to the iTunes Store (yes, my hands hurt) and have so been constantly reminded of the forthcoming 64bit requirement – new apps need to be 64bit as of February.

    I mention it because this may be a giant trap for people starting new projects in Xojo iOS. If they don’t deliver 64 compilation within the next two months, your apps next year won’t be accepted.

Comments are closed.