There have been a few recent article around compiled code for mobile devices that you might have seen... but if not are worth checking out:

  • Wired has a very long article on the LLVM technology, very interesting despite the sensationalist title ("The One Last Thread Holding Apple and Google Together"). It covers the origin of LLVM, how it is used by Apple in Xcode, how Google uses it for server side software, and the open ideas of using it for portable client applications.\
  • JT covers  llvm-an-emerging-industry-standard  in a blog post, commenting on the article above (I echo his comments below)
  • A very popular writing a couple of weeks ago (still worth checking) is  Why Mobile Web Apps Are Slow , in which the author clearly claims mobile apps need to be compiled and explains why with lots of technical details and numbers (I know, hard to have the perfect numbers backing a claim, but some of those in the article are interesting).
  • On the same line, I read a paper by Kinvey (not public, sorry) pushing mobile compiled apps (backed by their services, of course) compared to the pure JavaScript solutions some of their competitors are offering. They also go back to the Facebook going native story with some details. Interesting read.
  • Jim McKeeth (welcome on board!) has a nice piece echoing the paper above and commenting on it at delphi.org/2013/07/why-mobile-apps-web-are-so-slow/. Needless to say Delphi is fully in the compiled apps camp.

Some comments are needed:

  • As you probably know, Delphi uses LLVM for its iOS toolchain. In the future, LLVM is also going to power the Android offering. So even if not fully up to the level of portable client apps, we have the goal of single source mobile applications (and desktop too). C++Builder also uses LLVM for its 64 bit version. Embarcadero has all intentions to increase its leverage LLVM and the related tools in the future. (Side note: we are not so totally closed to open source as some of our detractors claim.)
  • While Delphi LLVM compiler uses ARC, as well as Xcode, the potential slow down is linear with use and takes place only at the very time you are allocating or freeing memory, and is very limited with each operation. At the opposite, garbage collected systems stop the running up to do their cleanup, creating non-linear response time to actions.
  • We know we have some room to optimize the FireMonkey framework, but the overall architecture (including GPU specific hooks) offers us room for improvement. And, as demonstrated by third parties, you can also go native on iOS controls.
  • While on iOS Delphi uses the same tricks of the platform tool (Xcode), the situation will be very different on Android. How many tools offer a native solution, with Google pushing application developers towards the Dalvik VM? The Delphi community will have some interesting times ahead.

PS: Sorry again for being slow with blogging, hoping to get back to a more regular schedule. Seems that when I travel (even if to visit Embarcadero offices like in the last two weeks) I end up with less time for blogging.