Expo – Open-source platform for making universal apps for Android, iOS, and web
github.com
github.com
It was our experience the expo layer added a lot of complexity and many bugs, with very little ability of users to actually fix anything without "ejecting" their project away from that ecosystem. That was on top of the RN layer, which in itself was full of bugs. We would send users to report expo bugs to the expo team, and were first met by "just fix it on your end, you are detox!" type of comments from that silly community, and those that did report the issues, saw no reaction from the expo team, despite detox being one of the most popular testing frameworks in the RN world at the time (no idea about now, but back then, even Facebook was using detox to test RN itself).
At the end of the day, we decided the hassle was not worth the low quality user benefit, so we decided to drop support for Expo. It was one of the best bureaucratic decisions we ever made.
This is at the core of my difficulty with cross-platform frameworks for Android and iOS. Dealing with the first-party stack presents enough problems on its own. Adding more layers to that easily compounds the frustration involved in getting anything done.
Tried at the time Xamarin and PhoneGap, and bit later RN, each one has his quirks and things that works in one platform but not in other so in the end you end up building one app for each platform more or less, but with more bugs than the official ones.
It’s more web than RN and depending on what you’re doing might not feel as native, but it’s pretty easy to make a solid app with it.
I find most people making this argument haven't worked full time with one or the other.
If you're a larger company who can afford two teams/groups, or if you are working on something lower level like OpenGL or ML, it makes sense.
Having done both for multiple years, I can't understand when people think it would be faster to build separate apps. It's not even remotely close. You're swapping out doing bug fixes, platform specifics like push notifications, the occasional separate UI implementation, and distribution twice with doing _everything_ twice.
So when people talk about cross-platform on the Mac, for example, it's always some JavaScript abomination, or Java, or Delphi (yes, seriously), or Go.
How about going the other direction and getting Cocoa running somewhere else? GNUstep, Cocotron etc. Gosh, that would actually make sense, can't have that. Literally.
In fact, one company did. Apportable. Google bought them and buried the tech.
Hmm
There’s definitely a huge learning curve and some rough edges, but the speed with which I can write a polished UI in it is staggering.
The problem isn’t that middlewares are bad. They are great: Unity and Unreal, your browser, Java…
The problem is mobile apps don’t make money. Games and web services do. The OP is talking about low quality users. They’re broke! They’re not incentivized to fix their own problems either! It’s all just a blub for them. So middlewares improve for the audiences where they’re at least viable, and stagnate when they support something that no one should be bothering to do in the first place.
Previously, much of my draw to things like Expo has been the reduction in mental load for handling multiple different platforms. In theory, they're built by people who know the different "gotchas" and can help me avoid them.
In practice, something always requires you to dive into the underlying layers. At which point, you're just fighting with bug-filled abstractions.
If you have react experience I really suggest giving modern RN & expo a try.
Relatedly, the developer demographic has grown and a lot more developers are adding Kotlin and Swift to their skill sets. They write JS and React most of the time while also writing custom native code when they need to. Most of the best Expo apps include custom native code.
Test frameworks have also grown a lot. I suspect the issues with Detox were often from developers looking to use it with the Expo Go starter app that doesn't support custom native code. These days I hear a lot of positive things about Maestro as well and there was a nice talk on it at App.js Conf earlier this year: https://www.youtube.com/watch?v=uoCzBdFCoqc
I'm glad to hear the tech and, more importantly, the community have improved.
By "layer", I mean custom controls and animation toolkits that get bundled in an Expo-enabled project. Those are in addition to the RN-provided ones. It all adds to complexity.
There are also no custom UI controls or animation libraries bundled with Expo. The Expo Go starter app includes a preset SDK, and when developers create a build for the app stores or a development build of their own app, only the libraries they use are included.
IMO it would be a meaningful improvement for the react-native package to provide the minimal runtime needed, namely JSI, Hermes, Turbo Modules, Yoga, Fabric, and perhaps a few primitive view components like View, ScrollView, and Text. The package provides more than a library needs. Animations and gestures today are better served in my experience by modules outside of the react-native package, like Reanimated and Gesture Handler that use truly native gestures. React Navigation uses the system navigator UI and Expo Router adds file-based routing and universal links. Expo Image adds support for modern image formats like AVIF and WebP and uses mature, performant image libraries like Glide and SDWebImage. So there is definitely still work to be done that can improve quality and reduce complexity in RN.
Sounds like I s gotten a lot better and found an actual usecase. I'll have to check them out again.
- Generally a poorer developer experience (bugs, bad documentation).
- Couldn't use some popular/common react native packages. It needed to be compatible with Expo, and there was an expo specific version to use the camera for example. These would have different (and more) bugs. Trying to use any unsupported packages meant ejecting, a hell that might be similar to ejecting from create react app or using craco, perhaps.
- Wasn't really adding much apart from being "all-in-one", but unfortunately each piece was sub par to the original react native.
- Unfortunately the react native docs were defaulting to suggest using Expo. They still do that now: https://reactnative.dev/docs/environment-setup. And yet developers often eject from Expo, so you'd rewrite the scaffolding of your app without expo instead of ejecting. IMHO that's quite sad to see the React Native docs still suggests Expo.
Side note: I've been using Flutter for a few years now, much better developer experience. Doesn't have code push yet, but https://shorebird.dev/ is working on it. (I am not affiliated with them).
But make no mistakes that Expo is a SaaS with the ability to inspect some part of the codebase.
(I stand corrected here) ~Everything important for building and distribution process is moving to EAS, cloud-based service that is not open-source and cannot be self-hosted. So if want to build your app using your own VPS, you are out of luck (at least for Expo managed workflow).~
Again I'm happy with their service and probably would pay for it when the time comes, but the open-source part is not really the big selling point anymore.
I mean that's the case for the 'regular' React Native workflow as well, and most mobile / crossplatform development. That said, yeah getting RN running is a bit more effort compared to Expo, but it allows for a bit more flexibility.
We decided against using Expo because we had a number of 3rd party dependencies (trackers, analytics, chat, sigh) that had native components; it can work with Expo, but the dependency has to implement support for it, and that was a bit all over the place.
Is the build job also open source somehow?
The hosted services offered by the Expo team called EAS has an implementation of an updates server that conforms to that protocol. If EAS went away or you wanted not to use EAS, you could write and operate your own server that conforms to the protocol instead.
The Expo framework gives you the module system, runtime environment, CLI tools, debugger, a suite of modules, navigation to build universal native apps. They're universal in that there is an Android build, an iOS build, and a web build, and, especially with Expo Router, they work together with universal links. They're native in that the user experience is native to the underlying platform, usually using system UI components and behaviors.
EAS provides hosted services for building your app, submitting it to the stores, and updating it. Many developers will use both EAS and their own hardware. It is convenient and fast to build locally when iterating on a feature. And it is convenient in a different way to use EAS to make preview builds of your app on your PRs that change your app's native code or to make release candidates for production.
However, as a user reading the Expo docs, I'm not sure if I can separate them easily without deviating from official docs.
Look at the Expo docs on building and deployment, which are essential steps to getting your app distributed. I don't see any mention of how to achieve it without EAS.
There used to be an expo build but it was deprecated a while ago.
https://docs.expo.dev/develop/development-builds/installatio...
"npx expo prebuild" (covered in that link) is a good command to know. It generates "android" and "ios" directories with your Android Studio and Xcode projects, respectively. These projects can be built entirely locally and there is no dependency on EAS.
As a side note, the old "expo build" command also ran on hosted servers. It was part of the old Expo CLI, which, for historical reasons from six or seven years ago, didn't separate the free & open source Expo framework from the hosted offering. We built EAS years later, with a major new feature being support for builds that have custom native code. Keeping EAS decoupled from Expo has been a conscious effort, and we've also designed EAS to work with any React Native app whether it uses Expo or not.
Then again, I can understand why it isn't a priority for the company.
My advice these days is to go in one of two directions:
- make a progressive web app. No, it’s not a native experience. But if your priority is cross platform then this is cross platform. Service Workers etc make it a ton more paletable than it was back in the day.
- make native UI and code your business logic in some kind of shared layer (Rust, Go, Kotlin Multiplatform). Native UI has come a long way too, as someone who speaks webdev I find SwiftUI and Jetpack Compose to be very grokkable compared to their predecessors, a lot like React if you squint a little.
True native development is, indeed, much better. But a small team will be hard-pressed for doing good work on both platforms, especially once you start fiddling with more important APIs. Configuration and getting your system to compile things to properly is almost a job in itself. Sigh.
KMM, Flutter, and MAUI are all promising, but with different trade-offs.
So we’re stuck with RN/Expo… At least Expo promises some stability between upgrades, by handling the package compatibility checks for you. Well, when it works.
“Make a progressive web app”: yes, that might be the way to go; provided you can get the users to ‘install’ it on their devices. For some companies that’s not optional due to different pressures (e.g. teachers would expect students to have our app installed on their phones).
Neither of these 2 solutions is that simple. There are trade-offs involved, and each team must compromise where they can/are weaker. All in all, if you MUST do RN, at least Expo saves you a lot of headaches with config/build/compatibility. It’s mediocre, but worlds better than pure RN (at least for me).
Sounded like a preferable approach to dealing with the complexity and limitations of RN and multi-platform. I wonder why more teams haven’t gone with this type of approach…
https://standardnotes.com/blog/react-native-is-not-the-futur...
Assuming you're talking about the not-well-known process of adding PWAs to the Home screen, it's worth noting that you can package web apps for app store distribution as well. https://capacitorjs.com/
Thanks for the tip tho :)
I wish things were different. It would have saved our company almost a year's worth of development on a pwa.
The story on iOS is much worse, naturally. But if you can get past getting users to actually install the app the rest of the experience is acceptable.
If PWAs were actually used by the mass markets, I'd go with that option, but the fact is they're not, and you can't expect to force your users to learn a new behaviour like that.
Maybe I'm too optimistic but as a web developer I loved being given the opportunity to learn some Swift and Kotlin. Compared to Objective C and Java they are really very approachable for JS devs and with not all that much work you'll end up with a deeper bench of developers more satisfied with their jobs.
Almost all of the best apps made with Expo also have a small amount of custom native code. And I find it's just generally good to understand the abstraction layer above and the abstraction layer below the one you're working at to bring the two together the best you can.
[development-builds]: https://docs.expo.dev/develop/development-builds/introductio... [expo-modules]: https://docs.expo.dev/modules/overview/
The best Android app for a product I've used is the AnonAddy app. It's stylish Material You while feeling very custom and tailored.
For instance, navigation is one of the more complicated parts of an app's UX. The navigator UI has many subtle behaviors and animations that have been built over the course of several years, like how the back button and screen headers transition in and out. The gestures often have invisible hit boxes that are hard to replicate without using the system UI components. The screen transitions use specific animation curves users expect. And there's non-visual behavior like supporting universal deep links that take the user to a specific screen, which tends to require quite a bit of work to implement.
Expo uses the system UI components and the behaviors described above are present. The goal is for Expo UI to be native UI. And in some aspects, Expo can already provide a better default user experience like with universal links. Every screen gets a URL with Expo Router since URLs are a first-class concept, like they are on the web. This lets us provide deep linking (navigate from URL to a screen) and universal linking (HTTPS links work across web and native) as default features.
Sometimes the way we talk about Expo is that it brings together the best of native and web, and a lot of that is the user experience of native applications with the developer experience of the web.
As an example, some time ago, it was impossible to implement those iOS large headers that shrink to small once you start scrolling. Even though they were de facto standard in iOS for years already. Also the heavy layering of modals introduced in mostly in iOS 15 were basically impossible. Plus they heavily rely on subtle transitions like the 2nd layer scaling down, moving back and top edge peeking out at the top, so that the user gets a hint where they are in the hierarchy... Not sure if all this stuff works now, but generally Expo & RN were very slow to catch up with iOS and you had to rely a lot on dubious libraries, ending up with messy patchwork.
All these minor details are extremely palpable, even by standard users, and the experience just always feels a bit off.
Stuff like the iOS 13 page sheet modals being broken is still an issue - but there’s a set of present/dismiss callbacks in the modal manager you can override in your code to fix it
Not sure if you meant page sheet controllers for iOS 15 (the ones that let you pin it half way up). There have been implementations of this, but they all suffered from a kind of crappy animation when you overstretched the page past its allowed limits. iOS would normally force a layout, then animate between the last layout and the new layout. But since RN’s layout is asynchronous, iOS couldn’t perform the animation and it looked sloppy
The measure function you mention isn’t co-ordinated to the layout, so you could read it while a layout is pending and get old data - but that doesn't really matter for most cases
May I ask, does the New Architecture and Fabric not solve this problem?
In contrast, 2D UI frameworks like Flutter, Silverlight, and Flash replicate the system UI. In my experience it is possible to create a replica that visually looks like a pixel-perfect match but it is very difficult to make the replica behave the same, like the rendering the subtle layer transitions you talked about, invisible boundaries around gestures, and showing the navigation history stack. It is an uphill task and using the native system UI is a tailwind for Expo.
eas build --profile develop --platform ios --local
... now looking more into it, I probably mistook `npm run export` / `expo build` with `eas build --local`. Is this correct?
Perhaps the issue you're thinking about was what I linked to in my other comment?
By my own thinking, I believe it's quite unlikely that Expo will ever manage to actually totally remove support for local builds, even though they probably will never encourage it; as otherwise, its really quite impossible to debug native builds, and indeed local builds are Expo's recommendation for debugging such issues. With regular React Native native dependencies now possible in Expo, a dizzying new array of hard to diagnose bugs can now be triggered, and its unlikely Expo is ever going to go back on their support for arbitrary native dependencies.
Turns out the client needs an --offline flag to so so, and I got a bit creeped out to have such a dependency.
Expo Go is entirely optional and it is recommended to graduate early on in your development cycle to using a development build of your own app instead. Development builds don't sign project manifests (unless you're intentionally using end-to-end signed updates, an advanced feature). They are like regular development builds of a traditional native app.
Also if you'd like to keep using Expo Go, the signing certificate mentioned earlier has an expiry of 30 days or so IIRC, during which time you don't need to connect to a server. You may still want to provide the "--offline" flag to turn off refreshing the certificate.
Being able to build your app on your own hardware is a relatively fundamental feature of any application software framework. The Expo framework is free and open source and we consciously keep it decoupled from Expo Application Services (EAS), which is a suite of hosted services we manage.
Two of the ways to build your app are: - Entirely locally, without EAS: generate your native Android and iOS projects with "npx expo prebuild:{android,ios}" and build your app with Android Studio/Gradle and Xcode/xcodebuild, respectively. - With EAS: after getting set up with EAS, installing EAS CLI, and configuring eas.json, run "eas build". There is also a "--local" flag that runs the compilation steps locally and uses your signing credentials managed by EAS.
Many developers use a mix. For instance, they'll build locally when working on a feature for a fast feedback loop. And they'll use EAS to build their release candidates and PR previews to share with their team.
My full build process is somewhat more complicated to keep my $HOME clean and remove other impurities, but just these patches should be enough to enable offline building.
Expo CLI is for entirely local builds. Run "npx expo prebuild:{android,ios}" to generate your Android Studio and Xcode projects, and build them with the IDEs or their respective CLI tools directly.
The managed services (EAS) are optional for Expo apps. The independence between Expo, the free and open source framework, and EAS, the hosted service offering, is something the Expo team consciously works on.
However, making your apps depend on a framework has the following dangers:
- the framework might stop being maintained
- the vc-backed framework might need to become monetized beyond your means
At the end of the day, all these frameworks offer are convenience APIs to easily integrate with native things like push notifications or social sign-ins
However, even when these work, they will force you to do things their way, and you won't be able to fully customize your app
Learning how to do these things natively in iOS and Android requires extra effort but pays off in the long term. Using frameworks, the time saved in the beginning of your app development journey will be greatly offset by the extra time required to do things like editing framework output in each build towards the end of your journey
Also from the beginning we believed the Expo framework needs to be free and open source. Introspecting as developers ourselves, we thought people would be a lot more likely to try out and recommend open source frameworks and incrementally build up an ecosystem of modules and StackOverflow answers. Expo gives developers much more agency because it is open source. And it is really hard in my opinion to make a business from licensing developer tools, libraries, and frameworks. There are so many free alternatives.
The goal of the Expo framework is to be the ultimate way to build universal, native application software. Universal apps have builds for Android, iOS, the web, and future platforms. And the user experience is truly native to each respective platform, often by using the native system UI components and not a replica. It does take significant effort to maintain the Expo SDK's set of convenient APIs. It's also just one part of Expo overall.
Separately, the way we are building a business is by offering hosted services for React Native apps, called Expo Application Services (EAS for short). These are optional services for building and updating your apps and using the Expo framework doesn't require EAS. We find developers often use a combination of EAS for some tasks and their own hardware for others.
We work to build developer trust. We are a small company but try to serve developers and our customers well, sometimes better than the companies that have endless trunks of money (we've all seen killedbygoogle.com). So, that's some of how we think about things at Expo.
For everyone that tried it in the past and has been reluctant due to the "old Expo" of the ejection days, you definitely need to give it another try. In the industry we're in, we all know technology changes rapidly, so to not adjust your mental model after 5 years have gone by is doing yourself a disservice for sure.
The RN template upgrades are painless. It enables you to develop on any operating system, which is a big forgotten perk. You can build in the cloud if you want, but you can also build locally (via EAS or the RN cli, this is important Expo apps are RN apps and vice-versa).
Need to drop into Native code? You can do that very easily now. It's not a show stopper. Need to whip up a quick demo app for a presentation? It works there too.
Oh yeah, do you find the app store dashboards painful? Send it over with EAS Submit all via CLI. You can even set this up in your CI if you want.
Preview PRs on release channels via EAS Updates, also amazing. Your QA will love testing features in isolation. Your management will love having the product testable on their devices and you won't get bogged down when they want to see the latest and greatest for some demo you don't need to be bothered with.
The team is made up of incredible, hardworking people who want the best for the native application scene. They want the best for your development team. And that's awesome!
I'm not there yet but totally intended to try putting Clojurescript and Expo together. Too many ideas require apps and Clojure is too great not to take with me yet I wouldn't do apps without Expo.
Exciting! Thanks for sharing!
I'm on re-frame too and that's been a dream.
I just wish I had a better UI lib on the (web) frontend. I went with re-com and it feels a bit half-done, though it's working for all my needs so far, I might just sending PRs if it comes to it.
1. I can't get a debug build of the app without using their cloud services.
2. Latest version of Android app to preview Expo apps did not work with latest stable Expo version.
3. Random build errors all the time due to some features being deprecated without being mentioned anywhere.
4. Tries to do too much and breaks quite often
This is the impression I've gotten recently testing their waters. Overall, my take has been to stay away from it unless the app I'm making is simple enough they have templates floating around the web and won't need further tweaking: similar to wordpress, great to have a certain type of app up and running fast but the minute you have to do extensive work on it, you'll wish death on it.
My primary issue with it is the lack of support for in app purchases (last checked in late 2022).
The only easy way to do it is via RevenueCat, as none of the other RN IAP libraries work with Expo.
Expo also has built in support for over-the-air updates, which is great. However, it is a paid product, for $5/m per 1000 users (first 1000 free).
I believe you can run your own server for OTA updates, but it's fairly obvious that this feature will eventually be removed when they need to monetize harder.
The ability to write and run your own update server is a part of Expo Updates and it is not going to be removed. The Expo Updates protocol is an open specification here: https://docs.expo.dev/technical-specs/expo-updates-1/.
Separately, EAS provides an optional, hosted service that implements the server side of the standard Expo Updates protocol and supports both simple and more advanced deployment patterns, for instance: https://docs.expo.dev/eas-update/deployment-patterns/. It also integrates with EAS's build service and appeals to teams looking for managed cloud infrastructure.
I wrote and released an iOS and Android app a few years ago and used Expo for ease of cross platform and the hosted build system.
I don't use all the fancy OTA updates and what not, but I can definitely recommend Expo as both a beginner to RN and beginner to iOS+Android app dev.
Additionally, I think RN has come a really long way from where it was when Expo first came about. Expo sought to smooth over a lot of rough edges, some of which no longer exist.
I think Expo realizes this as well, as their main revenue generator is now their deployment tools. The framework is opinionated toward using those paid services, which my org doesn't want to use as we already have processes for building and deploying, which makes working with it cumbersome.
Using Expo without EAS, the paid services, is definitely supported. The Expo framework is free and open source and is designed to be generally decoupled from EAS. "npx expo prebuild:{android,ios}" will generate "android" and "ios" directories that can be built with existing build processes.
Expo: free and open source framework. Includes Expo CLI, Expo Modules, Config Plugins, Expo Router, debugging tools. EAS: hosted paid services. Includes builds, submissions, updates, credentials. Works with any React Native project whether or not it is using Expo.
Things we love about the expo ecosystem
- React Native upgrades are much less painful if you use prebuild. Upgrading the expo SDK takes care of most things for you
- EAS makes distributing and managing certs incredibly easy
- Most expo packages (like expo-camera, etc) are some of the best out there and very well documented and supported
- The Expo team is incredibly talented and always willing to help if issues arise.
I’ve used Expo modules and services at both Tesla and SpaceX for building large scale apps. I’ve consistently found that their modules are some of the best maintained in the ecosystem.
One of the biggest technical risks we face is building a feature around a module that is later abandoned. Using Expo, we don’t really have to worry about this. Web support is also a huge plus (web support in other RN packages is hit or miss).
My poor understanding is that React Native, and hence Expo, doesn't use the same CSS frameworks as web development. I'm curious how that works from the same code base, or perhaps that's one of the major difficulties.
Also I see Expo as a fancy build framework but it's still fundamentally a RN application. Is this correct?
(My front-end colleagues are on another continent and we don't get any water-cooler time. Sorry for the possibly awful questions.)
I’ve never used Expo, React Native, or Flutter so can’t speak to those but I’m pretty happy with my setup. Yes I have to put a tiny bit of logic behind checks for if I’m on the web or if I’m in an app but it works surprisingly well overall IMHO.
[0] - https://solito.dev
[1] - https://www.nativewind.dev
[2] - https://tamagui.dev
As for the CSS part - yes, React Native uses order for priority, web CSS uses specificity. None of the attempts to get the RN way working on web were amazing
Expo aims to abstract away everything that a web developer wouldn't inherently understand when moving to mobile, i.e. the native stuff. Whether or not it succeeds in that mission, or if it's worth it, is up for debate.
I was afraid because of the Angular roots but the docs (and typescript support) are top notch for Angular/React/Vue.
I could basically transfer all my Vue knowledge (and code).
I was focused on native Android development (Java/Kotlin) for many years. React Native (I first used in late 2016) and Expo (I first used it in production in early 2020) have matured so much over the last years and all the Expo tooling is a game changer for building (cross platform) apps.
A few examples of how Expo has changed the game: - The Expo Go or Expo dev client make it possible to no longer need XCode or Android Studio during development and thus make it much easier to bring engineers onto a project who do not necessarily have mobile dev experience. The dev client can be built locally by one engineer and shared with the team or can be built in the cloud with EAS Build. - Upgrades in bare React Native projects used to be painful and time consuming. With Expo prebuild, one can (re-)generate the native projects at any time including after upgrading to the latest RN/Expo versions. Further this allows having to never source control the iOS/Android folders. - Expo config plugins have made it possible (and really straightforward) to apply modification to the XCode/AS projects such as adding permissions or adding extensions. Requiring modifications to the XCode/AS projects used to be a reason for having to use bare RN / eject from Expo. - The Expo Modules API has made it really simple to create a library project and allows for writing the native code in Swift/Kotlin. Setting up and maintaining a RN library used to be a lot more involved especially if it was small and not touched very often. - The entire Expo EAS offering basically provides you with what normally a mobile ops time would provide - builds in the cloud, app store submission and ota updating. For anyone who has set this up with Buildkite/App Center/CI tool knows how much time this could cost / take.
And these are just a few things that are top of mind.
It is my experience that using Expo + dev client, allows me to bring together a team from all backgrounds (iOS, Android, web, backend) and quickly get everyone up and running, contributing and have impact.
The first product I built with Expo was HowWeFeel (April 2020) and with a small team we shipped the initial version iOS, Android and web in less than two weeks. The most recent product is Pinterest TV Studio and because of Expo/RN it is feasible for us to have it not only available for iOS but also Android.
I'm excited for the future of Expo and curious what will drop during launch party (August 8th).
I have worked across these frameworks and React is the only one where I find the lib ecosystem satisfiyingly large (and still growing most steadily).
[1] https://npmtrends.com/@angular/core-vs-react-vs-solid-js-vs-...
(Disclaimer: I use Expo at work for cross-platform app including web but never wrote my own plugins)
With the "prebuild" workflow you can regenerate your iOS and Android projects anytime you need. And set up scripts for adding external libraries in the process.
It is more work to set up over just altering the native projects, but the result is rather nice.
I've never felt 100% confident that react native project folders wouldn't break for arbitrary reasons. Being able to so easily start over is very useful.
Maybe that's better now?
This is in contrast to an IPA or AAB file which can be deployed to a device or distributed to an App Store.
https://expo.canny.io/feature-requests/p/expo-sqlite-ship-ne...
RN is amazing for the business, especially small businesses.
Yes it’s full of quirks and yes it’s never perfect but if you’re a small to medium size business trying to get your app to market as cheaply as possible, there is no better option than RN right now. Maybe flutter.
If you want a web-like platform on which to build a cross-platform application, I recommend Flutter. It's not perfect but, it's better than all the other alternatives I've tried.
Likewise, with Expo it's easier to do code push, that is, just release a new JS bundle for over-the-air updates without going through the app store. Again, this is possible in RN as well, but it's a bit more involved.
Finally, Expo allows for easier (internal) demos; anyone with the Expo app installed can scan a QR code during your internal demo to install the app over the air, again without having to go through app stores. This can score you points depending on where you work.
Personally I'm still convinced 'real' native apps are better, but few companies want to invest in development & developers for that. My experience with React Native (not Expo) has been positive so far though, with very little issues between iOS and Android - actually, for me personally it's mainly been figuring out how to install custom fonts (custom fonts and Font Awesome for icons). I hope to not have to touch that again, lol.
I'm considering RN right now. Wondering whether to start from scratch or not. People refer to issues "ejecting" from Expo but those issues are vague and go back years.
Any concerns or experiences on your end that make it a good or bad option?
But still, upgrading SDK versions to stay on top of security/new features can be a burden with how many breaking changes there are.
I use it for the Rust (video game) companion app, using the stock libraries bundled within Expo so development is a breeze.
That is great because those project folders are usually quite fragile and can easily break over time.
Before "prebuild" was introduced, you had to stick to expo-included native modules to get that advantage, and if you didn't, you had to "eject", which was hardly better than not using expo at all.
With "prebuild" you can use any native module and still have a git repo free of those fragile iOS and Android folders. It is more work setting up those modules, but it's worth it IMO.