[sydneycollins-cio]

inApp.siteId is now optional, so apps set up with a pk_ key can turn on in-app with inApp: {}.

• Android uses MessagingInAppModuleConfig.Builder() when no site ID is set.
• iOS needs the native release with feat(MBL-2652): let in-app start without a site ID when set up with a pk_ key customerio-ios#1370. The iOS pin moves to it once it's out.

🤖 Generated with Claude Code

[github-actions]

Sample app builds 📱

Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.

---

Builds are in progress. This comment will be updated when they finish.

• iOS FCM: Build failed. See CI job logs to determine the issue and try re-building.
• Android APN: Build failed. See CI job logs to determine the issue and try re-building.
• iOS FCM: 685.2.0 (29885438)
• Android APN: 685.2.0 (29885438)

[Shahroz16]

Android looks good. One thing to sort out before this merges, inline.

[Shahroz16]

Could we hold this until the iOS release with customerio/customerio-ios#1370 is out and move the iOS pin in this PR? On 5.0.0, build(from:) still throws missingSiteId, so inApp: {} type-checks and works on Android, while iOS logs [InApp] Failed to initialize module and starts without in-app. Same gap #664 had.

[mrehan27]

__tests__/in-app-site-id.test.ts still says siteId stays required with a pk_ key, and nothing covers inApp: {}. Please update the header and add a case that inApp: {} reaches native initialize as-is.

Follow-up idea: the example app disables the in-app switch without a site ID (example/src/screens/settings.tsx:98-131), so inApp: {} can't be tried there. Allowing it when the key starts with pk_ would help QA.