You’ll never believe how LinkedIn built its new iPad app (exclusive)

Guess how much of LinkedIn’s new iPad app is actually mobile web and not native.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":425265,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Go ahead — guess. We’ve had a lot of fun asking people to guess this over the past couple days. They’ll start with 40 percent and edge up to 70 percent, but no one comes close to the real figure: 95 percent.

Yes, only one screen in the entire LinkedIn iPad app is actually native. The rest is good ol’ HTML5-based mobile web technology, running in the browser and leaning heavily on Node.js.

We were shocked to hear this 95-percent figure from Kiran Prasad, who heads up LinkedIn’s mobile development team. Shocked, but not appalled — after all, Prasad was the engineering heft behind the company’s recent slew of gorgeous mobile apps, which were also heavily reliant on the mobile web.

But the new iPad app had struck us as so surprisingly sexy during our initial review that we had to know more about how Prasad and his team of four (yep, just four devs built this app) packed so much punch into a web app for a tablet.

Especially as Silicon Valley tech companies pick sides in the web-versus-native war, it’s fascinating to see the presumably conservative LinkedIn lean toward the more progressive side of mobile technology. But this is a stance this team has taken for a while now, and LinkedIn is currently one of the mobile web’s biggest supporters and strongest case studies.

---

LinkedIn and the mobile web

“Last year, we had just launched three different phone apps. We were starting to invest more in HTML5,” Prasad told VentureBeat yesterday.

“We had a 60/40 split where about 60 percent of any app was in HTML5.”

LinkedIn’s big news at that time was how it had employed Node.js in its at-scale mobile apps — what seemed to many to be a pretty big gamble for the company. But the other part of the story was how Prasad and his team combined native and mobile web functionality in iPhone and Android apps, creating hybrids that bridged the divide in the native-versus-web mobile debate.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":425265,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Now, Prasad said the company relies on mobile web technologies more than ever. “Because we made that full investment, being able to get the mobile web on a tablet was really doable,” he said.

Of course, being able to have greater developer efficiency was a draw, but Prasad said that would never have come at the expense of creating a beautiful, responsive app that would be a pleasure to use.

“We always focus on user experience and app speed as a number one priority,” he told us. “If the performance wasn’t there, we wouldn’t have gone with the web.

“But with the iPad having the faster processor and being a more powerful mobile device, we felt like the web-based version could give us the performance we needed.”

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":425265,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

In the end, Prasad continued, it came down to the little things: Did onscreen buttons depress and pop back up quickly when tapped with a fingertip? Was scrolling snappy? Did crossfades occur smoothly and without any lag?

“We did users studies in-house, and I don’t think people noticed a big difference. Nobody said, ‘Oh that’s native,’ or ‘Oh, that’s web,'” said Prasad. “As long as we can make the experience fast enough, nobody can tell the difference. It still feels right.”

And a lot of that performance, Prasad said, came from removing unnecessary design wankery (our verbiage, not his) — the rounded corners, the omnipresent gradients. By making things simple, clean, modern, flat, and even print magazine-like, the LinkedIn app only got faster and better on the performance side, as well.

“Our focus on trying to get a simpler design is actually helping us make things faster. It’s a good feedback loop,” said Prasad.

[aditude-amp id="medium3" targeting='{"env":"staging","page_type":"article","post_id":425265,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Here are some screenshots of those super-speedy mobile web pages for your reference. The first slide shows the sole native page:

[vb_gallery id=421649]

---

Now, with more Node.js

In addition to seriously beefing up the company’s mobile web investment, Prasad is also leaning more heavily on Node.js — and with more confidence.

“We’re still full-on Node. We are excited that it can scale,” he said. “Over the past few months, we’ve made performance tweaks so we can scale even more. On four boxes, we can now handle 20 times the load we were handling before.”

[aditude-amp id="medium4" targeting='{"env":"staging","page_type":"article","post_id":425265,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Prasad said the company used to use nginx, an open source Web server and a reverse proxy server, due to the engineering team’s concerns about the stability of Node. “It was there to make us feel comfortable,” said Prasad. “If any of the nodes went down, nginx would report the errors.”

Today, however, Prasad no longer feels the need for the security blanket. “In the tablet version of the server, we’re still using Node, but now the clients are talking directly from the load balancers to Node, there’s no nginx.”

In addition to experiencing a growing confidence in the technology itself, Prasad et al. are also contributing to Node’s growing ecosystem of tools — stay tuned for those to be open-sourced.

“Some of the changes we’ve made are Node modules we’re going to release back into the community,” he said. “Some of it is application-specific… But overall, the tools for Node are becoming better.”

[aditude-amp id="medium5" targeting='{"env":"staging","page_type":"article","post_id":425265,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

---

“Responsive design” just doesn’t work

Finally, Prasad wrapped up with an impassioned statement on a new trend in mobile applications: responsive design.

The core concept of responsive design is that the designer/developer would create a single design that can scale up and down fluidly across scores of different devices — laptops, tablets, TVs, mobile phones, etc. Many advocates exist for this solution to widespread connected-device fragmentation, and these advocates have founded companies and launched tools specifically to make responsive design simpler and faster.

But Prasad thinks it’s all wrong. Responsive design might work for uncomplicated, one-off websites, he said, but for applications or networks (such as LinkedIn is), responsive design is actually bad.

“We’re looking at the ‘entrenched’ use case [for desktop users], the coffee-and-couch use case [for tablet users], the two-minute use case [for mobile phone users],” Prasad said, rapidly outlining a few of the ways people are interacting with digital information and highlighting how unique each of those scenarios can be — and how different are the needs they present.

“You can’t take a mobile app and just scale it up to tablet or desktop,” he said. “A lot of responsive design is building one site that works everywhere, and that works for websites. But it’s bad for apps… You have to come up with a completely different design because of the use case.”

Top image courtesy of Yuganov Konstantin, Shutterstock