Last time, we got into the nitty-gritty on how to make your web application into a Progressive Web Application (PWA to its friends). I promised we’d dig even deeper this time, and show you how to make your web app a little more ‘native’ on Android – and how to deal with iOS Safari’s special snowflake syndrome.
It’s project kickoff time, and you’re having a conversation with your client about what form the application will take:
Client: I’m thinking mobile app. Our users will definitely be using this on the go.
Dev: Sure, we can do a native mobile-
Client: Mind you, we’ll want a desktop version too. We’ll need to use it from the office.
Dev: Okay, well, a responsive web app-
Client: One of our priorities is definitely ease of access – we’ll need the app accessible from the home screen, ’cause who has time for typing in URLs, amirite? We’ll also want it to be useable offline, whenever people want to.
Dev: Ye-yeah, no problem, we can wrap your web app in a webview, bundle it up as a native app, and-
Client: Yeah, cool. So they’ll just be able to go to the site and install the app, right?
Dev: Well, no, they’ll have to download it from the appropriate App Store.
Client: Eh, that’s a no-go – this is internal only, we can’t have it showing up in the app stores. Didn’t I make that clear from the start?
The term your client was looking for is Progressive Web App – an application that acts like a responsive web app when accessed from the browser on any device, but can be installed to mobile devices like a native application. The link above makes the case for PWAs, so we won’t belabour the point – if you’re still here, it’s because you’re convinced it’s time to build a PWA.
Development effort Q&A: native Android versus iOS app
Q) What is the relative effort to develop a native app for Android versus iOS?
A) It depends on how proficient the developer is and what she’s told to do.
Some developers maintain that Android work tends to take about 20% longer than equivalent iOS functionality. Other voices maintain the opposite: that Android development—not to mention code submission—can progress much more quickly than iOS. I’d say it depends:
This keeps happening to me: people find out I’m involved in app development and they immediately start pitching their application ideas to me. In restrooms, at children’s parties, even in line at the DMV. I’ve heard all kinds of app ideas. Some innovative. Some banal. Some that require time travel to be invented first. The thing they all have in common is the uniform belief of their inventors that they will be one of the few apps to rise to the top of the charts and make a difference in the world. (more…)
Porting an iOS app to Android means frequently translating between the divergent UI paradigms of the two operating systems. Both platforms encourage developers to follow certain interface guidelines, but clients sometimes prefer replicating a familiar interface. Thankfully, Android offers fairly deep customization.
For one port, the Android app needed to use the same view transition animation as its iOS counterpart.
On iOS, the standard navigation stack defaults to animating a detail page transition (called by
animated:YES]) by sliding the detail view in from the right, and the root view out to the left. Navigating back to the root view (
[UINavigationController popViewControllerAnimated:YES]) reverses the animation, sliding the detail view out to the right and the root view in from the left.
On Android, the same transition (handled through a FragmentTransaction) defaults to a zoom animation, or sometimes a slide up animation. How can Android mimic iOS’ transition animation?