chore: [SDK-4759] remediate Angular XSRF advisory

[fadi-george]

Description

One Line Summary

Update the Angular Capacitor 7 demo to a patched Angular 19 release line and migrate its iOS dependencies from CocoaPods to SPM.

Details

Motivation

Angular's HttpClient XSRF protection advisory is patched in Angular 19.2.16 and later. The Capacitor 7 Angular demo was still on Angular 18.x, so this PR moves the demo dependencies onto the patched Angular 19 line.

The same demo was also still using CocoaPods for iOS dependencies. Migrating it to SPM keeps the Capacitor 7 demo aligned with the non-pods iOS dependency flow used by the main demo.

Scope

This change is limited to examples/demo_cap7:

• Updates Angular package versions and the Angular 19-compatible zone.js peer.
• Replaces the iOS app target's CocoaPods linkage with a local CapApp-SPM package.
• Removes the demo's Podfile and CocoaPods workspace metadata.

The plugin source, public API, Android project, and non-Angular demos are not changed.

Testing

Unit testing

No unit tests were added because this is a dependency and native project configuration remediation for an example app and does not change plugin behavior.

Manual testing

• cd examples/demo_cap7 && bun install
• cd examples/demo_cap7 && bun run build
• xcodebuild -resolvePackageDependencies -project ios/App/App.xcodeproj -scheme App
• xcodebuild -project ios/App/App.xcodeproj -scheme App -configuration Debug -destination 'generic/platform=iOS Simulator' CODE_SIGNING_ALLOWED=NO build
• vp run ios --target 25255953-BD0C-4557-97C0-1414545FE510
• vp install
• vp check
• vp test
• vp pack
• Searched examples/demo_cap7 for Angular HttpClient/XSRF usage and protocol-relative request URLs; none were found.
• Searched examples/demo_cap7 for leftover CocoaPods references; none were found.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

Made with Cursor