Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Can Mobile Software Developers Attain Zero Turnaround Time?

How can we locate inefficiencies in mobile software development?

Mobile apps codingHi, I’m Silver and I recently joined the ZeroTurnaround team from the world of mobile application development. In the past, I actually hadn’t encountered huge restart/redeploy times when it came to developing mobile apps, but after seeing how thousands of Java developers around the world are much happier using productivity tools like JRebel, even a 30-second delay while compiling seems like an unnecessary waste of time.

After getting to know more about the tools being used in the Java EE world, it made me wish it would have been possible to use similar tools back then when working with mobile applications. Especially with BlackBerry® OS platform. I believe many developers would be happy to eliminate the need of restarting the BlackBerry® Smartphone Simulator or the real device while developing certain kind of applications (e.g. ‘auto start application’).

While redeploying for other platforms like Android, JavaME, iOS may be less inconvenient than with BlackBerry® (at least in my experience), they all lack of the feature that I’m referring to; let’s call it an instantly visible code change, for lack of a better term. This is when a programmer can see code changes without restarting the application, losing their place in the code and dealing with other delays.

Now, this isn’t specific only to mobile applications, where developers have to perform a certain navigations to get back to the view where the code change can be verified. And while Java and Scala programmers have been quick to adopt JRebel and other productivity boosters for developing web apps, I haven’t seen the same issue taking hold in mobile development. Yet.

Some ways to decrease deployment and development time:

  • A large chunk of time-to-visible-code is taken up by compilation, and selecting hardware wisely may decrease build time. For example, I’ve even witnessed a 400% reduction in build time by switching to an SSD drive in some projects.
  • Designing your application for convenient and rapid development (of course, by keeping the other important software design aspects) so that verifying a code change on the device doesn’t require specially crafted navigation flows and/or certain expectations or dependencies from other software modules and components.
  • Prayers to the Mobile App Saints for rain, sun and zero-time restarts (note: may not be applicable nor guaranteed to work).

Tell us what sucks about developing mobile apps! :)

Now, we’re not saying that we are looking into JRebel-like solutions for mobile app developers–at this point, we are merely looking to learn and discuss. For now, I’d like to invite all the mobile hackers out there reading this blog post, to share your thoughts below (or email us at about the time efficiency aspects in mobile software development.

  • What takes up the most time in the cycle of code -> compile -> redeploy -> test on mobile emulators/simulators or on the actual device?
  • Which mobile platforms are you building apps for–Android, Java ME, iOS, BlackBerry®, etc?
  • What are the average redeploy times on the platforms you’re developing for?
  • Do you feel that something might be improved in the mobile app development cycle?
  • Which missing features do you hope for most from current mobile development tools?

By helping us consider these questions, we can certainly learn more about what pains mobile app developers face, and collectively work towards more efficiency and less turnaround time for developing and rolling out new app. Bye!