A caveat before starting, my interest in mobile apps has always been what you might call "utility" apps. So not games, nor apps that are super heavy in multimedia, or games. Apps that, broadly speaking fetch, store or retrieve moderate amounts of data from a rest (or Graphql) API, with maybe some images (or shorter videos) thrown in.
My first experiments with mobile apps (back in 2016/7) were with the Ionic Framework. This is a variant of Angular. At its core, Ionic just renders a browser on the phone (so, Safari for iOS, Chrome for Android) and then renders html components within that browser. Originally ported from PhoneGap (which I originally think was an Adobe project), it was for the first half of the last decade a pretty revolutionary way for developers with a web background to sink their teeth into the nascent world of mobile app development. However, the performance was bad, it was particularly hard to achieve consistency on the variety of android devices that are out there, and I found that the review teams at Apple tended to reject apps (on account of them looking too much like websites).
- Learn React for the web before attempting React Native
React Native was quite an uphill struggle for me when I eventually picked it up instead of Ionic. I tried to learn it before having much experience with ReactJS on the web. This was in hindsight a mistake, particularly at the time the ReactJS web community was much more established and it would have been much more gentle learning to first master the principles of ReactJS on the web first.
- Use Expo as much as you can
Another mistake I made back in 2017-8 was to default to building "bare-bones" React Native apps, using the "react-native init" command rather than the build management system of Expo.
At the time, this seemed sensible, there were just too many limitations on the packages you could use with Expo and the apps it built were massive (I think my first iOS build attempt was > 100MB for a super simple app).
They have also done a pretty good job of vetting many of the community libraries for react native and documenting them on their API Reference. This is great because one of the most time-consuming things about third-party React Native libraries is knowing how compatible and reliable they are likely to be in advance of installing them, them building an app and testing them on real devices. Getting quick feedback to clients on this, especially at the planning and budgeting stage of building an MVP is always super helpful, and the Expo Community is great for weeding out bugs.
Finally, the Expo notifications module is great. I've had good experiences using Onesignal as well in the past, but have found AWS (Pinpoint/Amplify) quite difficult to work with, as well as using Firebase for iOS. Expo have spent time creating a decent unified API for notifications on both iOS and Android platforms (despite significant underlying differences), and it makes backend integration super straightforward.
- Don't be tempted by Flutter
Now, partly in line with my primary interest in "utility" apps (as described above), I broadly don't get the hype/buzz around Flutter. This article from Jamon Holmgreen explains these reasons far better than I could, but for me the biggest points are:
At its heart, Flutter gives you a canvas. If you want to control every pixel of a mobile screen to the nth degree, then it probably opens doors otherwise only open via purely native (Swift/Java) approaches on iOS and Android. But for the majority of cases, this simply isn't what you need.
There's a lot of investment in React Native development from Microsoft (as well as Facebook). The community (at least outside Europe) is decent in size and it's used by Facebook/Whatsapp/Instagram, Uber, Airbnb, Microsoft Office/Teams, Shopify and Wix. In other words, proper heavyweights.
To use Flutter you need to learn a special language called Dart. Despite both being Google innovations, Dart and Angular are not very similar. So you won't be able to share much code with the web, unlike React Native which is similar to ReactJS for Web. Frameworks like Tamagui are even bridging the gap on visual components so you can share code for the majority of your frontend components.
You're most likely to have a ReactJS website to start with, and while ReactJS web devs can't just jump into React Native development, they are much better able to chip in and help, especially if your overall development team is small and developers are working in more of a full-stack and cross-platform way.
Did you find this article valuable?
Support Ben Watts by becoming a sponsor. Any amount is appreciated!