Ep 18 — Unexpected things I learned from building “When was I here?” using cross-platform frameworks

After going full native on Sidekick, SpendSimple, Travel Shopping Buddy, Sato and Selfie Camera Locator, I set aside time to learn flutter/dart and ReactNative deeper to see if it’s worth adopting them broadly. Experience tells me the devil is usually in the details and I want to find out where things stand.

Image by Michael Schwarzenberger from Pixabay

Here are the goods:

The best reuse I get from using flutter/RN is for data presentation on ListViews and master/detail type of data access from sqlite or firebase or MongoDB. No doubt about that there. As I ventured further, a few things surfaced.

1. Location/Maps 🗺: Native approach gives me many more options to optimize battery use. For instance. iOS location manager allows me to listen to significant location changes only. Android fused location provider also has settings that would greatly help balance battery consumption and data freshness.
2. Camera 📷 is an essential element and it’s harder to use advanced techniques like face detection, OCR in Flutter/RN. Also, device specific capabilities like depth detection can’t be done without dropping back to native code.
3. Onboarding with Google Login and Apple Sign In is not easy to do it well using reusable code.
4. Sensor data: Hard to reuse generic logic that process sensor data reliably across iOS and Android. This applies to audio streams, accelerometer and activity data.
5. Multi-app collaboration using Android intents or iOS shortcuts are pretty much platform specific. I didn’t get much reuse there.
6. In App Purchase flow must be carefully tuned to minimize drop-off. I found it hard to do it well with plugins that exposes common elements only.
7. Reusable test automation code is also not easy in RN or flutter.
8. The flutter UI widget tree becomes quite unwieldy when I opt to use Cupertino and Material Components to make things look native. I am sure flutter gurus can make them look nice and modular, but it takes time to develop that level of expertise.
9. Lifecycle management logic (e.g. when my app goes in and out of foreground) creates lots of if (iOS) doThis else doThat type of code. One codebase, yes, but the maintenance is actually not easy.

In summary,

• I was unable to justify the extra effort to switch foundations. I really miss direct access to native SDKs that allows me to fine-tune user experience.
• Instead, I decided to invest energy on intra-platform reuse for tablet, phone and multi-window scenarios. I can find good effort savings there.
• I reminded myself to build fewer features, but implement them tighter and nicer. Less is more.

Hope this helps!

Billy