Where Corona SDK Falls (kinda) Flat
Update 10/08/2011: Instead of making another post to highlight other issues with Corona, I'll just continue to update this article.
The Corona SDK is starting to become more and more popular among developers. In fact, my tutorial on setting up Corona for Windows development is still the most popular post on this site. Since I've posted, lots of other great game developers have been posting about Corona, along with Jesse Warden, who seems to have been making all sorts of contributions. In fact here is a video from Jesse Warden that is almost 2 hours long, covering the process for developing in Corona (on a Mac). Needless to say, there is lots of momentum and excitement surrounding Corona, and I'd say with good reason. Corona is a great solution for creating games quickly, which will work on (most) Android devices and iOS. Even with all of the Ant or Maven scripts in the world, it doesn't seem like there has been an easier solution made for cross-platform development yet.
(image credit: John W. Iwanski aka Chicago Man)
With all of this in mind, there are still a few things about Corona (aka Ansca Mobile) that seem to be counter-intuitive/counterproductive. This criticism isn't meant to be stated matter-of-factly, so if any of these gripes are unwarranted, please let me know in the comments. Here is another good blog post from a Flash/Corona developer which covers some of the same issues brought up in my article.
The marketing copy on Corona's website states (emphasis mine) "Corona is the only complete solution for developing across platforms, OS versions, and screen sizes," but that's not entirely true. Since Corona SDK's release #591, only Android OS 2.2+ and ARMV7 devices are supported. This means there is a long list of fairly recent Android devices which cannot run apps made with Corona (the best list I could find of ARMV6 devices was here. It includes HTC Aria, Hero, Legend, LG Optimus, Motorola Backflip, Samsung Galaxy, ViewSonic ViewpPad, ZTE Blade/San Francisco and others).
Not a deal-breaker, but it is worth mentioning, since Ansca Mobile doesn't make this very obvious on the website. It also seems as though there will be no intention of adding support in the future.
Also, there are a few (somewhat important) features in Corona which only work for iOS.
For example, in the notes on media.show(), it mentions anything related to the device Camera or Photo/Media library is for iOS only. Same goes for all of the map features - iOS only. While this probably isn't a reason to look elsewhere, it might be. Again, it's not overly obvious that Android isn't supported.
Response from Ansca Mobile:
As far as Android goes, everyone knows it's incredibly fragmented. There's tons of different devices, tons of form factors, versions, etc. Basically, in order to continue to move the product forward (in terms of Corona + Android), we had to draw the line somewhere. Android 2.2 and Armv7 just so happens to be where that line was drawn. For developers who absolutely need support for an old version of Android and anything below the Armv7 architecture, then Corona's definitely not for those developers.
All devices are not created equal. Although the hardware specs for Android devices vary greatly (compared to iOS devices) the general consensus among the Corona development community is that on average, Android performance is worse than iOS performance when using Corona. This is even highlighted by popular third-party library developers of Particle Candy and the Lime library. The particle candy download page explicitly states:
please keep in mind that Corona may run slower on Android devices than on iOS devices. Also, not all of the SDK's features are available on Android devices yet. Ansca is working hard, however, to further improve both, performance and feature richness on Android devices.
The developer for Lime made a similar observation on the Corona SDK forums:
The main performance issues I find, which are certainly a lot more prominent on Android, are down to how many tiles ( or other Display Objects/Groups ) are active.
Here is a thread on the forums where you can see for yourself how this can be a headache to developers, and one without any obvious solutions other than waiting for Corona to improve Android performance.
Can't Trust Simulator Performance
This might seem obvious, since your development workstation is almost certainly more powerful (by a few orders of magnitude) than your mobile device. You would expect a 64bit machine with 8gigs of RAM to outperform your phone, but it might not be obvious where the exact threshold is. For example, just by browsing the forums there are many developers having issues with performance discrepancies between the simulator and devices (here is just one example). Undoubtedly, there will always be developers having issues with something or another, and that doesn't mean it's the software's fault. However, just about everyone that has done game development has run into performance issues at one time or another, and the typical remedy is debugging and profiling. Both of which have very limited support right now (at least for windows).
This is further highlighted by a third-party Corona SDK library called Lime, which offers lots of helper classes and features. Unfortunately, with some implementations there are hardware-related performance issues. What's tricky is that it's not always obvious what the exact problem is - since some games work without issues. When that's the case, everything is fine... but if you are having issues, you may find yourself tweaking code endlessly without any clear resolution. Code that seems like it should work just fine (and appears to do so in the simulator) might not work on your device.
Again, this could all be code or game design related, but the fact that there are many developers having similar issues (and not a whole lot of answers) makes this noteworthy.
Response from Ansca Mobile:
... the other issues you have (such as inconsistent simulator/device performance, etc), all we ask is that if you find something, to please create a test case (a small example project that sort of reproduces and isolates the bug), and then submit a bug report. The bug base is engineering's "to-do list" so to speak, so that's definitely the fastest way to get something resolved. The bug reporter is here:
(When you log into your account on anscamobile.com, you can click the 'Report a Bug' link at the top to get back to that page at any time)
Since this article was originally posted, the Corona forums have been updated to allow non-verified users read-only access to forums - also, by signing up and verifying an account (no subscription needed, trial users are ok) you have full access to read and post in the support forums. This was perhaps main topics of this post, and the issue was completely resolved within a few days. I believe that speaks volumes about the developer support Ansca Mobile provides for it's Corona SDK users, which is vital to a thriving new language / API / developer tool.
The debugger for Corona SDK leaves a lot to be desired. It's basically a command-line debugger, so any debugging you do is done via typing actions into a terminal/command prompt. This is obviously a bit of a hassle when trying to debug, although better than nothing! (For a while, there was no debugging option for Windows). There are often times you will just get a "run time error at Line ##," which is certainly helpful to track down where it's happening, but there's no other information given (e.g., what type of error was it?)
Lua Library Support
Corona SDK uses Lua for the scripting, then parses this into the proper formats on their servers during the build process. This was a great idea, since Lua can be very powerful and flexible. However, as another blogger pointed out:
Lua has a rich library of code available to it, but Corona will not work with any of the many binary libs. In our case, this lead to us having to abandon interfacing with a web service using AES encryption. In general, you are restricted to whichever advance features the development team have included and exposed. This includes OpenFeint, Flurry, and an older version of the Facebook Connect library. For Twitter or Facebook using OAuth you'll have to roll your own solution (unless I decide to share mine…).
It's not unusual for software to limit the number of installations you can have across multiple machines. Corona SDK limits you to 2 installs per license. That means if you have a desktop and a laptop, all your installs are accounted for. However, what if your desktop and laptop are both PC? You also need a computer running OSX to build for iOS devices, which would put you over the 2 machine limit. Same for running a virtual OS, with a program like VirtualBox. If you have Corona installed on your desktop, and within a VirtualBox instance, both of your licenses are used up, and you will not be able to install on any other machines or VirtualBox instances.
The only way to "deauthorize" a computer, is by selecting an option in the Corona Simulator on that computer. Let's say you installed onto a VirtualBox instance which has since been deleted, or onto a computer which you don't have access to anymore, or one that has been reformatted. Unfortunately, you are out of luck and the only solution is to fill out a support ticket - so that Ansca staff can manually remove authorizations. As far as I know, there is no other way to deauthorize your machine. As you can imagine, this has the potential to turn into a very long and frustrating process (link goes to Corona forums, in a thread where someone has this exact problem).
Long story short, you may want to plan out your development process and think carefully about how many machines or Virtual Machines you will need for development.
Limited Subdirectory Support
When working on any apps, not just games, the organization of your code and assets can be a huge factor in how efficient your development process is. Unfortunately for Android developers, Corona does not currently support subdirectories for all of your assets, at least not in a very robust way. That means most of your non-lua files (music, art, etc.) are all in a single folder. This may not be a huge issue if the number of files in your project is small (less than 20), however it can become a nightmare for more complex projects. Here is just a small example of how this limitation could get out of control.
note: This limitation was not obvious to me right away... the Corona Simulator seemed to allow subdirectories without any problems. Issues only arise when you build the file and try to actually run on your device.
Honestly, there aren't too many other gripes I have about Corona. It seems like the perfect solution when everything works according to plan, and when you only need to use the features that are supported. If you venture into uncharted territory however, any troubleshooting or debugging could be entirely up to you. The community is extremely helpful, as are the admins, but there does seem to be a slight element of luck/magic/voodoo surrounding performance. Or maybe it's just a result of incomplete/insufficient documentation - either way, this small list of gripes encompasses the main issues I have noticed with Corona. Feel free to add on if you have others, or if you have alternate solutions.
Follow up thoughts:
Another important thing to note is Ansca Mobile's quick response to community feedback. It seems that whenever a blog/forum/etc. post is published anywhere online, Ansca Mobile staff are there to read it and provide responses within hours. I mentioned to the staff in an email that I haven't discovered a development community this enthusiastic since Actionscript 3 came out. Most of the other write-ups about Corona SDK state similar things - and now that I have access, I'll be speaking with the rest of you Corona developers in the forums! Special thanks to Hetal and Jonathan at Ansca Mobile for the feedback. If anyone notices other mistakes/misunderstandings in this post, please let me know via email / comments!