[gre]

Know when a React Native release needs adaptations in the library, without tracking RN releases by hand.

How it works

.github/workflows/rn-compat.yml, every Monday:

1. Reads the latest and next react-native dist-tags on npm. next is kept only when it targets a newer minor than latest, since it lingers on the last RC after a release.
2. Skips versions already reported ✅. Failing versions are re-tested every week, so a transient failure doesn't stick.
3. For each remaining version, .github/scripts/rn-compat-app.sh creates a fresh app (@react-native-community/cli init --version X) and installs the library from npm pack. The app's App.tsx uses ViewShot, captureRef and captureScreen.
4. Checks, new architecture only:
   • Android job: tsc type-check, release bundle, assembleDebug
   • iOS job: pod install, xcodebuild
5. Collects compiler warnings that point into the library's own sources: javac (with -Xlint:deprecation), kotlinc, Gradle and clang. Codegen output is excluded. These are the "adapt this before it breaks" signals.
6. Opens one issue per version, labelled rn-compat, titled RN compat: react-native@X — ✅ compatible or — ❌ <failed steps> failed. The issue contains the per-step table, the warnings, the tail of each failing log, and the release notes plus an Upgrade Helper link from the example's RN version. When a re-test gives a different result, the bot updates the title, comments, and reopens the issue if it fails again.

Manual run: Actions → RN compatibility → Run workflow. It takes a version, which can be a tag such as nightly or next, and a force flag to re-test a version that already has an issue. This only becomes available once the workflow is on master.

Pull requests that change the workflow or the script run it as a dry run on latest. The would-be issue goes to the job summary instead of a real issue, and the job fails if the result isn't ✅. This PR is the first such run.

Already tested locally against RN 0.88.0 (current latest; the example is on 0.84.1)

• Type-check, release bundle, Android build and iOS build all ✅. No changes needed today.
• Warnings found in our code (what the issue would list):
  • iOS: RNViewShot.mm:70, keyWindow deprecated since iOS 13.
  • Android, legacy-architecture APIs that RN 0.88 marks "will be removed in a future release": UIManagerModule / addUIBlock, NativeViewHierarchyManager.resolveView, UIBlockViewResolver, TurboReactPackage, plus AsyncTask, getCurrentActivity(), CompressFormat.WEBP and View.getDrawingCache().
• In 0.88, View is no longer a class, so useRef<View> doesn't type-check (use useRef<React.ComponentRef<typeof View>>). A ref of that type is still accepted by captureRef.

I also checked:

• version resolution (default, nightly, unknown version, force)
• the report step with a stubbed gh: new issue, unchanged result, forced re-test with reopen, setup failure, dry run
• the warning filters on sample javac, Kotlin and Gradle output

All of these ran locally; actionlint passes. Reviewed with three /code-review passes. What I didn't fix, and why:

• Packing the library once and sharing the tarball across jobs: the job only builds when a new RN version shows up, and macOS minutes are free for public repos.
• Re-testing versions already reported ✅: library regressions are covered by ci.yml on every PR.
• Pinning a newer Xcode version and handling GitHub issue-search lag: neither is needed today.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.