Explore removing expo dependency

[mkopcins]

Explore how we could remove expo dependency by separating Resource Fetcher outside of our library (this it the only feature depending on expo)

[rizalibnu]

Hi @mkopcins @msluszniak

First of all, thank you for building and maintaining react-native-executorch — it’s a great library and has been really useful to work with 🙏

I came across your discussion about removing the Expo dependency by separating the resource-fetching logic from the core library. Based on that, I’ve implemented a solution using an adapter pattern, and I’d love to get your feedback on the API design and overall approach. I’m also happy to contribute this upstream if it aligns with the project’s direction.

---

What I’ve Implemented

Architecture

react-native-executorch (core — no platform dependencies)
    ↓ adapters
    ├─ @rn-executorch/expo-adapter (expo-file-system)
    └─ @rn-executorch/bare-adapter (RNFS + background downloader)

Key Design Decisions

1. Adapter Pattern

The core library accepts a resource fetcher adapter via an explicit initialization step:

// Before (no initialization needed)
import { useLLM } from 'react-native-executorch';

// After (breaking change: apps must explicitly initialize with an adapter)
import { initExecutorch, useLLM } from 'react-native-executorch';
import { BareResourceFetcher } from '@rn-executorch/bare-adapter';
// or: import { ExpoResourceFetcher } from '@rn-executorch/expo-adapter';

initExecutorch({
  resourceFetcher: BareResourceFetcher,
});

2. Separate Packages

Adapters are published as separate packages to keep the core lightweight and platform-agnostic:

• Expo-specific logic → @rn-executorch/expo-adapter
• Bare React Native implementation → @rn-executorch/bare-adapter

---

API Questions for Discussion

I’d really appreciate your thoughts on the following:

1. Initialization Pattern
   Is initExecutorch() a reasonable way to inject platform-specific adapters, or would you prefer a different approach?

2. Package Structure
   Should adapters live as separate published packages, or be part of a monorepo setup?

3. Breaking Changes
   This introduces a migration step for existing users. Would you prefer:

   • a major version bump, or
   • a backward-compatibility layer (e.g. default to the Expo adapter, with the ability to override)?

4. Implementation Review
   Do you see any architectural or API concerns with this approach?

---

Benefits

• ✅ Bare React Native support without installing Expo modules
• ✅ Removes Expo dependency from the core library
• ✅ Extensible for custom resource fetchers
• ✅ Clear separation of platform-specific code
• ✅ Existing Expo functionality preserved via adapter

---

Working Implementation

You can try it out here:

• Repository: https://github.com/rizalibnu/react-native-executorch
• Branch: feat/resource-fetcher-adapters

If you prefer to review specific changes directly, you can also jump in via this commit:
👉 rizalibnu@8575eb4

Example Apps

• apps/llm_bare/ — full bare React Native LLM chat example
• Existing Expo apps updated to use the Expo adapter

Quick Test

git clone https://github.com/rizalibnu/react-native-executorch.git
cd react-native-executorch
git checkout feat/resource-fetcher-adapters
yarn install

# Test bare adapter
cd apps/llm_bare
npx pod-install
yarn ios  # or yarn android

---

Thanks again for the great work on this library. Looking forward to your feedback, and I’m very happy to contribute or iterate further based on your guidance.

Best,
Rizal

[msluszniak]

Hi @rizalibnu,

Wow, that's a huge thing! We will check this as soon as possible and get back to you. ❤️

[chmjkb]

Hey @rizalibnu,

Thank you so much, this is a huge contribution! 🥳
It would be great if you opened up a PR so we can discuss the implementation details there. We'd be happy to introduce this contribution in v0.8.0, as v0.7.0 is right around the corner.

Regarding your questions:
2. On the repo structure: I think we should keep them in the monorepo. We'll publish both the expo and bare resource fetchers as separate npm packages so users can still grab them easily.
3. On the timeline: As I mentioned, ideally we can release this as v0.8.0, as we're planning more big changes before we release a major version (see #2 for details).
4. We think it looks good, just some comments regarding code structure. Overall approach looks clean. Most improtantly, it doesn't pose a big friction point for the users while also introducing a lot of flexibility.

[rizalibnu]

Thank you so much for the kind words! 🙏 Really appreciate the feedback @chmjkb @msluszniak .

Sounds great on all points. Before opening the PR, I’ll first sync my changes with the current main branch, since this work originally started from v0.6.0. After that, I’ll open a PR so we can discuss the implementation details there and iterate on the code structure based on your comments.

Keeping everything in the monorepo while publishing the Expo and bare fetchers as separate packages makes a lot of sense 👍
And targeting this for v0.8.0 works perfectly on my side as well.

Thanks again for the thoughtful review — looking forward to refining this together.