So now that have we learned about all these alternatives,
the obvious question is, which approach should you use for your application?
Now I think throughout the course, you saw that using expo in general is an awesome development experience,
everything is super fast, it's easy to test changes both on simulators and real devices.
You don't need to build locally,
therefore you can also build and test for and on iOS, on Windows systems and Linux which is not possible
without the managed workflow
and that's all pretty cool.
But when we compare expo to non-expo setups and with non-expo, I mean both creating it with React
Native CLI or using a bare expo workflow,
then of course we have to compare all the things.
So as mentioned with expo, with the managed workflow, it's easy to use that, easy to develop, non-expo
means more manual setup and so on.
Now you also will have an easy time deploying your app as you will also see in the deployment section
and you can even build and deploy for iOS if you're on the Windows or Linux machine, something which
is not possible without the managed workflow.
So there, you have some restrictions there and deployment as you will see also takes more manual work,
like the non-expo workflow does in general. When in the expo managed workflow world, we also have a rich
suit of native modules,
so all these expo APIs which are always easy to use, just an expo installed away, don't need any
setup
so that's really amazing and you got pretty much everything you could want in a native app there -
camera, location, filesystem, it's all there.
If you sometimes need something which is not supported though or you need to write your own native code
that you want to connect to React Native, your own package or whatever it is, then non-expo is the solution.
So there you can use any native code but of course, you need to set it up manually and that might be
easy with React Native link as you saw or even some autolinking libraries but you might also have libraries
that take more effort.
In addition, it's worth noting that of course third-party libraries need to be maintained to stay up
to date with React Native and newer versions of React Native but also they need to stay up to date with
Android and iOS,
right,
because these platforms also evolve and introduce new features or deprecate old features.
The expo APIs are pretty guaranteed to be maintained because the expo team is active, is working
on that and it's a whole ecosystem that works together.
That might not be true for all third-party packages,
so this extra security you get with the expo packages is definitely pretty nice.
That being said as you saw with the bare workflow, you can of course also add certain but not all expo
APIs to non-managed apps,
that is possible but takes a bit more work. Now of course the managed workflow has downsides,
it's a wrapper around your app and that of course impacts both the size and performance,
most likely not in a way that you will feel or see but it's worth noting, there is a thin extra wrapper
and you don't have that in the bare workflow or when just working with the React Native CLI
and of course as mentioned, you're restricted to the built-in native modules.
There are a bunch of those and probably everything you might ever need
but if you need something else which is not built into expo,
so an API which is not supported by expo, then there is no way to get it to work,
then you need to eject because only non-expo
and with that I mean non-managed workflow apps support all third-party packages and all native modules
you might want to use.
So therefore my suggestion would be that for most apps, pretty much all apps probably,
you work with expo because of the great development experience and the great flexibility you have there.
Since you can always eject, there there's not much to lose, you can always go back to a non-expo managed
app if you want to
as you saw, starting with such a non-expo app,
so with a bare app or even with just a React Native CLI app is a good idea
if you know that you will need a lot of native functionalities that are not supported by expo or if
you're building a high performance application where every kilobytes of extra wrapping matters,
then of course you might start with such an app but otherwise I really see no strong reason for why not
to use expo
and especially if you're not working in a huge team, in a corporation or anything like that,
being able to build iOS apps on Windows too is really a nice thing,
so that alone is also good reason for staying in the managed world. So that are my two cents on that,
since you can eject,
it's not like you have to stick with one solution
if you start with it, just going back from the bare or the React Native CLI only setup to the managed
workflow is a bit more tricky because there, you need to create a new expo managed project,
copy over your code and if you did use any third-party libraries that are not from expo, you won't be
able to use them anymore.
So switching back can be hard,
switching from expo managed to expo non-managed, that is pretty easy with ejecting.