XDC 2019 Is Almost Here!

The Xojo Developers Conference (XDC) is just around the corner.  In less than two weeks Xojo developers from around the world will gather in Miami to talk Xojo for three full days.  The speakers have sent in their slides and gotten feedback from Xojo and flight and hotel reservations made.

This is my favorite part of the year!  Really.  BKeeney Software has been around for nearly 18 years and in that time I’ve gone to many Xojo Developers Conferences including those sponsored by Xojo, sponsored by Monkeybread Software, and even held a few I helped host with the defunct Xojo developers user group.  

Many of the developers that attend are my friends.  Many more are colleagues, and competitors.  Some are current and old clients.  Some of those clients I met at XDC looking for developers for their project since there will be no greater concentration of Xojo developers on the planet!

You’d think that with as many developers conferences under my belt there would be nothing new to learn.  I disagree since Xojo is always morphing into the next phase of its existence.  When I started, 68k Mac apps were transitioning to PowerPC.  They added Windows and Linux targets.  They added Cocoa for MacOS, 64-bit builds for Mac, Windows, and Linux, the ability to create web applications, Raspberry Pi apps, and mobile applications for iOS.  

I expect this year we’ll learn a lot more about Xojo for Android which will be a significant new target and make iOS that much more relevant with Xojo.  We’ll learn about InterOps that aims to make adding libraries much easier for iOS, MacOS, and Android.  And I’m sure we’ll see a lot about Web 2.0 that will make Xojo web applications more powerful and more robust.

At the end of the week, it’s always sad to go home.  The bonds you make while sitting across the table from someone at a meal, or over drinks at the end of the day, is something that you can’t get in the forums, email, or via videos from the conference.  Don’t get me wrong, the Xojo forum is one of the friendliest developers places I’ve ever experienced, but there is something truly powerful about chatting with people and being able to read their body language and talk about their developer experiences that far outweighs the convenience of the electronic venues.

If you have the means I highly recommend making it to XDC.  It’s well worth it.  You’ll get to meet some awesome people, learn a bunch of new things, probably see some alpha or beta of new features, and overall have a good time with your extended Xojo family.

If you’re going and we haven’t formally met, please feel free to stop me and introduce yourself.  Remind me how you came to find me and what products, if any, you use.  Tell me what features you like, or don’t like.  Just say hi and then go talk to the many other Xojo developers there – you might just find friends for life.

Of course I’ll blog about the keynote and the cool new things that I see at the conference.  See you in Miami!

Xojo 2019 R1

Xojo 2019 R1 was released today. This is the 2nd release in a row where there is not a dramatic number of new features but quite a few bug fixes and enhancements. Let’s dig into what’s changed in this release!

The big change in this release revolve around the URLConnection control. The HTTPStatusCode property is now available for both the Send and SendSync calls. The control now appears in the library. It now yields to other threads. Send requests are now closed before the ContentReceived and FileReceived events are fired. The string encoding for the ResponseHeaders is now consistent across platforms. It also now automatically handles compressed content-encodings in Windows and Linux (just like MacOS does). The TimeOut property now works (before it always did 30 seconds). Error messages are no longer empty in Windows. The ReceivingProgressed event now correctly reports the total bytes. The response headers are now updated property when a request is made. The SendSync no longer intermittently returns empty strings in MacOS.

The licensing has changed for Raspberry Pi. The license for Desktop and Console applications on the Pi is now free!

There are some other new items. The list is small but significant. The first is that 32-bit Windows builds can now set HiDPI and supported versions properties in the manifest file.

The TextArea control for Windows 8 (or newer), and Linux now support system spell checking. This matches the behavior on MacOS.

The Text datatype now has target appropriate EndOfLine properties. If you use Text you’ll no longer have to create your own EndOfLine constants.

The IDE added the ability to switch between Computed Properties and manual Getter/Setter methods. There is a new menu item when right-clicking on a property. In addition to the standard Convert To Computed Property there is a new menu item called Convert To Method Pair which creates two overloaded methods. For example, if you have MyProperty as Integer and select the Convert to Method it will create one MyProperty method that returns the integer value and another overloaded method that accepts an integer value with an assigns. So it looks like to consumers of this property as if nothing changed.

The constants setting has been changed from Dynamic to “Localized.” This creates a new grouping in the Code Editor called “Localized Strings”. It’s still a constant but it better reflects that it’s localized and should make it easier to visually see if a string is localized or not as there was no easy way to tell before.

There are 25 changes and 162 bug fixes for Xojo 2019 R1. Here are what I feel are the significant items:

The ODBC Database plugin now works better with 64-bit builds. Date fields in MacOS now work properly. In 64-bit Windows updating a binary/image column no longer fails with an invalid precision error.

The MySQLCommunityServer plugin no longer crashes when has certain field types and originated from a PreparedStatement.

The SQLiteDatabase no longer crashes when out of memory situations arise – an error is now generated.

Calling an OpenDialog from within a thread now properly raises a ThreadAccessingUI exception. I’m actually surprised that this wasn’t flag a long time ago.

StringShape rotation is no longer incorrectly offset. The original Feedback report was for Linux but it appears this affected other targets too.

The Window/Canvas Backdrop picture now draws correctly in HiDPI. This doesn’t affect me directly but this is the first time in several years where Canvas drawing in Windows seems really solid. I’m in testing right now with a client app that had been held back in 2017 R2.1 because of Windows drawing performance.

GroupBox caption in Windows now properly draws the size, bold, italic, and underlines styles instead of ignoring them.

A bunch of work was done in the Code, Constant, Layout, and FileTypes editors. The Inspector and Library received a little love too.

You can read the release notes at http://docs.xojo.com/Resources:2019r1_Release_Notes to get the entire list and see if anything affects you.

Conclusions

So far I’ve found this release to be solid and the major updates to URLConnection now appear to make it worthy of investigation. I’ve not used it enough, yet, to recommend it but I think most of the major bugs are worked out. The number of bug fixes and enhancements makes R1 a worthwhile upgrade.

I think this version is worthy of your time and effort to try out. As always, you should really test Xojo out on your projects, in all targets, to make sure it works as expected. Some of the bug fixes in this release might mean you have to get rid of some workarounds you’ve come up with (thinking of the StringShape rotation fix here).

You can download the new version at https://www.xojo.com/download/

Let’s hope that the major new features (like API 2.0, Web 2.0, and Android) can be staggered so there there isn’t a flood of new things in a single release. Too many new things makes it hard on beta testers.

Have you found any showstoppers? What are you most happy about in this release?

Until next time, Happy coding!

2018 Was a Weird Year

I hope everyone’s holiday season was good.  We’re approaching the end of 2018 and I find it nice to reflect on what’s happened and what we’ve accomplished this year.

Looking Back

Let’s start off with the blog posts.  I did 41 (well now 42) blog posts in 2018.  Five were about Xojo releases.  Four were BKeeney Software product releases.  Four posts were about the Xojo Developers Conference.  The rest were a variety of Xojo related topics.

The most highly commented blog post was from June called Chasing Xojo where I lamented that Xojo, at least until that point, seemed to be a less stable when it came to Windows and Linux due to major revamping of the drawing systems on both platforms.  In Windows, Xojo doesn’t flicker as much but the struggle to get speed was a concern for all of 2018.  In Linux, the switch to GTK 3 wasn’t as smooth as we could have hoped.

The most viewed blog post was from August called Xojo 2018 Release 2 where I did my usual review of the most recent release of Xojo.  I heavily criticized Xojo for their poor documentation in that release.  I received plenty of blowback on that one.  But I think the end result is that R3 and R4 documentation was much better.

We released two new products with BKS Report Studio and BKS Tab Control.  Report Studio is our reporting utility meant for end-users for macOS and Windows and it was built using the award winning Shorts reporting classes (also a blog post).  The Tab Control is a canvas subclass that replaces, and extends, the built-in Xojo tab control in many ways and was our attempt at replaced the old CustomTabControl that many use but is unusable for HiDPI apps.

The other major release of the year was ARGen 3.0.  ARGen is our utility to create Xojo projects that creates ActiveRecord objects.  Among the many changes was the ability to generate ActiveRecord objects for iOS projects, supporting GUID primary keys, and the ability to include Audit Trail, Localization, and Database Update modules that help in many products.  We use ActiveRecord in practically every project and having the ability to generate some basic desktop and web UI is a huge time saver.

2018 sure seemed like a mixed bag for Xojo.  The Windows drawing issues took up a good chunk of the year and I think R4 was the first solid Windows release (although I still have 2 client apps that won’t remote debug in R4).  I can’t imagine the amount of effort that Xojo and the community put into getting Windows drawing fixed.

64-bit remote debugging became a reality for all targets this year.  64-bit compiling isn’t the huge gain that many in the community hoped for but then we always want more.  We just have to remember that 64-bit doesn’t necessarily mean ‘faster’.  At least the debugger works and that’s not nothing.

Dark Mode came soon after the release of Mojave.  The IDE works in Dark Mode and we were given many of the tools to implement it in our own projects.  Dark Mode only works in MacOS but some are already clamoring for it in Windows too.  It’s still to early to tell if Dark Mode is a hit on Mojave much less in xojo.

Looking Forward

What is 2019 going to bring us?  For one, we’re almost finished with a fairly significant update to Formatted Text Control and after that’s released we’ll start with an even bigger version 4 update to the venerable word processing control to bring it up to date and extend its capabilities to make it even more powerful.

We have a number of large consulting projects that have been in gestation for many months and years.  It will be nice to have a big project or two to keep us busy.

With the release of Web 2.0 I will redo all of our Xojo training videos related to web.  They’ve been outdated for a while but it’s not worth redoing the videos until Xojo releases Web 2.0.  If they release Android I’ll start on at least some intro videos for that too.  This might finally be the year that I redo the remaining Real Studio videos.  No doubt I’ll redo them just before a major IDE change.  🙂

What do I expect from Xojo?  That’s a tough question to answer since they’re so damn secretive now.  I expect Web 2.0 to show up in time for XDC (so maybe release 2?).  I think it will be pretty solid in the first release but it wouldn’t expect it to be good until the following release.

I also think that at XDC we’ll get an alpha of InterOps but not anything other than another dog and pony show for Android.  Targeting another platform is long and tedious process and involves some serious IDE work.  How much of the iOS editors can they use?  I can only guess but at first blush I say not much.

Some of Android’s success may hinge on getting iOS to use the global framework and away from the Xojo Framework.  Nothing like rewriting an entire framework while keeping backwards compatibility.  The more I think about it the more I think the iOS rework is put on hold until Android is released.  

Which leads to API 2.0 in general.  We’ve already seen some of the first new controls to use API 2.0.  URLConnection was introduced in 2018 R4 with mixed success.  I would expect more API 2.0 controls to show up.

So what do you think?  Was 2018 a successful year for Xojo?  What do you see happening in 2019?

Xojo 2018 Release 4

Xojo 2018 Release 4 hit the internet this week.  This relatively small (84 bug fixes, 21 changes, 5 new items, and 11 doc and example changes) update is a nice end of year release that may or may not satisfy your Xojo dreams.  Let’s get into the highlights.

Of the new items list the big one is the new URLConnection class.  The URLConnection class works with the HTTP 1.1+ protocol and works with http and https connections.  This is a replacement for the Xojo.Net.HTTPSocket and brings back one of the things many developers missed about the old HTTPSocket class – Synchronous communications – using the SendSync method.  

SendSync is a concession by Xojo with the caveat that the application may appear to freeze while running this method.  The regular, and probably the better, Send method is asynchronous and does not freeze the app.  Admittedly the async way is the better way but for many developers the synchronous method is easier to implement and ‘good enough’ for their use.  Still, consider using the async method.

The Screen class now has the ScaleFactor property.  There are two new global constants: AppSupportsDarkMode and AppSupportsHiDPI  that are pretty self explanatory.

iOS builds now use the iOS 12.1 SDK.  macOS builds now use the 10.14 SDK for 64-bit builds.

There are couple of changes that are noteworthy.  The first being that the Windows IDE can now successfully build large projects for Linux 64-bit and ARM targets (frankly I didn’t know this was a problem but I bet that ‘large’ is the key word).  Any remaining threads are now killed after the app.close event (possibly a reason why some apps in macOS crash after they quit?).  EnableMenuItems no longer fires needlessly on every keypress in Windows.  Lingua and Remote Debugger Stub have been updated to work with Dark Mode on macOS.

There are 84 bug fixes in this release.  The more important ones (at least in my opinion):  The Build folder is properly emptied between build runs.  Remote Debugging to a Raspberry Pi no longer randomly crashes when stopping at a breakpoint.  Browsers that have disconnected from the web app will now reload the web app so they don’t appear frozen.  There are also a couple dozen IDE bug fixes to the Inspector, Navigator, Find & Replace and a number of the editors.

As with any new release you need to thoroughly test your projects before doing a public release.  It was noted during the beta period that the Einhugur Search Control didn’t work properly in Mojave but has since been fixed.  We had one large project not work when remote debugging from Mac to Windows but I haven’t had time to track it down.  If you have found any new issues with R4 please submit a Feedback report right away!

Happy coding!

XDC 2019 Session List

The session list for the 2019 Xojo Developers Conference (XDC) was released today at https://www.xojo.com/xdc/sessions/.  Take a look at this interesting list.

I’ve been attending Xojo developer conferences for twelve plus years (don’t remember what my first XDC was – maybe 2004?).  Each one is unique and the topics are usually interesting but do tend to be repetitive from year to year at times.  The session topics for XDC 2019 seem to be more unique than past years.

Obviously Geoff will do his keynote address and talk about what they’ve done in the past year, what they’re currently working, and what’s coming up (sometime) in the future.  There is a session each for Android, Web 2.0, API 2.0, beyond Linux, everything MS Windows, and more by the Xojo staff.

What’s left is an intriguing list of sessions that will be tough to figure out what I want to attend and which ones I can wait to see recorded (assuming they’re recorded again).  I can’t remember an XDC I’ve looked forward to more.

Carol is doing a session on Database Topics for Programmers and I’m doing one called “Xojo Mistakes We All Regret Later”.  My alternative title is “Thankfully time travel doesn’t exist otherwise my future self will no doubt come back to murder me for these stupid programming mistakes I’ve done.”

If you’ve never been to an XDC I highly recommend it.  You will get to meet some of the best Xojo developers on the planet, talk Xojo non-stop for 3 (or more) days on end, talk to Xojo staff, and have fun.  Of course that last point is mostly because of the first three.  You won’t find a bigger concentration of Xojo developers on the planet!

I hope to see you all in Miami in the first week of May.  What sessions are you excited about?

What Topics Do You Want Covered?

One of the joys of doing a blog for close to eleven years is that I feel like I’ve talked about a lot of topics and people ‘know me’ fairly well.  I always get a thrill when people tell me they’ve read this blog.  That is so cool and I thank you for your valuable time!

As many of you know I do a quick review of every Xojo release.  I often do a blurbs about updates to our own products.  Occasionally I even rant about things (you should see the posts where I never hit the Publish button!).

When I had a column in Xojo Developer magazine this blog was a convenient place to discuss the ideas from the column.  But writing a reoccurring column is tough.  Keeping a blog going for eleven years seems to be even harder.  I’ve been writing fewer and fewer posts and I’d like to change that trend.

At one point I thought about taking a topic in the Xojo Forums and talking about it in-depth  here.  We’ve been busy doing consulting work so I spend far less time on the forums than I used to but it might be an interesting way to generate new posts.

So, my fellow Xojo developers, what topics would you like to see me tackle?  Topics can include my opinions on the future of Xojo, how’s the 3rd party market doing, why did we choose <x> or <y> over <z>, or anything in between.  I’ll let you be in the drivers seat for while.

Some ground rules:

  • If you’re rude to me, my staff, or Xojo staff I’ll just delete the comment, ban you, and move on.
  • Keep it simple – this is a blog and not a magazine.  Though that doesn’t mean I can’t do a multi-part blog post.
  • I reserve judgement to make more rules as I think of them.  😉

So what topics do you have?

A Xojo Existential Crisis:  When Self is Nil

A couple of Formatted Text Control users found an interesting bug in the Xojo Windows 64-bit compiler.  If the user pasted anything into the control it would hard crash the Windows application.  I spent a couple of days trying to find a workaround and was flummoxed on how to fix.  Thankfully there’s an easy workaround thanks to Team Xojo.

In the Open event of the FTC control we create a new FTCUndoManager instance.  When the user pastes something into the control we pass the existing text into the Undo Manager so it can properly save the before state and allow an undo of the paste.

Pasting text calls the SavePaste method of the FTCUndoManager class.  This is where things start to go wrong.  This method passes Self into the constructor for the FTCUndoPaste class.  Stopping the debugger in this method shows us that self is nil!  What’s odd is several other passed in class objects are nil too (even though they are not at the control level).  That self is nil is indeed a problem since FTCUndoPaste needs the reference to the UndoManager for a variety of reasons.

How can self be nil?  After all this is a method in the class.  By definition self should be non-nil.  I think this would fall under ‘compiler problem’.  I submitted a private Feedback report to Xojo (53967)  and thankfully Xojo reviewed it quickly and were intrigued enough to look into it.  It was verified and a workaround was quickly found.

William from Xojo wrote this:  

There seems to be an issue with passing byval structure parameters (for 64-bit Window build), as a workaround you can pass these byref instead, i.e. MyFunction(…, Byref firstPa as ParagraphAttributes)

So I was able to change two methods, FTCUndoManager.savePaste and FTCUndoPaste.constructor, by using byRef for each object we pass into the Undo Manager into and in the Undo Paste class.  Voila!  Problem solved.

I suspect that FTC is big enough and complex enough to manifest some edge case for the 64-bit compiler.  If you run into an issue like this try this workaround.  And don’t forget to submit a Feedback report to Xojo since the more edge cases they can find the more likely it is they can determine the cause.

Happy Coding!

Xojo 2018 R3

The latest version of Xojo hit the internet this week.  Release 3 has a number of important new features, some changes, and the usual assortment of big and small bug fixes.  So let’s get to the highlights!

The flashiest new thing in Xojo is that it natively supports macOS 10.14 Mojave.  This means that the entire IDE (as well as all of the peripheral apps like Feedback, Linqua, and the Remote Debug Stub) draws properly when the user has Dark Mode enabled in Mojave.  

Perhaps it’s my older eyes the IDE seems very ‘light’ in color in Light Mode – meaning that there’s a lot of white and grey and the contrast isn’t nearly as prominent as it was in R2 and earlier.  Where some buttons have a slight 3D effect the buttons in R3 are flat with no grey background.  Funny enough, I think the contrast of the IDE in Dark Mode is better.

2018 R2

2018 R3

As a long-time Mac user I’m not entirely sold on Dark Mode.  Some of that is change and that I’m just not used to it yet.  In some respects I feel like I’m reverting to my college PC where light text on a black screen was the norm.  I guess the more things change the more they stay the same.

A new property, SupportsDarkMode was added to the Build Properties section to build apps with Dark Mode enabled.  To help developers the application class has a new event named AppearanceChanged to let them know when the OS has switched between light and dark modes.  

Labels, TextFields, and TextAreas running on Mojave will now use the automatic system colors to get the correct appearance on light and dark modes when text is test to opaque black (0, 0, 0, 255) and backgrounds set to opaque white (255, 255, 255, 255).  In a similar fashion, FillColor, TextColor, and FrameColor now map to proper light/dark system colors.

Since there are many OS colors available than what Xojo provides natively, you might want to look at CSTrueColors by Ulrich Bogun at https://drive.google.com/open?id=1vg-sN8_7mz18zeu9XoRWZaBc8Tm-_Enb.  

Currently Xojo does NOT support Windows dark mode but is looking into it.  A Xojo blog post suggests that Microsoft has released several API’s for dark mode and another one is due in the near future.

Incremental compiling for LLVM/64-bit targets now works.  The first run can still take some time but after that it should only compile changes.  This should significantly reduce cycle times on debugging 64-bit applications.

In Windows Xojo updated the text rendering so that it matches Win32 controls.  I’m just guessing but if Xojo ever moves away from Win32 controls the text rendering will have to change to match.  

Windows is now using the native Win32 Label control.  Overall drawing seems to be significantly faster with this change.

Among the changes is one that might affect a lot of legacy projects (we have a number of these) is that drawing directly to the Graphics property is no longer allowed.  To be explicitly clear about the change this does not affect, in any way, the graphics parameters passed into a canvas or window Paint event, nor does it affect getting the Graphics object from a Picture object.  This only affects the graphics *property* on Canvas and Windows classes.  The fact that it’s continued to work for all this time says that it was definitely time to retire this ‘feature’. 

There is also a list of 79 bug fixes.  Some Windows, Mac, and Linux framework issues fixed.  A couple of changes to MySQLCommunityServer and Postgres.  SQLite was updated.

Xojo 2018 Release 3 isn’t just about Mojave dark mode.  The 64-bit incremental compiling is a most welcome feature.  The speed increases in Windows drawing is also well worth the upgrade.  As always, please test your projects fully before releasing them into the wild.

What is your favorite new feature, change, or bug fix?  Anything causing you problems?  What are your thoughts on Dark Mode and the contrast of colors in the IDE?

Xojo 2018 Release 2

Xojo 2018 Release 2 is now available.  This release is heavy on fixes with some for the IDE, for Windows, Linux, and some new features for iOS.  

In iOS, the iOSTable now supports Pull-To-Refresh.  iOSTable now does a better job with variable height rows by setting the UseDynamicHeight property and lets the row height be determined by the content of the cell.  The inserting and removing of rows and sections is now animated if they are in the visible section of the table.  The IOSHTMLViewer is now using WKWebView instead of UIWebView.  A fix to the AutoLayout editor now tries to keep you from making constraints that could cause crashes.

Windows received a ton of love in this release but the biggest change is related to drawing.  Xojo 2018 R1 introduced a new way of drawing in Windows that effectively eliminated flicker but it also severely limited the speed of drawing.  R2 appears to have mostly fixed this issue by calling additional Paint events rather than caching pictures.  As always you should test the Windows versions of your apps to see if the drawing speed is acceptable for you.  Many of the old ways to eliminate flicker actually make drawing really slow now so test, test, test!

Besides the drawing issues there were plenty of other Windows changes as well.  Printing in no longer limited to 96 DPI.  BevelButton, HTMLViewer, Listbox, Xojo.IO.TextOutputStream/BinaryStream, Xojo.Net.HTTPSocket, Sliders, Object2D, OpenGLSurface, ContainerControls, and TabPanels were all touched in this release.

Linux and Raspberry Pi wasn’t ignored in this release either.  BevelButton, Listbox, HTMLViewer, and GroupBox received updates to fix various bugs.  Of note, the HTMLViewer on the Pi no longer hard crashes the application.

A change that could affect some people is that Graphics API now takes Doubles instead of Integers for better precision.  It probably won’t be a big deal for many developers but you will definitely want to try your drawing in non-HiDPI and HiDPI modes to see if anything has changed.  I did a quick test with Shorts, Formatted Text Control, and Tab Control and didn’t notice any drawing glitches so it’s possible that the average developer will be unaffected by it.  

Another graphics change is a new AntiAliasMode property that controls the quality level when drawing scaled pictures.  There are three modes:  Low, Default, and HighQuality.  Default Quality, I think, is simply what we have now.  The documentation (AntiAliasMode is missing from the built-in documentation but is online) is unclear as to how Default compares to Low and High Quality.  Testing should reveal this.  Also unclear from the documentation is how this affects speed but one can presume that High Quality will be a little slower but I have not tested this.

There are two new functions added to the SpecialFolder class.  The new Resources function returns the appropriate platform specific resources directory if it exists.  The new GetResource takes the passed in name and returns the file (if found).  Neither of these new functions are found in either the built-in or online documentation.

As always please review the Release Notes to see if anything affects you or interests you.

Documentation and examples are one of those things that no one likes to do.  But given the audience that Xojo caters to (the Citizen Developer) I am always amazed that things that are added to the framework often don’t have an example project.  I might be wrong (because I didn’t check every single example) but the new IOSTableRefresh and new animations don’t have an example project.  Nor is there anything for the new AntiAliasMode.  

The new SharedFolder.Resources and GetResource methods aren’t in any of the available documentation (other than release notes) but at least Resources is used in the SpecialFolderPaths project.  However, that example isn’t listed in the Release Notes as being changed.

The documentation not being available at release is simply unacceptable.  Each new feature should have an easy to find example project demonstrating its use (preferably available during the beta period too).  I also recommend having a folder for each version that has shortcuts to all of the examples that are new or modified for the current release.  Every release this list changes so the examples list doesn’t get loaded up with folders from old releases.  Regardless, I’m very disappointed the documentation in this release.  Xojo needs to do better.

Anything in this release that you’re happy, or unhappy, about?

Xojo and the Rapid Release Model

If I could change one thing about Xojo what would it be?  My answer is, without a doubt, the Rapid Release Model.  Here’s why.

The idea of the Rapid Release Model isn’t a bad one.  In the not too distant past many applications had major yearly updates.  Many still do.  In fact, Xojo (when it was called Real Studio) did this with varying degrees of quality.

Some of the complaints about the yearly, monolithic, release of Xojo (back when it was Real Studio) was that it wasn’t a very stable release and it took several dot releases to get it right.  This was the impetus that led me into the Beta Program so I could test out new features before it was released.  I was tired of new features not being usable due to an obvious lack of real world testing.

In theory, the Rapid Release Model introduces smaller changes and a few new features each release.  Releases are roughly every quarter but in recent years this timeframe has not been as consistent.  I believe this change happened, in large part, to address some of the complaints of the Rapid Release Model.  One of the complaints being that the constant drive to get new features in every release gives the software a perpetual beta feeling.  I would argue that the recent changes to the Windows drawing system certainly justifies that feeling to many current Xojo developers.  

From a developer standpoint, I can only imagine the pressure on Xojo’s small development team to constantly add new features every 90 days.  It means that developers are always pushed to get things done rather then get them right the first time.  Again, I would point to the plethora of changes to the Windows drawing system that have spanned many releases as proof.

I believe that marketing is entirely behind this new-features-every-release mantra so they can get buzz about something in every release.  I get it:  for a small company they need to create as much buzz as possible.  Buzz creates some sales and renewals.  But I think the Rapid Release Model is actually hurting them with many developers who value stability over new features.

More evidence that the Rapid Release Model is hurting Xojo is their recent change of telling customers their development plans.  No longer will they tell us the target date of when a feature is released and instead they’re simply saying if it’s a ‘priority’ or ‘important’.  Prior to this, Xojo CEO Geoff Perlman said that Interops and Android would ship by the end of 2017 and not only did they not deliver, but it seems highly unlikely they’ll get it out by the end of 2018 in anything other than an alpha release (purely a guess on my part and I’d love to be wrong).  

Being poor at estimating isn’t just a Xojo problem.  Chrono-Optimism is a human condition and I believe the old adage that 80% of the work takes 20% of the time and the final 20% takes 80% of the time.  Estimating is an arcane art form and at times software development is pure magic that takes time.  Forcing releases into this 90 day window makes the problem worse by having incomplete solutions and incomplete testing.

When all is said and done, I believe Xojo would be better off ditching the Rapid Release Model and going back to monolithic releases with regular dot releases that does nothing but fix bugs.  Perhaps this means that there are only two major releases a year.  Sometimes only one.

The Rapid Release Model is not without some merit.  We currently know that every release will fix a large number of bugs and we know roughly when that release is going to come out.  Not all bugs are created equal but for many developers we can’t wait six months to a year to get a release that fixes some bugs.  So any replacement to the Rapid Release Model must take into account that Xojo developers need a regular, perhaps monthly, bug fix releases for critical and important bugs.

I think changing to a hybrid model between the monolithic release and Rapid Release Model fits the small Xojo team better.  First, it lets the new features gestate in internal testing longer before we ever see them without being rushed out the door.  Second, the regular release of bug fix builds is simply that – bug fixes – and lets the developers continue to work on the next big thing without the pressure of having to add new things in each release.

To say that the Rapid Release Model is a failure is hyperbole.  To say that the model makes the product beta quality is also a stretch.  The truth is somewhere in the middle and I think this is an important discussion for the future of Xojo and their customer base.  What do you think?