Lower `@capacitor/core` peer dependency floor to support Capacitor 5

[keithyoder]

Context

A customer is on Capacitor ^5.2.3 across @capacitor/core, @capacitor/android, @capacitor/ios, and @capacitor/cli. They are not planning to upgrade Capacitor as part of adopting this plugin.

Our package.json currently declares:

"peerDependencies": {
  "@capacitor/core": ">=6.0.0"
}

This blocks installation for them as-is.

Investigation

Audited every native plugin registration file and both TS entry points for Capacitor-6-specific API usage:

• ios/Plugin/FlybuyPlugin.swift, FlybuyPickupPlugin.swift, FlybuyNotifyPlugin.swift — use only CAPPlugin / CAPPluginCall, stable across Capacitor versions.
• android/.../FlybuyPlugin.kt, FlybuyPickupPlugin.kt, FlybuyNotifyPlugin.kt — use only com.getcapacitor.Plugin and the @CapacitorPlugin annotation, which dates to Capacitor 3 (replacing @NativePlugin).
• src/index.ts — uses registerPlugin<T>() with a web: factory, stable since Capacitor 3/4.
• src/pickup/web.ts — uses WebPlugin, PluginListenerHandle, addListener(...): Promise<PluginListenerHandle>, all stable since Capacitor 3/4.

No usage found anywhere that requires Capacitor 6+. The >=6.0.0 floor appears to have been set to match the plugin's own devDependencies (built/tested against ^8.3.4) rather than reflecting an actual compatibility requirement.

Proposed change

"peerDependencies": {
  "@capacitor/core": ">=5.0.0"
}

Also worth doing in the same pass

• FlybuyCapacitor.podspec: s.ios.deployment_target is currently 14.0. Verified against flybuy-ios's own Package.swift (platforms: [.iOS(.v11)]) that this is not an SDK requirement — safe to lower to 13.0 to match this customer's current deployment target.
• Package.swift (our own SPM manifest) still declares platforms: [.iOS(.v14)] and pins capacitor-swift-pm from: "8.0.0". Not exercised by CocoaPods-based installs (like this customer's), so lower priority, but worth aligning for consistency and for any future SPM-based consumer.

CocoaPods support for the FlyBuy SDK itself

Confirmed this customer's ios/App/Podfile is a stock, cap sync-generated Podfile — no SPM usage anywhere (no XCRemoteSwiftPackageReference entries in the .pbxproj either). CocoaPods is their established path, not SPM.

Our FlybuyCapacitor.podspec currently has the FlyBuy SDK dependencies commented out:

# s.dependency 'FlyBuyPickup'
# s.dependency 'FlyBuyNotify'
# s.dependency 'FlyBuyPresence'

As it stands, the plugin only really documents an SPM path for the underlying SDK. For a CocoaPods-based host app, we need one of:

• Uncomment these dependency lines (need to confirm they resolve — presumably against a Radius-published podspec repo, not the default CocoaPods trunk, since FlyBuy is closed-source), or
• Document explicitly in the README that CocoaPods-based host apps add pod 'FlyBuyPickup' / pod 'FlyBuyNotify' directly in their own Podfile (in the # Add your Pods here slot Capacitor's generated Podfile leaves for this), with the exact pod lines and any required source line for Radius's spec repo

Either way, this needs resolving before this customer can actually link the SDK — right now the podspec and README both point toward SPM as the only documented path, which doesn't match how their app is set up.

Verification before merging

• Confirm npx tsc --noEmit passes with no changes needed elsewhere
• Test install against a Capacitor 5 host app (e.g. a throwaway Capacitor 5 scaffold) end to end: npm install github:RadiusNetworks/flybuy-capacitor#<branch>, npx cap sync, build for both platforms
• Confirm CI (verify:ios, verify:android) still passes — these build against the plugin's own devDependencies, unaffected by the peer dep change itself, but worth a clean run
• Confirm the CocoaPods path for FlyBuyPickup/FlyBuyNotify actually resolves (correct spec repo/source), either via the podspec or documented host-app instructions