It is unrelated to cljsrn, I would say. It’s on the RN level and down to your project and its requirements. This is a good discussion about the issues, pros/cons, tradeoffs, etc: https://www.youtube.com/watch?v=7-t6deIO1JE

I kinda like Expo. 😃 I have only used React Native professionally, because Expo was just not an option due to lack of support for things demanded by the projects. (Certain Bluetiooth API:s and such). It seems Expo is improving in this aspect, so I think more and more projects can use it.

Its worth pointing out that expo has two workflows, and recently the bare workflow has gotten a lot better due to their (currently still alpha) EAS Build tooling. So now you can submit a bare workflow app to the app store without needing xcode/android studio and push updates to it without needing to submit a bundle and get it reviewed https://docs.expo.dev/introduction/managed-vs-bare/

So if you think you might need bluetooth etc, but don’t have a mac or don’t like the deployment struggle its a pretty good system. I’ve tried it and it worked well, though you will need to do this if you’re using shadow https://github.com/thheller/reagent-react-native/blob/master/react-native/index.js

"It is unrelated to cljsrn,..." Good to know, @U0ETXRFEW! I am deeply impressed by all the CLJS interfacing with React; I peeked inside some internals and was suitably intimidated. I was afraid there might be some dependencies or anti-dependencies. Speaking of which, the "Certain Bluetooth API:s and such..." exception kinda blows my mind. I guess even power tools like Expo need tailoring for particular libraries.

Thx for the shadow tip, @U7KPK060K. I am using that. And the EAS workflow link. That was great reading, just what I needed. Sounds like I can get on with my RN+CLJS coding and worry about Expo when I want to try deploying. 🙏