Xojo: the Best Secret in the Programming Industry Part 1

Xojo turns twenty years old in 2016.  That’s an extraordinary feat not only for a business but even more as a development tool.  The simple fact is that 90% of all businesses in the United States fail within two years.  There’s a significant number of the remaining businesses that fail two years after that.  Xojo has beaten the odds from a business standpoint.

When it comes to software development tools and languages it seems that every time you turn around there is another programming language of the moment that is the hot, hot, HOT thing that everyone has to learn and then two years later it is relegated to old, has been, technology.  Each one promises to make software development easier and faster and in most cases they solve A problem but not necessarily all problems.  In reality, every development tool still requires a competent programmer to do some work – you get nothing for free.

Xojo has been renamed multiple times first as REALbasic and then as Real Studio but in each name iteration it’s been the same product:  a rapid application development platform and language that creates compiled desktop, console, and web applications native for Mac OS X, Windows, and Linux.  Not only in 32-bit but also for 64-bit.  For a vast majority of users it really is as simple as checking a box captioned “Windows” to create a fully functioning Windows application that works the same as the one you’ve create on the Mac or in Linux.

Xojo started out twenty years ago as CrossBasic before Real Software Inc purchased the rights.  It was modeled after the very successful Microsoft Visual Basic and those roots are still visible today.  Xojo initially ran only on Macintosh but within a few years it ran on Windows.  It now runs on Linux too.

Xojo has transitioned from 68k Macintosh desktop apps, to PowerPC apps, to Carbon apps, and finally to Cocoa apps.  Recently they transitioned from 32-bit applications to 64-bit applications for Mac OS X, Windows, and Linux and introduced Linux ARM as a new target.  This transition is still in progress (the IDE is still 32-bit and remote debugging isn’t available for 64-bit yet) and they’ve announce more transitions on the Windows side to start moving away from the venerable Win32 framework for some things.

Besides desktop apps Xojo also creates console and web apps.  Web apps are a different beast as they expect to keep a constant connection between the browser and application on the server.  This makes web apps work a lot like desktops apps and eliminates a host of typical web app issues.  These web apps can be deployed as either cgi applications or as standalone apps.  The cgi applications work with Apache or IIS servers.  Standalone builds require no server and act as their own server which makes them very easy to deploy to any Mac OS X, Windows, and Linux machine.  Much of the code used in a desktop app is reusable for web apps.

A few years ago Xojo introduced the ability to create iOS applications which introduced yet another target.  iOS transitioned quickly from 32-bit to 64-bit after one of Apples famous ‘deprecations’.  iOS built under Xojo works with the iOS Simulator that comes with Xcode to accomplish remote debugging.  Just a few weeks ago Xojo announced that in late 2017 Android will become another target.

Xojo is an integrated development editor, or IDE, that allows a developer from within one application, to write all the code, layout all the user interface, and include any resources necessary for it to work.  It has a series of built-in editors that mostly mean you’ll never have to leave the Xojo IDE.  Working on desktop, web, console, or iOS projects expose the available libraries and controls for those targets.

Xojo lets you compile final executables or do remote debugging to any of the supported platforms.  So while working on Mac OS X I can remote debug an application in Windows running on another machine on the same network or in a VM environment.  While remote debugging, any exceptions that occur in code are revealed in the IDE and users can view variable values and see the call stack.

These things are nothing spectacular by themselves because many development tools can do them.  What makes Xojo remarkable is that is does this regardless of what platform you develop on.  A Windows developer, Mac OS X developer, and a Linux developer get the same capabilities and can deploy to any of the other platforms.  The only exception is that to do iOS you must be using a Macintosh and have Xcode.

Like any tool it has its detractors but it’s managed to transition, quite quickly at times, due to sudden announcements from Apple (who thought they’d move away from PPC?  Or iOS apps would be 64 bit that quickly?) and from the inevitable changes from Microsoft, and the sometimes daily changes in Linux distributions.  Some users complain about the number of bugs introduced in new releases or that bugs sometimes go years without being fixed.  It’s my opinion, though, that every developer complains about those things in their development tool of choice.  Xojo averages a release every 90 days (with the occasional dot release) and always add some new features and fixes many bugs.

The Xojo community is incredibly welcoming to new people.  There is not a lot of condescension given to new users that ask simple questions on the Xojo forums.  Unlike some other venues there is not a lot of vitriol going on.  The Xojo engineers frequent the forums and answer questions.

Since Xojo has lasted twenty years they’ve already beaten the odds.  There is every indication that they’ll be around many more years.  They are no Apple, Google, or Microsoft, but yet they keep churning out new versions that attempt to keep up with the ever changing development landscape with what many would consider a very lean development staff.  Most of the development staff are former users so there is a high level of familiarity with the needs of the user base.

So why don’t more developers know about Xojo?  With the features and history described above it seems like everyone show know what Xojo can do for them.  That doesn’t seem to be the case so why not?  In part 2 we’ll examine some of those reasons.

2016 Xojo Design Award Winners

img_4508Xojo announced the winners of the 2016 Xojo Design Awards today in Houston, Texas during their annual Xojo Developers Conference (XDC). These are applications and tools made with Xojo that were considered the best in their respective categories.
Best Overall:  EverWeb http://www.everwebapp.com

Best Business App: Light Blue https://www.lightbluesoftware.com

Best Consumer App: Alinof Timer Pro https://www.alinofsoftware.ch/apps/products-timerpro/index.html

Best Cross-Platform App: PubCoder https://www.pubcoder.com

Best iOS App:  Studiometry Touch http://oranged.net/studiometrytouch/

Best Developer Tool:  Everweb http://www.everwebapp.com

These are great examples of what some awesome developers are doing with Xojo. Congratulations!

XDC News:  Android Support

iurThe 2016 Xojo Developer Conference kicked off in Houston, Texas today.  Geoff Perlmann, CEO of Xojo, Inc. took the stage this morning to deliver his keynote speech.  The biggest news of the day is that Android support is coming for Xojo.

Many Xojo developers (myself included) find that iOS support is great but without Android support it’s not complete.  Geoff announced that in the fourth quarter of 2017 Xojo will have the ability to compile Android mobile applications.

This is a big deal and a daunting challenge for this team.  It appears that they’ve done their homework to figure out what they want to do.  Details are scarce at this point but they already know they will compile down to native code and not Java.  They will also use native controls like Xojo does for iOS.

The target version of Android that they are aiming for is JellyBean (version 4.1) or better.  Roughly 97% of all Android users will be covered.  Sadly, version 4.1 was released in 2012 .  I would have thought that 4.4 (KitKat) or better would be a better choice.  Let’s hope that gets changed before release.

Geoff did not mention if Xojo is planning on adding additional staff.  The reason I bring this up is that I find a twelve month timeframe to implement a completely new platform.  A more realistic expectation is that it will be released in beta form and it will be 2018 before it’s ready for more usage.

More details as learn about them.

XDC News:  2017 Roadmap

img_4508In todays keynote address, Geoff Perlmann, CEO of Xojo announced the major features coming to Xojo in the 1st, 2nd, and 3rd quarters of 2017.

First quarter:

64-Bit builds will be out of beta.  This means that XojoScript will be 64-bit capable as well.  This also means that 64 bit builds for Windows will include application icons and version info.

Remote Debugging will be available for the Raspberry Pi.  This should make using and developing on the Raspberry Pi that much better.

Remote debugging will also be available for 64 bit!  This should make the transition to 64-bit much faster at this point.  I know that we are holding off moving to 64-bit builds because of the lack of remote debugging.

String and Join functions that are pretty slow in 64 bit builds will now be considerably faster.  Again, really good news for some developers that have experienced this.

Second and Third Quarters:

New projects will be 64-bit by default.  32-bit builds are NOT going away.  What is going away is 32-bit versions of the IDE and while nearly all Mac OS X and Linux OS’s are already 64-bit this might cause some pain for Windows users that will have to update to 64-bit.

The new Xojo framework will come to Console, Web, Desktop and Mobile.  (Technically speaking mobile is already using the new framework.)

New plugin format:  Currently plugins in Xojo are written in C/C++ and are only supported for console, desktop and web application.  Developers will be now be able to create plugins in Xojo that will include resources, windows, etc. that are not possible in the current format.  The advantage of this is that it will allow anyone with a Xojo Pro license to create plugins and could (potentially) dramatically increase the availability of 3rd party controls.

These plugins are compiled into an intermediate format that is not human readable.  Presumably this format is something that can’t be reversed by the average developer.

This new plugin format will become the preferred format but the old style format will be supported for the foreseeable future.  It will be supported for Mac OS X, Windows, Linux, Linux ARM, and for iOS.  This last item is a high want by many Xojo developers.

Fourth Quarter:

Interops is a new feature to take the place of Declares in Xojo.  Declares are great but there’s no autocomplete and there’s absolutely no data type checking.  Interops should make this much easier.

More news coming up!

XDC News: Xojo 2016 Release 4

img_4508In today’s keynote address, Geoff Perlmann, CEO of Xojo announced the major features of Xojo 2016 Release 4.  Release 4 is scheduled to go beta in November and go public in December.

The existing Windows framework drawing is currently done via GDI or GDI+.  Xojo recently dropped Windows XP support and this allowing them to update how Windows apps work.  In the upcoming release Xojo will switch to Direct2D and DirectWrite.

These two technologies will allow better picture scaling and better alpha channel support.  And while GDI+ does have some hardware acceleration these new libraries have full support for hardware acceleration.  In testing, Xojo says that intensive drawing routines should be roughly 280% faster than R3.  End users should only have to recompile their apps to take advantage of this new feature.

Geoff did not talk about flickering but I will attempt to find out more this week.

Among the other changes:

Windows HiDPI will now officially be out of beta.  In addition the Windows Xojo IDE will be released as HiDPI capable.

Xojo Cloud users should see exceptionally better upload speeds.  Starting in R4 the libraries used in the upload are cached so they are not uploaded every single deployment.  This should speed up deployment and testing quite a bit.

More news to follow.

The Power of Meeting Face to Face

In Kansas City this past weekend I attended MidAmerican 2, or WorldCon.  WorldCon is a Science Fiction and Fantasy fans dream come true.  Thousands of people from around the world attended hundreds of sessions covering television shows, movies, author readings and signings, many sessions on how to write, and much more.   It is a long convention at five days that culminates with the Hugo Awards ceremony (think the Academy Awards for science fiction and fantasy).

I am an aspiring science fiction writer (nothing published yet but I’m working on it!).  This convention was an excellent way to immerse myself with professional and amateur writers and learn.  There is something powerful about hearing people that have already “made it”.  Many of them still fight “Imposter Syndrome” and many have issues with the business of writing.  Writing is a solitary business and many are introverts and selling themselves is often nerve wracking.

Do these issues sound familiar?  They should.  In many ways, Xojo developers are much like writers in that they work in a vacuum with little feedback from others.  I know I personally struggle with Imposter Syndrome despite having done this gig for fifteen years and being ‘successful’ (whatever that means).  And much like writing, the only way to get better at Xojo programming is to do Xojo programming.

It seems a bit anachronistic to fly somewhere to meet with people.  After all, the internet makes this easier, right?  There is something powerful about being face-to-face with another person and being able to provide instant feedback.  We also tend to be much more polite in person than online and that’s a huge plus in my opinion.  I’ve met some wonderful people, in person, that online seem rude at best and sometimes simply belligerent.  The internet might make people more accessible but it seems to removal societal filters too, sadly.

In a month and a half Xojo is holding its annual Xojo Developers Conference (XDC) in Houston, Texas.  At XDC, Xojo developers from around the world will join together for three days of sessions covering practically every development topic you can think of.  And if you have a question that’s not covered you’ll be able to find someone to help you.  Besides the many amateurs and professionals attending you’ll have ample opportunities to talk to the Xojo engineers.

It’s not uncommon for businesses looking for a developer to attend XDC.  It gives them the unique opportunity to talk to many Xojo developers in a short amount of time.  We (BKeeney Software) typically speak to one or two prospective clients at XDC each year.  If you’re a consultant this conference should be on your ‘must attend’ list as it can pay for itself many times over if you land just one project.

Today is the last day to save $100 off the conference registration.  Sign up to learn and be inspired and to make some new friends.  See you in Houston!  http://www.xojo.com/store/#conference

 

We Are Part of the Problem

For some users, Xojo 2016 R1 hasn’t been a great release.  Some Windows users are experiencing frequent crashes.  For others (myself included), working in the WebPage Layout Editor is an exercise in frustration because it’s unusably slow.  We blame Xojo, but we, the beta testers, are culpable for these problems as well.

Before you start angrily sending in comments hold your horses.  R1 had a really long beta cycle.  Clearly, Xojo had issues with figuring out HiDPI for Windows and their work isn’t finished yet (hence the beta tag for HiDPI in Windows).  It happens and some times you have to ship an imperfect product.  We always have the option of NOT using the latest version of the product.

Some will say that Xojo shouldn’t have released R1 in the state that the Windows version was in.  That’s only partially true.  Xojo uses their own product all day long to create their product.  They, more than many of us, see the warts in their product and I know they try really hard to eliminate as many of those as possible.  But they use it differently than we do so I wouldn’t expect them to find every bug.  That’s where we come in.

The beta program exists so we can bang on the product using our own real-world projects.  It’s up to us to find and report the fringe cases and use the product in different ways that what the IDE expects.  I know that in this beta cycle I was swamped with consulting work so I only fired the betas up occasionally.  So whatever problems there is on me and on everyone else in the beta program that didn’t test.

I will grant you that the only incentive we have for participating in the beta program is a less buggy product.  For some that’s enough but when you’re busy trying to get your own products out the door there’s not much incentive to work even more and find bugs for someone else.  In my opinion, this has always been the problem with the beta program.

Some of use are also guilty of not starting testing until the Final Candidate releases.  This is actually the worst time to start testing because it means only show-stopper bugs will get fixed.  We really need to start testing with the early beta’s.  That’s when Xojo needs us the most to bang on their product.  Is it fun?  No.  Is it necessary? You bet because waiting until Final Candidate is worthless to them.  To us too, because those bugs might not get fixed for 3 months.

Did Xojo help us out in this cycle?  No.  There were times they were putting out a new beta every day.  Sometimes with only a couple of changes from the previous version.  I would download a beta with the intention of working with it and before I could get to it a new beta would be announced in the next couple of days.

I don’t know about the rest of the people in the beta program, but the high frequency of beta releases meant I looked at them less.  I don’t know why but it was.  I saw the announcements rolling in and I shrugged in apathy.  Perhaps I felt the frequent releases didn’t properly value my time.  I only have so much time to devote to beta testing and the frequency was off-putting.  I like to use a version for 3 or 4 days (or until I find a major bug a report it).  With so many releases I just didn’t test.

I propose that with the next cycle Xojo limit their public builds to once a week (maybe a Thursday or Friday release).  This respects my time a bit more since my only incentive is to make it a better product.  Frequent public releases says that they’ve not vetting their product enough before giving it to us.

I also think there needs to be something in place that identifies what type of beta tester we are.  Are you mostly a Windows user?  Then Windows specific changes get highlighted for you because you’ll be most likely to see them.  Same with Mac OS X, iOS, and Linux users.  Desktop, console, and web app users might also be a designation.  I realize this doesn’t fit in with the current generic “hey, we have a new beta” announcement.  But it’s clear from R1 that the generic approach didn’t work.

We have too many major bugs in this last release to call the beta program a success.  It’s not doing what we need it to do.  So how do we structure is to so that our time is respected and we actually report bugs before Final Candidate stage?

What about you?  What suggestions do you have to help us and Xojo out at the same time?

Xojo 2016 Release 1

Xojo 2016 Release 1 was released today.  This much anticipated version is all about Retina and HiDPI display support.  In addition to that, there are, as always, the usual mix of new features and bug fixes.  Let’s get to it!

The IDE is Retina Aware

The IDE itself is now Retina capable and all of the icons and images used in the IDE have been replaced with high resolution images.  On my 27 inch 5k iMac it’s quite a noticeable difference to my aging eyes: everything is very sharp.  As with many apps once you start using the high resolution version it’s hard to go back to a lower resolution.

Before you jump into this version you might want to do some testing.  On relatively new iMac the Web Layout Editor is very slow.  So slow as to be almost unusable.  This only happens on existing projects since new projects seem to work just fine.  Perhaps it’s a combination of project size and/or web page complexity or number of Web Containers.  I really don’t know but I’ve submitted a Feedback report showing the symptom and an application sample from Activity Monitor.

Your Apps Can Be Retina Aware

In the last Xojo version we were introduced to ImageSets and that feature is now more useful in 2016 Release 1.  The ImageSet allows you to add a normal sized image (1x), a 2x image, and also a 3x image.  Mac OS X only uses the 1x and 2x images but some Windows 10 resolutions will use the 3x image.

HiDPI support for Windows is officially beta and I believe that’s mostly because the various versions of Windows that Xojo supports all do HiDPI slightly different.   Currently Xojo does not support Window 10’s per-display scale factor and will use the scale factor of the screen it was launched on.  TextArea’s only display in large size, the HTMLViewer and MediaPlayer is not scaled, BevelButtons don’t display, and Image Set Icons do not appear correctly in toolbars.  Obviously this is less than ideal for Windows applications and you probably don’t want to release a Windows app with this set.

With Retina/HiDPI support is a new Application shared property called SupportHiDPI.  When set to true, Xojo will build your application with Retina and HiDPI awareness.  When set to false it will build apps that worked the same was as previous builds.  Sadly, this property cannot be changed at runtime because it would make enabling it for Mac OS X a no brainer but leaving Windows as is.

As you can imagine, Retina/HiDPI changes a number of important things.  The Picture class has a new constructor that can take one or more bitmaps in addition to its size.  All bitmaps must have the same aspect ratio or an invalid argument exception is generated.  One question that I’ve not explored for myself is how exact this ratio must match.  What is the precision on this check?

The graphics object now has a ScaleX and ScaleY property.  For pictures the scaleX/Y are always set to 1, but a graphics object passed in from the paint event might have a ScaleX/Y set to 2 on a Retina display.  Graphics.Pixel is now deprecated (NOT REMOVED).

Windows have a couple of changes too.  There is a new event ScaleFactorChanged on Mac OS X that is an indicator that all graphics for that Window should be invalidated.  A read only ScaleFactor tells you what the scale factor is for this window.  The Canvas object has a similar ScaleFactorChanged event on Mac OS X as well.

Local Language Reference

Retina is not the only new thing in R1.  The Local Language Reference has been revamped again and if you are a Dash user you’ll notice that it shares much of the same look and feel.  Searching for an item in the Language Reference, in my opinion, is considerably easier in this new version and I find I like it better than the online version.  Besides being able to search for any event, property, class, enum, etc the local language reference allows you to go back through your search history rather quickly.

Web Framework Changes

The web framework received a number of important changes.  Perhaps the biggest and most important to web users are that WebStyles have changes their implementation.  The change notes say “User defined WebStyles now have more specificity than framework applied styles.” which I have been lead to believe means that WebStyles now work properly in all cases as there were fringe cases where styles were either ignored or improperly applied.  During the beta cycle Xojo asked us to test web apps to make sure nothing broke.  In my testing I didn’t see any issues.

The connection type of a web app can now be set with a command line option.  The WebListBox received some love too.

Miscellaneous Fixes

  • Build times have been improved.
  • Xojo.net.httpsocket now works in Mac OS X console and web applications.
  • A memory leak in NSWindow was fixed in the Cocoa framework.
  • The FileTypes editor has received a number of bug fixes and changes.
  • 40 changes to the documentation and examples.

Conclusions

With all of this work on Retina/HiDPI applications for Release 1 I am disappointed at the lack of project examples for HiDPI and Retina.  Sure, the SupportHiDPI is an easy thing to do, but for many of our applications that create images on the fly we are only left with some fairly vague instructions.  A Xojo Blog posted today http://blog.xojo.com/a-journey-of-a-thousand-pixels might be your best bet in understanding some of these changes in more detail but even I scratched my head with some of the implementation details.  Actual example code that show the practical implications of Retina/HiDPI and creating images would have been very welcome.

I’m relatively happy with 2016 Release 1 though not without some reservations.  Since the number of Windows controls in HiDPI that don’t scale properly is fairly large it’s not ideal that you can’t turn off HiDPI for Windows but keep Retina on for Mac OS X.  Sure, you can always do two builds but it’s not an automated option.  Performance issues with the Web Page Editor is also troubling and perhaps this means there’s a dot release in our near future.

There are quite a few things on the horizon that Xojo needs to tackle.  Full debugging in 64 bit and a 64 bit IDE is perhaps the biggest one and the HiDPI stuff is surely a distraction from that important requirement.  This beta cycle was really long and it makes you wonder how much their schedule has shifted just to get HiDPI (mostly) working with some obvious work still to do.

What are your thoughts on Release 1?

Xojo Code Folding

I was talking with another Xojo developer and we both commented on how neither of us use Code Folding in the Code Editor.  I’ve been using Xojo for fifteen years and this developer is at least ten years.

For-Next

For-Next regular

If you’re not familiar with code folding it’s the ability to collapse an entire branch of an If – Then statement, Select – Case, For – Next, While – Wend, and probably a few others.  The code doesn’t go away, it’s just temporarily hidden.  It’s a convenient way to hide a good chunk of code so you can easily see what else is going on around it.

For Next Collapsed

For Next Collapsed

The other developer and I discussed this issue for a while and we really couldn’t come up with a good reason why.  The best reason we could come up with is that it *looks* like the code has been deleted.  Like I said, it wasn’t a good reason but at least it was a reason.

Do you use Code Folding? If not, why?

Have a Merry Christmas and Happy New Year folks!  Stay safe, enjoy time your family, and happy coding!

Xojo 2015 R4

Xojo 2015 Release 4 hit the internet today.  The fourth release of Xojo this year is full of bug fixes and only has a few new items.  I’d recommend using this release as the bug fixes are substantial.

Let’s get what’s NOT in this release out of the way.  This release was initially supposed to be about getting Retina and HiDPI capabilities in the IDE and in our applications.  It was determined that there just wasn’t enough time before the end of the year to get it done.  It’s disappointing to not get these new capabilities but I’d rather they be done right than Xojo giving us a half-assed feature that no one is really happy with.

This release also does not complete the 64-bit work started in 2015 Release 3.  We still cannot use the Remote Debugger to live debug 64-bit applications and there are still major gaps in the capabilities between 32-bit and 64-bit applications.  A full list is here:  http://developer.xojo.com/64-bit-guidelines

Changes and Fixes

What this release does is fix over one hundred compiler, framework, database, and IDE bugs.  There a number of 64-bit bugs that have been squashed that were causing linking errors or outright crashes when compiling 64-bit applications.

For the framework there are a couple of high profile fixes that are welcome.  XML Exceptions no longer ‘skip’ exception handlers.  I know this has been troublesome for many developers.  An issue with the new Xojo.IO.Folderitem class has been fixed on Cocoa that would cause crashing when a FolderItem object was put in a tag, for example.

The Web framework received

some bug fixes as well.  Some of the more notable:  WebSessions no longer quit when moving from network to network.  WebPicture’s no longer return nil when defined from a FolderItem and the WebPicture no longer uses twice the memory when the image is in the project file.  The web framework now recognizes the Epiphany web browser on Raspberry Pi.

The WebDragItem now has the Origin X and Y values that indicate the X and Y coordinates of the Sender web control where the drag began.  I haven’t tried this out yet, but this should make some things (like a web based designer) a little easier to create.

The MSSQLServer Prepared Statement no longer returns a nil and should allow developers to use this safer method of using Xojo with Microsoft SQL Server database servers.  The ODBC Database plugin also got an update so it no longer crashes when retrieving large SQL columns.

The IDE has dozens of bug fixes.  Most of them pretty minor but they add up.  Among the more notable fixes:  AutoComplete has had extensive work so that control arrays and structures should work.   Private methods and properties now show in AutoComplete as expected (now, only when in scope).

The Syntax Help Area (at the bottom of the Code Editor) is now scrollable  when the content does not fit the preexisting area.    This area will also show the description, if there is one, in addition to the signature.

The Interface dialog now resizes itself to 75% of the window height.  If you make it larger it will reopen at that size (or the limits of the window).

Filtering in the Navigator now shows results ordered on how closely they match the string based on the Levenshtein distance of the match.  So if you don’t quite get the name right you might still get results instead of requiring an exact match.

New Stuff

Despite this being a mostly bug fix release there are a couple of new goodies that might make your day.  The first is that MySQLCommunityServer now has a SecureAuth property which allows users to authenticate using old password hashes.

The Graphics class for desktop apps has a new property, called CharacterSpacing, that allows you to change the percentage spacing between characters.  You can use both positive and negative values.

Web Text controls now have a TextAlign property.  This should simplify web projects as you no longer do have to duplicate a WebStyle and change the alignment simply to change the text alignment for a single control.  You can still do that but this is a new way to eliminate that extra work.

In some preparation for Retina, Image Sets are now available.  Use the Insert Menu and select Image.  In the Image Set editor that are now 3 thumbnails for the set for normal size, double size, and triple size.  But since this release doesn’t include Retina support this feature is of limited usefulness – for now.

What might be the biggest news of the release is the addition of the CGFloat data type.  This temporary datatype aliases to a Single in 32-bit builds and a Double in 64-bit builds.  This should make fixing some the common libraries (think MacOSLib) easier since we can make one variable that will work for both build types.  Xojo has said that once 64-bit iOS and OS X builds are ONLY 64-bit the CGFloat data type will be deprecated.

Future Releases

I’m a big fan of these mostly bug fix releases.  In a product that changes so much and so quickly (at times), these bug fixes releases allow us to take a deep breath and not worry too much about using this release.  We worry about the big releases because of the shear amount of changes involved and the amount of testing required with our applications.

So what do we have to look forward to in 2016?  Presumably, 2016 will see a full compliment of Retina and HiDPI support since Xojo publicly pulled it from this release.  I would also expect the 64-bit journey to continue with hopefully the IDE becoming 64-bit which means that XojoScript, Windows version and icon information work, and the grandaddy of them all, Remote Debugging work in 64-bit.

I hope we get a Remote Debugger for Raspberry Pi simply because that will make life easier on that platform too.  I’m not sure what else we really need for Raspberry Pi.  What have I forgotten?

I would expect the IDE to get some level of redesign.  Many people, including myself, are unhappy with the workflow in Xojo and think it’s slower to use than Real Studio.  I know of several large customers that have stuck with Real Studio rather than migrate their projects to Xojo simply because of the IDE workflow issues.  Personally I’m happy that Xojo plans to address some of those issues.

I expect the iOS framework to grow with new controls and capabilities.  I also expect the new Xojo framework to keep growing (TCP Socket perhaps being the biggest need) and getting more attention to eliminate some of the cross platform bugs in it (looking at you HTTPSocket).

Will 2016 be the year that the desktop or web frameworks gets rewritten for the Xojo framework?  Perhaps, but Xojo isn’t saying much.  With XDC now in October we won’t get much of a hint of future plans until then, or until we see it in a beta cycle.

I know that Android support is at the top of the wish list in Feedback.  I do NOT see it in 2016 simply because it’s yet another platform.  Unless they’ve already started the work on it (which is always possible and we haven’t noticed it) I expect it to take at least 18 months (more likely two years) for an Android beta release.  And even then, how long until it’s really usable?

So what is your take on this release?  Good, bad, or meh?  What are you most looking forward to in 2016 from Xojo?