Xojo 2016 Release 2

Last week Xojo 2016 Release 2 was unleashed to the masses.  There are a lot of changes and tweaks in this version and if you are creating web or iOS applications there is a lot of like about this release.  There are also a myriad of changes and enhancements that should satisfy most developers.

iOS Stuff

The biggest changes in R2 is for iOS and these are things that developers have been requesting since its initial release.  Support for iOS 7 has been dropped because its market share is less than 20% and the minimum required version is now iOS 8.  This also means that Xcode 7 or Xcode 8 needs to be installed.

The Xojo engineers added iOSScrollableArea which allows you to view and display content that is larger than the view.  This is a very welcome addition and is worth the upgrade for this feature alone.

R2 also adds the iOSLocation class that allows your application to request location coordinates as well as get updates from the device.  Once your application gets permission to access the device location you receive changes via the LocationChanged event that gives you latitude, longitude, altitude, course and speed parameters.  An Accuracy property lets you change the desired accuracy.  In addition to iOSLocation Xojo has added the iOSMotion class that allows developers to access the accelerometer and gyroscope.

iOSTable was arguably the most useful and least powerful control in iOS for Xojo and this release definitely gives it some love.  You can now embed controls in the cells of iOSTable by using the iOSCustomTableCell class.  This allows you to create some very rich and powerful UI that lives in the cell of an iOSTable.  I guess the best equivalent in desktop and web terms is that the iOSCustomTableCell is a specialized ContainerControl you can put into an iOSTable cell.  I’m looking forward to using this.

They’ve also added support for Row Actions in the iOSTable.  The new ActionsForRow event passes in the section and row and you have to supply the iOSTableRowAction array.  The iOSTableRowAction has a title, an Auto tag and a Style.  The style can be either Normal or Destructive with Destructive changing the background of the Action to red (does this ever vary? – not sure).

The new iOSSharingPanel allows you to share pictures, text and URL’s with any registered system service or app.  That’s a fancy way of saying you can share this data between applications.  It’s the iOS version of the clipboard available to desktop applications.

The iOSPicturePicker class allows you to select images on the device or take pictures with the camera.

To avoid confusion for users, the old SQLiteDatabase class for iOS has been renamed iOSSQLiteDatabase.  The corresponding recordset class is now named iOSSQLiteRecordSet.

Non-IOS stuff

The Web framework is now HiDPI capable.  It works similarly as desktop apps in that it queries the browser for the scaling factor.  Then, the application serves up the proper image if it can.  You can change how this works by changing the Supports HiDPI in the Shared Build Settings.

In Windows there are a number of significant HiDPI changes that make it work better in Windows 8.1 and 10.  Perhaps the biggest Windows change is that Xojo.Net.HTTPSocket is no longer much slower than HTTPSecureSocket.  I have not had a chance to look at this one in detail yet so if you’ve had success or failure with it, please leave a comment below.

Always check the release notes that are in every release.  I’m just hitting the highlights out of hundreds of line items and you never know what might be there that affects your application.

As with any new release it’s better to test your project against it before releasing it into the wild.  In my own testing I had some instability with converting an old web project (started around the very first public beta of Web Edition) to use HiDPI graphics.  This involved adding an ImageSet and adding the 1x and 2x graphics, deleting the old graphic, and then fixing it in all locations in the project.  I was able to crash the IDE but all of the crashes were different and, of course, none of it was reproducible.

The Future

The 800 pound gorilla in the room is a 64 bit IDE and 64 bit debugging.  Things like XojoScript are holding back the IDE from being 64 bit.  I would also imagine that not having an integrated debugger available in 64 bit is holding back that as well.  I know we are avoiding releasing some 64 bit projects because of these limitations. We’ve also been playing around with the Raspberry Pi and it’s definitely not very useful without the debugger.

We need the 64 bit debugger.  Let’s hope that R3 provides us with some relief in that area!

How has your experience been with R2 so far?

Xojo iOS without Android

I will be honest and say that I did not think that Xojo for web apps was going to amount to much of anything.  Granted, I said this as I was struggling with a beta of the very first release to do some actual production work.  Since then it’s gotten considerably better and more stable and it’s become an increasingly large portion of our consulting work.

I was asked the other day what I thought about Xojo for iOS.  I replied that it’s stable and the community seems to be coming up solutions at a much faster pace than Xojo for web.  But until it starts bringing income into my consulting business I’m hesitant to say much more about it.

Let’s talk about that aspect of it for a bit.  When web came out I immediately landed a few consulting projects which was an awesome (and horrifying) way to learn the new framework.  Here it is roughly six months after release and I’ve only had a few nibbles but no actual projects on Xojo for iOS projects.  This despite the ten plus hours of training video I’ve created for Xojo for iOS.

So it makes me wonder if Xojo for iOS is really going to take off.  Part of me wonders if Xojo misunderstood the market for mobile apps.  Sure, iOS is where the money seems to be, but Android has the marketshare and Windows mobile (whatever they call it these days) just keeps hanging around.  Xojo simply doesn’t address Android or Windows mobile.

I think one could reasonably argue that part of Xojo’s strength on desktop is that it makes decent apps that are cross platform and it doesn’t matter which platform you develop on.  You do have to spend extra time for a Xojo app to be 100% compliant on Mac OS X and Windows (I’ll leave Linux out of the mix since I don’t cater to that crowd) and I don’t think many people would argue that if you were going to make a Mac-only application you might want to stick with xCode and Swift or Visual Studio for making a Windows only application.

Apple and Microsoft will always have the best gadgets and goodies for those platforms.  That’s just a fact.  Xojo is often a compromise of the lowest common denominator between the platforms.  It’s RAD capabilities are important but I’m not sure that I’d give it THAT big of an advantage once you get past the learning curve of all the respective platforms and languages.

Xojo for iOS is nice and works well but I feel that without Android it’s not going to get much traction.  Xojo is known for cross-platform apps yet it only supports one mobile platform.  If you were going to go the trouble of developing for more than one mobile platform wouldn’t you go with a tool that supported more than just iOS?

I mean no disrespect to Xojo.  They’ve accomplished a pretty amazing thing.  They have an IDE that allows you to create iPhone and iPad apps without learning Swift or CocoaTouch.  However, you are limited to developing on Apple hardware (that’s Apple’s not Xojo’s fault) and to do any remote debugging you have to use the iOS Simulator that’s part of xCode.  Just that part eliminates a good chunk of Xojo’s potential market (the Windows and Linux users).

Xojo for iOS works well.  It has good developer community support.  I see no reason why developers wanting an easier mobile development environment wouldn’t choose Xojo except for one thing:  It’s iOS only.

So what do you think my fellow Xojo users?  What do you think of iOS for Xojo?  Is it anything without Android and Windows Phone or is it missing something else?

iOS For Xojo Notes #1

After doing about five hours of training video for iOS for Xojo I’ve discovered a few things.  First, the new framework will take some getting used to.  It’s not that it’s difficult to figure out, it’s just different.  Each little difference requires that I analyze what it’s doing and evaluate if I need to change my coding practices.

We’ve already talked about one of those differences with the FromText methods.  In the old framework using string.val does a lot of assumptions (not all of them good ones as we’ve come to find out) and those assumptions will either result in a valid number or a zero.  Blank strings also convert to a zero as well.

We’ve all been used to those assumptions for so long that we didn’t even realize the assumptions.  Or we ignored them.  Either way, we depended upon them.  The new framework uses much more stringent rules and if the text is outside of those rules it will throw an exception.

We can argue all day long whether it’s really an exception but that’s an argument for a different day.  Xojo has decided that errors shall not be silent (am I the only one that just said in a Gandolf voice, “Thou shall not pass (errors)!”?).  Errors causing excpetions will change the way we code and I’m still not entirely sure that I’m comfortable with those changes yet.  I’m sure it’s really a matter of getting used to them.

The other thing I’ve discovered is that events on iOS controls are different than their desktop and web counterparts.  In desktop and web if you set the value of a control it fires their relevant change events.  In iOS it does not.

In desktop and web apps we’ve actually relied upon this behavior.  Rightly or wrongly, it was there so we did.  This also meant, however, that we’ve had to somehow make a distinction of whether or not the user or the developer set the value (and caused the event).  Usually it was a matter of setting the control enabled = false while loading the data and then setting enabled = true when we were done.

Since iOS does not have this behavior I suspect we’ll start putting less code in the events of controls and instead use a method that does the work.  This is probably a good thing.  Being dependent upon the events to do something will make us better programmers in the long run (hopefully).  It’s not really a huge change but it’s a somewhat important one given the background Xojo developers have in desktop and web.

At first I thought this might be a bug but after cornering a Xojo engineer this was by design.  I can live this change now that I’m aware of it.  Do you have different thoughts on this?

What significant changes have you found in iOS that were a surprise?

Xojo 2014 Release 3.1

Xojo 2014 Release 3.1 hit the internet today. This release is a minor maintenance release and is recommended for everyone.

Web received a number of fixes. Checkboxes now work properly on touch devices. Label offsets are calculated correctly when the initial text is an empty string. Labels that had been on a container that had been set invisible in the IDE and visible via code now appear properly.

It’s a shame that these bugs made it into release.  Beta testers were so enamored with iOS that desktop and web didn’t get much attention.  But then again I was using the beta’s for production web apps and didn’t spot these bugs either so my bad too.  They’re kind of obscure in how to set them up and I generally don’t do either of those.  Hopefully with 2015 R1 we’ll get some better testing for targets other than iOS.

iOS received a few critical fixes. The first is that SQLSelect and SQLExecute now work properly (it was randomizing the data). The second fixed soft declares.

If you have not played around with the iOS SQLiteDatabase class the SQLExecute and SQLSelect methods now have built in prepared statements so there’s no need to through the steps of creating the prepared statement and then binding the values.

The IDE received a few minor bug fixes.  So did the compiler.

I reported a bug with the new Xojo.Core.Timer.CallLater in Windows yesterday. It generates an exception in a compiled application but in the debugger it generates an exception in the IDE! Too weird to be anything bug true. 🙂

I am looking forward to 2015 (seems weird to be typing that) Release 1. It looks like iOS builds will be 64 bit in that release. That means that Xojo is creating 64 bit builds for standard and debug builds in the iOS Simulator (Intel) and, at a minimum, standard builds for device deployments (ARM).

Presumably, this means that the IDE can already understand 64 bit debugger instructions, right? Is 64 bit for other targets far behind? Let’s hope not!

We already know the fiasco over the FromText methods in the new framework are being addressed in 2015 R1. In addition to FromText Xojo will offer a much less stringent Parse method that should satisfy most developers.

Any bugs that you’ve seen in Release 3? Anything you’re really looking forward to in the next release?

iOS Development on Xojo

Xojo 2014 Release 3 was a big one for Xojo.  R3 allows the average person to create iOS applications in Xojo, in a RAD language, in an easy to use IDE.  I think most people will find developing iOS apps easy in Xojo.

The iOS applications that Xojo creates uses native controls.  This is huge because when iOS 9 comes around and Apple changes the native controls (because you know they will) Xojo iOS applications will most likely just work.  Some other iOS development environments use images for their controls which means they will have to update their tool set to work with the updated look.

For a first release, Xojo for iOS is pretty solid but it is definitely lacking in some areas.  Some of the controls are not fleshed out completely.  An example is the table.  What it does, it does well, but it is lacking in options that many developers will want.  Views aren’t scrollable yet and there are no UI pickers yet.  There is a Date and Time picker example that was done via declares but it’s not built-in to the control palette yet.

Another area that I’m sure the community will rally around is converting the iOS frameworks over to Xojo.  There is a similar project on the Mac OS side called MacOSLib and I’m sure some of the same developers will be active on both (they share some similar libraries after all).

Currently Xojo allows you to debug your application while it’s running in the iOS Simulator.  It would be awesome if Xojo could get it working so that we could debug while it’s running on the device.  Given the provisioning profile and the ability to manually add apps to the iOS device this might be possible but, to be honest, I don’t know what the sandboxing rules would be for that.  I also don’t know if that means Xojo developers in Window or Linux could deploy directly to the device or not (don’t hold your breath on this one, by the way, but one can always wish).

I am impressed with iOS in the first release.  Xojo has managed to take something that’s complex and made it easier.  If you already have some Xojo experience the transition will be a piece of cake (although there are framework differences between iOS and Desktop/Console/Web).  I think anyone with iOS development aspirations should take a look at Xojo.

We’ve been busy doing training videos!  We currently have over 4 1/2 hours (and growing) of iOS specific training videos available to subscribers over at http://xojo.bkeeney.com/XojoTraining/.  Come check it out!

[Update] I forgot to mention that the first couple of iOS apps developed with Xojo mad it through the approval process on Thursday.  Excellent news!

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.

Change is the Only Constant

No one likes change.  I know I don’t.  It introduces an unknown element and unknown equates to scary.

Back in college (granted, this was decades ago) the language dejour was Pascal and C was an upper level CS course (being an electrical engineering student I never had to take it).  Visual Basic wasn’t heard of and Xojo wasn’t even a wet dream yet.  Since then C++, C#, Java, Javascript and a myriad of other languages have come.  And some have gone too.  Then came the frameworks that made life much easier because no longer did we have to reinvent the wheel on every project.  The only constant in software development is change.

Xojo has been around for over fifteen years.  I think anyone that’s been using the product for any length of time can say it is not a static product.  It supported 68k Mac’s back in the day, then PPC Mac, then Universal Mac apps, then Carbon, and now Cocoa.  For Windows there’s been a bit more stability but things have changed from Windows XP to Windows 8.  Linux, well, it seems that there’s a new Linux distribution every month that are slightly different from each other.

Xojo introduced the ability to create web apps that ran on Mac, Windows, and Linux and introduced a new framework for the controls and for web specific things.  Overall, however, the web framework was exactly the same as the standard framework even when it didn’t make much sense (e.g. web controls having drag events when there’s no way they’d work like the desktop version).

And now Xojo is working on an iOS version (due out soon) which uses an entirely new framework.  iOS is a completely new beast.  It most definitely is not a Mac, Windows, or Linux desktop or console app.  When you think about it, making web apps is really just a console app so it wasn’t a big stretch since Xojo has been doing console apps for a while.

iOS is very different.  It uses a completely different processor which requires new system calls.  Heck, there are no ‘windows’ but has ‘views’ that are sort of, kind of, like windows.  The metaphors between mobile and desktop (and web) are completely different.

For 15 years the Xojo framework has had a lot of new stuff bolted on.  Different Xojo developers did different things but for the most part it’s just worked.  It was wildly inconsistent and every developer, like myself, that has spent a lot of time working with the language still has trouble remembering which framework calls used zero or a one index.  Names weren’t always consistent and some things were simply harder than they needed to be.

So Xojo is making a new framework that eliminates the confusion.  All indexes are zero based – no exceptions.  Methods and properties are consistently named so (theoretically, at least) if you are using an object you’ve never used before you should be able to make reasonable guess at what the method you want is.  Obviously, there will be exceptions to this rule but the goal is to make it easier on us developers in the long run.

In the long run…That’s that key phrase.  What we’re finding out is that it’s generating a bunch of concern amongst Xojo developers.  I get it.  Change is hard and it’s scary.  But it’s not that bad.

Here are the facts:

1.  The existing framework isn’t going away.  It will be around for many years (if not forever).  Xojo has said the existing framework will be 64bit and will be released sometime in 2015.

2.  The new framework is only required with iOS.  There are zero Xojo iOS customers right now.  All desktop, console, and web applications, are okay and need zero modifications in Release 3 to work.  NO CHANGES REQUIRED!

3.  You will be able to intermingle the new and old framework.  Xojo has introduced a Using keyword that allows you to use both at the same time.

Xojo isn’t forcing you to use the new framework in Release 3.  Your apps will still compile and work just like they used to (the compiler does find new types of bugs so don’t be surprised if you have to fix a few things).

Should you start looking at the new framework?  Absolutely!  Should you start converting code over to the new framework soon?  Well, I would hold off a release since the new framework is still in some flux (I think).

Porting code to the new framework isn’t all that difficult.  Is it work?  Yes – especially if you have extensive code libraries that are shared between console, desktop, web, and iOS.  Co-mingling new and old frameworks will be painful for a while but the nice thing is that the new framework (that parts that exist, at least) will work on all platforms in Xojo 2014 Release 3 and beyond.

The new framework is different.  You might have to looking at every line of code.  I personally won’t do this with existing code but certainly all new code will probably use the new framework.  It is the future and I hate coding things twice.  The biggest problem is legacy code and that the new framework is not backwards compatible.  As a 3rd party controls and library developer this has the potential to mess up development for a while.

The new framework is coming and it’s not all that scary – really.  iOS users will bear the brunt of the changes, at first, but everyone can start using it now and I encourage you to start looking at it.

Xojo 2014 Release 2.1

Xojo 2014 Release 2.1 was released this week. This maintenance release is huge in several important ways.

This is the last version of Xojo that will build Mac Carbon apps. The upcoming changes to the framework for iOS and 64bit (and who knows what else) have made it impossible (or at least unfeasible) for the engineering team to keep supporting the Carbon framework. So long Carbon, we have to split up. It’s you, really, not me.

Since this will be the last version to support Carbon some nagging bugs were fixed in the Carbon framework. The hard crash that occurred when creating a new instance of the XMLDocument has been fixed. In addition a bunch of plugin issues for Carbon were fixed.

Cocoa apps that use RegEx will now pass submission to the Mac App Store.

For web app developers a big change was made to HandleSpecialURL that breaks everything that depended upon how the old, incorrect way, WebRequests were handled. I know this affects Web Custom Controls and it may also affect Studio Stable Web Essentials (unconfirmed). More info in a Xojo blog post at http://www.xojo.com/blog/en/2014/08/handlespecialurl-changes-in-2014r21.php

A few other web bugs were fixed. WebSession.Quit now properly clean and close the Session. A bug with WebContainer.EmbedWithin used in a open event (never a recommended way, if you ask me) that would cause WebLabels and WebLinks to offset was fixed.

There were several of database class changes too. SQLite now uses FTS4 with unicode61 tokenizer on Mac OS X. MySQLCommunityServer SQLExecute and Prepared statements no longer assume the statement is UTF8 encoded. The ODBCDatabase DatabaseRecord.Insert no longer inserts the wrong value.

As always, read the release notes for additional information and Feedback ID’s.

This dot release is critical for those developers still building for Carbon. iOS will (presumably) be out in Release 3 in at least beta form and the new framework is causing changes in a big way. I’m sure some of those changes will be subtle but some will be a smack to our collective faces.

To paraphrase Game of Thrones, “iOS is coming.” Sorry, couldn’t resist. 🙂

Xojo vs Xamarin

AndroidLast week when I was the guest speaker on Xojo’s webinar on consulting, I fielded a question regarding Xamarin.  The basic gist of the question was if I felt that Xamarin was a threat to Xojo.  At the time I had heard of Xamarin and read a few articles on it but that was about it.  In the week since I’ve been doing more research on the topic.

Xamarin is an interesting development tool.  To sum up what it is in a sentence or two probably does it some injustice but here’s my take.  Xamarin takes the C# language and .NET framework and has ported it to Mac OS X, iOS, and Android.  This allows developers to use the Visual Studio IDE on Windows, and Xamarin Studio users on Mac OS X and Linux to create native Mac OS X, iOS, Android apps, in addition to Windows desktop and Windows Phone apps.

I threw Mac OS X in there since it’s listed on their website but it appears to more of an afterthought since the focus seems to be on mobile applications.  Indeed, their mantra is that they want to make the best development experience for mobile applications.

I am not a C# developer but like most modern languages it’s not the language that’s difficult to learn it’s the framework and .NET is arguably one of the biggest and most advanced frameworks around.  Having the .NET framework available for iOS, Android, and Mac OS X is a huge advantage for anyone already familiar with it.  Theoretically it should make the transition from Windows developer to cross-platform developer very easy.

Xamarin uses native platform user interfaces and compiles to native applications for each supported platform.  This is good in that you get the best of each platform.  The not so good is that it appears that you’ll end up coding each user interface separately (see Xamarin.Forms later on).  I can see the arguments going both ways on this whether this is good or bad.

Unlike Xojo, Xamarin does not have a built-in forms editor.  They give the option of building Cocoa and Cocoa-touch applications strictly via code or by using Apples Interface Builder.  You either stay in Xamarin to build everything via code or you exit to Interface Builder to design your UI.  I can’t imagine that’s very efficient but Interface Builder wasn’t always integrated in Xcode either.  As a developer you have to roll with the punches.

The Xamarin framework has some cross-platform calls to make life easier, but when it comes to iOS and Mac OS coding it appears that most of it is similar to Xojo’s ability to make declares into the native OS.  Again, you might call this a strength as you get the Apple methods but it also means that you’ll need to know each target OS in detail which can be a rather large learning curve.

Xojo abstracts as much of the platform as possible which means that a TextField on Mac OS has mostly the same capabilities as a TextField in Windows and Linux.  The strength in Xojo means that you don’t need to know the details of each platform but it also means that you generally get a compromise in functionality.  This is where system declares can really aid the Xojo developer.

Web Presentation

Xamarin’s website is gorgeous.  Nearly everywhere you go there are very helpful tutorials and videos explaining how to do things.  It’s also laid out in such a way that you can quickly find things.  The Xojo website is okay and relatively easy to find things but Xamarin goes out of their way to convince you to use their development tool.

The tagline on the Xamarin home page is “Create native iOS, Android, Mac and Windows apps in C#.  Join our community of 687,765 developers.”  Practically everything about the website screams, “Use me and you’ll make a great applications!”  It’s very professional looking and it’s all business.

The tagline on the Xojo website reads, “Create powerful multi-platform desktop, web & web-mobile apps.  Fast development.  Easy deployment.”  It’s not that Xojo doesn’t attract professional developers but their emphasis is on different things.

One thing that surprised me quite a bit was under the Support/Consulting Partners menu of the Xamarin website.  It’s a listing of Xamarin consultants and they are listed by tier (authorized or premier), by geographical region, and by expertise.  The Xojo website has the Find a Developer page.  The first says that it’s a serious language with a lot of software development partners and the other says that it’s a smaller community.

IDE Comparison

The Xamarin IDE is fairly simple and seems to be a hybrid between Xojo and Xcode.  Their Solutions pane is not nearly as complex as the Navigator and is far simpler and easier to use, in my opinion.  The Solutions list only shows objects unlike the Xojo Navigator that shows everything (methods, properties, constants, enums, etc) as you drill down into the object.  As you select an object in the Solutions list the source code editor loads all your source code.

If I had a major beef with Xojo is that they try too hard to dumb down the IDE.  You can’t just start typing away like you can in practically every other language/development environment I’ve ever seen.  Instead, you are forced to add methods through the Xojo UI.  You’re forced to do the same thing with properties, events, constants, enums and so on.  While this is great for people just starting out in Xojo it’s a limiting factor for more experienced users and forces you to use the mouse – a lot.  This means you can only see one method at a time unless you open up multiple windows whereas the Xamarin source code editor shows you everything in the source code.  Method definitions are defined via text in the code editor and not by a specific user interface.

Xamarin has the prerequisite autocomplete in the source code editor and appears to be work roughly the same as Xojo’s.  One thing that I REALLY liked about Xamarin was a tool tip showing you what the current parameter was.  As the user types the code editor recognizes where it is and provides a tool tip with a hint on what it’s currently expecting for the parameter.  This was one of my favorite features from VB6 and sadly, Xojo’s source code tip is an antique by comparison.

Xojo has a built-in forms editor.  Not only that but it has a reports editor, menu editor, database editor, as well as specific editors for a bunch of one-off items.  Xamarin shows objects and source code – that’s it.  So this forces you to either build all the UI via code or via an external editor.  While the Xojo editors aren’t perfect they are there and easy to use.

If you purchase the Xamarin Indie subscription (or better) you can use the Xamarin.Forms module which allows you to build iOS, Android, and Windows Phone screens from a single code base and it should speed up development.  However, I think Xamarin faces similar hurdles to Xojo in that a bug in their framework requires a new release so it’s no panacea.  And, you still build the UI via code not through a GUI editor.


Xamarin comes with four different subscription options.  The Starter Subscription is free and is good for individual developers and allows you to deploy Android, Windows Phone, and iOS apps to a device and to their respective app stores.  Apps are limited in size and you are forced to use the native UI builders.

The Indie Subscription costs $299 per year, per developer, per platform.  If you were interested in iOS, Android, as well as Mac OS X this would cost $807.30.  Apps are unlimited in size and can use Xamarin.Forms.

The Business subscription costs $999 per year, per platform, and per developer.  This gives you Visual Studio support, “business features”, and email support.  The same Android, iOS, and Mac bundle jumps to $2,697.30.

The Enterprise subscription costs $1899 per year, per platform, and per developer.  This adds Prime Components (pre-built UI assemblies), guaranteed response time of a day, hot fixes, an individual manager, a bunch of support and code troubleshooting options.

Xojo pricing is much simpler by comparison.  $99 for an individual platform license with a $99 1 year renewal.  $299 for all desktop apps (Mac, Windows, Linux) with a $150 1 year renewal.  $399 for web apps (running on Mac, Windows, or Linux computers) with a $200 1 year renewal.  $999 gets the Pro license which gives you all desktop, web, database server, and console/service apps, consulting leads, and beta program access and the 1 year renewal is $500.  The Enterprise license at $1,999 is everything as Pro with an additional day of custom training and the 1 year renewal is $1,999.  All of the licenses are for a single developer.

Xojo is considerably less expensive but the Xamarin pricing is inline with what professional developer organizations are used to paying for their tools.


If I were a C# developer I would be all over this product – especially if I wanted to my apps running on non-Microsoft computers and devices.  I believe this is where many of the nearly three quarters of a million developers are coming from.  I’m sure there are plenty of other developers that were tired of developing their mobile apps on one or possibly even three separate development tools too.  Xamarin makes the development process easier  by using a single tool.

Xamarin is really pushing mobile app development.  Based on the forum activity I suspect that Mac OS X isn’t in the limelight but because iOS is so similar I can see why it was added.  It’s another notch in the capabilities checklist for a growing tool and user base.  If you can do all of your development with one tool why wouldn’t you?

Xojo really isn’t competing in the same space as it’s for only desktop and web applications (an iOS version is currently in alpha testing and should be released this year).  Xojo has been doing cross platform desktop and console applications for nearly two decades and has transitioned through 68k, PPC, and Carbon to Cocoa on the Apple side as well as all the Windows and Linux variants and versions.  Web apps are relatively new but the framework is very much the same as the desktop side.

From what little we’ve seen of the iOS version (remember that it’s in alpha testing right now) it has a built-in forms editor and uses pretty much the same framework as the desktop and web (with specific differences, of course).  It promises to make developing for iOS extremely easy.  However, Xojo has no current plans to support Android or Windows phone.  This might be the one key difference that might make Xarmarin an attractive development environment for many.

Will this consulting company be switching from Xojo to Xamarin anytime soon?  No.  The cost of migrating to a new tool, retraining, and getting involved with consulting in a new environment is considerable.  If Xojo went away tomorrow I know which tool I’d look at first.

Xojo and the End of Carbon Support

In a blog post this week Xojo announced that they were dropping support for Carbon applications in Release 3 which is due in roughly 3 months. Furthermore, their reasoning for doing so was because the Carbon framework was causing interference with the ongoing iOS work.

At first blush, the decision kind of stinks. We still have some of our own applications and some client applications still using Carbon. Why are we still using Carbon? Mainly because of inertia. They work just fine as Carbon apps and we’ve identified enough items of concern (mainly threads) that will require some rework. Nothing that we haven’t done in other apps but for various reasons we (or the client) just haven’t bitten the bullet yet.

On the other hand, Carbon was deprecated over a year ago. If you haven’t tried to get your apps working in Cocoa by now I would say you have not been very proactive.

In other words, there was plenty of notice that Carbon was going to die a long slow painful death. Carbon bugs just aren’t going to get fixed unless they were critical and the definition of ‘critical’ gets less and less as time goes on. So it makes sense to just kill it and move on.

What about the iOS part? Well, that’s an interesting twist, I must admit. I can only speculate that getting iOS to work properly with all of the existing platforms was going to cause some major work (and future maintenance) in the Carbon framework. Why do all that work for a deprecated target?

This means that we should all be beating the hell out of our Cocoa applications to make sure bugs are squashed or decent workarounds found. If a Cocoa bug has been keeping you from moving to Cocoa and you haven’t reported it yet it’s your own damned fault. Now you have no excuse.  The clock is ticking.

For us, we have to have the discussion with our clients. Either they move to Cocoa and stay more or less in sync with the latest Xojo or we stick with an older version for Xojo (or Real Studio). The pain can be modest now or major later. From experience the more out of sync you are with the current release the more painful it is to update a project to the current version.

The good news is that Xojo Release 2 should work for many years so if you have to support Carbon apps it’s possible. The bad news is that you never know what Apple’s yearly updates will do to Carbon.  It’s probably just a matter of time before they kill Carbon but whether that’s one year or five only Apple knows.

I don’t see this is a huge deal for Xojo developers. The writing was on the wall for Carbon applications for a while. And honestly, Cocoa isn’t a huge transition for most applications and the end result is a much better application.

What do you think about the end of Carbon support?