Software Development Times has written an excellent article about one of the important early development decisions which needs to be made when developing a mobile app – should you use native mobile app development tools, or should you present your app functionality using web technology – HTML, CSS and Javascript?
According to SDT:
Native apps maximize performance and user experience
Native development is, on average, the most widely adopted approach. Forrester’s latest Business Technographics Global Developer Survey found that, overall, developers build native apps 38% of the time, hybrid apps 22% of the time, and Web apps 27% of the time. That’s not surprising: Native apps offer a great combination of performance and user experience. And when done right, they deliver a high level of customer satisfaction compared to Web applications, as well as enable superior offline processing and storage capability.
But regardless of these benefits, native apps are a challenge to maintain. Developers we’ve worked with report porting costs of 50% to 70% of the cost of the original app for every new mobile operating system the app needs to run on. Plan to support iOS, Android, BlackBerry and Windows? That’s an increase in development costs of 150% to 210%.
Web apps minimize costs and improve agility
While developers on average spend more time building native apps, at least 74% spend time building with a Web-based approach. But with native’s advantages in performance and user satisfaction, why would anyone want to use Web technologies?
Unless an unlimited development budget is available, taking a native-only approach exceeds the reach of many development teams. A good rule of thumb is to estimate 20% to 25% in additional porting costs when using Web technologies, significantly less than the cost of an all-native approach.
Web Apps vs Native Apps
Web Apps, at least for some types of apps, offer a cost advantage if you plan to target a large number of mobile platforms (iOS, Android, Blackberry, Microsoft, etc.).
HOWEVER, web apps in my experience present a challenge if you want to create an app which appears to be native – you can spend a lot of time and effort making web buttons look exactly like native buttons, only to have all the rules change next time Apple or Android upgrade their operating system.
In addition, there are many types of app functionality which would perform poorly if implemented using web app technology. For example, if your app presents a long list of database entries, particularly if you want the contents of the database list to update automatically as the user types text into a search field, the inferior performance of web app technology very quickly becomes an issue – if your database contains more than a 50 entries, it is very difficult to make a web app provide acceptable search performance, without developing native mobile app components to augment the search – which kindof defeats the purpose of using web app technology.
In general I advise clients NOT to opt for the web app approach, unless the functionality of their mobile app is simple and not computationally demanding. While the lure of being able to port the bulk of your app to different mobile platforms with minimal changes might seem attractive, in my experience the risk of unsatisfactory mobile app performance, and the difficulty of achieving that vital last 1% of polish to make the web app into a compelling user experience, more than outweighs any benefits.
The Facebook Web App Experience
I’m not alone in my assessment of the significant challenges associated with creating high quality web apps. Facebook chose to redevelop their web app into a native iPhone app, because of the stability and performance issues their team encountered during development of their web app.
Scaling up with HTML5
As mobile usage exploded over the last few years, our priority was to ensure that regardless of device, platform, network, or region, Facebook users had a good experience on their mobile devices. To support thousands of devices and multiple mobile platforms, we leveraged HTML5 to build and distribute Facebook mobile experiences across iOS and other platforms.
By allowing us to write once and ship across multiple platforms, HTML5 has historically allowed us to keep the Facebook mobile experience current and widely available, and has been instrumental in getting us to where we are today. We chose to use HTML5 because not only did it let us leverage much of the same code for iOS, Android, and the mobile web, but it also allowed us to iterate on experiences quickly by launching and testing new features without having to release new versions of our apps.
So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth. So, we rewrote Facebook for iOS from the ground up (I really did open up Xcode and click “New Project”) with a focus on quality and leveraging the advances that have been made in iOS development.
(Re-)Building for speed
One of the biggest advantages we’ve gained from building on native iOS has been the ability to make the app fast. Now, when you scroll through your news feed on the new Facebook for iOS, you’ll notice that it feels much faster than before. One way we have achieved this is by re-balancing where we perform certain tasks. For example, in iOS, the main thread drives the UI and handles touch events, so the more work we do on the main thread, the slower the app feels. Instead, we take care to perform computationally expensive tasks in the background. This means all our networking activity, JSON parsing, NSManagedObject creation, and saving to disk never touches the main thread.
To give another example, we use Core Text to lay out many of our strings, but layout calculations can quickly become a bottleneck. With our new iOS app, when we download new content, we asynchronously calculate the sizes for all these strings, cache our CTFramesetters (which can be expensive to create), and then use all these calculations later when we present the story into our UITableView.
If you would like advice on whether your proposed iPhone App or Android App is a good fit for being developed as a web app, or whether you should choose the native mobile app development option, please Contact Me