There also are more things you can set up of course,
one thing I want to dive into are the over the air updates though which you control with the updates
key in the app.json file.
Now that's a neat feature, which means that people running your app on their device no matter if it's
just running in the expo client because they scan such a barcode which as I mentioned isn't too useful
or if they really downloaded it from the app stores,
as long as you build your app in the managed expo workflow, you get the over the air update functionality
built in and that means that if you change something in your code, let's say here on this screen we change
something, we change some titles, some functionality or we even add a brand new native module,
no matter what you do, whenever you publish this update with the expo publish command, all your users,
even if they installed the app from the app stores will get this update in their app the next time they
open the app
and that's important. You can configure the functionality here in the updates key. Again in the official
docs, you learned more about this update key and what you can set there. What you can set,
for example is if it's generally enabled which by default it is
and with this fallback to cache timeout thing, you can configure how long the app when users launch it
on their device should check for updates and try to load them before it displays the recent available
version. By setting this to zero, you're saying whenever the app launches, it immediately displays what
it has. It looks for updates behind the scenes and for the next launch, it might then take them into account
but it doesn't try to look for updates and download them before actually loading the app.
Now you could change this to let's say five seconds,
this is a millisecond value, so five thousand milliseconds which is five seconds.
This would mean that when people launch the app, they will see the launch screen for up to five seconds
which is of course quite long because after loading everything else, expo or your app tries to look for
an update and if it finds an update, it tries to download it and take it into account.
That might be done in five seconds, it might be done faster in which case your app will also launch
faster but if it takes longer than five seconds, then it'll continue with the updating but not immediately
load it but instead load the most recent version that is available. Now it's of course up to you what
you prefer,
this approach makes sure that users have the fastest possible startup experience but they only get your
updated code the next time the app is launched.
This approach or setting this to an even higher value like 10 seconds means that users get newer versions
more frequently or quicker because they get it on the next app launch already
but the downside is that the app launch might take a bit longer, which is maybe not what you want.
So it really depends on which type of app you're building and which type of users you're targeting, what
you want to set there.
If it's a business app let's say which you distribute to your employees which needs to be updated all
the time and where the user experience is not that important,
you might want to take a value like 10 seconds here,
if it's an app you share with normal end users around the world, you might want to go for a faster start
up time to provide a good user experience and sacrifice update speed for that,
so users would then only get the update on the next launch after this launch.
With all of that out of the way, let's actually have a look at all of this and also at this over the air
update feature.
I changed a couple of settings here and therefore what I'll now do is I'll run expo publish again,
still that's the command which will not get it in the app stores but which will share it
here on this expo page so to say. So I run this command and we could have still optimized our assets
with expo optimize
but since we don't really have images included in the app other than the icons here which are generated
and optimized by expo anyways, this shouldn't be a problem,
so I can just run it like this and wait for this to complete and then I will test this on an Android
device because there, the advantage of course is that we can use this barcode here.
So now once this is finished, the cool thing is we'll immediately have this new app available by scanning
this barcode and thereafter, I'll show you how we can get over the air updates without even scanning
the app barcode again because that's the idea, we get any updates without scanning again,
it's pushed to our app the next time we launched the app. So let's wait for this publish process to
finish and the URL is still the same as before because I haven't changed anything about my slug here
which is part of the that URL or anything else.
So now here's the expo app on my Android device where I can now scan this barcode and therefore now
the app launches here on Android. Now you see I got the splash screen, I got the app running here and I can
of course also use it, for example I can take an image here. So that all works the way it should work
on my device here
and now let me show you this over the air updating functionality.
See that add place title here at the top?
Now let's change that in our code.
So let's go to the code here
and on the screen here in the new place screen where we set this title,
let's change this to add new place,
it's a tiny change but still.
So now if I run expo publish again, this app will be bundled up and will be published to
the expo servers again.
So let's wait for this process to finish and it's done
and now let me show you this live updating.
I still have the app running here,
so of course this does not change whilst the app is running, so of course here we still have the old title.
But now let's say I was away quite a time,
I closed this here and now I relaunched the app.
If I now go to the new places screen, I still see the old title.
Now that makes sense if you think about the updating strategy we used.
I made sure that the app launches as quick as possible and downloads a new update behind the scenes,
so that's what happened
now, this was the first relaunch of the app on my device after updating it.
So let's say I'm again away quite some time and I relaunch it again, by the way here you can see the
adaptive icon in action.
Now if I go to that screen, you'll see add new place as a text because now this is the second
launch after the update. In the first launch,
we downloaded the update and installed it so to say, in the second launch we're using it.
Now the app on the device technically didn't change, just what's in there changed, our Javascript code
changed and since we have this expo wrapper, this means that expo can take this into account and use
this new code
and this will also work if you publish your app to the app stores because there whilst you will build
a standalone app and people won't need the expo client, you will still include that expo client app into
your standalone app
as I mentioned earlier,
so your standalone app kind of has the thin expo wrapper the expo client built in and wrapped around
your app,
that's why over the air updates will even work there.
And speaking of that, we now test this a lot,
we tested this all with just expo and with scanning the barcode.
Now let's dive into how we can really build this app and publish this app for the app stores.