Posted on by

As you all know from our previous release, we worked very hard at getting Android to perform at the same level as iOS, and I believe we succeeded in doing so but we failed in some features that were critical to the release. After shipping that last version, we noticed that even though we had improved Android performance on the device, we had not succeeded (dare I say “failed miserably?”) at Android build performance on our cloud. And yes, we knew that, but as the usual trade-off of development cycle goes, we decided to ship what we had.

Then, as we started integrating monetization features and working on the performance features, we ran into several integration walls that made it very difficult to manage the integration of the different options we offer for monetization. So, a decision had to be made — we could ship what we had been working on and play the lottery game and expect the integration to go really smooth and succeeded in building an app, or we could fail completely. The odds of failing builds were pretty high.

Yes, it would have been easy to blame someone else for the integration woes. “It’s Google fault!” or “It’s Android!” Nevertheless, we decided to bite the bullet and make the decision that will make it easier across the board for you, us, and our third-party vendors to integrate with Corona.

Here is a perfect example (and a true work example) in trying to build a specific app on Android: It took over 8 minutes to produce an app’s APK. If in each one of the builds, a new test was done and a bug fix was introduced — so, doing ┬áthat 10 times would yield 80 minutes wasted just on waiting for the build server to return the app’s APK. Grrrr!!!

The good news about this is that the new build process that we have now implemented internally is yielding a 30-second build time. Phew! (remember: this is internal and we still have some optimizations to do and while this is great, build times may be reduced even further or increase depending on load time, we are even optimizing our load balancer and that even shows great performance improvements).

So, given our grief with Android, hopefully, this will be the last build improvement we will need to do for a while. Because of this detour, we had to delay other work. We decided to push out the graphics performance and focus on getting the monetization features in ASAP now that we have blazing builds speeds on Android.

We have continued to fix bugs for both Android and iOS versions of Corona, and a lot of you have e-mailed me directly thanking me for fixing “your” bug. But this time round, we had a bug inside, and I ask for your patience as we fix it. Once we roll this out, you will see dramatic build performances, and continued flawless integration of new features into Corona.

Carlos


Posted by . Thanks for reading...

24 Responses to “The Day the Earth Stood Still”

  1. Bob H

    The openness of your communications sets you above other companies across industries. Keep it up!

    Reply
  2. Seth

    Well, thanks for the heads-up, but am I the only one who cares more about the graphics performance boost than “monetization features”? I’d rather have you pushing back this feature over the perf boost.

    Reply
  3. John

    Hey Carlos

    As others have mentioned I really appreciate how open you are — we all totally understand that things don’t always go as planned but keeping us in the loop makes it all very easy to work with
    -John

    Reply
  4. J. A. Whye

    I care very little about Android stuff — but understand the performance increase is something you *have* to do. By making sure Corona SDK remains cross-platform, it will continue to grow users and the larger community we have, the better for everyone. Even us fanbois. ;)

    And I echo Bob’s comment about openness — you guys are examples for other companies to emulate.

    Jay

    Reply
  5. Andrew D. Goodfellow

    I thank you for your transparency Carlos and Ansca!

    Because you seem to care about such things I’ll echo @Seth’s comment in that an Android performance boost is sorely needed. I can’t really monetize when my app performs poorly. People won’t see the value. So…since you are committed to monetization first, take care of performance as a fast follower?

    Thanks for the great software guys. -Andy

    Reply
  6. yuewah

    thanks Carlos and Ansca, they changed my life. Hope that the integrated Ad support is the last monetization, and ansca can focus to improve graphic function and performance as soon as possible.

    Reply
  7. Stefan

    I also really appreciate the open communication, thanks!

    Also, the new monetization features aren’t important to me either. As Andrew said, I can’t monetize on Android since my apps are performing poorly. Without the monetization features, I can still make money (by selling the app or using in-app purchases). However without decent performance in Android (for certain situations, such as the ragdoll test app I wrote) I can’t do anything.

    Reply
  8. Noah

    I also would vote for the graphics performance boosts over being able to add ads and such.

    I have seen very dismal findings on how much money people actually make on free apps with ads as opposed to just charging for the app with no ads.

    To me, any performance enhancements that would help me make a better looking, better running app will always overrule the monetization features.

    Reply
  9. Mark

    I’m not interested in the monetization feature and would vote to have the graphics improvements as well

    Reply
  10. ckausik

    Thanks Carlos for this candid posting. My vote goes to performance improvements and iOS notification integration. You may have seen the post about lackluster Android sales. In most cases, that could be due to cheap Android devices. But we continue to see crashes even on devices with Android 2.2+ on ARM7 from big brand manufacturers. Improvements in that area will be highly appreciated.

    Reply
  11. Vladimir Angelov

    I agree with most of the people above — we can’t really monetize apps with poor performance!
    Corona is great and I think we need features like OpenGL shaders, for example, much more than monetization. It better be a kick-ass framework for iOS devices than an average framework for iOS and Android :)

    Reply
  12. Rob

    Carlos, ditto on the appreciation of your honesty and transparancy along with better graphics performance as my top priority

    Reply
  13. carlos m. icaza

    Maybe I need to expand, the performance issue we encountered here was not “graphics performance” it was “build time performance”. We are *not* stopping any graphics performance work, is just that we had planned and coordinated some press with monetization companies and due to the nature of the PR machine, we can’t really switch them around. Graphics performance features are not really PR material and given our upcoming partnerships, it wasn’t a, ‘hold the press’ type of thing.

    But trust me, if anyone insists on graphics performance here is both me and Walter. Shaders, plus some other goodies are going to sneak up right after we get this rev out the door.

    Carlos.

    Reply
  14. rudy

    i presume apple’s 1500 ios5 new api’s will kep ansca busy as well ……..

    Reply

Leave a Reply

  • (Will Not Be Published)