[RNE Rewrite] Integrate ResourceFetcher with refactor

[barhanc]

The PoC, we are basing this rewrite on, uses a crude, ad hoc solution for downloading and loading model files, see: https://github.com/barhanc/rnet-poc/blob/main/src/hooks/useModelDownload.ts. We should instead use the ResourceFetcher package. The PR referencing this issue should also add something like a download function so that it is possible to use create<Task> api with pre-exported models defined in models.ts as create<Task>(download(models.<task>.MODEL_CONSTANT)).

Here is an example of minimal storage implementation using 'react-native-blob-util' https://github.com/callstackincubator/ai/blob/main/packages/llama/src/storage.ts.

[msluszniak]

Design decision: which fetcher architecture for the rewrite

Considered four options:

1. Port the old two-package flow (expo-resource-fetcher + bare-resource-fetcher + adapter DI) ❌

• ~1750 LOC across 3 packages, adapter ceremony via initExecutorch, two divergent implementations to maintain.
• Its main justification — "Expo users shouldn't need extra native deps" — is moot: RNE ships native code, so Expo Go was never supported; every Expo user is on a dev client where any autolinked dep works.
• pauseFetching/resumeFetching throws PlatformNotSupported on bare Android and nobody complained — evidence the API surface it preserves isn't actually needed.

2. Keep the current react-native-fs hook ❌

• @dr.pogodin/react-native-fs is a maintained fork but with ~13× lower adoption than blob-util (~62k vs ~817k weekly downloads), and it's a filesystem lib where download is a side feature.

3. Own native downloader (URLSession/OkHttp behind our JSI layer) ⏸ deferred

• Zero peer deps and best control, but the rewrite's Android module is JSI-install-only, so it's the most plumbing-heavy option (~3–5 days both platforms). Not worth blocking the rewrite on; can be swapped in later behind the same interface.

4. Single fetcher on react-native-blob-util ✅ my candidate

• Purpose-built network→file API (config({path}).fetch() streams straight to disk), actively maintained, de facto ecosystem standard — same lib as the callstack example linked above.

Scope for v1:

• download(source, onProgress?): Promise<string> — promise-first so create<Task>(download(models.X)) works; hooks wrap it.
• Cache layout under <docs>/react-native-executorch/, unified multi-file progress, HF download-counter telemetry, cancel.
• Auto-resume of interrupted downloads via Range header + .partial file (covers a bit improvement: Resumable download #231) — no API surface needed.
• Explicit pause/resume dropped; can be added behind download() later if requested.

cc @barhanc

[barhanc]

Yes, totally agree. Separate packages shouldn't be needed for downloading, it should just be a part of the react-native-executorch with react-native-blob-util as a dependency (we can even use the linked implementation as a reference then :)). One thing regarding the example:.create<Task>(download(models.X)) will be difficult to achieve because of the type mismatch, so it needs some other solution to achieve the trick with model path substitution from url to local path that we currently use in use<Task> hooks. Some design question I don't see answered:

• What about downloading in the background? I guess it would be a useful feature for users building apps like e.g. Private Mind.
• What about file management (e.g. listing downloaded models, deleting them, etc.)? The example reference implementation has this. Do we also want to add such feature or stick only to downloading and returning the path, leaving the rest to the user?

[msluszniak]

What about downloading in the background? I guess it would be a useful feature for users building apps like e.g. Private Mind.

Regarding downloading in the background, worth splitting into what each platform actually gives us.

On Android blob-util can hand off to the system DownloadManager aka real background, survives app kill.

On iOS blob-util's IOSBackgroundTask is only a ~30s–3min grace period, not a background URLSession, so a locked phone won't finish a 2GB model.

So my idea is: blob-util + Range-based auto-resume of partial files: Android gets true background, iOS resumes where it left off on next foreground, nothing re-downloads.

If we believe, that there will be many Private-Mind-style apps that need real iOS background later, we can swap the engine (background URLSession natively or react-native-background-downloader) behind the same download() API without breaking anything.

What about file management (e.g. listing downloaded models, deleting them, etc.)? The example reference implementation has this. Do we also want to add such feature or stick only to downloading and returning the path, leaving the rest to the user?

Personally, I prefer the second option where resource fetcher is only responsible for downloading assets. Other functionalities are indeed helpful, but not in the scope of resource fetcher and I don't think our lib should tackle this. User should handle this by himself, and there are many solutions that will give user more FS functions that he or she will need. WDYT?

[barhanc]

Sounds good.