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.

The New Xojo Framework

Xojo, Inc. has talked a lot at XDC (Xojo Developers Conference) about their new upcoming framework.  The reasons for a new framework are many and valid.  Among them are consistency, a need to serve desktop, web, and soon to be iOS applications, and to remove archaic methods.

This sounds kind of scary because most of us have been using the existing framework for many years.  But in reality I don’t think this is a bad thing.  How many times have you been bitten by framework calls that are one-based rather than zero-based to name just a few.  The new framework promises to make everything consistent across the entire Xojo universe.  All arrays/lists will be zero-based and methods are more explicit in their naming.

Furthermore, UI controls will become portable between desktop, web, and iOS.  In the current framework a desktop button is not portable to web button and visa versa.  While this isn’t too horrible, it makes life a bit more difficult as you have to create new instances and then copy the code from the events from one to the other.  The new framework means that a button is a button is a button regardless of platform.  There will be SOME differences as there are some platform specific controls (iOS has views, splits, tab bar, etc) that have no equivalent on the other platforms.

The Xojo framework has several main modules:  Core, UI, iOS, String, Color, Number, Math, Media and a few others.  They’ve also added a number of common interface elements that I suspect will become a very big part of the framework.  The Core framework has common items like Dictionary, Point, Rect that will be used by other parts of the framework.  In today’s framework you would create a Dictionary object like:

dim d as new Dictionary

In Xojo it would become:

dim d as new xojo.core.dictionary

Not a huge difference but enough that I’m sure will tick some people off.  But what this gives you are new methods that are unique to the Xojo framework that are very useful like ValueOfKey and RemoveByKey.  Not that those do anything different than Value and Remove in the existing framework but they are more explicit in their use.

Strings are another change in that strings now are zero-based to become consistent across the entire Xojo universe.  But otherwise most functions are part of the Xojo.String module.  All the usual suspects are there but new functions that are more explicit are also available.

The new framework is a requirement for iOS.  When it ships it will NOT be able to use the old framework.  Shortly after the iOS release it will be released for Web and then shortly after that for desktop.

The good news is that the old framework and the new framework can be used simultaneously (exception iOS) for years to come so it probably won’t mean much to anyone for a while.  When I asked Xojo, Inc. when they’ll drop the legacy framework they really had no answer.  I suspect like many deprecated things from Real Studio it will take a while.  So there’s no need for panic.

The new framework should make life easier for all of us in the long run.  It’s not going to be a quick transition and we won’t be forced to use it.  I’m okay with it because I’m sure there will be a bunch of other things to worry about more.  Welcome to the future.

Real World Only Two Months Away!

I don’t know about you, but I’m really looking forward to Real World this year.  Not only do I get to overdose on one of my favorite topics I get to reconnect with the many, many Real Studio developer friends I’ve met over the years.  Usually by the end of the week my voice is totally shot because I talk so much.

I think this Real World promises to be one of the more memorable.  The new IDE will most likely be released by then and it will provide plenty of material to talk about.  It looks like the entire first day is devoted to the BIG topics such as the unreleased iOS version, Web Edition, and the new IDE, to name just a few.  I will even go so far as to say that we’ll get a surprise announcement or two.

If you’re on the fence about going I suggest you take a look at the Sessions list at http://www.realsoftware.com/community/sessions.php.  Lot’s of sessions there for everyone to learn something new.

Seth, my lead developer, is leading two sessions on Object Oriented Programming.  We’ve been talking about ways to make this more engaging and useful than some of the sessions we’ve seen in the past.  I think everyone will enjoy it a lot.

I’m also doing two sessions.  The first is intermediate database programming techniques.  I think this will be how to work around the most common issues related to using databases in Real Studio.  This one hit home the other day when I had to work in a project that uses traditional Real Studio database coding rather than the technique we use.  It was painful and a good reminder on topics I need to add to my session.

My second session is about reporting tools for Real Studio.  I’m not a huge fan of the built-in reporting tool with Real Studio mainly because it doesn’t do a good job creating reports more than just a few pages in length.  There are other tools that you might want to consider and I’m hoping to show you one or two options you might not know about yet.

Don’t forget on the Tuesday before the conference we’re holding a training session of our own.  The morning session is all about databases.  We’ll be reviewing the Real Studio database classes and my “THOU SHALT NOT” list when it comes to database coding in Real Studio.

The afternoon session is about all the little things you need to polish your Real Studio applications.  We’ll talk about 3rd party tools, utilities, controls, libraries, and plugins.  We’ll talk about some of the most common needs/problems that Real Studio developers face and how we’ve overcome them over the years.

Sign up for both Real World and our training day before March 17th to receive a discount!

More information on the Sessions at Real World can be found at http://www.realsoftware.com/community/schedule.php

More information regarding our training day can be found at http://www.bkeeney.com/real-studio-training-2013/

See you in Orlando!

Real Studio Schedule Change (Again)

Real Software announced today that the much vaunted and talked about new IDE is delayed yet again.  Real Studio 2012 Release 2 was released to the beta list today using the old IDE.  An alpha for 2013 Release 1 will be released (to alpha testers only) soon for us to evaluate and provide feedback on usability.

I have mixed feelings about the announcement.  First off, I’m glad they’re continuing updates using the venerable IDE user interface.  I know there are a number of bug fixes and enhancements that I can use on projects – right now.  The updates are welcome and hopefully no new bugs are introduced (though RS has done a couple of dot releases for Release 1 so I see no reason why it won’t continue as needed).

This announcement, in general, is a good thing and I’m glad that Real Software has decided that burning their bridges with the existing IDE just doesn’t serve us, the Real Studio developer community, very well.  The flip side, of course, is that every release they use the old IDE just pushes off the new one that much further into the future.

Like many Real Studio developers I’m still not convinced we are best served with a radically different IDE.  I believe minor tweaks to the existing IDE might be a better solution.  However, it might be a matter of scale that once you change one thing you have to change this, that, and everything else and by the time you’re done you’ve rewritten the whole user interface.  Add in the new iOS framework and editors and the changes to Web Edition and it might have been the only way to do it.  So perhaps this is a good change but only time, and usage, will tell.

I can’t wait to get my hands on the new IDE and work on my large projects.  I am curious to see how the always visible project tab will work.  If it makes life easier it will be a good thing.  If it hinders me in those areas I find important it will be a bad thing.  Obviously my opinion is the only that counts – to me, at least.  🙂

This announcement also pushes back the new licensing scheme and the one-click Web Edition deployment.  For some this is a big issue and for others not so much.  I guess that’s up to you to be mad, angry, or indifferent.

What do you think of this news?  Good, bad, or typical Real Software time slip?

Twas the Night After Real World

I love Real World for many reasons.  It’s like a high school reunion except that you actually like (mostly) and get along with all your old classmates.  Everyone is there at Real World to talk about Real Studio and praise it (and bitch about it).  There were plenty of things to talk about this year.

The good news/bad news is that the 2012 Release 1 will come out later than what anyone expected and will still have the old IDE user interface.  But it turns out that this is good news in that R1 will contain a ton of bug fixes and minor to medium changes that will help everyone.  Release 2 will then have the new IDE.  Personally, I feel that my post from several months ago was pretty much spot on though in no way do I feel that my post had any influence on their decision.  I guess I can say, with very minor satisfaction, “Told you so.”

Web Edition is maturing nicely with news of an upcoming WebCanvas control that works pretty much like the desktop canvas control.  The 1-click installation on Real Software web hosting is interesting and I think I will try to move my web apps to their service so I can go back to regular shared hosting for my website.  Take what’s simple and put it on a simple server and take what’s complex and put it on the complex server.  It will make my life easier in the long run I think.

Cocoa is turning out to be a tough nut to crack.  Apple is doing things MUCH differently in Cocoa than in Carbon in a few areas and it seems that it’s hard to figure that out until you actually do the work.  Any framework is big and the deal with Real Software is that they’re trying hard to make it transparent to us.   But, the move to Cocoa, while very difficult, is an absolute must because Apple is slowly killing Carbon, it’s the only way to get 64 bit support and, it’s the only way to get iOS apps built in the long run.

iOS applications could be huge for Real Software.  Assuming they get it to work like we all need it to and it’s ‘just like’ an xCode app only written using Real Studio then they will have an unbelievably huge hit on their hands.  I can’t tell you how many clients ask me about leveraging their Real Studio code in an iOS app.  Currently that’s not possible.  A year from now?  I don’t know but I’ll be eager to test it even in the alpha stage.

Bottom line is that even though the company has taken a very long time to get the next version out the door I believe that this delay has been put to good use.  They’ve found stuff in the frameworks that they’ve been able to fix before it ever gets to us.  This is a good thing.  The delay is painful (and possibly executed poorly especially considering the talk on Agile software development) but we, and they, will be better off for it.

One can certainly argue the effectiveness of trying to code both the Cocoa framework changes AND a new IDE interface all at the same time but the fact is that they have made the Cocoa framework better by trying to do both at the same time.  By using the framework closer to how WE’LL be using it they’ve identified and squashed many more areas of concern.  The new IDE is a lot of change and some will hate it and some will love it and most of us will be in the middle.  I won’t know until I can spend 8 to 10 hours a day on it for a couple of weeks.  Based on what I saw at the conference that’s not possible now so the delay in getting the new IDE out is another good reason to push it of a release.

This is the first year where I’ve had multiple prospective clients talk to me about work.  If I manage to get all of the work I’d probably have to double my developer staff.  That’s a good problem to have!  I even had one client show up to the conference specifically to talk to me and my developers.

I though the location was okay and it was certainly better than Austin (nothing against Austin, just been there 5 or 6 times now).  I didn’t bring my family because we’ve been to both Disney World and Disneyland so Orlando had no attraction for me.  If they were to hold Real World again next year I’d recommend Las Vegas, San Diego or Seattle.  While some people might have enjoyed having it at the forefront of the big Memorial Day holiday weekend I didn’t as I felt like I lost the first part of it traveling home.  To each their own and I’d love to see more feedback on it.

I want to thank everyone for introducing themselves.  I had a lot of compliments about this blog and the magazine column and that really gives me a warm and fuzzy feeling.  I certainly don’t do it for the money and there are plenty of times where I feel like I’m talking to myself.  So at least I know I’m not totally crazy.  🙂

What was your takeaway from the conference?  Do you want me to dig deeper into any topics I’ve been posting about?

 

Real Studio for iOS

Real World News Part 7

Real Software did a good job of surprising everyone during their keynote address on Thursday by announcing, almost casually, that the framework changes are necessary to unify the various existing platforms and to target new platforms. New targets? Yup, almost as an afterthought they announced they were working on iOS.

Interesting news. It is, after all, their number one request in the Feedback system and I know from various sources that getting an iOS compiler working required a number of things to happen, mainly Cocoa and LLVM to name a few.

Perhaps even more surprising was the demonstration that Joe Strout, former Real Software engineer who is now a consultant, gave. He showed a simple, but working, iOS Real Studio application! Granted, it was a very, very simple app (more involved than Hello World but still just 3 controls) but it compiled and then ran it in the iPhone simulator that runs on Mac OS X. Very cool and a surprising advancement.

I didn’t get a chance to talk to Joe or other RS staff about the limitations or capabilities of building iOS applications with Real Studio but it really doesn’t matter at this point as they only have 3 controls working. They did say the first release would have a limited set of controls and capabilities. I’m sure as the beta gets closer (announced for 4th quarter 2012) we’ll get more information. It is currently scheduled for a first quarter 2013 release.

I think this is good news and promises to grow the user base tremendously. The fact that an experienced RealBasic and iOS developer is doing the design and implementation makes me very happy and gives me confidence that it will be done right, the first time. I think their timeframe is a little optimistic and if I was a betting man I would say release one to be the summer of 2013, but I will give them the benefit of the doubt for now as it’s obvious they’ve been aggressively pursuing this.

I can only assume that this would be a Mac OS X only product since the simulator doesn’t run on Windows or Linux and I can’t imagine Real Software trying to re-engineer that (or Apple allowing it). I also believe that iOS apps cannot use dylibs so this means that plugins will have to be abandoned or completely redesigned. For some this will be a big deal and others not at all.

If this product means that it will be just as easy to build iOS applications as it is to build desktop and web apps then it will be a huge hit. I casually made the comment to someone that if the iOS version is ready for the next Real World attendance will easily triple, if not more, simply because it’s such a hot developer topic right now.

Like everything else, only time will tell. We know very little about what the product does and what its limitations are. I look forward to working seeing it!

Google Support Not So Supportive

There’s been a lot of posts recently about Google vs Apple and whether or not Android is beating iOS or not.  Is Google the new Microsoft and will it thrash Apple in a few years?  Frankly, I don’t care, as a developer or as an end consumer.  I’m firmly in the iOS camp at this point as a developer (we have two apps in the App Store and one in the Mac App Store with more coming) and as an end user with a house full of iPhones, iPods, and an iPad.  I think Google will fail with Android simply for their piss poor tech support.

If you have an Android phone and you have an issue with <insert problem here>, who are you going to turn to?  The hardware manufacturer, the carrier, or Google?  The end consumer doesn’t care they just want the problem solved and just like how Microsoft is responsible for their hardware partners problems, Google will probably be left holding the bag for their hardware partners too.  Let’s hope their Android support is better than their business services help.

I’ve been experiencing issues with my mail server on my virtual private server and thought that going to GMail might be a good solution for a variety of reasons.  Because of Google ID issues I messed the registration up (hey, I didn’t say I was very good at this stuff now did I?) and locked up the domain registration for GMail.  After searching fruitlessly (ironically using Google search), I came to the conclusion that Google doesn’t really want to help you.  It’s downright impossible to talk to a human being or even send off a plain email to a support department.

I was never able to find an official tech support phone number for Google.  Sure, there are forums and articles and other information but nothing to get hold of a real life person – even at a price (as far as I can find).  There are some ways of getting hold of them through forums and other means but it’s all indirect and after sending off what I hope was a message to someone that can help I’m still waiting on even an automated response email saying they’d get back to me.  I’m not holding my breath.

Now, do the same thing for Apple.  It doesn’t take long to find a whole web page full of ways to get help.  Phone, instant messaging, email are all prominently displayed after two clicks on their website.  Sure, some of them cost money, but as a business, when I need support I’ll pay for it.  If that’s still not good enough I can go to one of the over one hundred brick and mortar stores around the world and talk to an Apple Genius for nothing.  If that fails, I can find Apple Resellers and other Apple certified experts in my area.

Apple’s been doing this for decades as a computer and consumer electronics company.  They’ve consistently been ranked very high on support satisfaction surveys.  As a family, we’ve had various minor issues with our Apple components over the years but nothing that a phone call or trip to the local store (either Apple or local reseller) didn’t fix promptly to our satisfaction.  I’m sure there are example of poor customer support with Apple but it seems to be the exception rather than the rule.

People say that one of the great things about Android is that it’s free.  The old axiom that you get what you pay for holds true in this case.  Google’s support is awful in my opinion.  To say that Google is the new Microsoft is an insult to Microsoft.  At least Microsoft got support right even if you have to talk to someone on the other side of the world.

What’s your experience been with Google support?

Mac App Store

The Mac App Store, so far, has been pretty good for sales of Task Timer.  We have been running double of normal sales of the previous version.  Technically, version 5 was out before it was approved in the Mac App Store so that’s even more proof that the Mac App Store is doing well for us.  So from that aspect we are very happy with what we’ve seen from a sales standpoint from the Mac App Store.

What’s not very good is the amount of time it takes to get an application – even an application update – approved (or rejected) in the store.  We’ve been lucky that the few bugs that have been reported aren’t affecting everyone and aren’t critical.  We submitted our update on January 12th and didn’t receive a rejection until January 28th.  That’s 12 business days!

The rejection was from not linking properly to the HXRuntime library.  The problem and fix is documented on REAL Software’s blog.  What’s worse is that REAL Studio applications don’t even use this library so this is a false-positive result from some automated test that Apple implemented between our first second submissions.

I realize that we’re not generating a ton of sales from Task Timer so we’re not even a blip in Apples sales figures, but 12 days is an eternity when a customer has a problem.  They won’t complain to Apple, they’ll complain to me.  At the best I can offer customers to update outside of the Mac App Store but that’s a half-assed solution, in my opinion.  At worst, I’ll lose customers for life because I’m ‘unresponsive’ or write ‘crappy’ software.  I predict most people will be relatively forgiving but I think it depends on the cost of the software and what it does.

We are not the first and only developers to face this problem.  Panic, makers of the popular Transmit, had a similar issue that was thankfully taken care of quickly.  One has to wonder if a public blog post from a very popular developer didn’t speed things up a bit, but the point is that the process has a flaw.

I can’t believe that Apple is oblivious to this problem.  The wait times for app approval is just too long.

I’m not sure what the solution is.  All I know is that the current situation is not good for smaller, independent developers like me.  Wasn’t the Mac App Store supposed to be a boon for us?

Anyway, I’m not really all that angry.  I expect that approval times will get better as time goes on.  I would also expect that the automation tools they’re using internally will be available to developers for testing purposes (before submission) or, at the very least, some sort of automated testing submission process that, if not instantaneous, is light years faster than it is now.

What say you?

Task Timer for iOS

Task Timer for iOS

We’ve been very busy recently.  Besides all of our cross-platform desktop app consulting work we’re now iOS developers as well (feel free to contact me if you’re looking for iOS developers).  Our first iOS app, Task Timer for iOS, is now on the App Store.  This is the Lite, iAd supported version, of Task Timer, and simply lets you track your life and hopefully bill for it. This version works on the iPhone, iPad, and iPod touch.

Want to track how much time you spend commuting to and from your job?  Create a Personal project and add a Commuting task and the next time you get in your vehicle hit the start button and when you leave the car hit the stop button.  It doesn’t get much easier than that.

The same goes with your on-site with clients.  After the initial setup it’s as simple are pressing the start and stop buttons.  At the end of the day, week, or month, you can view a summary of all the time you’ve spent.

Task Timer supports multiple simultaneous timers for those multi-taskers out there that can bill multiple clients at the same time (yeah, I’m looking at you, lawyers).  The Lite version supports unlimited projects and tasks but does not sync to the desktop version.

What’s it worth to you to increase your billing by 30%?  Did I mention that the Lite version is FREE?

An upcoming (paid) version will be able to synchronize with the desktop version of Task Timer (for Mac OS X or Windows) all without being plugged in to your computer!  This will be a free upgrade for current owners of Task Timer for Mac OS X or Windows.

So never lose money again!  When we developed the desktop version years ago we saw an immediate 30% rise in billing!  Why?  Because we know, down to the minute, how much time we spend on a billable (and non-billable) projects.  It helps our bottom line with billing AND it helps us track how well we’ve done with our estimates.  If you’re not tracking your time you’re not doing a very good job at managing it!

We hope you enjoy this free version.