[GH-ISSUE #1489] fix(mobile): bound bridge and runtime-family conventions to path segments #505

New issue

Closed

opened 2026-10-15 18:25:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:25:41 +00:00

Owner

Originally created by @cursor[bot] on GitHub (Oct 10, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1489

TL;DR: Android and Apple bridge bases, and Apple runtime families, treat a path substring as a framework convention. libcommunity.so becomes unity-convention. MyApp.framework becomes Flutter.

#1470 was one identity rule applied at the wrong boundary. Here an inference from one side of a pair is stamped onto every pair, and the matcher is wider than the convention it names.

Area

Evidence, artifacts, or reconstruction

Observed behavior

Android bridgeBasis (src/domain/android/androidApplication.ts) looks only at the native path, then:

includes("react") or includes("hermes") → react-native-convention
includes("flutter") → flutter-convention
includes("unity") → unity-convention

lib/arm64-v8a/libcommunity.so contains unity, so every DEX or class file paired with it is unity-convention. That match wins over jni-library-convention. preact and reactivity contain react. The basis is then copied onto every managed component in the Cartesian product.

The Android projection does say that families are inferred, that bridge candidates are hypotheses, and that the basis comes from the native path and is repeated. The matcher still fires on those substrings. Runtime-family detection next to it is tighter (reactnative, libflutter.so, libunity.so) than the basis function.

Apple bridgeBasis (src/domain/apple/appleApplication.ts) is the same shape, with a wider Flutter test: includes("flutter") or includes("app.framework"). Something.app/Frameworks/MyApp.framework/... contains app.framework, so the pair is flutter-convention. includes("unity") has the same community hit. includes("react") does not require reactnative or react.framework.

Apple identifyRuntimeFamilies adds flutter when any path contains app.framework, and adds swift-objective-c for every .dylib or *.framework/<name> path. A C dylib is enough. The Apple limitations say bridge candidates are path hypotheses and that bundle roles follow path conventions. They do not say runtime families are inferred, and they do not say the basis is taken only from the native path and repeated for every script.

coverage.status can still be complete-within-inventory while those fields are substring guesses.

Expected behavior

A convention basis should match a bounded path segment (libunity.so, UnityFramework.framework, libflutter.so, Flutter.framework, libhermes.so). The basis should be labeled as an inference from the native path, repeated for each pair, on both projections. swift-objective-c should require a Swift or Objective-C observation, or the family list should say it is only a path-shape guess.

Where

src/domain/android/androidApplication.ts — bridgeBasis, runtimeFamilies
src/domain/apple/appleApplication.ts — bridgeBasis, identifyRuntimeFamilies, projectionLimitations

Originally created by @cursor[bot] on GitHub (Oct 10, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1489 **TL;DR:** Android and Apple bridge bases, and Apple runtime families, treat a path substring as a framework convention. `libcommunity.so` becomes `unity-convention`. `MyApp.framework` becomes Flutter. #1470 was one identity rule applied at the wrong boundary. Here an inference from one side of a pair is stamped onto every pair, and the matcher is wider than the convention it names. ### Area Evidence, artifacts, or reconstruction ### Observed behavior Android `bridgeBasis` (`src/domain/android/androidApplication.ts`) looks only at the native path, then: - `includes("react")` or `includes("hermes")` → `react-native-convention` - `includes("flutter")` → `flutter-convention` - `includes("unity")` → `unity-convention` `lib/arm64-v8a/libcommunity.so` contains `unity`, so every DEX or class file paired with it is `unity-convention`. That match wins over `jni-library-convention`. `preact` and `reactivity` contain `react`. The basis is then copied onto every managed component in the Cartesian product. The Android projection does say that families are inferred, that bridge candidates are hypotheses, and that the basis comes from the native path and is repeated. The matcher still fires on those substrings. Runtime-family detection next to it is tighter (`reactnative`, `libflutter.so`, `libunity.so`) than the basis function. Apple `bridgeBasis` (`src/domain/apple/appleApplication.ts`) is the same shape, with a wider Flutter test: `includes("flutter")` or `includes("app.framework")`. `Something.app/Frameworks/MyApp.framework/...` contains `app.framework`, so the pair is `flutter-convention`. `includes("unity")` has the same `community` hit. `includes("react")` does not require `reactnative` or `react.framework`. Apple `identifyRuntimeFamilies` adds `flutter` when any path contains `app.framework`, and adds `swift-objective-c` for every `.dylib` or `*.framework/<name>` path. A C dylib is enough. The Apple limitations say bridge candidates are path hypotheses and that bundle roles follow path conventions. They do not say runtime families are inferred, and they do not say the basis is taken only from the native path and repeated for every script. `coverage.status` can still be `complete-within-inventory` while those fields are substring guesses. ### Expected behavior A convention basis should match a bounded path segment (`libunity.so`, `UnityFramework.framework`, `libflutter.so`, `Flutter.framework`, `libhermes.so`). The basis should be labeled as an inference from the native path, repeated for each pair, on both projections. `swift-objective-c` should require a Swift or Objective-C observation, or the family list should say it is only a path-shape guess. ### Where - `src/domain/android/androidApplication.ts` — `bridgeBasis`, `runtimeFamilies` - `src/domain/apple/appleApplication.ts` — `bridgeBasis`, `identifyRuntimeFamilies`, `projectionLimitations`

bsakaguchi

2026-10-15 18:25:41 +00:00