So You Want Your Hybrid Mobile App to Feel Native…
The use of hybrid app-development platforms and frameworks is on the rise — especially those that let you develop for iOS and Android simultaneously — but having the right set of tools is different from using them correctly.
In fact, it may be this very distinction that has made it difficult for hybrid (that is, HTML5/CSS3/JavaScript-based) apps to shed the stigma of their past: Hybrid apps can, in many cases, reach performance parity with their native-coded peers, especially with device hardware power becoming more and more of a non-issue in recent smartphone generations, but a lack of best-practices combined with the fact that hybrid development has become more and more accessible likely means that the quality of the average hybrid app isn’t really indicative of the technology’s potential.
Of course, it would be nice to change that, don’t you think?
Today’s article is a rapid-fire class in best practices for making your hybrid-app projects feel like masterful native executions for Android and iOS devices.
Rule #1) Use native transitions & animations
When you swipe or tap to get to a new screen within an iOS or Android app, you have expectations about what will happen next. You might not even realize it, but you do.
We become used to the way that app pages slide in and materialize as we navigate around, so much so that we likely don’t even think about it… right up until something goes wrong and rubs against the grain of our expectations.
Think about it, if you dragged your finger across the screen right-to-left, and a page jumped in from the left side, it would feel pretty damn weird.
You might arrive at the right content, but something’s going to feel off. When writing any kind of an app, it’s important to go look at how other successful apps handle transitions and loading (is there a load screen/spinner anywhere? How do new pages load in? Do they make you tap a button for a certain function, or do you use some sort of swipe/gesture?).
Apply this evaluation to a broader range of animations as well, knowing that where a new view or object would just ‘appear’ in a loading website, it will likely animate into existence in an app.
Don’t reinvent the wheel, and definitely don’t break it.
Rule #2) Use caching to preserve online content when the app is re-opened
Another feature you naturally expect from apps — and, coincidentally, one you also may not even think about it until it doesn’t work — is that content that you were reading when you minimized an app is still there if you re-open the app a couple of minutes later.
If you’re reading an article, then have to take a call and send a message to someone, you don’t want the friction of having to re-open the app you were reading in and then scrolling down the page to find where you left off.
When possible, let your app’s pages take advantage of caching to help preserve offline capabilities and meet user expectations, especially when consuming content that has already been loaded once (reading a text, scrolling through a feed, etc.).
Rule #3) Refer to Android and iOS’ guidelines for design and UI; these can be mimicked on various hybrid platforms
Did you know that iOS and Android (and Windows Phone, for that matter) all offer specific guidance libraries for how they expect apps to look and behave for users?
Oh, you did know that? Well did you have the links to them?
BAM. Now you do:
- Apples guidance for iOS app design & behavior
- Google’s guidance Android app design & behavior
- Windows Dev Center design resources
One of the quickest ways to get rejected by Apple’s App Store is to submit an ugly app that blatantly shows you didn’t bother looking at their design guidelines.
Rule #4) When you do have to code, try to keep your components in minimal HTML/CSS, rather than using JavaScript, which can hurt app loading times
The title says it all: Don’t code every component in JavaScript if you don’t need to. Moving right along…
Rule #5) If you only pay attention to making one component of your app look truly native…
Then god dammit, it better be your app’s header bar.
You know, the title bar at the top of the screen?
If you give special care and attention to any component in your app, make it your app’s header bar. It’s the first thing that will catch a user’s attention, and every mobile OS has a fairly distinct style here (here’s an example for iOS, Android, and Windows).
Customizing the header bar (which generally includes your app title and navigation cues) is a super easy way to give a native impression.
Rule #6) Use the OS’ correct font
This is already covered in the previously linked design resources, but it’s so, so important: Your users will notice if you choose a font that isn’t what they’re used to seeing on their phone.
In a similar article on Smashing Magazine, Patrick Rudolph recommends the following font stacks for the most popular mobile operating systems:
/* iOS */
font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;
/* Android */
font-family: 'RobotoRegular', 'Droid Sans', sans-serif;
/* Windows Phone */
font-family: 'Segoe UI', Segoe, Tahoma, Geneva, sans-serif;Rule # 7) Choose icons and buttons over text and text links
One of the biggest quality shortcomings dragging down the average quality of hybrid apps are the apps that are essentially just a website framed into an app.
Hybrid movile apps are not websites. Even if the underlying technologies are the same, the expected experiences are still different.
All navigation and actions taken within an app should be executed through gestures, buttons, and icons. In a nutshell: physical and visual. These are the languages of mobile, so leave those anchor text links and dropdown menus behind when developing for mobile.
Rule #8) Optimize speed
The incredible Smashing Magazine (2nd shoutout this article) published a guide that covers making websites load more quickly on mobile devices, which also contains tricks to help hybrid mobile apps created in HTML5, CSS3, and JavaScript perform better.
We think they’ve done a pretty good job of covering this area, so we’ll just link you to the original article here.
Rule #9) Account for different screen rotations
Not all apps rotate. Some games are only played in landscape mode, and some apps remain in portrait orientation because it makes the most sense for their functionality.
That said, locking an app into one viewing mode should never be a decision made out of laziness. If there’s an argument to be made for allowing your app users to freely rotate their screens, be sure to include it!
For example, allowing a text or video-heavy app to rotate into landscape mode can allow elements to increase in size and make them easier for your users to see.
Conversely, certain pages of an app may display information or functionality that works better in a certain view, so not locking your entire app into one view is a good idea.
Rule #10) Don’t give gestures the finger
Swiping all over the place to navigate through apps and pages is a natural habit of the mobile user these days.
A great way to make sure your app doesn’t just feel like a ported website is to include gestural controls where they make the most sense.
For example, iOS users expect to be able to swipe horizontally on items in a list (like a messaging inbox or a shopping list, for example) in order to bring up options for manipulating or deleting an item.
A great way to ensure your apps feel like native experiences is to make sure you aren’t forcing ‘taps’ when a ‘swipe’ or other gesture (pinch to zoom, etc.) would be more natural or familiar.
Rule #11) Don’t just port your stupid website into a stupid app
I’ve dropped hints like crazy, but let’s just state it flat out: A carbon copy of a website wrapped inside of a native webview is not a hybrid app, it’s an embarrassment.
A mobile app should create some kind of added value for users or customers, and framing your entire website into a webview is not going to accomplish that.
Consider how the end-user experience or interaction will be enhanced by the development of your mobile app, and think twice about publishing if that value proposition isn’t clear.
One of the biggest strikes against hybrid app development comes from the unfortunate number of people who have basically plopped a website into their “app” and then sent it out into the world. In fact, Apple now rejects app submissions that are simply website ports as they consider them (rightly so) to not have any business on the app store.
Rule #12) Choose the right tools
When a contractor know he needs a hammer, a screwdriver, and a saw to build your house, he doesn’t walk out of a hardware store with only the saw and think, “eh, I’ll just figure out the rest as I go along.”
Likewise, if you know what features are in your app’s development roadmap, you should make sure you choose a toolset that allows you to explicitly do all of those things (and do them well).
For example, if you know your app will need to have user registration/login services, you don’t want to use a hybrid platform/framework that has easy frontend creation tools, but which ultimately leaves you in the dark when it comes to backend and integrations.
Conversely, if design is your weak spot, it might become more important to choose a framework or platform that has a great built-in library of UI components.
You get the idea.
No matter how user-friendly it purports to be, every approach to app development, ranging from fully manual self-coding to drag and drop “builders” will involve some learning curve and time investment in order to produce a great end-product. For this reason alone, it’s worth doing your homework from the beginning to find out which approach or tool will best serve your project’s needs.
The Takeaway:
Despite some initial bad press and a stigma to overcome, the limitations in appearance, performance, and feel of cross-platform hybrid apps have all but disappeared for many common app uses.
Or, more accurately, these limitations are no longer set by device computing power and available tools, but rather by the skill and dedication of the developer(s) themselves.
That is to say, there is a lot that can be done these days to ensure that hybrid apps based in HTML5, CSS3, and JavaScript delight their end users with the experience they expect and deserve, but it’s still up to you to be mindful of and address various challenges along the way.
Hopefully, this article can serve as an initial checklist of considerations for you hybrid developers out there, and if you’ve got something I left out— or just want to show off an app you’ve made yourself — don’t hesitate to drop a response below!
Appademics Magazine is a community-driven online publication for current and aspiring app developers. If you’d like to read more of our content, be sure to follow us using the button below, or connect with us via twitter or Facebook.
Got an idea for a story, article, or tutorial? Read about contributing to the publication here.
