NOTE: GrowthBeat is less than 2 weeks out! VentureBeat is gathering the best and brightest in modern digital marketing to help declutter the landscape, simplify the functions, clarify the goals, and point the way to success. Get the full scoop here, and buy your tickets while they last.
LinkedIn has just launched the latest versions of its mobile apps, and in a stunning reversal, it’s gone from mobile web-based apps back to fully native.
Less than a year ago, the company was touting its iPad app as fully mobile-web based, with just one screen, the homescreen, running natively. Now, all that’s gone, as is some of the optimism about the current capabilities of the mobile web.
In a revealing chat with Kiran Prasad (pictured), LinkedIn’s senior director for mobile engineering, we learned exactly why — and it’s not what you think. Prasad said performance issues weren’t causing crashes or making the app run slowly. What he did say shows that HTML5 for the mobile web still has a bright future — but only if developers are willing to build the tools to support it.
Here’s the bulk of our chat with Prasad on engineering topics around the new apps:
VentureBeat: [interrupting interview about the app launch] Wait, let’s go back a second. Did you just say these apps are native? Isn’t that the exact opposite of where you guys were philosophically the last time we talked about mobile?
Prasad: We have definitely shifted from HTML5 to native. The primary reason for that is, we’re seeing that more and more people are spending more time in the app, and the app is running out of memory. It’s not performance issues, like speed or rendering, but it’s still a big problem.
The second reason we’ve gone native is trying to get some of the animations — the spinners and the way they work — getting that smoothness, we felt like we needed native to really do that well.
VentureBeat: Does this mean that LinkedIn is giving up on developing mobile web apps or working with mobile web technologies?
Prasad: The way we built our system, we used template JSONs. We always have to support HTML5 because so much of our traffic comes from email. When we were [serving] a smaller group [of users], we were hoping we could duplicate all that mobile web work to make our clients faster in terms of code deploys. It worked really well when mobile only made up 8 to 10 percent of traffic. … I’m not sure I could have predicted it, but we recognize now that HTML5 is not allowing us to do the best for our users.
VentureBeat: So what would it take for mobile web technologies to meet the needs of a company like LinkedIn and with apps as widely used as yours?
Prasad: There are a few things that are critically missing. One is tooling support — having a debugger that actually works, performance tools that tell you where the memory is running out.
If you look at Android and iOS, there are two very large corporations that are focused on building tools to give a lot of detailed information when things go wrong in production. On the mobile web side, getting those desktop tools to work for mobile devices is really difficult.
The second big chunk we are struggling with is operability, runtime diagnostics information. Even now, when we build HTML5, we build it as a client-side app. It’s more of a client-server architecture. … The operability of that, giving us information when we’re distributed to a large volume of users, there aren’t as many great tools to support that, as well.
[Prasad also noted that dev and ops tools for solving issues quickly "don't exist."]
Because those two things don’t exist, people are falling back to native. It’s not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support it. … There are tools, but they’re at the beginning. People are just figuring out the basics.
Image credit: Kirin Prasad/Twitter