ci: [SDK-4717] add iOS E2E workflow with signing

[fadi-george]

Description

One Line Summary

Add a CI workflow that builds a signed iOS demo IPA and runs the shared Appium E2E suite on real devices.

Details

Motivation

The iOS demo now matches the cross-SDK demo spec, but there was no automated path to build a device-signed IPA and run the shared Appium tests in CI. This PR wires up that pipeline so iOS gets the same E2E coverage as the other SDK demos.

Scope

• Adds .github/workflows/e2e.yml with two jobs:
  • build-ios: checks out the repo, runs the new setup action, installs Appium signing certs/profiles via sdk-shared, archives and exports a signed IPA, verifies aps-environment is present, and uploads the artifact.
  • e2e-ios: reuses OneSignal/sdk-shared/.github/workflows/appium-e2e.yml@main with the uploaded IPA.
• Adds .github/actions/setup-demo composite action to install XcodeGen, generate examples/demo/App.xcodeproj, and write App/Secrets.plist from CI secrets.
• Adds examples/demo/ExportOptions.plist for manual development export with the Appium provisioning profiles (main app, NSE, Live Activity widget).
• Updates examples/demo/project.yml with Release manual signing settings per target so xcodebuild archive can produce a device-signed build in CI.

Does not change SDK source or demo app behavior. Workflow triggers on rel/** pushes and workflow_dispatch.

Other

Requires these repo secrets/vars (same as other SDK E2E workflows):

• vars.APPIUM_ONESIGNAL_APP_ID
• secrets.APPIUM_ONESIGNAL_API_KEY
• secrets.APPIUM_IOS_DEV_CERT_P12_BASE64
• secrets.APPIUM_IOS_DEV_CERT_PASSWORD
• secrets.APPIUM_APP_STORE_CONNECT_KEY_ID
• secrets.APPIUM_APP_STORE_CONNECT_ISSUER_ID
• secrets.APPIUM_APP_STORE_CONNECT_PRIVATE_KEY

Testing

Manual testing

Not run locally in this PR. The workflow is intended to be validated on the first CI run after merge (or via workflow_dispatch on this branch).

Affected code checklist

None of the SDK runtime code paths below were touched. Changes are CI and demo signing config only.

• 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