Why did Netflix move from UIWebView to UIKit?

Recorded February 24th 2021 – watch the full episode on YouTube.

‌In the early days Netflix was more or less a UIWebView, right? And that's clearly moved away over the years to a more native UIKit solution – what made you move away from the UIWebView to UIKit in full?

Jordanna Kwok: It's interesting because when I first joined I was a JavaScript engineer on what was called the mobile and tablet UI team at the time, and there was only iOS – there wasn't an Android product that had been fleshed out quite yet. And the reason why we were using a UIWebView is because it allowed us to deploy remotely pretty quickly, and we were doing a lot of A/B testing at the time and we didn't want to go through the App Store process for every single A/B test that we'd launched.

Paul Hudson: It was slow back then, in the early days – it was a week or 10 days, and two weeks sometimes.

Jordanna Kwok: So, that's why we used the web view for all the UI pieces. I think the only native piece was really the player itself, so once you tapped on play we would go across the WebKit bridge back into native code and launch the native UI player. But everything else, when you're scrolling through the browse experience, search, and so on, that was all written in JavaScript, HTML, CSS. And the thing that really tipped us over was when we started to think about the future and the product itself.

"What did we want? Are we okay with this type of experience or did we want to experiment more with, say, video? I think video was the big thing, how do you integrate video into the browse experience on your home page?"

What did we want? Are we okay with this type of experience or did we want to experiment more with, say, video? I think video was the big thing, how do you integrate video into the browse experience on your home page? And with HTML5 video at the time that was not doable. So at that point the future didn’t look too bright for this WebKit environment, and we had to make a hard decision – it wasn't an easy decision to make.

Because you have a bunch of JavaScript engineers, and then you're saying, “okay, we need to rewrite this from scratch." Do people want to hop on and do iOS? Some wanted to do it, and there were some people who wanted to stay JavaScript developers. I was one of the engineers that decided to learn iOS, so that's when I learned it and picked up on Objective-C. At the time Swift wasn't quite out yet, maybe Swift 1.0, but we weren't quite ready to hop on the Swift bandwagon yet. If it was a little bit more ready that would've been great, because JavaScript and Swift are syntactically much more similar, so transitioning to Objective-C was kind of ugh – the syntax was kind of off putting at first.

I can't remember how many months it took us to rewrite the app from scratch, but it was a quick turnaround. We actually reformed the team into a much smaller team at the time – I think it was like six, seven engineers maybe. And then we rewrote it just vanilla UIKit and Objective-C. We did evaluate other solutions along the way before coming to that conclusion to do UIKit.

"You have to design the interface completely differently, and the paradigms are different, even though the underlying technology is very similar, I think because of the user experience that TV has versus mobile is so drastic."

We did look at React Native, and that was very early on. We investigated the technology because it's open source, so you could dig into it. We found that it wasn't really conducive to the user experience that we were trying to achieve – we wanted something that was very responsive, and also that we would be able to integrate with video pretty easily. So when we looked at React Native, I think it had slightly different goals. They wanted it to be more of a cross-platform type of framework, whereas we were trying to optimize for the best experience for iOS users. So, I think slightly different goals there, so that's why we ended up with UIKit.

Paul Hudson: It's interesting because I do use Netflix everywhere. I mean, I tend to watch the same shows again and again and again, I've got a real problem! I've watched Archer so many times now, and right now I'm watching Big Mouth again – that's a very silly show. But I use Netflix everywhere, so I use it on my iPhone, I use it on my iPad, I use it on tvOS, I'll use it absolutely everywhere. And it sounds like you're actually optimizing for the best experience on each platform.

Does that mean you're thinking, "we want to share lots of code to reduce costs", but also is that secondary to getting a great platform experience?

Jordanna Kwok: Yes, it is. So, a lot of people ask me, “do you also own the tvOS app?" And the answer is no, because we have very different interactions on a TV because you have Left, Right, Up, Down navigation on a TV. So you have to design the interface completely differently, and the paradigms are different, even though the underlying technology is very similar. I think because of the user experience that TV has versus mobile is so drastic, it makes more sense for a separate team to take over that.

"The code base is the same code base, but as you can imagine, there's going to be the variance and we don't want to deviate too much but once you start deviating, then it becomes quite challenging as you can imagine to manage."

However, there are pieces that are quite sharable, I have to admit, such as the playback pieces. For some time there was a lot of sharing in that space because it's just AVFoundation and we could build an abstraction over that. But the UI itself, because of the differences, they live in different code bases.

Paul Hudson: But does that include iPad as well? Did you try and share code between iOS and iPadOS or were you thinking actually it's a very different experience?

Jordanna Kwok: We do share iPad and the iPhone experience. The code base is the same code base, but as you can imagine, there's going to be the variance and we don't want to deviate too much but once you start deviating, then it becomes quite challenging as you can imagine to manage. Because it's almost like two code bases in one then.

So, that's always a constant thing that comes up – how closely do you want to make this work? And I think when you look at some of the new Apple design guidelines, I think it does make it so that it's easier to integrate the experiences versus building something completely different just for the iPad.

Sponsor Hacking with Swift and reach the world's largest Swift community!