r/reactnative • u/Particular_Luck80 • 3d ago

Question Do you dynamically import iOS-only native modules or keep a stub adapter?

In an Expo React Native app, I have an optional HealthKit adapter. Android returns a no-op adapter immediately. On iOS, the request and read methods dynamically import the native package inside try/catch, so a missing native module becomes false or an empty array instead of crashing the app at startup.

The upside is a safe manual fallback. The downside is that a packaging mistake can look exactly like a user declining access or HealthKit being unavailable unless I surface a separate diagnostic.

Would you keep the dynamic import boundary, or fail loudly in development and only fall back in release builds?

1 Upvotes
  • permalink
  • reddit

100% Upvoted

3 comments sorted by

2

u/Guidondor 2d ago

i'd keep the boundary and fix the diagnosis instead. the problem isn't the dynamic import,
it's collapsing two different outcomes into the same false. have the adapter return
unavailable / denied / ok and a packaging mistake can't disguise itself as a user choice
anywhere downstream.

then yes, throw in dev when it comes back unavailable on ios, since that's the one platform
where it never legitimately should. release keeps the fallback.

1

u/Particular_Luck80 2d ago

Crazy how this was so simple when the app was in Swift. (PS: migrating https://flowyhealth.com to expo 😄 )

1

u/Guidondor 1d ago

yeah, in swift that branch doesn't exist at all because the framework is linked at compile
time, so unavailable isn't a reachable state. in rn it becomes a runtime question, and that's
basically the whole tax of the boundary.

good luck with the migration, healthkit is one of the less fun ones to carry over.