chore(deps)!: use non-legacy Expo FS in Resource Fetcher, bump SDK version to 56 in demo apps

[chmjkb]

Description

This PR bumps Expo SDK to 56 across all demo apps using Expo. It also refactors the Expo Resource Fetcher to use the aforementioned version. For users using <56, a /legacy import for ExpoResourceFetcher is still available.

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

• In an app on Expo SDK <56 (e.g. SDK 54/55), install this package and import { ExpoResourceFetcher } from 'react-native-executorch-expo-resource-fetcher'. Confirm it throws RnExecutorchError with code ResourceFetcherFileSystemApiUnavailable (0xbc) and a message pointing at the /legacy entry point — not the cryptic File.createDownloadTask is not a function.
• In the same old-SDK app, switch the import to react-native-executorch-expo-resource-fetcher/legacy and confirm fetch, pause/resume/cancel, deleteResources, and listDownloadedFiles all still work.
• In an app on Expo SDK 56+, import from the default entry point and confirm the guard does not fire and downloads work end-to-end.
• Run yarn install at the repo root and confirm no new peer-dep warnings on the SDK-56 demo apps under apps/.

Screenshots

Related issues

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

[msluszniak]

I'll check why CI has diffs on comments in *.h files. This is definitely related to my addition to CI which suppose to check if error codes are regenerated.

[chmjkb]

I'll check why CI has diffs on comments in *.h files. This is definitely related to my addition to CI which suppose to check if error codes are regenerated.

im pretty sure pre-commit does a lint, and yarn codegen:errors returns something that is not yet linted properly:)
so changed on this branch are linted, while the ones generated by the codegen are not, hence the diff. not sure tho

[msluszniak]

Yeah, makes sense. That's not the reason. This branch has stale main tip and it caused the CI failure.

[msluszniak]

Actually the reason why CI fails is because you are not rebased on main, please rebase it first ;)

[msluszniak]

Can we drop the react-native-executorch devDependency bump?

In packages/react-native-executorch/package.json this PR bumps the core package's dev baseline to RN 0.85:

- "@types/react": "~19.1.10",
- "react": "19.1.0",
- "react-native": "0.81.5",
+ "@types/react": "~19.2.0",
+ "react": "19.2.3",
+ "react-native": "0.85.3",

I don't think the core package should move off 0.81, for a few reasons:

• It's not needed for this PR. The only RNE-core change here is the new ResourceFetcherFileSystemApiUnavailable enum (8 lines across ErrorCodes.ts + ErrorCodes.h) — no RN 0.85 APIs. All the actual expo-file-system work lives in packages/expo-resource-fetcher, which already carries its own react-native@0.85.3 / expo@^56 devDeps. That's the right place for it, since File.createDownloadTask is SDK-56-only.

• peerDependencies are react-native: "*", so there's no install-time floor on consumers. The dev RN version is effectively the only thing pinning what we type-check and test core against — bumping it to 0.85 silently drops our 0.81 coverage with nothing to catch a regression.

• It works against this PR's own goal. expo-resource-fetcher/legacy exists for Expo SDK <56 users, who are on RN 0.81/0.83 — never 0.85. If core RNE is only developed against 0.85, the exact users /legacy is for are running a core that's no longer tested on their RN. Same for bare-resource-fetcher (untouched here, still peer react-native: "*" / dev 0.81.5) and apps/bare-rn (pinned 0.81.5).

Could we revert just those three devDep lines and keep the SDK-56 / RN-0.85 bumps scoped to the demo apps and expo-resource-fetcher? The core package staying on 0.81 is what makes the legacy + bare lanes meaningful.

[chmjkb]

Can we drop the react-native-executorch devDependency bump?

In packages/react-native-executorch/package.json this PR bumps the core package's dev baseline to RN 0.85:

- "@types/react": "~19.1.10",
- "react": "19.1.0",
- "react-native": "0.81.5",
+ "@types/react": "~19.2.0",
+ "react": "19.2.3",
+ "react-native": "0.85.3",

I don't think the core package should move off 0.81, for a few reasons:

• It's not needed for this PR. The only RNE-core change here is the new ResourceFetcherFileSystemApiUnavailable enum (8 lines across ErrorCodes.ts + ErrorCodes.h) — no RN 0.85 APIs. All the actual expo-file-system work lives in packages/expo-resource-fetcher, which already carries its own react-native@0.85.3 / expo@^56 devDeps. That's the right place for it, since File.createDownloadTask is SDK-56-only.
• peerDependencies are react-native: "*", so there's no install-time floor on consumers. The dev RN version is effectively the only thing pinning what we type-check and test core against — bumping it to 0.85 silently drops our 0.81 coverage with nothing to catch a regression.
• It works against this PR's own goal. expo-resource-fetcher/legacy exists for Expo SDK <56 users, who are on RN 0.81/0.83 — never 0.85. If core RNE is only developed against 0.85, the exact users /legacy is for are running a core that's no longer tested on their RN. Same for bare-resource-fetcher (untouched here, still peer react-native: "*" / dev 0.81.5) and apps/bare-rn (pinned 0.81.5).

Could we revert just those three devDep lines and keep the SDK-56 / RN-0.85 bumps scoped to the demo apps and expo-resource-fetcher? The core package staying on 0.81 is what makes the legacy + bare lanes meaningful.

While I agree that this PR maybe is not the best place to bump it, since it involves no internal changes I think opening up another PR is frankly a waste of time.

Also, I've seen Reanimated and RNGH bump to latest RN versions, so I think it might make sense to bump it. I guess it would make sense to use the latest version to keep up with eventual breaking changes as they come.

[msluszniak]

Ok, as these are devDeps, we can indeed follow the latest version. Let's keep it.

[msluszniak]

A few code-level notes from a pass over the resource-fetcher refactor (separate from the devDep comment above). All non-blocking except possibly the first, which is a genuine question about the new download API's error behavior.

[msluszniak]

I'll test all demo apps, testing instruction worked. Just one small thing, please resolve this warning:

EDIT: I tested and all apps worked. Please fix this warning and it's good to go for me.

[chmjkb]

I'll test all demo apps, testing instruction worked. Just one small thing, please resolve this warning:

EDIT: I tested and all apps worked. Please fix this warning and it's good to go for me.

should be resolved now!