[RNE Rewrite] Integrate resource fetcher (react-native-blob-util)

[msluszniak]

Description

Adds resource fetching to the rewrite as a single react-native-blob-util-backed fetcher inside react-native-executorch. Replaces the temporary react-native-fs hook.

download(source, { onProgress, signal }) is a single generic entry point: it takes any nested structure of plain objects and arrays, downloads every string leaf that is an http(s) URL, and returns the value with those URLs replaced by local paths. Everything else passes through untouched, so the result is structurally identical to the input. download<T>(source: T): Promise<T> types correctly for every task config without per-task overloads:

const model = await download(models.classification.EFFICIENTNET_V2_S.XNNPACK_FP32);
const { classify, dispose } = await createClassifier(model);

Backend is split by platform: Android uses the system DownloadManager (reliable for files >2 GB, background), iOS streams via NSURLSession with .partial/HTTP-Range resume.

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

Testing instructions

1. Run the computer-vision example app.
2. Open Classification, pick an XNNPACK model — it downloads with progress, then loads and runs.
3. Reopen the screen — the model is served from cache instantly (no re-download).
4. Open Speech-to-Text — model, tokenizer and the nested VAD model resolve in one pass, with progress weighted across all three.
5. Imperative: createClassifier(await download(models.classification.EFFICIENTNET_V2_S.XNNPACK_FP32)).

Screenshots

Related issues

Closes #1253

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

Additional notes

• Swaps the react-native-fs peer dependency for react-native-blob-util.
• Android must use DownloadManager.
• isEmulator is now installed on the __rnexecutorch_jsi__ module by the native layer.
• File management (list/delete downloaded models) is intentionally out of scope; the fetcher only downloads and returns paths.

[barhanc]

We should also delete the resource fetcher packages. It can be in a follow-up PR though as not to clutter this one.

[barhanc]

This might return language code which is not a valid country code, e.g. if locale is 'en'.

[msluszniak]

Yes, I know. But this is how it has been implemented since now. Do you know if there are any better ways to get country code?

[barhanc]

According to clanker RNBlobUtil.fs.dirs.SDCardDir resolves to the root external storage directory (/storage/emulated/0), not an app-private external files directory. On Android 10+ (API 29+), Scoped Storage blocks direct writes to /storage/emulated/0/react-native-executorch without broad WRITE_EXTERNAL_STORAGE or MANAGE_EXTERNAL_STORAGE permissions. Android DownloadManager and RNBlobUtil.fs.mkdir/mv operations will throw EACCES (Permission denied).

[msluszniak]

I'll check that.

[msluszniak]

I think this claim is genuinely wrong. With current version (0.24.10) of blob-util, SDCardDir is getExternalFilesDirPath(ctx, null) → ctx.getExternalFilesDir(null). This results in /storage/emulated/0/Android/data/<pkg>/files directory which is cool. The legacy and incorrect one is: LegacySDCardDir (Environment.getExternalStorageDirectory()). I already tested fetcher on Android, and if it would be a problem, this should have probably appeared.

[barhanc]

This seems slightly convoluted. Why do we need an array received, wouldn't just a single number that we update directly in onBytes be enough?

[msluszniak]

Probably not, a single accumulator would be wrong. onBytes reports absolute bytes-so-far per file, not deltas. DownloadManager gives cumulative and the iOS path reports offset + recv to account for resume. += would double-count every progress tick.

[barhanc]

Couldn't we just do something like this. We don't need to expose the collectRemoteSources and substituteRemoteSources this way and since the download caches downloads internally there shouldn't be any problems with re-renders.

export function useResourceDownload<T>(config: T, preventLoad?: boolean) {
  const [resource, setResource] = useState<T>();
  const [downloadProgress, setDownloadProgress] = useState(0);
  const [downloadError, setDownloadError] = useState<Error | null>(null);

  useEffect(() => {
    setResource(undefined);
    setDownloadProgress(0);
    setDownloadError(null);

    if (preventLoad) return;

    let isMounted = true;
    const controller = new AbortController();

    download(config, {
      signal: controller.signal,
      onProgress: (progress) => {
        if (isMounted) setDownloadProgress(progress * 100);
      },
    })
      .then((resolved) => {
        if (!isMounted) return;
        setResource(resolved);
        setDownloadProgress(100);
      })
      .catch((e) => {
        if (!isMounted || e instanceof AbortError) return;
        setDownloadError(e instanceof Error ? e : new Error(String(e)));
      });

    return () => {
      isMounted = false;
      controller.abort();
    };
  }, [config, preventLoad]);

  return { resource, downloadProgress, downloadError };
}

[msluszniak]

Ok, I'll test it.

[msluszniak]

Deps [config, preventLoad] are fine for every current call site, but an inline config: useClassifier({ modelPath, modelOpts }) loops forever. Effect runs → setResource(resolved) → re-render → new object identity → effect re-runs. So this really only prevents re-downloads. Each cycle still tears down and reloads the native model via useModel. So we need to decide: indirection and tolerate inline configs or your variant, document that configs must be referentially stable. I think your approach is a cleaner one, but want to make sure wa are on the same page.

[msluszniak]

We should also delete the resource fetcher packages. It can be in a follow-up PR though as not to clutter this one.

What do you mean by deleting fetcher packages? We cannot delete them as such, because we need them for versions <= 0.9.x. I guess the first moment when we could remove them will be release of version 2.0.0. In the current implementation we don't ship any resource fetchers.