Guest blogger Josette Rigsby has over 15 years experience in leading technology teams and delivering solutions. She has a special interest in enterprise architecture and emerging technology. Josette attended the SXSW in Austin last week and is here to give us the low down.
South by Southwest Interactive (SxSWi), the annual pilgrimage of thousands upon thousands of techies to Austin, TX to learn, pitch start-ups, commune with their peers and (of course) party, has concluded. This year’s conference was held March 9 to Match 13. SxSWi attracted more than 20,000 attendees and featured over 1,000 panels. Each day every conference room, event hall and corridor was filled with discussions of the latest trends and what might be coming next. Given the gadget loving audience, it shouldn’t be too shocking that mobile technology was one of the most common themes in many of these conversations.
Mobile technology adoption has grown at an astounding pace. Mobile Internet usage has doubled every year since 2009, and analysts project mobile browsing will surpass traditional desktop Internet use by 2015. Our desire to be constantly connected to the digital universe has resulted in over 5.9 billion mobile subscriptions. That’s around 87% of the global population and a huge market for all types of mobile applications and content. SxSWi sessions like: Why Mobile Apps Must Die, Mobilizing Web Sites: Strategies for Quick Mobile Web Implementation, Best Practices: Native + Web Hybrid Mobile Apps and Demystifying the Future of Web and Apps, explored the challenges of creating engaging mobile experiences from almost every imaginable angle. A sprinkling of attendees and I rose early on the last day of the conference to attend the “The Right Tool for the Job: Native or Mobile Web?” panel, which featured
- Buzz Andersen and Jacob Bijani of Tumblr
- Majd Taby of Facebook
- Matthew Delaney of WebKit
- Tom Dale of Ember.js
The Right Tool for the Job: Native or Mobile Web panel
The panel began with a brief history of how creating modern software has evolved from using early low-level, machine specific languages to highly abstracted web-based development and finally to the age of the app. Native development has long been “the” way to create rich, highly interactive mobile applications. However, developing native apps comes with a number of challenges – no standards, difficult to deliver dynamic content, a constant stream of new devices and a lack of cross device/platform compatibility. These factors can result in long test and development cycles, high levels of complexity and significant expense, but native development is not the only choice for delivering mobile applications. Approaches from CSS-based responsive design and locally rendered HTML (Flipboard) to HTML5-based mobile websites (Financial Times) and native/web hybrids (Apple App Store), now offer capabilities that rival native solutions. It is important for developers and designers to understand the nuances of each option to make the best choice for their project.
Google iOS web app
Facebook hybrid native/web app
Web, Native or Little of Each
The popularity of Apple and Google Android app stores has made mobile delivery almost synonymous with native development. Locally installed applications developed in Objective-C (iOS), Java (Android and Blackberry) and .Net (Windows mobile) offer:
- Fast performance
- Tight integration with operating system and device
- Native user interface components that conform closely with the device
- App store distribution
- Several easy to implement monetization options
- Ability to function without an Internet connection
However, native development is the most expensive and time-consuming option for mobile applications - especially when multiple platforms must be supported because the application must be customized for each supported platform (and often platform version). The challenges of native development have led many developers to embrace alternatives.
- Faster to develop
- Easier and cheaper to staff with development resources
- Excel at displaying and delivering dynamic content without deploying app store updates
Web apps are also getting faster as browsers begin to support technologies like WebGL. Panelist cautioned against attempting to create web apps that simulate native features. This often results in lots of overhead, poor performance and a potentially negative user experience.
Yet, web applications aren’t the right tool for every scenario. For example, high performance games are likely a better fit for native mobile development since they often require more than the limited amount of application cache and local storage allocated for each web application on platforms like iOS. In addition, native apps may gain access to device capabilities before web applications; for example, Apple exposed iCloud APIs in advance to iOS developers allowing them to integrate the technology in advance of other developers. These issues will become even more important as hardware-based payment technologies like NFC becomes more prevalent. There can also be variance in the features supported by mobile browsers. The problems aren’t as significant as cross-platform compatibility issues, but all the panelists noted that more standards are needed for mobile browsers. In the interim, tools like rng.io, developed by Facebook and Bocoup, can help developers instantly understand what capabilities are available in a specific mobile browser. Rng.io shows feature compatibility visually using rings (hence the name) and includes a drill down that details exactly which tests a browser passed or failed.
Pure mobile and pure web aren’t the only choices; you can also mix the approaches and create hybrid applications. Native apps are really about using the best tool for the job, and many recognizable brands like Apple (app store), Netflix and LinkedIn use this approach. Most hybrid applications wrap web content in a native shell and call device functions as needed making hybrid apps almost indistinguishable from a pure native application. Hybrid apps can be easier and faster to build than fully native apps and they are easier to update since only the changes that impact native code require redeployment to the app store.
Choosing which approach is best is almost always a grey area. You should try to determine:
- Who is the target audience?
- What devices is your target audience likely to use to access the site?
- What are the key goals of the application (e.g. revenue generation, traffic etc)?
- What native capabilities are required or there other implementation options?
- Are you building or buying?
Once you are able to answer the questions, determining the right platform should be easier.
What’s Next in Mobile Development
After discussing the various development options for targeting mobile devices, the panel explored the future. What’s the best approach going forward? The answer – nobody knows. While Jacob Bijani of Tumblr and Tom Dale of Ember.js felt a hybrid approach could offer the benefits of native and web development and let implementation progress quickly, Maijd Taby of Facebook said,
Hybrid development is a road frocked with danger. There are so many ways that the native and web client can get out of synch.
There isn’t a simple answer. Currently there is no technology convergence. The mobile market is growing and moving too fast for anyone to really know where mobile development or devices are going. Device, platform and browser technology will continue to change each year making it almost impossible to develop a strategy that’s future proof beyond a few. The best developers can do is ensure their applications have good separation of concerns. Loose coupling will make it easier to perform the inevitable changes that will be required when mobile technology evolves. This may not be a popular conclusion, but it is reality.