Xojo Musings

iOS 64 bit builds was introduced in Xojo 2015 R1.  Raspberry Pi support and 64 bit builds for Xojo desktop, web, and console apps was released in Xojo R3 in October 2015.  iOS, Raspberry Pi, and the 64 bit builds are all using the LLVM compiler.  The lack of a 64 bit debugger really holds back adoption of these new platforms in Xojo, in my opinion.

I’ve spent the last month working on a couple of different Raspberry Pi projects.  One was for a client and one was for fun.  In both cases the projects weren’t exceptionally tricky or complex but they took way longer than necessary since you can’t ’see’ anything while it’s running so I was is forced to use ‘old-school’ debugging methods with log files, message boxes, console messages, and whatnot.  Regardless, it’s not fun using the Raspberry Pi with Xojo.

It’s obvious that the move to 64 bit is much harder than they anticipated.  If it was easy the Xojo IDE would already be 64 bit by now – a year after 64 bit was released.

As a company we’ve officially held off on supporting 64 bit builds of our products.  Both Shorts and Formatted Text Control use XojoScript which isn’t 64 bit compatible yet.  XojoScript can be stripped from both products but it’s not an ideal situation and one that seems pointless since 64 bit is coming – eventually.

Xojo 2016 R3 was released a few weeks ago so the chances of R4 coming out in October is pretty slim.  The Xojo Developers Conference (XDC) is coming up in two weeks so I’m sure everyone at Xojo is gearing up for it.  And since they are all at the conference there is not much chance of real work getting done that week.  Good for those attending but bad for those anxiously awaiting new features and bug fixes.

In the past two and half years Xojo has added two new platforms (iOS and Raspberry Pi not to mention 64 bit builds) and not added any permanent staff (that I’m aware of).  Xojo does amazing stuff with the limited staff it has.  While they swear it doesn’t take away from their work I have to call them on it.  Two new platforms with initial development cost, debugging time, and the subsequent bug reports from users HAS to slow them down on other things.  It simply does.

I’m not doing their level of work but we manage five employees each with their own set of projects.  To put one person on ‘project x’ when they’re already working on ‘project y’ means that ‘project y’ gets delayed.  Since 2016 R2 was a big iOS release one has to wonder what was delayed to get those features added (and some would argue they were a year late anyway but that’s a different post).

I’m hoping to see a 64 bit debugger at XDC but I’d bet on a 64 bit IDE first.  This makes sense because they need time to work with it internally before we see it.  This will mean that XojoScript and whatever else was holding 64 bit back has been figure out.

Other things I predict for XDC:

Android.  Don’t get me wrong, I want Android because I feel it’s the only way for Xojo to grow into the mobile space, but if it means that the same staff are now adding yet one more platform it’s not worth it.  I’d rather have the big ticket items they’ve already said are coming than yet another platform that takes precious time away from what they already have. Likelihood:  sadly, pretty good given a recent Xojo blog post

Windows framework changes.  It’s been a while since Windows has received significant love.  We know they’ve been talking about using part of the .NET framework in Windows and now that Windows XP support was dropped this might become a reality.  The only question is what does it give us and when do we get it?  Likelihood:  Good

New framework additions.  The Xojo framework has been slow to gain momentum in the community.  Part of it is bugs those brave enough to use it have discovered and part of it is that it’s incomplete.  I’m not sure how much of the new framework is used in new parts of the IDE but it seems like this would become a bigger part of their mission as time goes on.    Likelihood:  Good

New database frameworks.  In iOS we’re already seeing the potential changes coming where a database error throws an exception.  This is a good change but will require a lot of patience on our part to get used to.  Many XDC’s ago Xojo showed off ORM classes (a lot like ActiveRecord but built into the IDE) for SQLite that looked interesting so it will be nice to see if that’s gone anywhere.  Prepared Statements are now built into the SQLExecute and SQLSelect commands but they’ve also screwed up (read removed) dynamic queries with the lack of BindType and BindValues so I’m looking for a new solution in this front.  Likelihood:  Maybe

Libraries with Xojo.  This was brought up last year at XDC so I don’t expect to see a lot of news about it but I do expect an update.  It would be really nice to create libraries using Xojo instead of using plugins or encrypting source code.  Likelihood:  Mention only

Plugin Management.  The simple fact of the matter is that many Xojo developers (myself included) use plugins.  For many it’s the simplest way of doing things and between Monkeybread Software and Einhugur they offer a ton of functionality that is not built into Xojo.  It would be nice to have the IDE manage them so you can have multiple versions of a plugin installed and only some of them activated on a per project basis.    Likelihood:  Wishful thinking

I’m sure there will be a surprise or two but honestly I expect methodical, evolutionary changes.  What news do you expect to see from the Xojo Developer Conference?  What would surprise you?

16 thoughts on “Xojo Musings

  1. If something new is coming like Android or a new Windows framework, I really hope they had an extra secret coworker doing that for a year or two.

    On the other side having 64-bit debugger (not necessary the 64-bit IDE) would help a lot to start using 64-bit.

    • I really hope for the 64bit Debugger.. followed by 64bit IDE (close second).

      As for the framework, I dont use it as it is limited and has had some serious bugs. If it was more complete (when compared to the old framework) I would be using it more. I know some of the 3rd party tools I use use it.

      I am hoping for a lot from XDC but I am not hanging my hat on it. Also I will miss you guys as I will be working instead of at the conference.

      • I would guess the 64bit debugger to come first as otherwise debugging a 64bit IDE is driving you mad. Maybe they are coming to the public at the same time.

        Improvements to the Windows framework are long overdue. Cross-platform on the desktop is Xojo’s core, and it has been thoroughly neglected.

        I just want a tool that works, and for me the new framework isn’t. It came out way too early in my opinion.

        Android is a possibility, but I’m not looking forward to it. If it is anything like iOS support at its introduction (very basic, then languishing for a year) then Xojo will be in for a LOT of derision and nobody outside the Xojo community will want to come within touching distance. It would be very important to hit the ground running there.

  2. Based on the past couple of XDC’s I think there will be some vague ‘future’ stuff announced with no timeframe. I do expect news about 64 bit IDE and debugging – whether we like it or not is besides the point.

    I *think* that Mac OS X remote debugging is working already but everything else is taking longer. LLVM experts aren’t exactly growing on trees and becoming an expert takes time.

  3. Unfortunately, I think you are right. Personally, the only thing I want is more work on the new framework. If they want us using it, we need more feature parity. Like databases, tcpsocket, and threads.

    The longer they wait to finish the new framework, the more “right” I become about it being a bad idea. And this is an area where I do not want to be right. I want nothing but the best for Xojo, and although I don’t agree with the decision, it’s the one they made so I hope it is a success. So far, it has not been.

    • Anything the Xojo engineers are not using themselves on a daily basis is, by definition, not going to be complete. I know I’ve found edge cases in several of the new framework classes that made me think, “WTF, this bug says they’re not using it themselves.” And several times the new framework simply doesn’t work they way I, and others, expect them to (the httpsocket subclassed in Windows comes to mind).

      I sort of like the new Text and Auto data types. Auto is a pita to work with I *understand* why and it’s not horrible once you get used to it. Text is similar in that it has a learning curve.

      I’ll beat this dead horse some more: until they’re using it on an hourly basis it’s not going to ever be complete. Sort of like how the old Real Studio IDE was always buggy since they wrote it in C++ instead of Real Studio. Eating your own dog food does have some advantages (though some disadvantages too).

      • I’m not convinced that will ever happen. Porting to the new framework is just too tedious. Even porting Feedback – which would be a good start – would be way too much work. The IDE? I can’t see that ever happening.

        Like I said, I want to be wrong. I want to eat my words.

        • we all would love the 64bit Feedback/IDE. And the more it uses the new framework the better for all of us. But converting it would be a major chore. Not sure when that would happen.

          I would love the 64bit IDE/Feedback not that i have to have 64bit but it will help them work out the details/issues with 64bit builds that would help all of us with our apps.

  4. For my business, adding an Android target in relatively short timespan (e.g. by the end of 2017) would be enormously helpful. I’ll probably end up boring everyone senseless about this at XDC next week.

    Xojo’s cross-platform features allows my business to cover a lot of ground with limited resources. I think of it as a force multiplier that allows us to take a certain amount of work and deploy that to the platforms that our customers want to work on. We’ve recently used Xojo to bring our iOS development in-house and, although translating all of our business rules to the new framework was fairly time-consuming, the project was an enormous success and we’ve been able to make huge improvements upon our previous, outsourced app, and still save a lot of time compared to rewriting the whole thing in Xcode.

    We’re seeing a lot of customer demand for an Android app, and our current options are either diverting internal resources to building one from scratch or outsourcing it. Either option would be a huge and expensive project, so if someone at Xojo were to come to us and say “we can make it possible for you to reuse lots of the work you did for iOS to produce an Android app, but we need to find a way of paying for the extra resources that we’d need to make that happen” then I’d be happy to do whatever I can to make that happen.

    I understand that my business’ needs are going to be different from lots of other Xojo developers, and that the Xojo community has a diverse set of requirements. Ideally, the company would be able to make constant progress on all of their targeted platforms, but I’m saying that as someone who has only the shakiest grasp of the economics behind that.

    What I wouldn’t want to see is new platforms being added and then not given enough support to survive. We’ve been lucky (and have also planned well) that Xojo has always been just in time to deal with crises that could affect us (e.g. recent 64-bit requirements), but adding more targets increases the risks associated with the constantly changing requirements we all face.

  5. I would love to see Android but I dont see it happening anytime soon. It is different enough that it is a major change to get it to work. rPI is a linux variant so it is close enough for most of the framework. Just the LLVM part that goes to native code on ARM. iOS and MacOS are similar so adding it wasnt too bad. But there is nothing like Android. And there is a ton of different models/sizes/screens/etc in the android world. Unless they add another set of engineers then I dont see it anytime soon. Would love it. But I would rather them finish with the platforms they have now over adding another platform.

  6. I would like them to just finish something instead of always putting things aside and working on next big thing. It is getting really old to never have anything even close to completed. All this time since 64 bit, then we don’t even have Icons on 64 bit windows applications. (And that has nothing to do with their problems with the debugger) Given how many times Xojo has changed the Icon on Xojo it self they should know how important the Icon is. Fact is they just have a very nasty habit of just turning to next big thing and leaving things as is.

    I am not against the platforms they added, I think Raspberry PI for example put them at a very different spot than most others, it was sort of a new momentum. But same there as with everything its not followed up since next big thing is always more important.

    iOS, there is no point in it without Android so I wont protest over the Android getting added, but same applies, there is no point in adding any of it if the customer knows it will never be safe bet to use as Xojo will just go for next big thing leaving the new platform as only a teaser that that is incomplete or only barely working.

    • I agree Xojo Inc takes a VERY long time (if ever) to get big new features/platforms to a reasonably complete/stable place… And It is frustrating

      But Xojo does let me get a lot done for desktop apps (using the old framework) …and luckily as I mostly write apps for in-house use at work, the Windows side is good enough.

      The thing with trying to use the new framework, outside of bugs, is that it kills my productivity, both because it is different enough, and because it is incomplete, having to mix the 2 styles…

      Some of that is because I have been using the product since V3 so the old framework is 2nd nature for me, but the mixing I think would be an issue for new users too.

      – karen

Comments are closed.