Xojo 2015 Release 1

This week saw the release of Xojo 2015 Release 1.  This release has only a couple of new features (and one really big change) but many smaller changes and bug fixes.

The biggest new feature for Xojo is that you can now build 64 bit iOS applications.  This is a big deal because Apple is making 64 bit iOS apps mandatory for those apps submitted to the App Store.  As of February 1st submissions to the App Store must be universal 32 bit / 64 bit app bundles.

In December 2014 Xojo gave us a tentative roadmap and met it as 2015 R1 was in a usable beta on February 1st.  This is an accomplishment in and of itself since Xojo rarely, if ever, gives us their schedule.  Not only gave a schedule but met it!  I’d say lets give them some kudos for being a bit more open and accomplishing their task!

So far in testing it appears that 64 bit iOS applications are solid.  This also means that the 64 bit compiler is working and works in a 32 bit application and debugger.  According to their December 2014 blog post the next up for the 64 bit treatment is Linux web/console and this will be much anticipated by anyone that’s tried to install a Linux web app on a 64 bit Linux OS and struggled to find 32 bit compatibility libraries.

Besides 64 bit for iOS, there are a plethora of bug fixes to the IDE, the new framework, and the compiler.  To say that the IDE received some love would be an understatement.  These changes should make for a more stable development environment.  The number of bug fixes is too many to list here and I highly recommend reading the release notes.

The IDE Icon Editor received another makeover (how many is this in the past 15 years?) that allows it to handle 1024 by 1024 icons.  Some unused sizes were removed and the output format is now PNG rather than JPEG2000.  In my own testing it seemed that images moved forward from older projects didn’t look quite right so you should definitely make sure your icon images are updated before doing a release.

The Web framework received a few important updates.  WebLabels now work properly on dynamically created WebContainers.  WebCheckboxes respond properly on touch devices.  WebContainer mouse event handlers no longer interfere with scrolling.  WebListbox no longer offsets the selection if placed inside a WebContainer and accessed from a touch device.  Internet Explorer now supports gradient fills.

The new framework received new Parse functions for Integer, Double, Single and will act like the existing framework Val and CDbl functions.  What this means, in reality, is that Parse is more lenient and doesn’t throw exceptions when it can’t figure out the value of the passed in Text.  I think it’s obvious that Xojo is mindful of how we are using the new framework and reacting to our (valid) criticisms and wants and needs.

Windows and Linux users didn’t receive much love in this release, however.  The release notes only have a few for each and those seem pretty minor.  One bug fix that affects everyone, but appears to affect Windows more, was the Serial control.  It appears that it was possible to receive incorrect data.

I think many will be happy with this release.  64 bit iOS applications were a necessity and everything else was bug fixes and expansions of functionality.  I wish more releases were like this (i.e. a few new features and mostly bug fixes).

As with any new release you’ll need to test it against your own projects to find out if you have any issues.

What are your comments about Xojo 2015 Release 1?

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?

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 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?

XDC 2014: Future Hints

In my last post I talked about what version 1 of the new compiler is going to accomplish in the first quarter of 2015.  It’s a great first step and with any switch to a newer, better technology it means some things will become easier to accomplish.

In Joe Raneri’s Compiler session he talked about several new things that the new compiler might be able to do.  I will stress the might bit.  If it doesn’t happen don’t say they promised it.  🙂

Autocomplete:  The current autocomplete mechanism in Xojo is completely separate from the compiler.  It’s possible with the new compiler these are unified.  This would be great because the autocomplete code pretty much duplicates what the compiler does since it needs to process the same level of information.  I’ve been told there are dozens of autocomplete classes in Xojo.  If the compiler can process some of this information perhaps autocomplete will be even faster and more reliable.

Debugger Tooltips:  I’ve wanted this one ever since I moved to Xojo from Visual Basic.  While in the debugger it would be very cool to get the value of the variable you’re hovering over to get displayed in a tooltip.  The current object viewer in the debugger is less than ideal and I really despise using it.  I always seem to be fighting it so being able to hover over the variable to get its value would be a very welcome addition.

Xojo Plugins:  This is the long term, and only, approach to getting plugins on iOS.  Currently iOS does not allow dynamic libraries so until Xojo can create plugins, developers will have to use declares into the iOS frameworks.  This is less than ideal so the new compiler will allow iOS developers to create plugins entirely in Xojo code.

I believe that, at least for iOS, Xojo plugins is a definite.  How this affects desktop remains to be seen but what it would mean is that developers would not have to create plugins using C.  What we don’t know is what happens to the current plugin SDK.  Does it get deprecated or does the new way get more/better support over time until no one’s using the old SDK?  Only time will tell.

Other:  A few of the other possibilities that Joe shared that the new compiler might be able to do for us:  better refactoring tools, source indexing (e.g. finding the callers of a method), and more platforms or architectures.

The new compiler is a big deal and it’s been many years in the making.  Some of things that might come out of it are exciting.  It’s my opinion that if Joe is saying these things at lease some preliminary work has been done, or at least some preliminary proof-of-concept code has been completed.

What are you most excited about?

Xojo Developers Conference 2014

Geoff Perlman of Xojo gave the keynote address at the Xojo Developers Conference (XDC) today.  In his hour long talk Geoff talked a lot about Xojo Cloud and a little bit about the upcoming iOS version of Xojo.

This years XDC sold out and attendance was up over 16% over last year.  Attendees represented 14 different countries and over half were first time attendees.  Early on in the presentation Geoff acknowledged over 20 attendees that have been using Xojo since version 1.0.  He also presented Marc Zeedar (of Xojo Developer Magazine) with having attended every single conference.

Geoff then went on to acknowledge that the name change from Real Studio to Xojo has gone well.  There is one issue in that a sports drink made it to market about the same time with the same name.  The two separate companies are on friendly terms and on Friday all of the attendees will get a bottle of the sports drink.  This may or may not be a good thing on a Friday in Las Vegas.

Xojo Cloud

Xojo Cloud has now been released.  It has a number of benefits including zero configuration, one-click deployment, no maintenance, and better security.  The latter issue is incredibly huge since Xojo discovered that it takes about 15 minutes for a brand new server on the internet to get its first unauthorized access (attack).  With Xojo Cloud the servers are automatically configured with security in mind.

In the long run anyone creating web apps does not want to be a security expert.  However, those developers should be, so the security focus of Xojo Cloud is worth the additional cost.  Xojo admits that it is not the cheapest host, but it doesn’t take too much of your time doing configuration and maintenance on your (non-Xojo) server to make up the cost difference.

Xojo is paranoid about security and this is a good thing.  It was during XDC 2013 that their servers got hacked.  They feverishly moved all their backups into the Xojo Cloud servers.  Since then there have been no infiltrations (that they know of) in over 15 million scans.  When they reviewed their security with RackSpace (their server provider) who told them, “Only our most paranoid customers have this much security.”

Framework Changes

Parts of the Xojo framework have been been around for 15 years.  In that time Xojo has supported Mac OS 68k and PPC, Windows x86, Linux, Mac OS X, Cocoa, and Web (to name a few).  Obviously there are a few areas of cruft that have crept in and there are inconsistencies in the API.  Add in iOS, ARM, 64 bit, and LLVM and Xojo has some serious issues in the framework.  Thus a new framework is in the works.

The existing framework (classic) consists of the desktop and web.  Each of these sits on top of the console framework.  The console framework consists of non-ui items like FolderItem, TextInput/OutputStream and BinaryStream.

With the new frameworks there will be framework namespace for each platform (desktop, web, iOS) and will contain things that are specific for each.  For common elements (like buttons) these will live in the UI framework that lives underneath the platform frameworks.  The ultimate goal of this change will be copying common UI from a desktop app and pasting them into a web app the controls will just work with no problems.  This can’t be done now as the desktop and web controls have separate frameworks.

The new framework will arrive first in console, then web, iOS (initially it will have its own version of the new framework), and then finally desktop.  My advice is to not stress out about this until more information is known.


The big news of the day is that iOS is very close to being sent to alpha users.  The current schedule (always take schedule news with a grain of salt) has the alpha shipping in May with a beta in June and hopefully shipping to end users in the third quarter of 2014.

Pricing will be $400 for those users that want iOS only.  Pro licenses will go up $200.

Geoff did an initial demo with the iOS application running in the iOS Simulator.  This is similar to things we’ve seen before.  What was new, however, was that Geoff did a final build, used Apple’s Configuration Utility and ran the demo app on an iPhone and an iPad.

From this evidence it seems that work on the LLVM and ARM compiler is well advanced.  Built iOS apps are currently only 32 bit.

Another interesting tidbit from the demo was that Auto Layout is in full force in iOS.  Auto Layout is a super advanced way to handling automatic layout for windows, views, containers, etc. and is much more advanced than the simple locking properties.  This should really help in localization.  Other than the quick aside in the demo there was not much said about it.

All-in-all the keynote was fairly quiet.  Not a whole lot of new information was given out.  Ta ta for now and if I find out more information I’ll share it with you.


Features, Roadmaps, and Pricing. Oh my!

Lot’s of drama on the Xojo forums the past couple of days.  People are gnashing teeth at perceived slips in timeframes that were really estimates at the 2013 Xojo Developers Conference.  There’s also some gnashing of teeth going on whether or not Xojo Pro licenses will include iOS ot.

Xojo has a number of options in regards to feature sets, timeframes, and pricing.  Let’s review:

One:  They tell us nothing and release new features when they feel they’re ready.  Always an option but not satisfying to the users especially at developers conferences.  We go, in part, to find out about the new and upcoming features and provide some feedback.  Without this information it’s hard to get excited about future releases.

Two:  They tell us about possible features and give rough timeframes.  They’ve done this in the past and it seems that once they say it, people assume that’s it’s gospel and that it will be in the next release.  It doesn’t take long for people to complain about ‘missing’ features but at least the new features get released – eventually.

Three:  They give us a timeframe and release regardless of whether it’s ready or not.  It’s been a while, but I can remember new ‘features’ that did not work.  Period.  Not how I wanted them to work or even how they intended it (as in demo projects didn’t even work as intended).  Thankfully they don’t pull crap like that anymore and I can’t imagine anyone wanting to go back to that.  Trust me, that lead to very pissed off customers and people leaving the community for good.

Of those three options, option two is the only viable one and is a balancing act.  Unfortunately it leads to speculation, misinformation, pissed off users, and much trumpeting of outrage (real or feigned).  I can live with this because option 1 is hard to deal with as a professional users and option 3 is simply unacceptable for any developer.

Pricing is a bit trickier since the new licensing scheme lets anyone use the IDE without buying a license.  If you wish to build a final executable you need a license for the target.  Theoretically, this should mean that when Xojo iOS is released anyone on a Mac can test it.  It’s only when you want to build you’ll have to buy a license.  Currently, Pro users can build for all known targets targets (note that this does not include iOS).

The question everyone is asking:  Will current Professional license holders have to upgrade or will iOS be included?  As with features and roadmaps it’s an irrelevant question right now.  You either need the Pro license or you don’t.  Forget about 3, 6 or 9 months from now.  Buying a license now for a feature that doesn’t currently exist is kind of pointless.  Get what you need now.

Honestly, I doubt that iOS will be included in current Pro licenses.  Maybe I’m wrong but iOS is a HUGE deal.  Perhaps the biggest deal Xojo/Real Software has ever done.  If it were *MY* company iOS would be an additional cost even for existing Pro users though I’d give a nice discount for early adopters since there is a risk for those developers.

So my bit of advice is to hold tight.  The 2014 Xojo Developer Conference is towards the end of March.  That’s not very far away and in realistic terms it means that Xojo is already preparing for what they’re going to talk about at at the conference.  I’m sure they already know what new features, updates, roadmaps and pricing they are revealing.

Watch this blog and I’m sure I’ll be writing about all of these things.  Just take it all with a grain of salt.  Oh, and I’m sure we’ll be reliving this conversation about the same time next year.

Xojo for iOS

Xojo Inc showed off the iOS version of their development tool at XDC last week.  They showed several Xojo compiled applications running in the iOS Simulator.  They noted that all of the controls they showed were native iOS controls rather than drawn.  This is important because some non-Apple iOS dev tools are not using native controls and instead draw their controls.

They showed buttons, lines, rectangles, ovals, html viewers, canvas controls, images, text area and text fields.  The text fields automatically bring up the keyboard when they have the focus.  In addition to controls that are more or less common to all platforms they iOS specific controls like bar buttons, icon buttons, views, split views, tab bars, tab buttons, and tables to name a few.

Tables look like they will be very easy to implement in iOS.  Xojo implements sections and grouping at runtime and allow buttons and all sorts of crazy things you’d expect in an iOS table.  One thing it will not do for the version 1 release is support gestures (swipe a table item to bring up a delete button for example).

The iOS version is going to use Styles for their controls.  Styles can be at the application level, view level, and even down at the control level.  This should make for some very interesting style sets.  Xojo Inc indicated that eventually this new Style set will be implemented in all UI builds starting with iOS, then for Web Edition, and then finally for Desktop builds.

Debugging occurs in conjunction with the iOS Simulator on Mac OS X.  Builds will be made with the LLVM compiler which is the same compiler that Apple uses for ARM.  LLVM is a little slower than the regular Xojo compiler so builds will take longer than debug runs.  LLVM is scheduled to be ready for iOS for the beta.

Because iOS devices change their rotation the concept of control locking is kind of outdated, or at a minimum rotation makes it much harder.  Apple recommends using Auto Layout which allows you to make the maximum use of space for your controls.  For example, localizing your apps can be difficult when it comes to sizing and laying out the controls.  Auto Layout should make this easier.  Cross-platform differences (like pushbuttons in Linux) should be easier with Auto Layout too as you can control sizes, relative sizes, fit to caption, and matching other controls.

The Xojo IDE handles much of this silently when you add controls to the layout.  The Guidelines in the view/page/window editor will show the constraints and then there are a number of properties you can use too.

The demo that Geoff demonstrated during the keynote showed a couple of interesting Auto Layout properties.  For one, he changed the localization between English and Afrikaans and captions automatically resized properly.  Auto Layout also automatically constrains window minimum widths and heights.  Frankly, it was nothing that you couldn’t do via code right now, but the demo showed what you could do without code.  Only time will tell if Auto Layout is helpful or not.  Xojo is implementing Auto Layout for iOS first, then Web and then for Desktop apps.

Building for iOS requires using the new Xojo framework.  See this post for more info on it.

Xojo for iOS Beta isn’t close yet though it is scheduled for late summer 2013.  They plan on shipping in December 2013.  It will be missing a number of things like Core Data but there should be nothing from stopping a developer from making declares into the system to use what they need at the OS level.

iOS for Xojo looks promising.  Much of the heavy lifting has already been done and now it’s just a matter of finishing it up.  Sure, not everything will be available in the first release and I expect there to be hiccups that no one thought of but it’s showing promise now in the iOS Simulator.

I am skeptical of the summer beta and December release timeframes but perhaps we can all be pleasantly surprised for once.  You can be sure that once we get closer we’ll know a whole lot more about its limitations in comparison to doing it in xCode and CocoaTouch.