A few weeks ago I was speaking with a venture capitalist (VC) about a mobile development contract that one of his companies had accepted. Sadly, the company was about to miss their first milestone: the delivery of wireframes. He was about to call the client to grovel and ask for an extension, and he wanted my advice.
Wireframes are rarely part of my mobile development process. I normally deliver working prototypes, often as web apps, in incremental stages. Instead of telling the VC about my process, though, I asked him whether the late delivery was for a native app, a hybrid app, or a web app, and what devices it was targeting.
He was flabbergasted. "I don't recall my chief technology officer ever asking my client about those other options—he assumed they needed native iOS and Android apps and did the proposal on that basis. Why, is there a price difference?"
It was my turn to be flabbergasted. "Yes—about four-to-one, sometimes more. There are trade-offs to be made, but many business apps will be fine as hybrid apps, basically web apps with a PhoneGap or Cordova native wrapper."
When situations like this come up, it's important to know what your mobile development options are.
Strengths and weaknesses
Fully native apps typically run the fastest, make the best use of device hardware, behave the most smoothly, take the longest and cost the most to develop, and are the hardest to update in the field. The typical cost of one medium-size iOS or Android app built with the native software development kit is $100,000, and adding another platform means reimplementing all the code, although most of the design can be preserved.
Mobile web apps typically run the slowest, make the least use of device hardware, are most prone to choppy behavior, take the least time and money to develop, and are the easiest to update in the field: the installation issue essentially disappears. The typical cost of one medium-sized app built with an HTML5 and a JavaScript framework is $25,000, and it should run on every device you can throw at it.
One major weakness of a web app is that it may not retain state across a context switch or device reboot. If you explicitly save and load state on the device, however, you can get around this problem. The issue of choppy behavior, such as jerky scrolling, can be fixed with carefully written JavaScript widgets and by the use of high-performing JavaScript frameworks.
Another major weakness of a mobile web app is that it won't have access to many of the device's capabilities. The usual cure for that is to build a native wrapper for each supported device with Adobe PhoneGap or its open source foundation, Apache Cordova. That may reintroduce installation and updating issues, but the additional capabilities are well worth it. The cost of the wrapper is incremental to the cost of the underlying web app, which runs in a window in the native shell, creating what's called a hybrid mobile app.
Platforms and tools
All sorts of variations on these basic approaches exist. You can implement the server side of your mobile app with a back-end-as-a-service platform, which may include a design package and a generator for basic client apps. You can find mobile app development tools that run in a browser and others that install on your development machine. Some platforms and tools generate or support native apps, some hybrid apps, some web apps, and some support all the above.
Some mobile back ends connect to enterprise data sources and systems of record, making them useful for extending existing systems to mobile clients. On the other hand, enterprise back ends often command enterprise prices: an annual fee in the six-figure range is common.
A few newer frameworks go beyond the thin shell of PhoneGap to expose native mobile controls and a wide assortment of native device capabilities, with only a bit of JavaScript controlling the app. As these frameworks come with native libraries for all the major device families, and as they use high-performance JavaScript engines such as V8, they offer a hybrid app that looks and feels native.
What does your app really need?
The first questions I ask when it comes to a request for an app are about the audience, purpose, and expectations for the app, along with the budget and time line. That seems obvious to me, but my VC friend's now-former CTO didn't seem to understand the need for that step.
In many cases, the client's answers eliminate the possibility of creating pure native apps, usually because they want the app yesterday, for no money. Then it's a matter of drilling down to see whether the use cases for the app require a native shell or not. Once I know the goal, I build the app page by page, test the web portion of the app in a browser frequently, and provide a build to the client for review at least once a week. I also make the client actually try the app before I work on the next iteration, although fighting that battle is probably asking for another rant.
Image source: Lenore Edman/Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
