|< What is the process if a new developer doesn't do well?||How much is A/B testing driving app development at Netflix? >|
Recorded – 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?
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.
"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.
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.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED Spend less time managing in-app purchase infrastructure so you can focus on building your app. RevenueCat gives everything you need to easily implement, manage, and analyze in-app purchases and subscriptions without managing servers or writing backend code.
Link copied to your pasteboard.