feat: add app version message #131
Conversation
📝 WalkthroughWalkthroughAdds expo-application dependency, bumps app.json version and runtimeVersion to 3.4.0, and registers a new MessageManager handler getAppVersion that returns { version, buildNumber } using app.json in Expo Go or expo-application values in native builds. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant MessageManager
participant Env
Client->>MessageManager: invoke("getAppVersion")
alt Running in Expo Go
MessageManager->>Env: read appJson.version
Env-->>MessageManager: version
MessageManager-->>Client: { version, buildNumber: undefined }
else Running standalone/native
MessageManager->>Env: read Application.nativeApplicationVersion & nativeBuildVersion
Env-->>MessageManager: version, buildNumber
MessageManager-->>Client: { version, buildNumber }
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
app.json (1)
61-61: CRITICAL: Bump runtimeVersion (or set policy) to avoid OTA crashes after adding a new native module.This PR adds a new native module (expo-application). Shipping this via EAS Updates without bumping runtimeVersion can push a JS bundle to older binaries that don’t contain the native module, leading to runtime “unavailability”/module-not-found crashes at startup (due to the static import in getMessageManager.ts).
Two safe options:
- Bump runtimeVersion to a new value (e.g., 3.3.2) and ship a new binary.
- Preferably, adopt the appVersion policy so runtimeVersion auto-tracks app version.
Example update:
"runtimeVersion": { "policy": "appVersion" }or
"runtimeVersion": "3.3.2"Note: See the getMessageManager.ts comment for an additional guard (dynamic import) to keep older clients from crashing if they ever receive a mismatched bundle.
I can provide a minimal PR diff to switch to policy-based runtimeVersion if desired.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these settings in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (3)
app.json(1 hunks)package.json(1 hunks)src/lib/getMessageManager.ts(2 hunks)
🔇 Additional comments (2)
app.json (1)
3-3: Version bump looks good; ensure store build numbers are incremented for release.Marketing version is now 3.3.2. If you intend to ship a new binary:
- Android: increment android.versionCode (currently 329).
- iOS: ensure ios.buildNumber is incremented (not present here; either add it or use EAS auto-increment).
If you rely on EAS auto-increment, confirm eas.json is configured accordingly to avoid upload failures.
package.json (1)
25-25: expo-application@^6.1.5 — compatible with Expo SDK 53; plan native rebuildVerified: Expo SDK 53 bundles expo-application ~6.1.5, so the dependency is SDK-compatible.
- File: package.json — line ~25:
"expo-application": "^6.1.5"(OK)- Action: Plan a new iOS/Android binary (this is a native module). Don’t rely on OTA-only rollout unless all installed binaries already include this module.
- If using EAS Updates: constrain the update by the new runtimeVersion (or equivalent) in app.json to prevent older binaries from loading this bundle.
- Optional: run
npx expo install expo-applicationto ensure the SDK-compatible package is installed.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these settings in your CodeRabbit configuration.
📒 Files selected for processing (1)
app.json(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: NeOMakinG
PR: shapeshift/mobile-app#131
File: src/lib/getMessageManager.ts:0-0
Timestamp: 2025-08-14T09:51:12.307Z
Learning: NeOMakinG prefers clean, simple code over complex backward compatibility fallbacks, and favors pushing users to update native app versions rather than maintaining extensive error handling for older versions.
🔇 Additional comments (1)
app.json (1)
61-61: Confirm runtimeVersion bump; consider switching to a policy-based runtimeVersionVerified: app.json sets runtimeVersion to "3.4.0" (this will gate OTAs to that native runtime and prevent older runtime bundles from receiving updates).
Files to check:
- app.json — line ~61: "runtimeVersion": "3.4.0"
- package.json — includes "expo-updates" (repo uses EAS/Expo updates)
- README.md — documents runtimeVersion OTA gating and bump process
Suggested minimal change to let Expo derive runtimeVersion from the app version:
- "runtimeVersion": "3.4.0" + "runtimeVersion": { "policy": "appVersion" }Notes:
- If you intentionally want to lock OTAs to a specific native runtime, keep the explicit "3.4.0".
- If you gate by native build numbers across platforms, prefer { "policy": "nativeVersion" } instead.
- After changing to a policy, manually confirm your EAS Update channels and channel partitioning behave as expected.
| { | ||
| "name": "ShapeShift", | ||
| "version": "3.3.1", | ||
| "version": "3.4.0", |
There was a problem hiding this comment.
Avoid pushing OTA for this one so we ensure users have the expo-application native files
Again does what it says, allow the webapp to query the app version, so we can enable and disable feature depending on the version
Summary by CodeRabbit
New Features
Chores