App developers get inundated with demands (some of them personal, others professional) to find that sweet bridge of communication and design something that appeals to both Android and iOS camps. This is true despite the idea that the two technologies were designed to be at odds, as if the animosity that exists at Apple towards Android is somehow translated through the platform’s language (which is exactly what happened).
Cross-development mobile frameworks, such as Appcelerator’s Titanium and Adobe’s PhoneGap, provide decent platforms for developing in the best of both worlds. There are good and bad things about such technologies. Below are some of the pros and the cons about cross-platform development tools for mobile apps. Whether you find yourself leaning more toward apples than robots, there’s something to be said for understanding both.
- Deployment speed increases and cost decreases: This is a simple inverse proportion. The faster a developer can create apps, the less money it costs. Creating apps is significantly faster using cross-platform technologies. Plus, the code developed can be reused as a primary reference for use in other projects on either the iOS or Android platform. Since the code is developed to work on iOS and Android, the translated piece of language is a good launching point as demand rises for a related app, regardless of platform. This saves money because it allows companies to avoid investing in a new team to create an app for just one system.
- Easy access to plugins: Appcelerator and PhoneGap offer easy access to plugins that can easily be used in other services or tools. These also include offering common links to similar APIs, such as those for the devices’ cameras, accelerometers, or location sensors. Instead of writing unique code to talk to an iPhone’s GPS and a Samsung Galaxy S II’s GPS, one centralized set of code will be automatically modified to interface with both devices.
- Support for enterprise and cloud services: These frameworks allow for the easy integration of cloud services. For example, after an Exchange integration is coded once, it will work on both platforms. Also, multiple security methods aren’t needed, because the apps will function similarly on either the iOS or the Android platform.
- All supporting features may not be included in updates: When Google, Apple, or Microsoft adds a new feature, the framework being used will need to be updated. Given that the two languages are different, the communication “bridge” that the framework forms may not allow all pieces of information to pass. This is an inherent challenge, which will hopefully find its answer soon, although it will necessarily always lag behind each platform’s official SDKs.
- Tools are restrictive: Frameworks mandate that developers use prescribed tools and suites limited to the software, which inherently requires the user to ignore their preferences and use something that they may have to learn all over again (that is the worst-case scenario).
- Slower code and render time: Any cross-compilation process has the chance to be slower, especially since the user most likely won’t be able to use tools with which they’re familiar. Also, the code render time will be longer, because it will have to churn out code for each platform.
- Inefficient code: Because the developer will not be working in each platform’s native language, the efficiency of the final code will be determined by the efficiency of the translation engines in the tool. This may cause the final code to contain bloated code and inefficient coding techniques that a seasoned developer wouldn’t use.