Sunday, September 8, 2013

Considerations for Cross Platform App Development - Direct iOS/Androd SDK vs. Titanium Appcelerator

After having developed a number of apps on both iOS and Android, using both native SKDs as well as a cross platform development toolkit (Titanium Appcelerator) , I thought I'd reflect on some of the benefits and drawbacks that I experienced using Titanium as opposed to doing development directly in the native development environments. With more experience developing on Android with Java than on iOS with Objective-C, this comparison is based more on my specific Android/Java experience, though it's applicable to both.
  • Documentation: I found the Titanium Appcelerator documentation somewhat lacking in detail and incomplete. This issue is somewhat mitigated by the fact that the developer community Q&A site is active enough that answers to most questions can readily be found. However, I'm a big fan of Google's developer documentation in general and along with the over-abundance of StackOverflow activity, it's always a pleasure to develop in a Google environment.
  • Cross Platform Compilation. For the McRun Running Calculator of which we have an iOS version and an Android version, we developed first for iOS and released a couple of versions using Titanium Appcelerator getting the app stable on iOS before moving to Android. Development time for initial release was perhaps an 8-10 week project. This included working through UX considerations, directing graphic design, and also working thorough the process of implementing and testing the algorithm that is the core of the McRun app. Other than having to do additional graphic work (see below) to support android, much of this effort translated to Android with zero additional effort. However, while much of the backend code was easily ported to Android, most of the UI components had to be completely redone on Android. Appcelerator calls their cross platform framework as a "write once, adapt everywhere" platform, in which perhaps 80% to 100% of the code can be re-used. My experience is that now that we have revised the code to support both Android and iOS with conditional branching in the code (if (platform=="iOS" { // do iOS stuff } else { //do Android stuff }) and some conditional includes per platform, the code is now perhaps 90% compatible across both platforms. Eventually, we might strive to release updates on both platforms concurrently. Right now, we're one code base, and we release on one platform, then later do a release on another, and things get broken across platforms in the process. On our first Android build when the UI was so broken that app was in no way usable - complete jumbled spaghetti - fixing this and getting release ready was about a 3 week project. So from an effort perspective,  it required an additional 1/3 of the iOS development effort to release on Android.
  • Graphic Assets: Beyond the actual porting to Android, it's important to understand that the screen size and density permutations on Android is really extensive as compared to iOS which owns the entire hardware and software stack. Android development required multiple versions of graphics to support the various device configurations. This effort was wrapped into our porting effort mentioned above, but would have been required even if our app was purely an Android only app. iOS is easy in this respect - though I suspect this will change in the future.
  • Performance: I have found that Titanium performance on iOS to be very crispy. The load time is fast and the UI is very responsive. While the same app built on Titanium for Android suffers from extremely slow startup time. I suspect (and hope) this is an issue we'll be able to debug (more on this below) and resolve, but as of now, this remains an open issue and - for me - remains a big negative factor with Titanium Appcelerator.
  • Debugging: One challenge with Titanium Appcelerator is debugging on-device Android debugging. Developing directly in Java provides easy access to debug, error message, stack traces, etc. This is something I am still working through, so I may have more to say, but for now, I am still unclear on where my issue is on my app load performance issue on startup and on-device debugging capabilities aren't helping.
  • File size: An app built on the Titanium Appcelerator platform might be a 6MB Android APK file, whereas the same app built directly on Android with Java, would likely be less than 1MB; this is similar with iOS. While mobile devices are resource constrained on many levels, I don't believe that file storage is the biggest constraint. So, while this is definitely something to be aware of, this is not necessarily a deal breaker.
  • Hardware support: One benefit of using Titanium Appcelerator as compared to an HTML5 cross platform solution (at least the last time I checked) is that you get access (albeit indirectly) to the device APIs that control the hardware; so in theory as a developer you get full access to cameras, audio and sensors, such as the accelerometer.  Where this breaks down however, is where Appcelerator opts not to support an element of the API. For example, with BlueScan, my Android Bluetooth 4.0 scanner app research project, direct development in Java worked best as Titanium chose not to support Bluetooth. I have contacted Appcelerator directly and submitted an Issue that has been unresolved for months. Furthermore there are quite a few comments on the developer message boards that have gone unanswered by the Appcelerator team, so Bluetooth support doesn't appear to be on the horizon. There is a 3rd party module available but I didn't want to entrust my core code to a module that seemed to have limited usage and unproven support. Furthermore, as a research project, I needed to be tinkering at a lower level with Bluetooth capabilities, so I did not want to be abstracted from the API. Not all apps are appropriate for Titanium.
  • API Updates: One risk of using a framework like Appcelerator's Titanium is that their team needs to react and revise their platform as the underlying Android and iOS APIs evolve. I have seen a number of API updates (including the update to support the iPhone5) during my Appcelerator development cycles and was always surprised how quickly the Appcelerator team reacts to updates. This has never been an issue for me.
  • App store submittal: I haven't noticed any difference in my experience submitting to the app stores based on my development platform. As a security guy I like the Apple closed system, but as a developer Android is refreshingly simple and fast.

These are just my un-scientific observations. What's the best approach for cross platform development? I guess as with most anything, that really depends on the specific requirements, but there are merits to either approach.

5 comments:

  1. Really, these quotes are the holistic approach towards mindfulness. In fact, all of your posts are. Proudly saying I’m getting fruitfulness out of it what you write and share. Thank you so much to both of you.
    Mobile App Development Company in Dubai
    Android App Development Company in Dubai
    Mobile App Development Company
    Mobile App Development Company in UAE

    ReplyDelete
  2. Well explained! To support mobile app development demands I would also like to share, With the increased usage of mobile apps, the industry is now expecting to generate over $156 billion in consumer app spend by 2022. Constantly, Top Software development companies in the USA are growing rapidly with the increasing demands of android & iOS mobile app development.

    ReplyDelete
  3. Emerx Services provides outstanding cross-platform mobile app development capabilities and access to various tools and technologies, and strategic vision enable us to build robust, interactive, and scalable cross-platform mobile apps. Our expertise extends to building cross-platform apps for eCommerce, banking, hospitality, logistics, education, and many other domains.

    ReplyDelete