September 28, 2025 • 34 mins
Ever wondered what's really happening behind the scenes when you tap that app icon on your phone? From the sensors tracking your every move to the complex business decisions determining which features you get access to, the world of mobile apps is fascinating.
Hannah Clayton-Langton and Hugh Williams, former VP at Google and eBay, break down why companies invest millions in app development instead of just using mobile websites. The answer lies in the incredible capabilities of your smartphone – packed with nearly 20 different sensors that apps can access to create personalised, responsive experiences. Beyond the obvious cameras and GPS, your phone contains barometers measuring elevation changes, magnetometers functioning as compasses, and accelerometers tracking how your phone accelerates and decelerates. This sensor-rich environment enables everything from fitness tracking to navigation and even fraud detection.
The differences between Android and iOS development reveal insights into how tech companies operate. At Google, Hugh explains how Android apps would pioneer new features with iOS versions "fast following" six months later after seeing user reactions. This approach highlights the careful balancing act between innovation and stability that defines modern app development. Similarly fascinating is how different devices get different experiences – laptops for deep exploration, phones for quick "snacking" interactions, and tablets for activities requiring more screen real estate.
Hugh and Hannah also discuss the business model behind app stores, with Apple and Google taking up to 30% of all purchases and subscriptions – a "tax" that's sparked legal challenges in the EU. And if you've ever wondered how some apps keeps working when you lose your connection, Hugh reveals the sophisticated caching techniques that predict when you'll lose connectivity and download content in advance (which we'll hear more about in Episode 5!). These glimpses behind the digital curtain will forever change how you think about the apps you use every day.
Like, Subscribe, and Follow the Tech Overflow Podcast by visiting this link: https://linktr.ee/Techoverflowpodcast
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Hannah Clayton-Langton (00:05):
Hello world, Welcome to the Tech
Overflow podcast, the podcastwhere we break down technical
concepts for smart people.
I'm Hannah Clayton Langton andafter five years working in a
tech company surrounded byengineers, I decided I wanted to
understand a little bit moreabout what was going on around
me.
Hugh Williams (00:21):
And I'm Hugh Williams.
I'm a former vice president atGoogle and also at eBay, and I
was one of the first engineersto help Microsoft build Bing and
my job is to help Hannahdemystify tech concepts for the
smart listeners that we have outthere.
Hannah Clayton-Langton (00:33):
Today, as always, we're coming to you
from Melbourne and London, somaking the most of the smart
technology out there to enabledual hemisphere recording.
We're about to get into theinteresting topic of apps and
how they work, but before we dothat, hugh, how's it going down
there?
Are you cold?
Hugh Williams (00:52):
I am cold and I'm getting a little hungry because
it's dinner time here and Iknow it's probably just
breakfast time there.
So I'm cold and hungry.
How are you?
Hannah Clayton-Langton (01:01):
I am very warm.
Heatwave in London issustaining.
But I'm really excited to getinto this topic.
So I say we just let's get intoit, let's go.
Okay, so start at the verybeginning.
Why would a company build anapp Like what is the use case
for the investment in?
Let's start with just a mobileapp.
Hugh Williams (01:19):
Well, maybe a good place to start is with the
alternative, right?
So I think we've all tried toaccess a website on our mobile
phone, and to some degree thatcan be a satisfactory experience
, but often there's a lot ofthings missing and it can be
quite infuriating.
So, for example, you mightaccess your favorite shopping
app through the mobile web andthen next time you go to do it
(01:40):
it's logged you out for somereason or you can't find the tab
that you used, and so theexperiences could be a little
bit disjointed.
The visual experience oftenisn't as deep and as immersive
as you want, and then sometimesyour mobile web experience won't
be able to access parts of yourdevice that you wish it could
access, and, in the extreme,mobile web can't actually do all
(02:04):
the things that you need as acustomer.
But sometimes it's good enoughwhen the task is pretty simple.
So that kind of leads us to whybuild an app?
So if we're a company and we'rebuilding an app, we're building
it because we want to build adeep, rich, immersive experience
, we want to keep the userlogged in, we want them to be
able to open up the app anytimeand pick up where they left off,
(02:26):
and we want to make sure thatthat app can access all of the
different, less frustrating youcan like.
Hannah Clayton-Langton (02:32):
Whenever I decide, I'm going to quit
social media and delete theInstagram app.
I end up using the Instagramwebsite, which basically is just
like a worse experience, butit's exactly that.
(02:55):
It's like all my stuff's inthere, they know what I'm doing.
I can like whether I'm shoppingor browsing or scrolling.
It's definitely a moreintuitive experience.
So, yeah, richer experience.
I'd love to know more about thesensors in the phone, because I
have a hunch that there's a lotmore than I, as a layperson,
(03:15):
can think of.
Hugh Williams (03:16):
There's probably nearly 20.
You might be surprised to know,hannah.
So there's an enormous numberof sensors in a modern
smartphone.
Some of them are obvious,probably the reasons that you
buy the phone, right?
So things like the cameras, youknow, hannah.
So there's an enormous numberof sensors in a modern
smartphone.
Some of them are obvious,probably the reasons that you
buy the phone, right.
So things like the cameras, youknow two or three cameras,
typically on the rear of thephone, and then there's, of
course, there's a camera on thefront for taking selfies.
I guess something else that'sfairly obvious is that it's got
(03:38):
a GPS in it, so globalpositioning, so your phone knows
where it is, and so if you'veinstalled something like Google
Maps on your phone or some otherlocation aware tool, then
that's very, very central tothat app, right?
So knowing exactly where you arehelps you navigate the world,
for example.
And then, right down the otherend, there's some very obscure
(03:58):
sensors, so you might besurprised to know.
For example, there's abarometer, and it's a very, very
sensitive barometer.
So when you're using a fitnesstracking app, for example, and
you travel up a flight of stairs, it's a lot of action from the
barometer there that figures outhow far you've traveled up a
flight of stairs.
There's a magnetometer in therewhich is effectively a compass,
so your phone knows which wayit's pointing.
(04:21):
Again, that's important inthings like google maps for
navigation.
And then there's anaccelerometer, which is really
interesting, which is basicallya device that measures how fast
your phone is accelerating ordecelerating, and again that's
pretty handy when it comes tothese motion aware kinds of apps
and tons of sensors in between.
Hannah Clayton-Langton (04:40):
That's crazy.
I hadn't even heard of amagnetometer.
You're lighting up all parts ofmy brain because, you're right,
I'm big into Strava.
I use AllTrails sometimes, sothese are the kind of apps where
those things play into it quitea lot.
As a user, you expect yourlittle blue dot on Google Maps
to point in the right direction,and I know some of the
listeners have probably feltfrustrated when it doesn't.
(05:01):
But you don't actually thinkabout how that works.
So next time I use Strava, I'mgoing to be thinking about the
technical complexity of that.
So the app is about leveragingeverything that the smartphone
has to offer, but notnecessarily in a way.
I guess that the users areaware of that because as modern
phone users, we just sort ofexpect those things to exist.
Hugh Williams (05: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 quiteoften pop up dialogue boxes, as
we call them, that tell youabout the sensors that are being
used by your app.
So I think most of our userswho are in the Apple ecosystem
will be familiar with Applepopping up a dialogue that says
do you want to allow this app tokeep on knowing your location,
(05:45):
or only when the app's beingused?
And so or never?
And so it does remind you thatsome of these apps are making
very, very heavy use of thesensors that are in the phone.
Hannah Clayton-Langton (05:55):
That was exactly the example that I was
thinking about.
Location is the one that I'mlike, sort of I never know what
to say.
Obviously, if it's somethingobvious, like Google Maps, of
course I'm going to grant it mylocation, but when it's
something like Instagram or Ican't think of another one right
now but I'm like are you goingto be exploiting this
information to give me moretargeted advertising?
And I think the answer to thatis probably yes, but that's
(06:17):
maybe not for this section ofthis podcast.
Hugh Williams (06:19):
Yeah, we should do advertising as a topic
someday.
Hannah Clayton-Langton (06:22):
Yeah, I guess the sort of takeaway is
the incredible power that'senabled by those sensors.
When I asked the question, Ispecifically mentioned mobile
apps, but I have an iPad and Ihave apps on there and I assume
something like an iPad or atablet has fewer sensors and
therefore the types of apps thatare optimized for those devices
(06:43):
are more about like streamingon a larger screen or maybe a
word processing type app,because you might have a
keyboard attached to somethinglike a tablet in a way that you
wouldn't to a phone.
Is that right?
Hugh Williams (06:55):
Yeah, I think, thinking about product
management, which we spoke aboutin the last episode, a great
product manager will think aboutthe characteristics of the
device that they're building forand also really hard about why
the user would want to use thatdevice, right?
So if you think about somethinglike an ipad, as you say, it's
got great screen real estaterelative to a smartphone, right.
So one reason you might buildan app for the ipad is because
(07:18):
you want that high resolution,wider, deeper screen experience
and that you know the smartphonemight not be suitable.
And word processing, I think,is a fantastic example of
something that's far moresensible on the iPad than it'll
ever be on the smartphone, well,unless you're using dictation
rather than trying to actuallytype in keys.
But it's a fantasticenvironment when you're on the
(07:39):
move, right.
So all of these sensors you'vegot a computer in your pocket
that's traveling around with youis a fantastic product for
things that require a productsolution.
That is about being on.
Hannah Clayton-Langton (07:50):
Okay.
So basically, if you're againthrowing back to our last
episode about product management, as a product manager you would
probably be thinking about thedifferent features and how they
play in with the differentdevices and assume you'd know
something about your user setand how much they're using
tablet versus smartphone or evensmartwatch I imagine that's not
(08:10):
that many and then you'd sortof be optimizing the different
user experiences to each ofthose devices.
Hugh Williams (08:16):
Yeah, absolutely.
I remember back when I was ateBay, which admittedly was in
the early 2010s we used to haveconversations about what are
users trying to accomplish ontheir laptop and what is it that
they're likely to want toaccomplish on their smartphone.
And if you think about ashopping site like eBay, this is
probably true for most shoppingsites.
The laptop is a fantasticexperience when you're doing
(08:37):
something exploratory whileyou're watching TV in the
background on a Sunday night,right?
So it's a great place to sortof discover, read reviews, you
know, look at the broad spectrumof possibilities, you know, do
price comparison, all thesekinds of things, and so if I was
the product manager, I'd bethinking really hard about how
to make those features availablefor customers who want to use a
(08:58):
laptop on a Sunday evening,right?
And that's a very differentscenario to the app that's on
the phone.
So the eBay app, for example, isdesigned for what we call
snacking, right?
So that means that you'rerunning between a meeting,
you're incredibly busy, you know.
You're racing for the train,whatever it is.
You want to be able to pullthat app out, you want to start
up fast and you want to be ableto carry out actions that you
(09:19):
might need to carry out, andthen you put the phone back in
your pocket.
So the classic on eBay is bidon an auction Auctions are still
very popular on eBay.
You might want to quickly openit up, quickly bid and then
quickly put the phone back inyour pocket, and that's a very
different scenario to thescenario on the laptop or
perhaps on the iPad.
So I think good productmanagers really think about what
(09:40):
device is suitable for whatscenario and really understand
their users' lives and, I think,also respect the fact that
users in many cases have morethan one device.
Now that isn't true insub-Saharan Africa, southeast
Asia, india and a few otherplaces.
Often people just have asmartphone, but in other parts
of the world, people will accessa product through multiple
(10:01):
devices and I think making surethat the experiences that you
build take advantage of thosedevices and also meet the user
scenarios is incrediblyimportant for product management
working across this wholespectrum.
Hannah Clayton-Langton (10:13):
Oh, that makes so much sense.
In front of right now, as wespeak, I have an iPad, a laptop
and a smartphone and I use themall very consciously for very
different things and differentdevices for different use cases.
So let's get technical for aminute.
What is an app on my phone likefrom 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, anapp is something that's written
in code.
So there's going to be one ormore software developers,
software engineers, who arewriting code and that code is
the basis of the app that is onyour phone.
So in the case of a simple appso let's imagine you and I are
(10:56):
building a calculator that'sprobably something that a single
software engineer could build,a complex app.
So if you think about somethinglike Google Maps, which I was
lucky enough to work on, thereare hundreds of mobile engineers
working on that because it's anincredibly broad product and
it's also an incredibly deepproduct and that all those
(11:17):
software engineers arecoordinating together to build a
single app that ends up in theapp store and being something
that you, that you download.
The other way to think about anapp, I guess, is to think about
sort of the depth of it, if youlike.
So a calculator is somethingthat just exists on your phone,
so you open it up, carry outsome simple maths.
(11:40):
It's not talking to theinternet, it's not communicating
with anything else, there's nosubstance that sits behind that.
So really, very literally, issome code that's written for
your phone, that runs on theoperating system on your phone.
At the other extreme, there aremany apps where the user
experience that you have on thephone so the actual code that's
running on your phone isactually fairly simple, but
what's sitting behind it isenormous sophistication that's
(12:02):
running in the cloud, whichmeans it's running in google's
data centers or amazon's awsdata centers or in microsoft's
data centers in most cases, andthat's where all the
sophistication is and that'swhere all the energy is going
from the software engineers.
So it really depends on what itis you're trying to build, as
to sort of how deep the app is,if you like, and how sort of
(12:23):
broad the app is.
But they're all built bysoftware engineers and most app
teams have a product manager.
Hannah Clayton-Langton (12:28):
Okay.
So I love this point aroundsimplicity and complexity at the
front end and then sort ofbehind the scenes, and it really
makes me think of chat gpt,which I'm now slightly
embarrassed to admit I've onlyever used on its web version.
Hugh Williams (12:43):
But that's super complex behind the scenes and
yet the user interaction pointis like basically as simple as
it gets yeah, I think that itmay be underestimating a little
bit some of the animation andthose kinds of things that goes
on in there.
So there's probably a bit ofsophistication around sort of
making that experience feel likeit's active.
(13:03):
But I'd say one good reason todownload the app is you log in,
you stay logged in, it remembersall of the chats that you've
had and it's easy to navigate,right.
So whereas again, if you goback to that web experience, I
bet sometimes you say whathappened to that tab?
Oh no, I have to log in again.
You know all those kinds ofthings and once you've got the
app, of course you can have amore seamless experience.
Hannah Clayton-Langton (13:24):
And then , what about something like a
banking app?
Is that super complex behindthe scenes?
Because of all the security?
Hugh Williams (13:31):
I think banking apps are a great example where
there's some sophisticationactually in the app and there's
also plenty of sophistication upin the cloud, right.
So let's just maybe talk aboutthe app on the phone for a
second.
So it makes pretty heavy use oflots of the sensors that are in
the phone.
So you've got things like theface sensor that's helping you
probably log in.
(13:52):
When there's risk of fraud,you're quite often asked to
record a video and move yourhead around and say some words.
So you're making use of themicrophone and the video
facilities in the phone.
So lots of things going onthere.
Of course, it's always sendingback your GPS location to the
bank's servers, because one ofthe ways you can detect fraud is
that somebody logs in from asuspicious location or appears
(14:15):
rapidly somewhere else, whenrecently they were in a
different location.
So knowing where the customeris, using the customer's
biometrics, is important.
But there's also lots ofsophistication going on in the
cloud.
So lots of algorithms runninglots of AI, if you like, in the
cloud doing things like frauddetection, the actual banking
itself.
There's some sophistication tothat, but that's really about
(14:35):
credits and debits and movingthings between accounts.
Hannah Clayton-Langton (14:38):
I was at an engagement party recently
and someone was telling me thathe's a tech investor a
non-technical tech investor, sodefinitely a potential listener
for this podcast but he wastelling me that they were
looking to invest in some sortof technical product where it
was smart enough to know if evenjust the way that you were
(14:59):
using the app was different.
So, like when I opened mybanking app, I am sure that my
session let's call it my usersession follows the exact same
patterns of behavior every time,because I check the same
accounts and I probably evenlike navigate the app in the
same way.
Is that something that'spossible in apps today?
Hugh Williams (15:16):
Yeah, absolutely, and this sort of dates back 20
years really.
So you know, one of the thingsthat the big internet companies
did back in the day was try andlook for bots that are scraping
them, and obviously bots have adifferent pattern of interaction
to humans, right?
So humans sort of interact andthen there's random pauses and
you know they have certain sortof characteristic behaviors.
(15:38):
Bots tend to just, you know,pound a website in a sort of
rhythmic kind of way, and evenif they're trying to act like
humans, they don't tend to looklike humans.
So 20 years ago, companies werevery, very good at trying to
keep bots off their site bylooking for behaviors that were
human and behaviors that werenon-human, and apps today are
still doing that, right.
(15:58):
So your app most certainly inmany cases is trying to
understand if your interactionsare typical of you or typical of
human interactions, and that'scertainly again one of the
characteristics that somethinglike 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 thedifference there?
I think I know that you needdifferent teams, you need
different types of engineers.
Hugh Williams (16:23):
So maybe, starting at the fundamental
level, the operating systems aredifferent.
So Apple has iOS and Google hasAndroid, and so they are
different operating systems,which is a bit like the
difference between MicrosoftWindows and the Mac OS on a
Macintosh computer, and so forour customers who've used
Android, if you switch to iOS,things aren't quite where you
(16:44):
expect them to be, and viceversa is true.
So the user paradigms, how itlooks and feels, is quite
different.
Hannah Clayton-Langton (16:50):
Okay, so just to build on that, throwing
back to our episode on productmanagement, do you have a single
product manager for an Androidapp versus for an iPhone app?
Because that feels like it's adangerous 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 theproduct.
But I would say for any companythat's delivering an Android
app and an iOS app that have anysort of moderate level of
sophistication, it's almostcertain that there's at least
two product managers involved.
So the iOS team probably has atleast one product manager and
the Android team has anotherproduct manager and at least one
(17:25):
of those.
I think the job of a directoror a vice president the person
who sits above those folks is tomake sure that these things run
down the same train tracks andyou don't end up with too much
diversity in the experiences.
But that that's as much scienceas it is art.
But usually designing for oneand designing for the other
requires depth and you typicallyhave product managers and
(17:46):
different teams building the,building the android and
building the ios apps okay,because again a throwback, but
this time to our first episodeon 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 codinglanguages and the way you go
about the development is quitedifferent between iOS and
Android.
There are some tools out there,so you know, Meta has released
some tools.
Google has released some toolsthat allow you to build
something common.
Meta has released some tools.
Google's released some toolsthat allow you to build
something common and then,behind the scenes, it creates
(18:18):
code in the languages that arespecific to the Android
ecosystem and the iOS ecosystem.
But typically you'd only usethat for prototyping, for sort
of MVPs, sort of a simpleversion of your product as
you're testing it out.
Once you get to any level ofsophistication, you're probably
going to find yourself hiringsoftware engineers to work on
Android and a different set ofsoftware engineers to work on
(18:38):
iOS.
Hannah Clayton-Langton (18:39):
So is it very possible here that, like a
version of an app that I haveand my husband has on, different
operating systems might havedifferent feature sets, because
they're not going to be exactlylike for like at all times.
Hugh Williams (18:50):
Yeah, almost certain that they're different
and sometimes that'sdeliberately the case.
So what we used to do at Googlewas we would build the Android
app and we put that in the appstore and the customers would
get that and then we'd see howthe usage of the features that
we'd recently shipped went.
And then the iOS team would sortof look at those features.
Maybe they also had a fewfeatures that they want to build
(19:12):
that were slightly different.
They'd look at those featuresand then they'd what we call
fast follow, probably six monthsbehind.
So the iOS app at any point intime is probably about six
months behind the Android app asthe iOS team watches and
listens and learns and seeswhat's happening with Android.
And of course there's vastlymore Android engineers at Google
than there are iOS engineers.
(19:33):
So if you look at the relativesize of the teams, the Android
team is much larger and canreally pioneer new features, get
lots of features out there, dolots of experimentation, whereas
the iOS team is really in thisfast follow mode.
So much smaller, tighter team.
That's sort of looking at thefeatures and then adapting those
features, getting the designaesthetic right you know, making
it feel like it's an iOSfeature and getting it out the
(19:54):
door, maybe six months later.
Hannah Clayton-Langton (19:56):
I'm fascinated by this sort of two
horse race between iOS andAndroid.
But thinking about the appstores now, like Google Play and
the Apple App Store, like howdoes that all work If I'm
building an app, like there'stwo parts to my question.
I want to build an app.
How am I getting it onto theApp Store?
Can, like any old person, buildan app and put it on the App
Store and then like, what's thedifference in the Google Play
(20:18):
App Store and the Apple AppStore from, like, a developer
perspective?
Hugh Williams (20:23):
Yeah, great question.
So first thing to do if you'rethinking about building an app
for one of these app stores isto understand what the
guidelines of the app store are,right?
So Apple definitely has astricter and a longer list of
guidelines of things you can andcan't do if you want to put an
app in the app store.
So I'll give you a quickexample.
An example would be don't makeuse of sensors that your app
(20:44):
doesn't need.
You've got a calculator app andyou want to put it in the app
store.
You're going to have a lot oftrouble 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 userswith no reason to actually make
use of the GPS.
So in practice, you really needto understand the guidelines of
the app store before you reallyget started, right?
(21:04):
So Google's less strict, so theguidelines are shorter and
they're less stringent aboutwhat goes into their app store.
So it's much, much easier toget an app into the Google Play
Store than it is to get into theApple 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 workfor the arbiters, as it were so
for Apple and Google, but Idon't pay for a lot of apps.
The arbiters, as it were so forApple and Google, but I don't
pay for a lot of apps.
So, like, how does that work?
I pay for some apps, I mightpay for a subscription, but most
things I'm using, like myAmazon app or Instagram or
(21:41):
WhatsApp, I paid maybe like adollar once for.
But like, how does that workcommercially for them?
Hugh Williams (21:46):
Yeah, great question, hannah.
So there's a few things goingon in this ecosystem.
So first thing is, if you payfor an app, then the company is
keeping up to 30% of theproceeds.
It can be as little as 15% inmost cases, but it can be up to
30% in many cases.
So lots of money is being keptas a tax, if you like, by Apple
or Google.
(22:06):
When you put your app in the appstore and you charge for your
app, which is still a verycommon way to monetize the work
that you do.
They also take a clip on any inapp transactions that are part
of their ecosystem.
So, you know, sometimes you'llbuy extra features within the
app.
So I've got a weather app.
You know I wanted to haveaccess to graphs that showed me,
you know months of temperatureand I had to pay the app
(22:29):
provider for that feature.
That didn't come by default,you know.
So I pay my $1.99 and I getaccess to temperature graphs.
Again, apple and Google willtake a clip on that.
The other thing they'll take aclip on is subscriptions.
So if you subscribe to thingsthrough your app, then they're
very likely taking a clip onthat.
But there's lots of apps, as yousay that are just free-free
(22:50):
right.
So the Amazon app you downloadit, you have it on your
smartphone.
You didn't pay for that.
There's no subscriptions goingon, you're not paying to enable
any features.
So, yeah, it's true that bothApple and Google are not
directly making money out of theAmazon app, but it helps their
ecosystem.
So now you want to be part ofthat ecosystem because that
(23:12):
ecosystem has lots of tools thatare very useful to you.
So there's lots of apps therethat are not monetized really by
Apple and Google, but are justpart of having a vibrant,
successful ecosystem, and, ofcourse, that helps everybody
else.
That causes people to actuallypay for other apps.
You know, buy features in appsand subscribe because they're
part of this vibrant ecosystemand they become very, very loyal
(23:34):
to their apple device or theirandroid device.
And we should chat at somepoint about some of the legal
things that are happening inthis space.
But certainly in the eu,there's an attempt to dismantle
apple's you know monopoly overthe app store, right, so that
you can actually get apps ontoyour phone that don't come from
the Apple App Store.
(23:54):
So it's something that the EUis trying to impose upon Apple.
You know the EU often leads inthese kinds of areas, so
typically the EU will dosomething first and then often
you'll find the United Statesfollows sometime later with
something similar.
So there's certainly an attemptgoing on right now to sort of
remove this monopolistic typenature that Apple has over the
(24:19):
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 Storewithout any other context.
That just sounds like a prettyhefty chunk.
It's a pretty good deal, Ithink, for Apple and iOS.
Hugh Williams (24:35):
Yeah, and they would say, of course, that
there's lots of costs in runninga store and administering the
store and approving things thatgo into the store and all the
services they provide and thephone ecosystem itself.
So they'll certainly tell youthere's a good reason for that,
but certainly it does feel likea 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 sortof legal and commercial elements
of this stuff, because tech canfeel counterintuitive in that
sense, like you get a lot forfree, and I once watched a very
sobering documentary where theywere like if you're not paying
for the product, then someone'spaying for you as the product,
your data.
Hugh Williams (25:12):
Yeah, absolutely Okay.
So no such thing as free intech.
Hannah Clayton-Langton (25:15):
Yeah, okay, so let's finish up with
back to some of this productstuff, which I know is your sort
of sweet spot.
But what's it like to build anapp?
We've mentioned a few of them.
I I think you talked about likeprototyping and testing, but
like what's the flow if you wantto get a feature onto an app?
Like it's kind of the productmanagement, but let's talk about
it specifically in the appscenario.
Hugh Williams (25:38):
One thing that makes building for the web and
building for mobile reallydifferent is experimentation.
So a lot of the very, verylarge companies and it's
probably true of even mediumsized companies these days do a
lot of experimentation on theirusers.
So, for example, if you'reusing Facebook, you are for
certain going to get a differentexperience in quite a few
(25:59):
subtle ways than my experienceon Facebook, and the reason that
that's the case is not justabout personalizing for you, but
Facebook wants to try out newfeatures, and that can be as
simple as things like changingvery subtly the colors of fonts,
the size of things, how big theX is for closing things, how
big images are all sorts ofreally subtle stuff and what
(26:21):
they're trying to do is figureout, in many cases, what drives
more engagement.
Ultimately, if the new featurethat they're testing drives more
engagement, then they.
If the new feature that they'retesting drives more engagement,
then they'll ship that out totheir customers.
That's a lot harder to do in anapp, because an app is something
that's produced and it's put inthe app store and then it's
downloaded onto a phone.
(26:41):
So it's a little bit more likethe 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 acopy and then you install it.
So that sort of fast testingand iteration is much, much
easier on the web than it is inan app.
So that's one of the really bigdifferences is apps are really
a little bit more waterfall.
If you like, you kind of buildit, you ship it out to the app
(27:03):
store, you wait some amount oftime until it's approved, ends
up in the app store and thenyour customers get to download
it.
The other thing I'd say aboutapps is that users tend to have
lots of different versions ofthe app, right, so you might be
one of these people thatreligiously updates their apps
whenever a new update isavailable.
Lots of people don't do that.
So having worked at lots ofthese tech companies, you will
(27:27):
find that versions from 10, 12years ago are still in use by a
minute number of customers.
So every version you've everreleased is probably being used
by somebody, especially whenthey're a significant fraction
(27:50):
of the user.
Traffic is another thing thatmakes app development really
really different to webdevelopment, where you know if
you go and visit the website,you're getting the latest
version every time you visit thewebsite, right, but that's not
necessarily the case when itcomes 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 pointof view sometimes it's really
annoying.
You can ignore a pop-up andthen you'll sort of keep getting
them until you don't have achoice is so valid because from
a user point of view sometimesit's really annoying you can
ignore a pop-up and then you'llsort of keep getting them until
you don't have a choice.
But would a company ever justdeprecate a really old version
of an app and not give the usera choice?
Hugh Williams (28:19):
They absolutely should Look.
I've worked at companies wherewe sort of forgot to do that.
So you know we're back in theearlier days of apps and we
haven't built that feature inand that app version has gone
out.
Right Now there's no way toactually deprecate that.
So I've worked at companiesthat have done that.
You regret that a lot later on.
So I'd say one of the bestpractices in app development is
(28:40):
to make sure that you have someway of deprecating the app,
which is as simple as when theuser opens the app you say I'm
sorry, but this version's beendeprecated.
Please download the latestversion, and then you're
effectively ending the life ofthat app.
And then you're making yourdevelopers a lot happier because
they're not having to supportevery single version of the app
that's out there.
You're actually getting rid ofversions that are reasonably old
(29:01):
and only used by a small numberof customers in your user base.
Hannah Clayton-Langton (29:05):
Okay, but presumably you risk there.
If you deprecate an app and yourequire someone to download a
new version, you essentiallyrisk them lapsing as a user.
Hugh Williams (29:13):
Yeah, that's right.
So you wouldn't want to do thatfor any significant fraction of
the user base.
But if we're talking fractionsof a single percent of users so
you've got 0.2 of a percent ofthe users on an app version
that's 10 years old then I thinkit's pretty reasonable in most
cases to say, hey, this isdeprecated, get the new version.
And of course you can upsellthe new version.
Right, you can tell them allthe great new features they're
going to get and give them areason to do that, and hopefully
(29:35):
most of those customers willstick.
Hannah Clayton-Langton (29:37):
Okay, that makes sense.
And is it possible to update anapp without requiring me to
install a new version?
I know at work we sometimestalk about like silent releases.
They don't need to know thatwe've changed tiny things in the
background and actuallysometimes you can draw too much
attention to something reallyinconsequential 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 theapp that you can later turn on
right.
So I could release an appthat's capable of doing some
things that the user can't yetuse, that's capable of doing
some things that the user can'tyet use, and then sometime in
the future I can communicatewith that app and I can tell
that app to turn on that featureand make it available to the
user.
So that's called an app flag.
The reason you might do that isbecause you haven't quite
finished what's going on in thecloud, so you haven't quite
(30:23):
finished the sort of behind thescenes work that needs to be
done.
Or perhaps you haven't quitefinished some of the
experimentation you're doing andyou're not sure whether you
want to turn that feature on orwhen you want to turn that on.
So the apps have lots of thesesort of secret app flags in them
that allow them to changewithout the user downloading a
new version of the app.
(30:43):
The other way to do it is tomake your app into something
that's a little bit more likethe web.
So very simple apps often arejust web containers, so they're
really a web browser.
You download it and you thinkyou're getting a really
sophisticated app, but whatyou're really getting is another
web browser that goes andretrieves web pages and shows
those web pages to you.
(31:04):
Now, obviously, if you changethose web pages, then you get a
very different app experience,and so that's another way where
you can really make an appchange pretty dynamically
without having to download a newcopy, because it's not really
the app that's changing, it's awebpage that's being displayed
within the app that's actuallychanging.
So there's ways to certainlywork around a customer having to
download an app and still havethat app evolve.
Hannah Clayton-Langton (31:26):
And, from a user's perspective, if
it's done right, does it sort oflook and feel like an app.
Hugh Williams (31:31):
I'd say no.
I think it looks and feels likebrowsing the web, so it doesn't
quite have the sophisticatedanimations and the deep
immersive experience, andperhaps it isn't able to access
in a really native way some ofthe sensors and features that
are on the phone.
So it's great if you just wantto display information Works
okay in shopping apps, forexample but if you're trying to
(31:52):
build a deep, rich, immersiveexperience you know something
like a Google Maps or a Stravaor an Instagram then you
probably want to build it innative code and really make sure
it's highly optimized and areally 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 themost is Spotify.
Everywhere I'm going, I've gotsomething in my ears, whether
it's podcast or music, and as aLondon 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'mlistening to something that I've
(32:25):
not downloaded locally, andsometimes I'll get like a few
songs or like another 10 minutesof my podcast, and sometimes I
don't, or like I'm not reallysure 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 towhat is caching.
So caching is about gettinginformation close to you that
you're likely to use again or inthe near future.
So a simple example would beimages.
So you're browsing on ashopping website, you're very
(32:58):
likely to go back to an itemthat you've seen, and if that
item is pictures, are storedclose to you or actually on your
device, you'll get a faster,more seamless experience.
So having those images close toyou is going to make your
shopping experience richer anddeeper and you'll probably buy
more stuff.
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 listento those again, and then also we
(33:19):
could do some predictivedownloading right.
So if I was at Spotify they'rea very sophisticated company I
would probably have the ideathat as a customer gets close to
the tube or as a customercarries out a predictable day,
so I probably know when I'mgoing to lose connection with
you and where you're going to bewhen that's going to happen.
Perhaps I'll be smart enough toreally slurp down the next 10
(33:42):
minutes of the podcast or acouple of songs, so that you
have a seamless experience andyou don't quit Spotify.
You know you're probablydelighted by that experience, so
that's exactly what caching is.
It's about getting things thatyou're likely to need in the
future, or storing things thatyou'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 themain points that I had, with
some teasers for future episodes.
It's been really great chattingwith you today, hugh.
Hugh Williams (34:08):
Thanks, adam.
It's been fantastic to talkabout apps with you and you're
right, there's lots of reallycool 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 onyour favorite platform.
We're also available onLinkedIn at techoverflowflow
(34:29):
Podcast, and you can find us onInstagram and X.
Hannah Clayton-Langton (34:32):
Awesome, so I'll see you again next time
, hugh, for anotherdemystification of technology.
I can't wait, hannah, see yousoon, see ya.
Hello world, Welcome to the Tech
Overflow podcast, the podcastwhere we break down technical
concepts for smart people.
I'm Hannah Clayton Langton andafter five years working in a
tech company surrounded byengineers, I decided I wanted to
understand a little bit moreabout what was going on around
me.
Hugh Williams (00:21):
And I'm Hugh Williams.
I'm a former vice president atGoogle and also at eBay, and I
was one of the first engineersto help Microsoft build Bing and
my job is to help Hannahdemystify tech concepts for the
smart listeners that we have outthere.
Hannah Clayton-Langton (00:33):
Today, as always, we're coming to you
from Melbourne and London, somaking the most of the smart
technology out there to enabledual hemisphere recording.
We're about to get into theinteresting topic of apps and
how they work, but before we dothat, hugh, how's it going down
there?
Are you cold?
Hugh Williams (00:52):
I am cold and I'm getting a little hungry because
it's dinner time here and Iknow it's probably just
breakfast time there.
So I'm cold and hungry.
How are you?
Hannah Clayton-Langton (01:01):
I am very warm.
Heatwave in London issustaining.
But I'm really excited to getinto this topic.
So I say we just let's get intoit, let's go.
Okay, so start at the verybeginning.
Why would a company build anapp Like what is the use case
for the investment in?
Let's start with just a mobileapp.
Hugh Williams (01:19):
Well, maybe a good place to start is with the
alternative, right?
So I think we've all tried toaccess a website on our mobile
phone, and to some degree thatcan be a satisfactory experience
, but often there's a lot ofthings missing and it can be
quite infuriating.
So, for example, you mightaccess your favorite shopping
app through the mobile web andthen next time you go to do it
(01:40):
it's logged you out for somereason or you can't find the tab
that you used, and so theexperiences could be a little
bit disjointed.
The visual experience oftenisn't as deep and as immersive
as you want, and then sometimesyour mobile web experience won't
be able to access parts of yourdevice that you wish it could
access, and, in the extreme,mobile web can't actually do all
(02:04):
the things that you need as acustomer.
But sometimes it's good enoughwhen the task is pretty simple.
So that kind of leads us to whybuild an app?
So if we're a company and we'rebuilding an app, we're building
it because we want to build adeep, rich, immersive experience
, we want to keep the userlogged in, we want them to be
able to open up the app anytimeand pick up where they left off,
(02:26):
and we want to make sure thatthat app can access all of the
different, less frustrating youcan like.
Hannah Clayton-Langton (02:32):
Whenever I decide, I'm going to quit
social media and delete theInstagram app.
I end up using the Instagramwebsite, which basically is just
like a worse experience, butit's exactly that.
(02:55):
It's like all my stuff's inthere, they know what I'm doing.
I can like whether I'm shoppingor browsing or scrolling.
It's definitely a moreintuitive experience.
So, yeah, richer experience.
I'd love to know more about thesensors in the phone, because I
have a hunch that there's a lotmore than I, as a layperson,
(03:15):
can think of.
Hugh Williams (03:16):
There's probably nearly 20.
You might be surprised to know,hannah.
So there's an enormous numberof sensors in a modern
smartphone.
Some of them are obvious,probably the reasons that you
buy the phone, right?
So things like the cameras, youknow, hannah.
So there's an enormous numberof sensors in a modern
smartphone.
Some of them are obvious,probably the reasons that you
buy the phone, right.
So things like the cameras, youknow two or three cameras,
typically on the rear of thephone, and then there's, of
course, there's a camera on thefront for taking selfies.
I guess something else that'sfairly obvious is that it's got
(03:38):
a GPS in it, so globalpositioning, so your phone knows
where it is, and so if you'veinstalled something like Google
Maps on your phone or some otherlocation aware tool, then
that's very, very central tothat app, right?
So knowing exactly where you arehelps you navigate the world,
for example.
And then, right down the otherend, there's some very obscure
(03:58):
sensors, so you might besurprised to know.
For example, there's abarometer, and it's a very, very
sensitive barometer.
So when you're using a fitnesstracking app, for example, and
you travel up a flight of stairs, it's a lot of action from the
barometer there that figures outhow far you've traveled up a
flight of stairs.
There's a magnetometer in therewhich is effectively a compass,
so your phone knows which wayit's pointing.
(04:21):
Again, that's important inthings like google maps for
navigation.
And then there's anaccelerometer, which is really
interesting, which is basicallya device that measures how fast
your phone is accelerating ordecelerating, and again that's
pretty handy when it comes tothese motion aware kinds of apps
and tons of sensors in between.
Hannah Clayton-Langton (04:40):
That's crazy.
I hadn't even heard of amagnetometer.
You're lighting up all parts ofmy brain because, you're right,
I'm big into Strava.
I use AllTrails sometimes, sothese are the kind of apps where
those things play into it quitea lot.
As a user, you expect yourlittle blue dot on Google Maps
to point in the right direction,and I know some of the
listeners have probably feltfrustrated when it doesn't.
(05:01):
But you don't actually thinkabout how that works.
So next time I use Strava, I'mgoing to be thinking about the
technical complexity of that.
So the app is about leveragingeverything that the smartphone
has to offer, but notnecessarily in a way.
I guess that the users areaware of that because as modern
phone users, we just sort ofexpect those things to exist.
Hugh Williams (05: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 quiteoften pop up dialogue boxes, as
we call them, that tell youabout the sensors that are being
used by your app.
So I think most of our userswho are in the Apple ecosystem
will be familiar with Applepopping up a dialogue that says
do you want to allow this app tokeep on knowing your location,
(05:45):
or only when the app's beingused?
And so or never?
And so it does remind you thatsome of these apps are making
very, very heavy use of thesensors that are in the phone.
Hannah Clayton-Langton (05:55):
That was exactly the example that I was
thinking about.
Location is the one that I'mlike, sort of I never know what
to say.
Obviously, if it's somethingobvious, like Google Maps, of
course I'm going to grant it mylocation, but when it's
something like Instagram or Ican't think of another one right
now but I'm like are you goingto be exploiting this
information to give me moretargeted advertising?
And I think the answer to thatis probably yes, but that's
(06:17):
maybe not for this section ofthis podcast.
Hugh Williams (06:19):
Yeah, we should do advertising as a topic
someday.
Hannah Clayton-Langton (06:22):
Yeah, I guess the sort of takeaway is
the incredible power that'senabled by those sensors.
When I asked the question, Ispecifically mentioned mobile
apps, but I have an iPad and Ihave apps on there and I assume
something like an iPad or atablet has fewer sensors and
therefore the types of apps thatare optimized for those devices
(06:43):
are more about like streamingon a larger screen or maybe a
word processing type app,because you might have a
keyboard attached to somethinglike a tablet in a way that you
wouldn't to a phone.
Is that right?
Hugh Williams (06:55):
Yeah, I think, thinking about product
management, which we spoke aboutin the last episode, a great
product manager will think aboutthe characteristics of the
device that they're building forand also really hard about why
the user would want to use thatdevice, right?
So if you think about somethinglike an ipad, as you say, it's
got great screen real estaterelative to a smartphone, right.
So one reason you might buildan app for the ipad is because
(07:18):
you want that high resolution,wider, deeper screen experience
and that you know the smartphonemight not be suitable.
And word processing, I think,is a fantastic example of
something that's far moresensible on the iPad than it'll
ever be on the smartphone, well,unless you're using dictation
rather than trying to actuallytype in keys.
But it's a fantasticenvironment when you're on the
(07:39):
move, right.
So all of these sensors you'vegot a computer in your pocket
that's traveling around with youis a fantastic product for
things that require a productsolution.
That is about being on.
Hannah Clayton-Langton (07:50):
Okay.
So basically, if you're againthrowing back to our last
episode about product management, as a product manager you would
probably be thinking about thedifferent features and how they
play in with the differentdevices and assume you'd know
something about your user setand how much they're using
tablet versus smartphone or evensmartwatch I imagine that's not
(08:10):
that many and then you'd sortof be optimizing the different
user experiences to each ofthose devices.
Hugh Williams (08:16):
Yeah, absolutely.
I remember back when I was ateBay, which admittedly was in
the early 2010s we used to haveconversations about what are
users trying to accomplish ontheir laptop and what is it that
they're likely to want toaccomplish on their smartphone.
And if you think about ashopping site like eBay, this is
probably true for most shoppingsites.
The laptop is a fantasticexperience when you're doing
(08:37):
something exploratory whileyou're watching TV in the
background on a Sunday night,right?
So it's a great place to sortof discover, read reviews, you
know, look at the broad spectrumof possibilities, you know, do
price comparison, all thesekinds of things, and so if I was
the product manager, I'd bethinking really hard about how
to make those features availablefor customers who want to use a
(08:58):
laptop on a Sunday evening,right?
And that's a very differentscenario to the app that's on
the phone.
So the eBay app, for example, isdesigned for what we call
snacking, right?
So that means that you'rerunning between a meeting,
you're incredibly busy, you know.
You're racing for the train,whatever it is.
You want to be able to pullthat app out, you want to start
up fast and you want to be ableto carry out actions that you
(09:19):
might need to carry out, andthen you put the phone back in
your pocket.
So the classic on eBay is bidon an auction Auctions are still
very popular on eBay.
You might want to quickly openit up, quickly bid and then
quickly put the phone back inyour pocket, and that's a very
different scenario to thescenario on the laptop or
perhaps on the iPad.
So I think good productmanagers really think about what
(09:40):
device is suitable for whatscenario and really understand
their users' lives and, I think,also respect the fact that
users in many cases have morethan one device.
Now that isn't true insub-Saharan Africa, southeast
Asia, india and a few otherplaces.
Often people just have asmartphone, but in other parts
of the world, people will accessa product through multiple
(10:01):
devices and I think making surethat the experiences that you
build take advantage of thosedevices and also meet the user
scenarios is incrediblyimportant for product management
working across this wholespectrum.
Hannah Clayton-Langton (10:13):
Oh, that makes so much sense.
In front of right now, as wespeak, I have an iPad, a laptop
and a smartphone and I use themall very consciously for very
different things and differentdevices for different use cases.
So let's get technical for aminute.
What is an app on my phone likefrom 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, anapp is something that's written
in code.
So there's going to be one ormore software developers,
software engineers, who arewriting code and that code is
the basis of the app that is onyour phone.
So in the case of a simple appso let's imagine you and I are
(10:56):
building a calculator that'sprobably something that a single
software engineer could build,a complex app.
So if you think about somethinglike Google Maps, which I was
lucky enough to work on, thereare hundreds of mobile engineers
working on that because it's anincredibly broad product and
it's also an incredibly deepproduct and that all those
(11:17):
software engineers arecoordinating together to build a
single app that ends up in theapp store and being something
that you, that you download.
The other way to think about anapp, I guess, is to think about
sort of the depth of it, if youlike.
So a calculator is somethingthat just exists on your phone,
so you open it up, carry outsome simple maths.
(11:40):
It's not talking to theinternet, it's not communicating
with anything else, there's nosubstance that sits behind that.
So really, very literally, issome code that's written for
your phone, that runs on theoperating system on your phone.
At the other extreme, there aremany apps where the user
experience that you have on thephone so the actual code that's
running on your phone isactually fairly simple, but
what's sitting behind it isenormous sophistication that's
(12:02):
running in the cloud, whichmeans it's running in google's
data centers or amazon's awsdata centers or in microsoft's
data centers in most cases, andthat's where all the
sophistication is and that'swhere all the energy is going
from the software engineers.
So it really depends on what itis you're trying to build, as
to sort of how deep the app is,if you like, and how sort of
(12:23):
broad the app is.
But they're all built bysoftware engineers and most app
teams have a product manager.
Hannah Clayton-Langton (12:28):
Okay.
So I love this point aroundsimplicity and complexity at the
front end and then sort ofbehind the scenes, and it really
makes me think of chat gpt,which I'm now slightly
embarrassed to admit I've onlyever used on its web version.
Hugh Williams (12:43):
But that's super complex behind the scenes and
yet the user interaction pointis like basically as simple as
it gets yeah, I think that itmay be underestimating a little
bit some of the animation andthose kinds of things that goes
on in there.
So there's probably a bit ofsophistication around sort of
making that experience feel likeit's active.
(13:03):
But I'd say one good reason todownload the app is you log in,
you stay logged in, it remembersall of the chats that you've
had and it's easy to navigate,right.
So whereas again, if you goback to that web experience, I
bet sometimes you say whathappened to that tab?
Oh no, I have to log in again.
You know all those kinds ofthings and once you've got the
app, of course you can have amore seamless experience.
Hannah Clayton-Langton (13:24):
And then , what about something like a
banking app?
Is that super complex behindthe scenes?
Because of all the security?
Hugh Williams (13:31):
I think banking apps are a great example where
there's some sophisticationactually in the app and there's
also plenty of sophistication upin the cloud, right.
So let's just maybe talk aboutthe app on the phone for a
second.
So it makes pretty heavy use oflots of the sensors that are in
the phone.
So you've got things like theface sensor that's helping you
probably log in.
(13:52):
When there's risk of fraud,you're quite often asked to
record a video and move yourhead around and say some words.
So you're making use of themicrophone and the video
facilities in the phone.
So lots of things going onthere.
Of course, it's always sendingback your GPS location to the
bank's servers, because one ofthe ways you can detect fraud is
that somebody logs in from asuspicious location or appears
(14:15):
rapidly somewhere else, whenrecently they were in a
different location.
So knowing where the customeris, using the customer's
biometrics, is important.
But there's also lots ofsophistication going on in the
cloud.
So lots of algorithms runninglots of AI, if you like, in the
cloud doing things like frauddetection, the actual banking
itself.
There's some sophistication tothat, but that's really about
(14:35):
credits and debits and movingthings between accounts.
Hannah Clayton-Langton (14:38):
I was at an engagement party recently
and someone was telling me thathe's a tech investor a
non-technical tech investor, sodefinitely a potential listener
for this podcast but he wastelling me that they were
looking to invest in some sortof technical product where it
was smart enough to know if evenjust the way that you were
(14:59):
using the app was different.
So, like when I opened mybanking app, I am sure that my
session let's call it my usersession follows the exact same
patterns of behavior every time,because I check the same
accounts and I probably evenlike navigate the app in the
same way.
Is that something that'spossible in apps today?
Hugh Williams (15:16):
Yeah, absolutely, and this sort of dates back 20
years really.
So you know, one of the thingsthat the big internet companies
did back in the day was try andlook for bots that are scraping
them, and obviously bots have adifferent pattern of interaction
to humans, right?
So humans sort of interact andthen there's random pauses and
you know they have certain sortof characteristic behaviors.
(15:38):
Bots tend to just, you know,pound a website in a sort of
rhythmic kind of way, and evenif they're trying to act like
humans, they don't tend to looklike humans.
So 20 years ago, companies werevery, very good at trying to
keep bots off their site bylooking for behaviors that were
human and behaviors that werenon-human, and apps today are
still doing that, right.
(15:58):
So your app most certainly inmany cases is trying to
understand if your interactionsare typical of you or typical of
human interactions, and that'scertainly again one of the
characteristics that somethinglike 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 thedifference there?
I think I know that you needdifferent teams, you need
different types of engineers.
Hugh Williams (16:23):
So maybe, starting at the fundamental
level, the operating systems aredifferent.
So Apple has iOS and Google hasAndroid, and so they are
different operating systems,which is a bit like the
difference between MicrosoftWindows and the Mac OS on a
Macintosh computer, and so forour customers who've used
Android, if you switch to iOS,things aren't quite where you
(16:44):
expect them to be, and viceversa is true.
So the user paradigms, how itlooks and feels, is quite
different.
Hannah Clayton-Langton (16:50):
Okay, so just to build on that, throwing
back to our episode on productmanagement, do you have a single
product manager for an Androidapp versus for an iPhone app?
Because that feels like it's adangerous 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 theproduct.
But I would say for any companythat's delivering an Android
app and an iOS app that have anysort of moderate level of
sophistication, it's almostcertain that there's at least
two product managers involved.
So the iOS team probably has atleast one product manager and
the Android team has anotherproduct manager and at least one
(17:25):
of those.
I think the job of a directoror a vice president the person
who sits above those folks is tomake sure that these things run
down the same train tracks andyou don't end up with too much
diversity in the experiences.
But that that's as much scienceas it is art.
But usually designing for oneand designing for the other
requires depth and you typicallyhave product managers and
(17:46):
different teams building the,building the android and
building the ios apps okay,because again a throwback, but
this time to our first episodeon 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 codinglanguages and the way you go
about the development is quitedifferent between iOS and
Android.
There are some tools out there,so you know, Meta has released
some tools.
Google has released some toolsthat allow you to build
something common.
Meta has released some tools.
Google's released some toolsthat allow you to build
something common and then,behind the scenes, it creates
(18:18):
code in the languages that arespecific to the Android
ecosystem and the iOS ecosystem.
But typically you'd only usethat for prototyping, for sort
of MVPs, sort of a simpleversion of your product as
you're testing it out.
Once you get to any level ofsophistication, you're probably
going to find yourself hiringsoftware engineers to work on
Android and a different set ofsoftware engineers to work on
(18:38):
iOS.
Hannah Clayton-Langton (18:39):
So is it very possible here that, like a
version of an app that I haveand my husband has on, different
operating systems might havedifferent feature sets, because
they're not going to be exactlylike for like at all times.
Hugh Williams (18:50):
Yeah, almost certain that they're different
and sometimes that'sdeliberately the case.
So what we used to do at Googlewas we would build the Android
app and we put that in the appstore and the customers would
get that and then we'd see howthe usage of the features that
we'd recently shipped went.
And then the iOS team would sortof look at those features.
Maybe they also had a fewfeatures that they want to build
(19:12):
that were slightly different.
They'd look at those featuresand then they'd what we call
fast follow, probably six monthsbehind.
So the iOS app at any point intime is probably about six
months behind the Android app asthe iOS team watches and
listens and learns and seeswhat's happening with Android.
And of course there's vastlymore Android engineers at Google
than there are iOS engineers.
(19:33):
So if you look at the relativesize of the teams, the Android
team is much larger and canreally pioneer new features, get
lots of features out there, dolots of experimentation, whereas
the iOS team is really in thisfast follow mode.
So much smaller, tighter team.
That's sort of looking at thefeatures and then adapting those
features, getting the designaesthetic right you know, making
it feel like it's an iOSfeature and getting it out the
(19:54):
door, maybe six months later.
Hannah Clayton-Langton (19:56):
I'm fascinated by this sort of two
horse race between iOS andAndroid.
But thinking about the appstores now, like Google Play and
the Apple App Store, like howdoes that all work If I'm
building an app, like there'stwo parts to my question.
I want to build an app.
How am I getting it onto theApp Store?
Can, like any old person, buildan app and put it on the App
Store and then like, what's thedifference in the Google Play
(20:18):
App Store and the Apple AppStore from, like, a developer
perspective?
Hugh Williams (20:23):
Yeah, great question.
So first thing to do if you'rethinking about building an app
for one of these app stores isto understand what the
guidelines of the app store are,right?
So Apple definitely has astricter and a longer list of
guidelines of things you can andcan't do if you want to put an
app in the app store.
So I'll give you a quickexample.
An example would be don't makeuse of sensors that your app
(20:44):
doesn't need.
You've got a calculator app andyou want to put it in the app
store.
You're going to have a lot oftrouble 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 userswith no reason to actually make
use of the GPS.
So in practice, you really needto understand the guidelines of
the app store before you reallyget started, right?
(21:04):
So Google's less strict, so theguidelines are shorter and
they're less stringent aboutwhat goes into their app store.
So it's much, much easier toget an app into the Google Play
Store than it is to get into theApple 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 workfor the arbiters, as it were so
for Apple and Google, but Idon't pay for a lot of apps.
The arbiters, as it were so forApple and Google, but I don't
pay for a lot of apps.
So, like, how does that work?
I pay for some apps, I mightpay for a subscription, but most
things I'm using, like myAmazon app or Instagram or
(21:41):
WhatsApp, I paid maybe like adollar once for.
But like, how does that workcommercially for them?
Hugh Williams (21:46):
Yeah, great question, hannah.
So there's a few things goingon in this ecosystem.
So first thing is, if you payfor an app, then the company is
keeping up to 30% of theproceeds.
It can be as little as 15% inmost cases, but it can be up to
30% in many cases.
So lots of money is being keptas a tax, if you like, by Apple
or Google.
(22:06):
When you put your app in the appstore and you charge for your
app, which is still a verycommon way to monetize the work
that you do.
They also take a clip on any inapp transactions that are part
of their ecosystem.
So, you know, sometimes you'llbuy extra features within the
app.
So I've got a weather app.
You know I wanted to haveaccess to graphs that showed me,
you know months of temperatureand I had to pay the app
(22:29):
provider for that feature.
That didn't come by default,you know.
So I pay my $1.99 and I getaccess to temperature graphs.
Again, apple and Google willtake a clip on that.
The other thing they'll take aclip on is subscriptions.
So if you subscribe to thingsthrough your app, then they're
very likely taking a clip onthat.
But there's lots of apps, as yousay that are just free-free
(22:50):
right.
So the Amazon app you downloadit, you have it on your
smartphone.
You didn't pay for that.
There's no subscriptions goingon, you're not paying to enable
any features.
So, yeah, it's true that bothApple and Google are not
directly making money out of theAmazon app, but it helps their
ecosystem.
So now you want to be part ofthat ecosystem because that
(23:12):
ecosystem has lots of tools thatare very useful to you.
So there's lots of apps therethat are not monetized really by
Apple and Google, but are justpart of having a vibrant,
successful ecosystem, and, ofcourse, that helps everybody
else.
That causes people to actuallypay for other apps.
You know, buy features in appsand subscribe because they're
part of this vibrant ecosystemand they become very, very loyal
(23:34):
to their apple device or theirandroid device.
And we should chat at somepoint about some of the legal
things that are happening inthis space.
But certainly in the eu,there's an attempt to dismantle
apple's you know monopoly overthe app store, right, so that
you can actually get apps ontoyour phone that don't come from
the Apple App Store.
(23:54):
So it's something that the EUis trying to impose upon Apple.
You know the EU often leads inthese kinds of areas, so
typically the EU will dosomething first and then often
you'll find the United Statesfollows sometime later with
something similar.
So there's certainly an attemptgoing on right now to sort of
remove this monopolistic typenature that Apple has over the
(24:19):
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 Storewithout any other context.
That just sounds like a prettyhefty chunk.
It's a pretty good deal, Ithink, for Apple and iOS.
Hugh Williams (24:35):
Yeah, and they would say, of course, that
there's lots of costs in runninga store and administering the
store and approving things thatgo into the store and all the
services they provide and thephone ecosystem itself.
So they'll certainly tell youthere's a good reason for that,
but certainly it does feel likea 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 sortof legal and commercial elements
of this stuff, because tech canfeel counterintuitive in that
sense, like you get a lot forfree, and I once watched a very
sobering documentary where theywere like if you're not paying
for the product, then someone'spaying for you as the product,
your data.
Hugh Williams (25:12):
Yeah, absolutely Okay.
So no such thing as free intech.
Hannah Clayton-Langton (25:15):
Yeah, okay, so let's finish up with
back to some of this productstuff, which I know is your sort
of sweet spot.
But what's it like to build anapp?
We've mentioned a few of them.
I I think you talked about likeprototyping and testing, but
like what's the flow if you wantto get a feature onto an app?
Like it's kind of the productmanagement, but let's talk about
it specifically in the appscenario.
Hugh Williams (25:38):
One thing that makes building for the web and
building for mobile reallydifferent is experimentation.
So a lot of the very, verylarge companies and it's
probably true of even mediumsized companies these days do a
lot of experimentation on theirusers.
So, for example, if you'reusing Facebook, you are for
certain going to get a differentexperience in quite a few
(25:59):
subtle ways than my experienceon Facebook, and the reason that
that's the case is not justabout personalizing for you, but
Facebook wants to try out newfeatures, and that can be as
simple as things like changingvery subtly the colors of fonts,
the size of things, how big theX is for closing things, how
big images are all sorts ofreally subtle stuff and what
(26:21):
they're trying to do is figureout, in many cases, what drives
more engagement.
Ultimately, if the new featurethat they're testing drives more
engagement, then they.
If the new feature that they'retesting drives more engagement,
then they'll ship that out totheir customers.
That's a lot harder to do in anapp, because an app is something
that's produced and it's put inthe app store and then it's
downloaded onto a phone.
(26:41):
So it's a little bit more likethe 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 acopy and then you install it.
So that sort of fast testingand iteration is much, much
easier on the web than it is inan app.
So that's one of the really bigdifferences is apps are really
a little bit more waterfall.
If you like, you kind of buildit, you ship it out to the app
(27:03):
store, you wait some amount oftime until it's approved, ends
up in the app store and thenyour customers get to download
it.
The other thing I'd say aboutapps is that users tend to have
lots of different versions ofthe app, right, so you might be
one of these people thatreligiously updates their apps
whenever a new update isavailable.
Lots of people don't do that.
So having worked at lots ofthese tech companies, you will
(27:27):
find that versions from 10, 12years ago are still in use by a
minute number of customers.
So every version you've everreleased is probably being used
by somebody, especially whenthey're a significant fraction
(27:50):
of the user.
Traffic is another thing thatmakes app development really
really different to webdevelopment, where you know if
you go and visit the website,you're getting the latest
version every time you visit thewebsite, right, but that's not
necessarily the case when itcomes 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 pointof view sometimes it's really
annoying.
You can ignore a pop-up andthen you'll sort of keep getting
them until you don't have achoice is so valid because from
a user point of view sometimesit's really annoying you can
ignore a pop-up and then you'llsort of keep getting them until
you don't have a choice.
But would a company ever justdeprecate a really old version
of an app and not give the usera choice?
Hugh Williams (28:19):
They absolutely should Look.
I've worked at companies wherewe sort of forgot to do that.
So you know we're back in theearlier days of apps and we
haven't built that feature inand that app version has gone
out.
Right Now there's no way toactually deprecate that.
So I've worked at companiesthat have done that.
You regret that a lot later on.
So I'd say one of the bestpractices in app development is
(28:40):
to make sure that you have someway of deprecating the app,
which is as simple as when theuser opens the app you say I'm
sorry, but this version's beendeprecated.
Please download the latestversion, and then you're
effectively ending the life ofthat app.
And then you're making yourdevelopers a lot happier because
they're not having to supportevery single version of the app
that's out there.
You're actually getting rid ofversions that are reasonably old
(29:01):
and only used by a small numberof customers in your user base.
Hannah Clayton-Langton (29:05):
Okay, but presumably you risk there.
If you deprecate an app and yourequire someone to download a
new version, you essentiallyrisk them lapsing as a user.
Hugh Williams (29:13):
Yeah, that's right.
So you wouldn't want to do thatfor any significant fraction of
the user base.
But if we're talking fractionsof a single percent of users so
you've got 0.2 of a percent ofthe users on an app version
that's 10 years old then I thinkit's pretty reasonable in most
cases to say, hey, this isdeprecated, get the new version.
And of course you can upsellthe new version.
Right, you can tell them allthe great new features they're
going to get and give them areason to do that, and hopefully
(29:35):
most of those customers willstick.
Hannah Clayton-Langton (29:37):
Okay, that makes sense.
And is it possible to update anapp without requiring me to
install a new version?
I know at work we sometimestalk about like silent releases.
They don't need to know thatwe've changed tiny things in the
background and actuallysometimes you can draw too much
attention to something reallyinconsequential 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 theapp that you can later turn on
right.
So I could release an appthat's capable of doing some
things that the user can't yetuse, that's capable of doing
some things that the user can'tyet use, and then sometime in
the future I can communicatewith that app and I can tell
that app to turn on that featureand make it available to the
user.
So that's called an app flag.
The reason you might do that isbecause you haven't quite
finished what's going on in thecloud, so you haven't quite
(30:23):
finished the sort of behind thescenes work that needs to be
done.
Or perhaps you haven't quitefinished some of the
experimentation you're doing andyou're not sure whether you
want to turn that feature on orwhen you want to turn that on.
So the apps have lots of thesesort of secret app flags in them
that allow them to changewithout the user downloading a
new version of the app.
(30:43):
The other way to do it is tomake your app into something
that's a little bit more likethe web.
So very simple apps often arejust web containers, so they're
really a web browser.
You download it and you thinkyou're getting a really
sophisticated app, but whatyou're really getting is another
web browser that goes andretrieves web pages and shows
those web pages to you.
(31:04):
Now, obviously, if you changethose web pages, then you get a
very different app experience,and so that's another way where
you can really make an appchange pretty dynamically
without having to download a newcopy, because it's not really
the app that's changing, it's awebpage that's being displayed
within the app that's actuallychanging.
So there's ways to certainlywork around a customer having to
download an app and still havethat app evolve.
Hannah Clayton-Langton (31:26):
And, from a user's perspective, if
it's done right, does it sort oflook and feel like an app.
Hugh Williams (31:31):
I'd say no.
I think it looks and feels likebrowsing the web, so it doesn't
quite have the sophisticatedanimations and the deep
immersive experience, andperhaps it isn't able to access
in a really native way some ofthe sensors and features that
are on the phone.
So it's great if you just wantto display information Works
okay in shopping apps, forexample but if you're trying to
(31:52):
build a deep, rich, immersiveexperience you know something
like a Google Maps or a Stravaor an Instagram then you
probably want to build it innative code and really make sure
it's highly optimized and areally 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 themost is Spotify.
Everywhere I'm going, I've gotsomething in my ears, whether
it's podcast or music, and as aLondon 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'mlistening to something that I've
(32:25):
not downloaded locally, andsometimes I'll get like a few
songs or like another 10 minutesof my podcast, and sometimes I
don't, or like I'm not reallysure 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 towhat is caching.
So caching is about gettinginformation close to you that
you're likely to use again or inthe near future.
So a simple example would beimages.
So you're browsing on ashopping website, you're very
(32:58):
likely to go back to an itemthat you've seen, and if that
item is pictures, are storedclose to you or actually on your
device, you'll get a faster,more seamless experience.
So having those images close toyou is going to make your
shopping experience richer anddeeper and you'll probably buy
more stuff.
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 listento those again, and then also we
(33:19):
could do some predictivedownloading right.
So if I was at Spotify they'rea very sophisticated company I
would probably have the ideathat as a customer gets close to
the tube or as a customercarries out a predictable day,
so I probably know when I'mgoing to lose connection with
you and where you're going to bewhen that's going to happen.
Perhaps I'll be smart enough toreally slurp down the next 10
(33:42):
minutes of the podcast or acouple of songs, so that you
have a seamless experience andyou don't quit Spotify.
You know you're probablydelighted by that experience, so
that's exactly what caching is.
It's about getting things thatyou're likely to need in the
future, or storing things thatyou'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 themain points that I had, with
some teasers for future episodes.
It's been really great chattingwith you today, hugh.
Hugh Williams (34:08):
Thanks, adam.
It's been fantastic to talkabout apps with you and you're
right, there's lots of reallycool 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 onyour favorite platform.
We're also available onLinkedIn at techoverflowflow
(34:29):
Podcast, and you can find us onInstagram and X.
Hannah Clayton-Langton (34:32):
Awesome, so I'll see you again next time
, hugh, for anotherdemystification of technology.
I can't wait, hannah, see yousoon, see ya.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!