Several weeks ago, I talked about how we’ve begun our feature cycle. We’ve actually gotten quite a few items done that you can check out on the Corona roadmap. However, we haven’t hit our stride quite yet because of some difficult challenges related to OS versions. So this week, I wanted to give you a behind-the-scenes tour of some of those challenges, what we’ve learned from the experience, and our plans to tackle them.

Working around Breaking Changes

Last month, I talked about the breaking changes Apple introduced in 10.8. Thinking that we were about to wrap up with workarounds, I had planned to do a follow up on a new public release for 10.8.

Boy was I wrong!

We’ve spent the last few weeks working around even more issues, not just with the Mac, but also with iOS and Android: on Android 4.x, there were breaking changes in the behavior of UI elements that started misbehaving with OpenGL, causing native display object to render incorrectly; on the Mac, an Apple API was leaking and causing the simulator to crash after several refreshes; on iOS, audio would not play on resume because there was a behavior change between iOS 4 and iOS 5 in Apple’s CoreAudio library. There are more gory details on the Corona Daily Builds summary page.

And most recently, we finally found a fix to a longstanding issue on HTC devices. We got some critical clues from some of you last week that helped us squash this one. It turns out that the the implementation of OpenGL on certain HTC devices violated the spec, causing images not to render at all. We’ve corrected it and found a way to do some minor optimization.

Boiling the Ocean

It’s fun to share engineering “war” stories over the campfire, but we’d rather spend our cycles on new features, new products, and new platforms instead of boiling the ocean on the fragmentation across OS versions.

We took a step back and realized that we’ve been fighting an uphill battle. Apple and Google have been pretty consistent about making the breaking changes between OS versions. They don’t break everything, but they break enough for it to be a significant distraction for us.

Even without the breakages, supporting multiple OS versions is a lot of work. There are numerous times where we have to implement a feature twice, once for each version of the OS because the OS API changed. We also spend a lot of time making sure you can build one single binary per platform so you don’t have limit your app’s reach. To do that, we have to employ a variety of techniques to make sure everything is backwards and forwards compatible, from weak-linking frameworks to dynamic symbol lookups.

Apple has been particularly forceful with pushing developers to the latest OS versions. Gone are the days when a user could count on using a Mac for 10 years…

Stopping the Insanity

So here’s what we are planning to do:

(1) The next public release is going to officially support Mountain Lion 10.8. As I’m getting a little superstitious, I’m not going to promise any dates just yet. I’ll announce something when we are very close to releasing it.

Also, for those developers using OpenFeint, please be aware that GREE has stopped support for all new OpenFeint games. Therefore, this will be the last public release to support OpenFeint. On iOS, we recommend you use GameCenter. We’re still working on the right solution for Android — there’s a lot of noise out there.

(2) We have decided to stop fighting Apple’s policy — if you can’t beat ‘em, join ‘em — and will be more aggressive about dropping support for older versions of MacOS X and iOS. Loosely speaking, we will aim to support the last two major iOS versions because consumer upgrade adoption rates have been extremely high. However, depending on features introduced and bugs fixed in the latest version of the OS, we may decide that it makes more sense just to release the most recent previous version. And we’ll of course give you fair warning if that’s the case, and if you gives us good reasons to make a course correction, we will.

For the Mac, this means:

  • 10.6 is not officially supported. To ease the transition, we are still permitting the simulator to run on 10.6, but if you want to perform device builds, you’ll need to upgrade to 10.7 or higher, as even Apple doesn’t support 10.6 for iOS or Android (the latest Java security update doesn’t work on 10.6).
  • Soon after, you won’t even be able to run the simulator on 10.6, because we want to adopt newer 10.7+ technologies in both the simulator and in MacApp, e.g. in-app purchase, AVFoundation, etc.
  • 10.7 is officially supported. However, there are some key 10.8+ technologies we’d like to get in your hands, e.g. Game Center, so we’ll be closely evaluating the benefit of going just 10.8+.

For iOS, this means:

  • iOS 4.3 will be supported in the upcoming public release.
  • However, all 4.3 users can upgrade to 5.x, so we will likely drop 4.3 as soon as iOS6 comes out.
  • iOS 6 beta device builds will be available in a daily build soon after the upcoming public release.

(3) On Android, the predominant market share still is on 2.2 and 2.3 based devices. This may change with the popularity of the Nexus 7 tablet and Jelly Bean (Android 4.1), so we’ll be watching closely.

* * *

In an ideal world, we wouldn’t have to drop support for older versions. But we don’t believe in battling complexity for complexity’s sake. We want to fight the good fight — building more great features and products for you all

  1. I agree with Jade above, but please think hard about only supporting 10.8. There’s a lot of bad press around about it and the need for ‘new macs’ to run it due to it being slow on any of the ‘older macs’. This makes it an expensive ‘upgrade’ for many who like me happily work with 10.7 on a Macbook pro from 2008.

    • this! I hope 10.7 will be supported as long as possible. It feels wrong to buy a new Mac when a 4 year old is working just fine. And I don’t want to buy the glossy MacBooks! A new Mac Mini is long overdue.

  2. Given Apple’s ludicrously aggressive upgrade schedule (my original iPad, just over 2 years old, becomes effectively defunct as a development device once iOS5 support is dropped) I think your approach is the only sensible one.

    Interesting that the Android “changes” you mention amounted to “no change”!

    Apple makes a lot of fuss about fragmentation on Android, but there’s a significant cost to developers in their endless ditching of OSes more than a couple of iterations back.

  3. Hello
    I am a University Professor. I teach Corona Sdk to my students in a classroom of 20 iMacs of the year 2008. Update a Mountain Lion we would come out very expensive, (would have updated computers). When will Snow Leopard not be supported?. This is bad news for us. We have scheduled a Corona Sdk 80 hours course next September.

    Best regards

    • @Ray, great to hear you are teaching a class! You can still run the simulator on 10.6 (Snow Leopard).

      If you want to do device builds on 10.6, you might be able to get it to work, but we can no longer actively support it because Apple does not. Specifically, they do not offer XCode for 10.6 and they made a security update to the Java framework that breaks the Android SDK on 10.6. So if you want to do any sort of mobile development, Apple is forcing everyone to upgrade.

  4. I have co-workers who give class with Turbopascal (from 1995). Do not you could keep a version of Corona sdk that would work in Snow leopard? Only The Simulator, not for publish in Appstore :). Only for teaching purproses.
    Thank you for your excellent work

  5. FYI – Your link in this article (as well as on the “Corona SDK Daily Builds” page) to the Corona Daily Builds summary page doesn’t work.

    You get a “Sorry! This page can’t be accessed.” page.

    And conveniently on that page, the “If you think an error occurred, feel free to contact support.” link takes you to paid support. :)

    • Argh, that’s embarrassing! We’re getting bitten by Drupal permission issues (again).

      Okay, thanks for letting us know. We’re looking into it.

  6. This makes sense. Android 4.x support will be important by fall or spring of 2013.
    Google has made moves to push quicker adoptions. The time it took us get to Froyo from Eclaire was quick (in relative terms). It was quick because you had the trickle of new devices with 2.2, then the flood of the cheaper ones.

    I know Apple gets their customers to upgrade quickly, if I remember right I heard New iPad sales aren’t as fast as original iPad sales. Apple customers might be getting upgrade fatigue?

    Important in this Android space, though, is the Kindle Fire and the NOOK Tablet.

    • @Tony, if you mean the issues on Android 4.x, those were fixed in daily build 878.

      Yes, we are working on fixing the permission issue on the summary page — seems to be a really obscure Drupal bug.

  7. Aaron Isaksen says:

    Hi Walter,

    I think your plan makes a lot of sense. In particular, i no longer want to support iOS 4.3 because I can’t get my hands on a test handset, and I just don’t think there are many customers left that haven’t upgraded to 5.0 but still are savvy enough to buy apps. (I used to feel very differently about this, but Apple doesn’t make it easy to support older OS since you can’t downgrade a test device, so as you say, why fight them?)

    Thanks for letting us plan ahead.

    -Aaron

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>