Hannah Clayton-Langton: 0:05

Hello world, Welcome to the Tech Overflow podcast, the podcast where we break down technical concepts for smart people. I'm Hannah Clayton Langton and after five years working in a tech company surrounded by engineers, I decided I wanted to understand a little bit more about what was going on around me.

Hugh Williams: 0:21

And I'm Hugh Williams. I'm a former vice president at Google and also at eBay, and I was one of the first engineers to help Microsoft build Bing and my job is to help Hannah demystify tech concepts for the smart listeners that we have out there.

Hannah Clayton-Langton: 0:33

Today, as always, we're coming to you from Melbourne and London, so making the most of the smart technology out there to enable dual hemisphere recording. We're about to get into the interesting topic of apps and how they work, but before we do that, hugh, how's it going down there? Are you cold?

Hugh Williams: 0:52

I am cold and I'm getting a little hungry because it's dinner time here and I know it's probably just breakfast time there. So I'm cold and hungry. How are you?

Hannah Clayton-Langton: 1:01

I am very warm. Heatwave in London is sustaining. But I'm really excited to get into this topic. So I say we just let's get into it, let's go. Okay, so start at the very beginning. Why would a company build an app Like what is the use case for the investment in? Let's start with just a mobile app.

Hugh Williams: 1:19

Well, maybe a good place to start is with the alternative, right?

Hugh Williams: 1:21

So I think we've all tried to access a website on our mobile phone, and to some degree that can be a satisfactory experience, but often there's a lot of things missing and it can be quite infuriating.

Hugh Williams: 1:33

So, for example, you might access your favorite shopping app through the mobile web and then next time you go to do it it's logged you out for some reason or you can't find the tab that you used, and so the experiences could be a little bit disjointed. The visual experience often isn't as deep and as immersive as you want, and then sometimes your mobile web experience won't be able to access parts of your device that you wish it could access, and, in the extreme, mobile web can't actually do all the things that you need as a customer. But sometimes it's good enough when the task is pretty simple. So that kind of leads us to why build an app? So if we're a company and we're building an app, we're building it because we want to build a deep, rich, immersive experience, we want to keep the user logged in, we want them to be able to open up the app anytime and pick up where they left off, and we want to make sure that that app can access all of the different, less frustrating you can like.

Hannah Clayton-Langton: 2:32

Whenever I decide, I'm going to quit social media and delete the Instagram app. I end up using the Instagram website, which basically is just like a worse experience, but it's exactly that. It's like all my stuff's in there, they know what I'm doing. I can like whether I'm shopping or browsing or scrolling. It's definitely a more intuitive experience. So, yeah, richer experience. I'd love to know more about the sensors in the phone, because I have a hunch that there's a lot more than I, as a layperson, can think of.

Hugh Williams: 3:16

There's probably nearly 20. You might be surprised to know, hannah. So there's an enormous number of sensors in a modern smartphone. Some of them are obvious, probably the reasons that you buy the phone, right? So things like the cameras, you know, hannah. So there's an enormous number of sensors in a modern smartphone. Some of them are obvious, probably the reasons that you buy the phone, right. So things like the cameras, you know two or three cameras, typically on the rear of the phone, and then there's, of course, there's a camera on the front for taking selfies.

Hugh Williams: 3:35

I guess something else that's fairly obvious is that it's got a GPS in it, so global positioning, so your phone knows where it is, and so if you've installed something like Google Maps on your phone or some other location aware tool, then that's very, very central to that app, right?

Hugh Williams: 3:51

So knowing exactly where you are helps you navigate the world, for example. And then, right down the other end, there's some very obscure sensors, so you might be surprised to know. For example, there's a barometer, and it's a very, very sensitive barometer. So when you're using a fitness tracking app, for example, and you travel up a flight of stairs, it's a lot of action from the barometer there that figures out how far you've traveled up a flight of stairs. There's a magnetometer in there which is effectively a compass, so your phone knows which way it's pointing. Again, that's important in things like google maps for navigation. And then there's an accelerometer, which is really interesting, which is basically a device that measures how fast your phone is accelerating or decelerating, and again that's pretty handy when it comes to these motion aware kinds of apps and tons of sensors in between.

Hannah Clayton-Langton: 4:40

That's crazy. I hadn't even heard of a magnetometer. You're lighting up all parts of my brain because, you're right, I'm big into Strava. I use AllTrails sometimes, so these are the kind of apps where those things play into it quite a lot. As a user, you expect your little blue dot on Google Maps to point in the right direction, and I know some of the listeners have probably felt frustrated when it doesn't. But you don't actually think about how that works. So next time I use Strava, I'm going to be thinking about the technical complexity of that. So the app is about leveraging everything that the smartphone has to offer, but not necessarily in a way. I guess that the users are aware of that because as modern phone users, we just sort of expect those things to exist.

Hugh Williams: 5:23

Sometimes you will be a little bit aware because it you know, for example, apple's pretty obsessed with privacy, and so they'll quite often pop up dialogue boxes, as we call them, that tell you about the sensors that are being used by your app. So I think most of our users who are in the Apple ecosystem will be familiar with Apple popping up a dialogue that says do you want to allow this app to keep on knowing your location, or only when the app's being used? And so or never? And so it does remind you that some of these apps are making very, very heavy use of the sensors that are in the phone.

Hannah Clayton-Langton: 5:55

That was exactly the example that I was thinking about. Location is the one that I'm like, sort of I never know what to say. Obviously, if it's something obvious, like Google Maps, of course I'm going to grant it my location, but when it's something like Instagram or I can't think of another one right now but I'm like are you going to be exploiting this information to give me more targeted advertising? And I think the answer to that is probably yes, but that's maybe not for this section of this podcast.

Hugh Williams: 6:19

Yeah, we should do advertising as a topic someday.

Hannah Clayton-Langton: 6:22

Yeah, I guess the sort of takeaway is the incredible power that's enabled by those sensors. When I asked the question, I specifically mentioned mobile apps, but I have an iPad and I have apps on there and I assume something like an iPad or a tablet has fewer sensors and therefore the types of apps that are optimized for those devices are more about like streaming on a larger screen or maybe a word processing type app, because you might have a keyboard attached to something like a tablet in a way that you wouldn't to a phone. Is that right?

Hugh Williams: 6:55

Yeah, I think, thinking about product management, which we spoke about in the last episode, a great product manager will think about the characteristics of the device that they're building for and also really hard about why the user would want to use that device, right? So if you think about something like an ipad, as you say, it's got great screen real estate relative to a smartphone, right. So one reason you might build an app for the ipad is because you want that high resolution, wider, deeper screen experience and that you know the smartphone might not be suitable. And word processing, I think, is a fantastic example of something that's far more sensible on the iPad than it'll ever be on the smartphone, well, unless you're using dictation rather than trying to actually type in keys. But it's a fantastic environment when you're on the move, right. So all of these sensors you've got a computer in your pocket that's traveling around with you is a fantastic product for things that require a product solution. That is about being on.

Hannah Clayton-Langton: 7:50

Okay. So basically, if you're again throwing back to our last episode about product management, as a product manager you would probably be thinking about the different features and how they play in with the different devices and assume you'd know something about your user set and how much they're using tablet versus smartphone or even smartwatch I imagine that's not that many and then you'd sort of be optimizing the different user experiences to each of those devices.

Hugh Williams: 8:16

Yeah, absolutely. I remember back when I was at eBay, which admittedly was in the early 2010s we used to have conversations about what are users trying to accomplish on their laptop and what is it that they're likely to want to accomplish on their smartphone. And if you think about a shopping site like eBay, this is probably true for most shopping sites. The laptop is a fantastic experience when you're doing something exploratory while you're watching TV in the background on a Sunday night, right? So it's a great place to sort of discover, read reviews, you know, look at the broad spectrum of possibilities, you know, do price comparison, all these kinds of things, and so if I was the product manager, I'd be thinking really hard about how to make those features available for customers who want to use a laptop on a Sunday evening, right? And that's a very different scenario to the app that's on the phone.

Hugh Williams: 9:04

So the eBay app, for example, is designed for what we call snacking, right? So that means that you're running between a meeting, you're incredibly busy, you know. You're racing for the train, whatever it is. You want to be able to pull that app out, you want to start up fast and you want to be able to carry out actions that you might need to carry out, and then you put the phone back in your pocket. So the classic on eBay is bid on an auction Auctions are still very popular on eBay.

Hugh Williams: 9:27

You might want to quickly open it up, quickly bid and then quickly put the phone back in your pocket, and that's a very different scenario to the scenario on the laptop or perhaps on the iPad. So I think good product managers really think about what device is suitable for what scenario and really understand their users' lives and, I think, also respect the fact that users in many cases have more than one device. Now that isn't true in sub-Saharan Africa, southeast Asia, india and a few other places. Often people just have a smartphone, but in other parts of the world, people will access a product through multiple devices and I think making sure that the experiences that you build take advantage of those devices and also meet the user scenarios is incredibly important for product management working across this whole spectrum.

Hannah Clayton-Langton: 10:13

Oh, that makes so much sense. In front of right now, as we speak, I have an iPad, a laptop and a smartphone and I use them all very consciously for very different things and different devices for different use cases. So let's get technical for a minute. What is an app on my phone like from a technical perspective as an engineer?

Hugh Williams: 10:34

If you think back to our first episode, we spoke about coding. So you know, at the core, an app is something that's written in code. So there's going to be one or more software developers, software engineers, who are writing code and that code is the basis of the app that is on your phone. So in the case of a simple app so let's imagine you and I are building a calculator that's probably something that a single software engineer could build, a complex app. So if you think about something like Google Maps, which I was lucky enough to work on, there are hundreds of mobile engineers working on that because it's an incredibly broad product and it's also an incredibly deep product and that all those software engineers are coordinating together to build a single app that ends up in the app store and being something that you, that you download.

Hugh Williams: 11:26

The other way to think about an app, I guess, is to think about sort of the depth of it, if you like.

Hugh Williams: 11:30

So a calculator is something that just exists on your phone, so you open it up, carry out some simple maths. It's not talking to the internet, it's not communicating with anything else, there's no substance that sits behind that. So really, very literally, is some code that's written for your phone, that runs on the operating system on your phone. At the other extreme, there are many apps where the user experience that you have on the phone so the actual code that's running on your phone is actually fairly simple, but what's sitting behind it is enormous sophistication that's running in the cloud, which means it's running in google's data centers or amazon's aws data centers or in microsoft's data centers in most cases, and that's where all the sophistication is and that's where all the energy is going from the software engineers. So it really depends on what it is you're trying to build, as to sort of how deep the app is, if you like, and how sort of broad the app is. But they're all built by software engineers and most app teams have a product manager.

Hannah Clayton-Langton: 12:28

Okay. So I love this point around simplicity and complexity at the front end and then sort of behind the scenes, and it really makes me think of chat gpt, which I'm now slightly embarrassed to admit I've only ever used on its web version.

Hugh Williams: 12:43

But that's super complex behind the scenes and yet the user interaction point is like basically as simple as it gets yeah, I think that it may be underestimating a little bit some of the animation and those kinds of things that goes on in there. So there's probably a bit of sophistication around sort of making that experience feel like it's active. But I'd say one good reason to download the app is you log in, you stay logged in, it remembers all of the chats that you've had and it's easy to navigate, right. So whereas again, if you go back to that web experience, I bet sometimes you say what happened to that tab? Oh no, I have to log in again. You know all those kinds of things and once you've got the app, of course you can have a more seamless experience.

Hannah Clayton-Langton: 13:24

And then, what about something like a banking app? Is that super complex behind the scenes? Because of all the security?

Hugh Williams: 13:31

I think banking apps are a great example where there's some sophistication actually in the app and there's also plenty of sophistication up in the cloud, right. So let's just maybe talk about the app on the phone for a second. So it makes pretty heavy use of lots of the sensors that are in the phone. So you've got things like the face sensor that's helping you probably log in. When there's risk of fraud, you're quite often asked to record a video and move your head around and say some words. So you're making use of the microphone and the video facilities in the phone. So lots of things going on there.

Hugh Williams: 14:04

Of course, it's always sending back your GPS location to the bank's servers, because one of the ways you can detect fraud is that somebody logs in from a suspicious location or appears rapidly somewhere else, when recently they were in a different location. So knowing where the customer is, using the customer's biometrics, is important. But there's also lots of sophistication going on in the cloud. So lots of algorithms running lots of AI, if you like, in the cloud doing things like fraud detection, the actual banking itself. There's some sophistication to that, but that's really about credits and debits and moving things between accounts.

Hannah Clayton-Langton: 14:38

I was at an engagement party recently and someone was telling me that he's a tech investor a non-technical tech investor, so definitely a potential listener for this podcast but he was telling me that they were looking to invest in some sort of technical product where it was smart enough to know if even just the way that you were using the app was different. So, like when I opened my banking app, I am sure that my session let's call it my user session follows the exact same patterns of behavior every time, because I check the same accounts and I probably even like navigate the app in the same way. Is that something that's possible in apps today?

Hugh Williams: 15:16

Yeah, absolutely, and this sort of dates back 20 years really. So you know, one of the things that the big internet companies did back in the day was try and look for bots that are scraping them, and obviously bots have a different pattern of interaction to humans, right? So humans sort of interact and then there's random pauses and you know they have certain sort of characteristic behaviors. Bots tend to just, you know, pound a website in a sort of rhythmic kind of way, and even if they're trying to act like humans, they don't tend to look like humans. So 20 years ago, companies were very, very good at trying to keep bots off their site by looking for behaviors that were human and behaviors that were non-human, and apps today are still doing that, right. So your app most certainly in many cases is trying to understand if your interactions are typical of you or typical of human interactions, and that's certainly again one of the characteristics that something like a sophisticated bank app would make heavy use of.

Hannah Clayton-Langton: 16:13

Okay, so the age-old question Android versus iPhone, what's the difference there? I think I know that you need different teams, you need different types of engineers.

Hugh Williams: 16:23

So maybe, starting at the fundamental level, the operating systems are different. So Apple has iOS and Google has Android, and so they are different operating systems, which is a bit like the difference between Microsoft Windows and the Mac OS on a Macintosh computer, and so for our customers who've used Android, if you switch to iOS, things aren't quite where you expect them to be, and vice versa is true. So the user paradigms, how it looks and feels, is quite different.

Hannah Clayton-Langton: 16:50

Okay, so just to build on that, throwing back to our episode on product management, do you have a single product manager for an Android app versus for an iPhone app? Because that feels like it's a dangerous way of creating two very different user experiences.

Hugh Williams: 17:03

Depends on the size of the company and, again, this breadth and depth of the product. But I would say for any company that's delivering an Android app and an iOS app that have any sort of moderate level of sophistication, it's almost certain that there's at least two product managers involved. So the iOS team probably has at least one product manager and the Android team has another product manager and at least one of those. I think the job of a director or a vice president the person who sits above those folks is to make sure that these things run down the same train tracks and you don't end up with too much diversity in the experiences. But that that's as much science as it is art. But usually designing for one and designing for the other requires depth and you typically have product managers and different teams building the, building the android and building the ios apps okay, because again a throwback, but this time to our first episode on coding.

Hannah Clayton-Langton: 17:53

It's different coding languages, right at its core.

Hugh Williams: 17:56

If it's a serious app, then yes, yeah, if it's a serious app, then the coding languages and the way you go about the development is quite different between iOS and Android. There are some tools out there, so you know, Meta has released some tools. Google has released some tools that allow you to build something common. Meta has released some tools. Google's released some tools that allow you to build something common and then, behind the scenes, it creates code in the languages that are specific to the Android ecosystem and the iOS ecosystem. But typically you'd only use that for prototyping, for sort of MVPs, sort of a simple version of your product as you're testing it out. Once you get to any level of sophistication, you're probably going to find yourself hiring software engineers to work on Android and a different set of software engineers to work on iOS.

Hannah Clayton-Langton: 18:39

So is it very possible here that, like a version of an app that I have and my husband has on, different operating systems might have different feature sets, because they're not going to be exactly like for like at all times.

Hugh Williams: 18:50

Yeah, almost certain that they're different and sometimes that's deliberately the case.

Hugh Williams: 18:54

So what we used to do at Google was we would build the Android app and we put that in the app store and the customers would get that and then we'd see how the usage of the features that we'd recently shipped went.

Hugh Williams: 19:07

And then the iOS team would sort of look at those features. Maybe they also had a few features that they want to build that were slightly different. They'd look at those features and then they'd what we call fast follow, probably six months behind. So the iOS app at any point in time is probably about six months behind the Android app as the iOS team watches and listens and learns and sees what's happening with Android. And of course there's vastly more Android engineers at Google than there are iOS engineers. So if you look at the relative size of the teams, the Android team is much larger and can really pioneer new features, get lots of features out there, do lots of experimentation, whereas the iOS team is really in this fast follow mode. So much smaller, tighter team. That's sort of looking at the features and then adapting those features, getting the design aesthetic right you know, making it feel like it's an iOS feature and getting it out the door, maybe six months later.

Hannah Clayton-Langton: 19:56

I'm fascinated by this sort of two horse race between iOS and Android. But thinking about the app stores now, like Google Play and the Apple App Store, like how does that all work If I'm building an app, like there's two parts to my question. I want to build an app. How am I getting it onto the App Store? Can, like any old person, build an app and put it on the App Store and then like, what's the difference in the Google Play App Store and the Apple App Store from, like, a developer perspective?

Hugh Williams: 20:23

Yeah, great question. So first thing to do if you're thinking about building an app for one of these app stores is to understand what the guidelines of the app store are, right? So Apple definitely has a stricter and a longer list of guidelines of things you can and can't do if you want to put an app in the app store. So I'll give you a quick example. An example would be don't make use of sensors that your app doesn't need. You've got a calculator app and you want to put it in the app store.

Hugh Williams: 20:47

You're going to have a lot of trouble explaining to Apple why you need access to the GPS, right? They'll say hang on a minute. This isn't very user-centric. You're just spying on our users with no reason to actually make use of the GPS. So in practice, you really need to understand the guidelines of the app store before you really get started, right? So Google's less strict, so the guidelines are shorter and they're less stringent about what goes into their app store. So it's much, much easier to get an app into the Google Play Store than it is to get into the Apple app store.

Hannah Clayton-Langton: 21:20

Okay, I have a potentially dumb question, but I'm going to ask it anyway. This sounds like a lot of work for the arbiters, as it were so for Apple and Google, but I don't pay for a lot of apps. The arbiters, as it were so for Apple and Google, but I don't pay for a lot of apps. So, like, how does that work? I pay for some apps, I might pay for a subscription, but most things I'm using, like my Amazon app or Instagram or WhatsApp, I paid maybe like a dollar once for. But like, how does that work commercially for them?

Hugh Williams: 21:46

Yeah, great question, hannah. So there's a few things going on in this ecosystem. So first thing is, if you pay for an app, then the company is keeping up to 30% of the proceeds. It can be as little as 15% in most cases, but it can be up to 30% in many cases. So lots of money is being kept as a tax, if you like, by Apple or Google.

Hugh Williams: 22:06

When you put your app in the app store and you charge for your app, which is still a very common way to monetize the work that you do. They also take a clip on any in app transactions that are part of their ecosystem. So, you know, sometimes you'll buy extra features within the app. So I've got a weather app. You know I wanted to have access to graphs that showed me, you know months of temperature and I had to pay the app provider for that feature. That didn't come by default, you know. So I pay my $1.99 and I get access to temperature graphs. Again, apple and Google will take a clip on that. The other thing they'll take a clip on is subscriptions. So if you subscribe to things through your app, then they're very likely taking a clip on that.

Hugh Williams: 22:47

But there's lots of apps, as you say that are just free-free right. So the Amazon app you download it, you have it on your smartphone. You didn't pay for that. There's no subscriptions going on, you're not paying to enable any features. So, yeah, it's true that both Apple and Google are not directly making money out of the Amazon app, but it helps their ecosystem. So now you want to be part of that ecosystem because that ecosystem has lots of tools that are very useful to you.

Hugh Williams: 23:14

So there's lots of apps there that are not monetized really by Apple and Google, but are just part of having a vibrant, successful ecosystem, and, of course, that helps everybody else. That causes people to actually pay for other apps. You know, buy features in apps and subscribe because they're part of this vibrant ecosystem and they become very, very loyal to their apple device or their android device. And we should chat at some point about some of the legal things that are happening in this space. But certainly in the eu, there's an attempt to dismantle apple's you know monopoly over the app store, right, so that you can actually get apps onto your phone that don't come from the Apple App Store. So it's something that the EU is trying to impose upon Apple. You know the EU often leads in these kinds of areas, so typically the EU will do something first and then often you'll find the United States follows sometime later with something similar. So there's certainly an attempt going on right now to sort of remove this monopolistic type nature that Apple has over the App Store.

Hannah Clayton-Langton: 24:19

I was going to say, even when you mentioned that it was like a 15% or 30% cut that they take for purchases via the App Store without any other context. That just sounds like a pretty hefty chunk. It's a pretty good deal, I think, for Apple and iOS.

Hugh Williams: 24:35

Yeah, and they would say, of course, that there's lots of costs in running a store and administering the store and approving things that go into the store and all the services they provide and the phone ecosystem itself. So they'll certainly tell you there's a good reason for that, but certainly it does feel like a pretty big clip if you're a developer.

Hannah Clayton-Langton: 24:52

Yeah, okay, so more in a future episode about some of the sort of legal and commercial elements of this stuff, because tech can feel counterintuitive in that sense, like you get a lot for free, and I once watched a very sobering documentary where they were like if you're not paying for the product, then someone's paying for you as the product, your data.

Hugh Williams: 25:12

Yeah, absolutely Okay. So no such thing as free in tech.

Hannah Clayton-Langton: 25:15

Yeah, okay, so let's finish up with back to some of this product stuff, which I know is your sort of sweet spot. But what's it like to build an app? We've mentioned a few of them. I I think you talked about like prototyping and testing, but like what's the flow if you want to get a feature onto an app? Like it's kind of the product management, but let's talk about it specifically in the app scenario.

Hugh Williams: 25:38

One thing that makes building for the web and building for mobile really different is experimentation. So a lot of the very, very large companies and it's probably true of even medium sized companies these days do a lot of experimentation on their users. So, for example, if you're using Facebook, you are for certain going to get a different experience in quite a few subtle ways than my experience on Facebook, and the reason that that's the case is not just about personalizing for you, but Facebook wants to try out new features, and that can be as simple as things like changing very subtly the colors of fonts, the size of things, how big the X is for closing things, how big images are all sorts of really subtle stuff and what they're trying to do is figure out, in many cases, what drives more engagement. Ultimately, if the new feature that they're testing drives more engagement, then they. If the new feature that they're testing drives more engagement, then they'll ship that out to their customers.

Hugh Williams: 26:33

That's a lot harder to do in an app, because an app is something that's produced and it's put in the app store and then it's downloaded onto a phone. So it's a little bit more like the old CD days, when we used to buy Microsoft Office on CD, right, so it's being sort of shipped out and then you get a copy and then you install it. So that sort of fast testing and iteration is much, much easier on the web than it is in an app. So that's one of the really big differences is apps are really a little bit more waterfall. If you like, you kind of build it, you ship it out to the app store, you wait some amount of time until it's approved, ends up in the app store and then your customers get to download it.

Hugh Williams: 27:09

The other thing I'd say about apps is that users tend to have lots of different versions of the app, right, so you might be one of these people that religiously updates their apps whenever a new update is available. Lots of people don't do that. So having worked at lots of these tech companies, you will find that versions from 10, 12 years ago are still in use by a minute number of customers. So every version you've ever released is probably being used by somebody, especially when they're a significant fraction of the user. Traffic is another thing that makes app development really really different to web development, where you know if you go and visit the website, you're getting the latest version every time you visit the website, right, but that's not necessarily the case when it comes to opening up your phone and tapping on the app.

Hannah Clayton-Langton: 28:02

And that point around updates is so valid because from a user point of view sometimes it's really annoying. You can ignore a pop-up and then you'll sort of keep getting them until you don't have a choice is so valid because from a user point of view sometimes it's really annoying you can ignore a pop-up and then you'll sort of keep getting them until you don't have a choice. But would a company ever just deprecate a really old version of an app and not give the user a choice?

Hugh Williams: 28:19

They absolutely should Look. I've worked at companies where we sort of forgot to do that. So you know we're back in the earlier days of apps and we haven't built that feature in and that app version has gone out. Right Now there's no way to actually deprecate that. So I've worked at companies that have done that. You regret that a lot later on. So I'd say one of the best practices in app development is to make sure that you have some way of deprecating the app, which is as simple as when the user opens the app you say I'm sorry, but this version's been deprecated. Please download the latest version, and then you're effectively ending the life of that app. And then you're making your developers a lot happier because they're not having to support every single version of the app that's out there. You're actually getting rid of versions that are reasonably old and only used by a small number of customers in your user base.

Hannah Clayton-Langton: 29:05

Okay, but presumably you risk there. If you deprecate an app and you require someone to download a new version, you essentially risk them lapsing as a user.

Hugh Williams: 29:13

Yeah, that's right. So you wouldn't want to do that for any significant fraction of the user base. But if we're talking fractions of a single percent of users so you've got 0.2 of a percent of the users on an app version that's 10 years old then I think it's pretty reasonable in most cases to say, hey, this is deprecated, get the new version. And of course you can upsell the new version. Right, you can tell them all the great new features they're going to get and give them a reason to do that, and hopefully most of those customers will stick.

Hannah Clayton-Langton: 29:37

Okay, that makes sense. And is it possible to update an app without requiring me to install a new version? I know at work we sometimes talk about like silent releases. They don't need to know that we've changed tiny things in the background and actually sometimes you can draw too much attention to something really inconsequential by, like, announcing an update.

Hugh Williams: 30:02

One thing you can do, of course, is you can build in what we call flags into the app that you can later turn on right. So I could release an app that's capable of doing some things that the user can't yet use, that's capable of doing some things that the user can't yet use, and then sometime in the future I can communicate with that app and I can tell that app to turn on that feature and make it available to the user. So that's called an app flag. The reason you might do that is because you haven't quite finished what's going on in the cloud, so you haven't quite finished the sort of behind the scenes work that needs to be done. Or perhaps you haven't quite finished some of the experimentation you're doing and you're not sure whether you want to turn that feature on or when you want to turn that on. So the apps have lots of these sort of secret app flags in them that allow them to change without the user downloading a new version of the app.

Hugh Williams: 30:43

The other way to do it is to make your app into something that's a little bit more like the web. So very simple apps often are just web containers, so they're really a web browser. You download it and you think you're getting a really sophisticated app, but what you're really getting is another web browser that goes and retrieves web pages and shows those web pages to you. Now, obviously, if you change those web pages, then you get a very different app experience, and so that's another way where you can really make an app change pretty dynamically without having to download a new copy, because it's not really the app that's changing, it's a webpage that's being displayed within the app that's actually changing. So there's ways to certainly work around a customer having to download an app and still have that app evolve.

Hannah Clayton-Langton: 31:26

And, from a user's perspective, if it's done right, does it sort of look and feel like an app.

Hugh Williams: 31:31

I'd say no. I think it looks and feels like browsing the web, so it doesn't quite have the sophisticated animations and the deep immersive experience, and perhaps it isn't able to access in a really native way some of the sensors and features that are on the phone. So it's great if you just want to display information Works okay in shopping apps, for example but if you're trying to build a deep, rich, immersive experience you know something like a Google Maps or a Strava or an Instagram then you probably want to build it in native code and really make sure it's highly optimized and a really great experience that really resonates with the users.

Hannah Clayton-Langton: 32:05

Makes sense. Okay, I have one last question. One of the apps that I use the most is Spotify. Everywhere I'm going, I've got something in my ears, whether it's podcast or music, and as a London resident, I also take the tube a lot. So I'm going underground and, like when I go underground, I sometimes try my luck if I'm listening to something that I've not downloaded locally, and sometimes I'll get like a few songs or like another 10 minutes of my podcast, and sometimes I don't, or like I'm not really sure what's going on there. But what is that? Is that caching? Is that what caching is?

Hugh Williams: 32:37

Yeah, that's it. That's exactly what caching is, and the caching in this case might be very, very smart. So maybe let's just go back to what is caching. So caching is about getting information close to you that you're likely to use again or in the near future. So a simple example would be images. So you're browsing on a shopping website, you're very likely to go back to an item that you've seen, and if that item is pictures, are stored close to you or actually on your device, you'll get a faster, more seamless experience. So having those images close to you is going to make your shopping experience richer and deeper and you'll probably buy more stuff.

Hugh Williams: 33:11

In the case of music, downloading the tracks that you listen to often seems really, really smart because you're more likely to come back and listen to those again, and then also we could do some predictive downloading right. So if I was at Spotify they're a very sophisticated company I would probably have the idea that as a customer gets close to the tube or as a customer carries out a predictable day, so I probably know when I'm going to lose connection with you and where you're going to be when that's going to happen. Perhaps I'll be smart enough to really slurp down the next 10 minutes of the podcast or a couple of songs, so that you have a seamless experience and you don't quit Spotify. You know you're probably delighted by that experience, so that's exactly what caching is. It's about getting things that you're likely to need in the future, or storing things that you're likely to come back to that you've accessed.

Hannah Clayton-Langton: 33:58

I think that takes us to time and I think we've covered all of the main points that I had, with some teasers for future episodes. It's been really great chatting with you today, hugh.

Hugh Williams: 34:08

Thanks, adam. It's been fantastic to talk about apps with you and you're right, there's lots of really cool things that we can include in later episodes. If you've enjoyed this podcast, I would encourage you to visit our website, techoverflowpodcastcom. Subscribe to our podcast on your favorite platform. We're also available on LinkedIn at techoverflowflow Podcast, and you can find us on Instagram and X.

Hannah Clayton-Langton: 34:32

Awesome, so I'll see you again next time, hugh, for another demystification of technology. I can't wait, hannah, see you soon, see ya.