MOEN-46639: Declare pod as static framework

[abhishek-moe]

Jira Ticket

MOEN-46639 — companion to MoEngage-iPhone-SDK#1050

Change

One line: s.static_framework = true

What broke

The iOS SDK now links its 8 app-only modules statically. CocoaPods rejects any target using use_frameworks! whose transitive dependencies include statically linked binaries. This pod depends on MoEngage-iOS-SDK and /InApps, so it sits directly above static modules:

[!] The 'Pods-App' target has transitive dependencies that include statically
    linked binaries: (MoEngageSDK, MoEngageInApps, MoEngageTriggerEvaluator, ...)
pod install → exit 1

pod install fails outright — no .xcworkspace is produced, so the client never reaches a build.

What fixes it

Marking this pod static satisfies the constraint. Verified against the SDK's static branch with a sample app using use_frameworks!:

	pod install
without static_framework	exit 1
with it	exit 0 → BUILD SUCCEEDED

Resources still resolve — the SDK's <Module>.bundle files land at the app bundle root, which is where Bundle.moEngageResourceBundle looks first.

The requirement propagates up every layer of the chain, verified with a three-tier test: making the middle pod static isn't enough on its own. That's why the framework wrappers (Flutter, React Native, Capacitor) need the same change.

Client impact

• Without this change: any app using use_frameworks! and this plugin cannot install pods at all.
• With it: no change required on the client side. The alternative — asking every client to add use_frameworks! :linkage => :static to their Podfile — also works, but puts the burden on them.

Precedent

Braze ships static xcframeworks and sets exactly this in their Flutter plugin (braze-flutter-sdk/ios/braze_plugin.podspec). CleverTap, who ship dynamic, do not — consistent with the constraint following from static linkage.

Note on versioning

Downstream repos pin exact versions of this pod, so they need coordinated bumps once this releases; the podspec change alone won't reach clients.

🤖 Generated with Claude Code

[moe-hodor]

🚪 Hodor is reviewing this PR... 👀

[moe-hodor]

Review: MOEN-46639 — Declare pod as static framework

Branching & CFR: feature/MOEN-46639_staticFramework — category: feature, impact: Neutral CFR ✅

---

Summary

Single line change adding s.static_framework = true to MoEngagePluginBase.podspec to make this pod compatible with apps using use_frameworks! when the underlying MoEngage-iOS-SDK now ships static binaries for 8 modules.

---

Quality Gates

✅ PR Size: 1 line changed across 1 file — Good size.
✅ Tests: Test spec included in podspec.
ℹ️ Commits: 1 commit, 0 follow Conventional Commits.
✅ Migrations: No migration files.
✅ Duplication: No copy-paste patterns.

All checks passed. ✅

---

Jira Alignment

✅ Matches ticket scope: Jira MOEN-46639 is a parent ticket for the static/mergeable framework initiative. This PR is the plugin-base companion to the SDK PR.
✅ Complete: The single-line change is exactly what's needed at this layer.

---

Issues Found

• 🔴 Critical: 0
• ⚠️ Warning: 1
• 💡 Suggestion: 0

---

Key Concerns

1. ⚠️ CHANGELOG not updated — Every release of this pod should be documented. The PR description explains the change clearly, but future maintainers need a historical record in CHANGELOG.md.

---

Regression Risk

Low. Impact analysis:

✅ CocoaPods-only change:
The s.static_framework = true flag is a CocoaPods-specific directive that only affects pods consumed via CocoaPods. It has zero impact on Swift Package Manager users (Package.swift has no equivalent setting — SPM linkage is controlled by the consuming project).

✅ Downstream plugin pods:
Four plugin repos depend on MoEngagePluginBase:

• moengage/apple-plugin-cards → MoEngagePluginCards.podspec
• moengage/apple-plugin-geofence → MoEngagePluginGeofence.podspec
• moengage/apple-plugin-inbox → MoEngagePluginInbox.podspec
• moengage/apple-plugin-personalize → MoEngagePluginPersonalize.podspec

These will inherit the static linkage requirement once they update their pinned version of MoEngagePluginBase. The PR description notes these repos need coordinated bumps — this is correct and expected. None of these repos currently declare s.static_framework = true themselves (only moengage/React-Native's Expo adapter does), so they'll need similar PRs to propagate the requirement up the chain.

✅ Integration testing:
The PR description references manual verification against the SDK's static branch with a sample app using use_frameworks!:

• Without static_framework: pod install → exit 1 ❌
• With static_framework: pod install → exit 0 → BUILD SUCCEEDED ✅

This indicates the change was functionally tested.

⚠️ Version coordination:
As noted in the PR description, downstream repos pin exact versions (e.g., Flutter SDK pins 'MoEngagePluginBase', '6.10.0'). Once this releases as 7.00.0, those repos must bump in lockstep or stay on 6.x if they're not yet compatible with SDK 11.0. This is a release coordination concern, not a code bug.

---

What's Good

✅ Surgical change — Single line, zero behavioral risk.
✅ Well-documented PR description — Explains the constraint, the fix, and the testing clearly.
✅ Follows precedent — Braze's Flutter plugin uses the same pattern (static_framework = true) for the same reason.
✅ Podspec metadata looks solid — Deployment targets (iOS 13+, tvOS 13+), Swift 5, dependencies, test specs all properly configured.

---

Verdict

✅ LGTM with one documentation gap. The code change is correct and necessary. The only issue is the missing CHANGELOG entry. This is not a blocker for merge, but should be added before release tagging so the version history is complete.

---

Hodor holds the gate. One ⚠️ warning found (CHANGELOG), but the gate is open. The code shall pass. ✅

[msoumya-engg-sdk]

Please add a CHANGELOG.md entry for this — the linkage switch to a static framework is client-visible (it changes how the pod is built into the app) and should be traceable to the release it ships in.

[msoumya-engg-sdk]

Approved. Single-line s.static_framework = true on the podspec, consistent with the same change across the other apple-plugin-* pods and iOS-PluginBase, and with the linkage classification in moengage/MoEngage-iPhone-SDK#1050. No resources in this pod, so no resource-bundle handling is needed here.