Today’s developers now have several choices to assist with cross-platform design, ranging from options of application type, supported languages, toolkits, and delegation of logic to scalable, remote backends. Each of these comes with a set of trade-offs, and the speed with which they evolve requires examination of where each will be headed in the future.
In this report, we explore and expand on the following:
- The four avenues through which mobile cross-platform development can be achieved (mobile-styled web app, hybrid app, cross-compiled app, and MBaaS), along with the limitations, benefits, and use cases for each.
- The tremendous upside of solutions like Xamarin and Appcelerator, which enable developers to write code in one language and cross-compile down to native code on mobile devices.
- The fairly recent trend in offloading client-side business logic to MBaaS and remote service solutions and where this approach does and does not make sense.
- Organizational and structural challenges encountered by web and desktop development teams and how managers can best overcome those challenges.
(Feature image courtesy Flickr userphilcampbell)
2 Defining the mobile beast
Cross-platform mobile app toolkits appear to make two beasts many of us are familiar with — cross- browser web development and stand-alone desktop apps — into a single plausible animal with the obvious benefits of each. Although these toolkits are both real and extremely abundant, they can lead
developers to mistakenly view their mobile app as a chimera rather than the entirely new species that it is.
Because our mobile devices are (at least in theory) constantly connected to the network, we even have the ability for the apps to simply be native UI wrappers that pass some or all of their heavy lifting over REST to remote servers with centralized codebases written by our web teams in the language they are most proficient in. If you don’t want to write those backends from scratch, there are even mature, thriving spaces known as MBaaS and remote services, with many vendor options to choose from.
3 User expectations trump developer benefits
Good developers know that they should be reusing code. They know model-view controller (MVC) software makes their lives easier and their software easier to maintain and extend. They know that patterns repeat, and they pride themselves on being able to know when and where to use these patterns. They know in their heart of hearts that cross-platform mobile development is what they should be doing. What both developers and enterprises often fail to realize, however, is that mobile is a beast unlike any other, with the biggest difference being the expectations of users about speed, functionality, and familiarity (native UI).
Mobile users expect the responsiveness of a desktop app even when calling remote services. They expect that their apps will easily integrate with all of their specific device’s hardware, and they expect their apps will present familiar, well-rendered UIs, regardless of their screen size or resolution.
Unfortunately for the mobile developer, speed, functionality, and familiarity are the same three attributes on which cross-platform tools compromise in order to fulfill the promises of productivity and single code base. Hardware access and/or UI limitations alone could outright disqualify many a cross-platform tool from even being considered for use, and more than one enterprise has had to recently rebuild its app natively on each platform after user outcries about speed of HTML-based solutions.
In Sept. 2012, Mark Zuckerburg pulled no punches in stating that “HTML5 was one of Facebook’s biggest mistakes,” citing speed issues as the largest cause of user dissatisfaction with its app. Just a few months later, LinkedIn revealed that due to memory constraints, it too had been forced to scratch its HTML5 app and rerelease on native.
4 Questions to ask before you start
Given all of this evidence, it would be easy to write cross-platform mobile development off as a myth, tell you to write your apps native from the get-go, and let you continue about your day. Anyone who tells you that, however, is dead wrong. HTML5 is a completely viable way to deliver some apps in a cross-platform manner, but it’s no longer the only game in town. Developers can now choose from a spectrum of tools and toolkits — some of which can be used in concert— to centralize code base, cut down development and maintenance time, and deliver their apps faster and more reliably across multiple platforms.
The decision tree starts getting more complicated after that first question, and the HTML5 branch has many more leaves. The high-level questions you need to ask before writing a single line of code will probably resemble something like this:
Do we have in-house HTML5, CSS, or JS wizards? And/or:
- Is my app incredibly simple?
- Can our users accept slower interactions (and possibly even a web app)?
- Can our users can tolerate a clunkier UI?
- Will our app only be consumed by internal users?
- Is our app a prototype to prove market demand?
- Can we (or must we) push logic to a remote service? And/or: Can our users live with a network requirement?
|Mobile-styled web app||Extremely fast deployLittle or no maintenanceCommon UI across platforms||Not a true mobile app (no access to hardware, no icon, no app store)Network requirementUnsuitable for widespread external audience||Internal customersComplicated web product that would be costly to reproduce as an appCustomers just need “something on mobile now”|
|Cross-compiled app (Xamarin)||Native performanceAccess to all device hardwareNative UIIndustry-standard languageDiscoverable in-app storesPotential for code reuse
|.NET and C# requirementCurrently limited to only Android and iOS||Enterprises with access to good .NET and C# developers|
|MBaaS and remote service||Can be used in concert with any of the above solutions or even straight nativeScalableCost-effective (usage-based pricing)Quickly leverage existing enterprise and legacy systemsOffload heavy lifting to in-house or third-party remote servicesAllows nondevelopers to build mobile apps
Single codebase in well-understood language (if developing in-house service)
|Network requirementAdditional costCould result in vendor lock-inExperience degrades with slow connections||Access to existing enterprise functionalityDon’t want to reinvent the wheelLogic cannot be implemented with limited mobile device processing and storage powerPrototyping (start with third-party MBaaS to speed deployment and save dev costs)|
The answers to those questions will drive your direction and lead you down one or more of the four paths we discuss in this article.
If you do want to take an HTML5-based approach or leverage remote services, pay particular heed to the speed, functionality, network connectivity, and UI concerns of your users. You wouldn’t want a prototype giving a false negative because the delivery, not the idea itself, was flawed.
HTML5 is without a doubt still the riskiest route to take, but many have achieved success, as long as they understand and account for the risks. Chief among those risks is this: If you use HTML5-based cross- platform toolkits, you could well find all of your productivity gains negated upon having to code work- arounds for limitations of the kit or platforms. HTML5 cross-platform dev tools provide over 90 percent of all the functionality and UI needs. But it’s common to need something from that remaining 10 percent, and coding work-arounds can get costly. For many projects, the current tools might involve an unacceptably high risk for a marginal, possible gain. But expect that to change in the future. “Wherever there is interest,” says Loper, “the tools will improve.”
5 Four paths to a cross-platform app
There are a myriad of risks and rewards inherent with cross-platform mobile development, but fortunately, there are really only a handful of approaches you need concern yourself with. Let’s explore four of the most promising paradigms: web apps, hybrid apps, cross-compiled apps, and MBaaS and remote services. Each comes with its own trade-offs, summarized below.
6 Mobile-styled website
Plain Jane web apps should be considered for any mobile experience outside a widespread external audience. You’ll be able to release them quickly, and if they are nothing more than styling on an existing web product, your mobile users will automatically receive any upgrades made to the core code, meaning little or no maintenance.
7 Hybrid apps
In addition, these apps are susceptible to entering the “uncanny valley,” where they look and behave close to a native app, but the subtle differences throw users off and can significantly interfere with the experience. Perhaps the best bit of advice to keep your app looking native with these toolkits is, surprisingly, don’t. Apps in this space will never look or behave exactly like native apps. Because that’s never going to happen, be bold and go the other direction, like TripCase did: Give your app a unique look and feel that is largely the same across platforms.
“It’s hard to compare any hybrid approach directly to native dev, because ‘hybrid’ simply means HTML/JS/CSS and some kind of device API framework, like Apache Cordova,” explains Brandon Satrom, the lead product manager for Cross-Platform Tools and Services at Telerik. “It’s only when you consider the developer tooling experience around building hybrid apps that a fair comparison can be drawn. In the case of Kendo UI Mobile, we’ve dedicated a lot of time to performance because we believe that hybrid app developers should get the same high quality UI widgets in a mobile web framework that they get from built-in native equivalents.”
Debugging tools are perhaps one of the fastest-changing areas in this space, with several commercial and open-source offerings readily available. In addition to several recent performance-focused improvements in Kendo UI Mobile, developers now have access to tools like Google’s Chrome DevTools and Safari’s own DevTools, which allow them to connect their mobile device and thus, their app, to the desktop debugging devices that they already use.
Despite their limitations and risks, hybrid app toolkits boast a long list of Fortune 500 companies that have successfully deployed apps (including games and complicated UIs) with their tools, and that list has ballooned over the past year as the tools themselves have improved. If you have a strong web team and can accept the caveats and limitations we’ve covered, these tools can enable them to crank out an app on multiple platforms in a fraction of the time it would take to write native. The strict definition of an app is a small, single-focus piece of mobile software, and if you’re writing a true app —something simple and straightforward, which is unlikely to enter the “10 percent is really tough” arena — both PhoneGap and Appcelerator (which can also package apps to hybrid, and even has MBaaS solutions) are worthy of your attention.
8 Cross-compiled native apps
One step higher up the abstraction layer, we have tools that cross-compile code to native applications, with providers like Appcelerator Studio and SDK Xamarin, and RubyMotion (at the time this report was written, the latter, unfortunately, can only deploy to iOS).
For the UI layer, Xamarin gives you the option of either building a separate UI for each platform or cross- compiling the UI, although most folks opt for the former in order to avoid the uncanny valley problem. One might think that building separate UIs could slow development down significantly, but even with UI- heavy apps, such as the highly successful iCircuit, Xamarin has allowed developers to achieve 70 to 80 percent code reuse. Where Xamarin can shine even brighter is on the other end of the spectrum, where you have a complex piece of mobile software of which UI is only a relative fraction of the codebase.
This cross-compile space offers maybe the most exciting current and future prospect for cross-platform apps. What could be more enticing than a platform that lets developers write mobile apps in an industry- standard language and provides native speed and functionality for both the program logic and UI?
9 MBaas and remote services
Most cross-platform discussions stop right here with the three approaches of delivering the core application. When you’re in the mindset of doing cross-platform development, however, you really need to always be thinking of MBaaS and remote services, which allow you to offload some of the app’s logic to server-side code. Many operations such as file storage and sharing, push (to device) notifications, user management, third-party (typically social network) integrations, and possibly even core business logic either cannot or should not be performed using the limited processing and storage power of the mobile device. Furthermore, you may already have partially or fully built backend systems that you simply need to tie together and deliver in a mobile experience. “Regardless of how you build your application, be it with HTML5 or native, moTwin allows you to orchestrate, integrate and streamline delivery to mobile of any enterprise back-end data” explains Allan Denis, the CTO of moTwin. By pushing logic to a single codebase on a remote server, your team will save time both building and maintaining that logic.
If competition is a proxy for developer interest, then MBaaS (which provides not only the API but also the actual backend storage and processing services as well) and remote services (which provide middleware connectors to enterprise and/or legacy systems) may be where most of the “cross-platform mobile app” interest lies, with at least 30 competing product offerings from companies like StackMob, Appcelerator (which also makes Titanium), moTwin, Catavolt, and Parse.
A big draw of these products is that most offer API builders that let developers (or even nondevelopers) quickly connect to third-party or even internal data sources and systems such as ERP and CRM, oftentimes via point-and-click interfaces. For apps that either need a considerable amount of remote interaction or integration with third-party or enterprise systems, these services can save considerable development and maintenance time. The cost for most of these services follows the reasonable, usage- based service model of the cloud, and the only real downside is the network-connectivity requirement and possible lag, which are often mitigated by doing device-side caching.
True MBaaS services such as those offered by Parse, Appcelerator, and StackMob also often provide the actual processing and storage layer, something to watch if you’re concerned about vendor lock-in. If you’re worried about starting down that path, take the time to investigate and understand how your data could be exported should you ever wish to switch providers.
With network speeds and coverage getting better all the time, it may also be worth following the MBaaS model and acquiring a bit of cross-platform compatibility by pushing some of your app’s more-involved logic to your own centralized, REST-accessible custom backend, essentially building your own internal MBaaS.
10 Organizational concerns
To get an app right, an enterprise needs to not only match its mobile users’ speed, functionality, and familiarity requirements up to the appropriate technology stack and tools but also make the right organizational decisions. This is especially true if, like most enterprises, the teams responsible for the app are coming from a desktop or web development background.
It’s often said that a good software developer is worth 10 mediocre ones, and in mobile, that gap can be wider. “With mobile, you have to take staffing even more seriously,” says Loper. “Good mobile developers are in high demand, and both recruiting and retention can be a challenge.” He suggests that one of the best ways an enterprise can ramp up strong mobile developers is by carefully selecting and cross-training internal resources. “Most enterprises out there have excellent Java, C, or .NET developers who know the business and technologies well, but may have grown bored and do not feel challenged — mobile may and re-engage and retain them.” That said, you still probably want at least one experienced in- house or external mobile developer leading your team for the year or so it will take for your cross-trained staff to ramp up.
A final caveat for cross-training web or desktop developers is, again, making sure they give enough respect and ample consideration to their new medium. The more experienced they are, the stronger inclination they will have to assume they already know the answers to questions about functionality, form factor, flow design, and architecture. “With mobile, when you stop to ask the same questions, you get different answers,” Loper reminds us. Err on the side of lightweight, single-focus apps; make sure you’re using experienced in-house or contracted mobile flow designers; and make sure all other critical questions are getting asked at every step from requirements through test.
Another critical decision you’ll often make as a manager of a mobile team is determining and standardizing the appropriate development environments. In addition to the preferred native development tools of Eclipse (for Android) and Xcode (for iOS), most of the aforementioned toolkit providers also offer desktop or cloud-based IDEs. Managers should budget a good amount of time researching and comparing the available tools and consulting with their developers on which to standardize on. Loper cautions against leaving this decision solely in the hands of your developers: “Shoving tools down developer throats will always fail, but when you leave the decision entirely up to them, they often lean too far toward the bleeding edge which may cause headaches for the whole team.” If you have developers who feel strongly about an environment or toolset you didn’t choose, it’s important to make sure they at least know you heard them and that they understand your final decision and why it was made.
Mobile development itself presents a whole new set of challenges that you and your team may have not encountered before, and layering cross-platform design on top of that can be the straw that breaks the camel’s back. Although cross-development toolkits are viable for use today, they have a set of constraints around them that could result in disaster if the risks they involve are not completely understood and carefully considered.
If it’s a true, simple, single-focus mobile app you’re looking to build, cross-platform HTML5 tools could help immensely with getting something out the door, and it’s worth your time to evaluate them. Any serious mobile app built today should still have an end game plan of going native, and for a client-facing enterprise app that stands to get wide adoption, it probably makes much more sense to invest in the native app from the start. Using a development platform like Xamarin or Appcelerator in concert with or independent of MBaaS and remote services, your native app can still achieve the promises of cross-platform app development while avoiding nearly all the pitfalls.
Across the board, cross-platform mobile tools and methodologies are both viable and growing rapidly in number. Although HTML5’s current restrictions and risks limit use cases, the cross-compile space has only a few vendors, and network speed may limit usage of a MBaaS or remote service, both the tools and the environments are evolving very quickly and warrant our constant review and reconsideration.
11 Key takeaways
- Although cross-platform mobile app development is still high risk, the tools and methodologies can be considered for a number of use cases today.
- For a mobile application of any complexity, going straight native is still generally the fastest, most-efficient, and least risky way to deliver. If the application is simple (and true mobile apps should be) and end users can tolerate a less familiar UI, an iterative development approach using HTML5 hybrid tools like PhoneGap or Titanium can offer significant speed to market and prove and tune a concept before investing more deeply in native versions.
- Regardless of how you deliver your app, investigate if custom or third-party MBaaS services can be used to push some functionality out to remote servers.
- In addition to the unique user expectations and technology-stack challenges of mobile, managers of a mobile team must also pay extra attention to staffing, education, tools, and environments.
12 About Rich Morrow
Rich Morrow is a 20-year open-source technology veteran who enjoys writing code as much as he does teaching. His current passions are cloud technologies (mainly AWS and OpenStack) and big data (Hadoop and NoSQL), and he spends about half of his work life traveling around the country training other technologists and business leaders on their use. He leads the Denver-Boulder Cloud Computing group, as well as quicloud, a Boulder, Colo.–based cloud and big data consultancy.
13 About GigaOM Research
GigaOM Research gives you insider access to expert industry insights on emerging markets. Focused on delivering highly relevant and timely research to the people who need it most, our analysis, reports, and original research come from the most respected voices in the industry. Whether you’re beginning to learn about a new market or are an industry insider, GigaOM Research addresses the need for relevant, illuminating insights into the industry’s most dynamic markets.
Visit us at: pro.gigaom.com.