Ah, native…sorry, I don’t have much experience there unfortunately.

I understand. What's really weird to me is how it works with Om.next, which is why I think it's something related to Fulcro. If I simply replace the Om.next calls with the fulcro.client.primitives versions (without even creating a full Fulcro client), same thing happens - everything works fine in dev mode with figwheel bridge, but breaks in prod.

On a positive note, I was easily able to get a Fulcro server running as an Ion on Datomic Cloud. Would be happy to share that if anyone is interested.

i think there was someone in this channel that used fulcro with react native successfully, @tony.kay do you remember who?

no…I know there were some others who played around with it, but don’t know if anyone tried release build

I figured it out! As usual, it was a stupid little bug obscured by a jillion layers of tooling and complexity. But in a nutshell, the difference was that Om.next returns a regular fn from its factory method, and Fulcro returns a MetaFn. This factory ultimately gets passed to Expo when you register the root component, and of course JavaScript doesn’t know how to handle a MetaFn. Solution was easy - wrap the root component passed to Expo in an anonymous fn that then calls the underlying factory. I still have NO idea why it worked in dev mode - probably related to figwheel-bridge and how it loads things, which is still witchcraft to me. 😉

@mdhaney I have a demo repo with expo and fulcro here if you still need https://github.com/wilkerlucio/multi-timer

Ah, yes, that would be a difference. Fulcro needs to do that because of the changes to how dynamic queries work.