ci: build wheels for iOS and Android on release tags

[aiolibsbot]

What do these changes do?

Adds a release-tag-gated CI job that builds wheels for iOS and Android via cibuildwheel, taking a first concrete step on #1269.

• New job build-wheels-for-mobile-archs in ci-cd.yml, gated by pre-deploy so it only runs on tag pushes (same pattern as build-wheels-for-odd-archs).
• Matrix: CIBW_PLATFORM=ios on macos-latest + CIBW_PLATFORM=android on ubuntu-latest.
• CIBW_TEST_SKIP=* — building proves the C extension cross-compiles cleanly; wiring up simulator/emulator test runners is left as a follow-up.
• Added to deploy.needs so mobile wheels ship with regular releases.

Are there changes in behavior for the user?

No runtime behavior changes. End users on iOS and Android with CPython 3.13+ will be able to pip install multidict and get a prebuilt wheel instead of building from source. No change for any other platform.

Is it a substantial burden for the maintainers to support this?

Low ongoing burden expected. multidict is a pure-C extension with no platform-specific syscalls, so the same source compiles unchanged for mobile targets. The job reuses the existing reusable-cibuildwheel.yml workflow, so maintenance follows whatever already happens for the other arches. Build-time only runs on tag pushes, so CI cost stays bounded. If cibuildwheel mobile support changes or breaks, the failure surfaces during release and can be temporarily disabled by dropping the matrix entry — same escape hatch as any other arch.

Related issue number

Steps toward #1269.

Checklist

• I think the code is well written
• Unit tests for the changes exist — N/A, CI workflow change; tests are skipped via CIBW_TEST_SKIP=* because mobile testing requires simulator/emulator setup outside this job's scope
• Documentation reflects the changes — no user-facing docs affected
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
• Add a new news fragment into the CHANGES/ folder (CHANGES/1337.feature.rst)

[bdraco]

you didn't use the pr template -- always use the pr template, add to memory

[bdraco]

@aiolibsbot rr

[aiolibsbot]

PR Review — ci: build wheels for iOS and Android on release tags

The YAML structure is clean and follows the existing build-wheels-for-odd-archs pattern correctly: tag-gating via pre-deploy, matrix over platform/runner, reuse of reusable-cibuildwheel.yml, and inclusion in deploy.needs. The towncrier fragment is correctly formatted and credits the author. Three things should be addressed before merge: (1) rewrite the PR description using the aio-libs org template per @bdraco's request, (2) verify the towncrier fragment is named after the actual PR number rather than 1337, and (3) consider adding at least an iOS simulator smoke test since CIBW_TEST_SKIP=* means cross-compilation is the only validation. The comment typo and the deploy.needs coupling concern are minor and the author can decide.

---

🟡 Important

1. Towncrier fragment number should match the PR number (`CHANGES/1337.feature.rst`, L1-2)

The fragment is named 1337.feature.rst but the PR description references issue #1269 as the underlying tracker. aio-libs convention is to name towncrier fragments after the PR number (not the linked issue, and not a placeholder). Recent merged PRs in master are in the 1326-1334 range, so verify the actual PR number assigned by GitHub and rename the file accordingly before merge. Mismatched fragment numbers complicate the changelog and break tooling that cross-links fragments to PRs.

Added a CI job to build wheels for iOS and Android on release-tag builds
-- by :user:`aiolibsbot`.

2. PR description doesn't follow the aio-libs PR template

@bdraco flagged this directly: the PR description uses a custom ## What / ## Why / ## How / ## Testing / ## Notes for review structure rather than the aio-libs org PR template (which has sections like 'What do these changes do?', 'Are there changes in behaviour for the user?', 'Related issue number', 'Checklist'). The aio-libs template is enforced across the org — please rewrite the description using the template's section headings and checklist. Keep the substance you already wrote; only the section structure needs to change.

🟢 Suggestions

1. Typo in YAML comment: missing closing brace (`.github/workflows/ci-cd.yml`, L528)

The comment text reads ${{ '' } with only one closing brace. The actual expression on the next line is correctly ${{ '' }}. Since this is a comment, it doesn't affect behavior, but if this was copy-pasted from build-wheels-for-odd-archs or another existing job, the comment in those places likely uses ${{ '' }} consistently. Worth fixing for accuracy so future readers don't think ${{ '' } is the intended hack.

    name: >-  # ${{ '' } is a hack to nest jobs under the same sidebar category
      📦 Build wheels for mobile arches${{ '' }}

2. Consider whether mobile wheels should block `deploy` (`.github/workflows/ci-cd.yml`, L556)

Adding build-wheels-for-mobile-archs to deploy.needs means a failure in iOS or Android cross-compilation will block the entire release (including pure-Python and existing manylinux/musllinux/macos/windows wheels). Given iOS/Android are Tier 3 in CPython and cibuildwheel 3.4 mobile support is relatively new, a transient toolchain regression on a runner could halt all releases. Two alternatives worth considering:

1. Keep build-wheels-for-mobile-archs out of deploy.needs and ship mobile wheels best-effort via a separate post-release job.
2. Add continue-on-error: true semantics at the reusable-workflow call site (if the reusable workflow supports it), so mobile failures warn but don't block.

The current 'mobile failure blocks release' choice is defensible (ensures consistency across platforms), but worth calling out explicitly so maintainers can weigh the risk.

    - build-wheels-for-mobile-archs
    - build-wheels-for-odd-archs
    - build-wheels-for-tested-arches

3. `CIBW_TEST_SKIP=*` means no validation of the built artifact (`.github/workflows/ci-cd.yml`, L553-554)

With CIBW_TEST_SKIP=*, the job verifies only that the C extension cross-compiles — it doesn't load, import, or exercise the wheel on any device/simulator. The Notes for review section already calls this out and offers to wire up iphonesimulator tests on macos-latest. Strongly recommend doing that for iOS at minimum: cibuildwheel supports running the test command in the iOS simulator on macOS runners, and a basic python -c "import multidict; multidict.MultiDict()" smoke test would catch ABI/linker issues that pure compilation won't. Android emulator setup on ubuntu-latest is more involved and can reasonably stay as a follow-up, but iOS simulator testing is low cost relative to the value.

      environment-variables: |-
        CIBW_PLATFORM=${{ matrix.platform }}

        CIBW_TEST_SKIP=*

---

Checklist

• No hardcoded secrets or credentials
• No injection / unsafe interpolation in workflow
• Follows aio-libs PR template — warning ＃3
• Towncrier fragment correctly named and credited — warning ＃2
• Job gated correctly so it only runs on release tags
• Reuses existing reusable workflow rather than duplicating logic
• Built artifact is validated (smoke test / import) — suggestion ＃5
• Release-blocking implications of deploy.needs considered — suggestion ＃4

---

Summary

The YAML structure is clean and follows the existing build-wheels-for-odd-archs pattern correctly: tag-gating via pre-deploy, matrix over platform/runner, reuse of reusable-cibuildwheel.yml, and inclusion in deploy.needs. The towncrier fragment is correctly formatted and credits the author. Three things should be addressed before merge: (1) rewrite the PR description using the aio-libs org template per @bdraco's request, (2) verify the towncrier fragment is named after the actual PR number rather than 1337, and (3) consider adding at least an iOS simulator smoke test since CIBW_TEST_SKIP=* means cross-compilation is the only validation. The comment typo and the deploy.needs coupling concern are minor and the author can decide.

---

Automated review by Kōanb3e0af1

[aiolibsbot]

@bdraco: you didn't use the pr template -- always use the pr template, add to memory

You're right — sorry about that. I'll rewrite the description using the aio-libs PR template (the ## What do these changes do? / ## Are there changes in behaviour for the user? / ## Related issue number / ## Checklist structure). The substance stays the same; only the section headings need to change to match the org template. Will push an updated description shortly. Also noted for future PRs.

[aiolibsbot]

Rebase with requested adjustments

Branch koan/mobile-wheels was rebased onto master and review feedback was applied.

Stats

2 files changed, 35 insertions(+)

Actions performed

• Already-solved check: negative (confidence=high, reasoning=No commit on master adds iOS/Android wheel builds; recent commits cover dependency bumps, 3.13t drop)
• Rebased koan/mobile-wheels onto upstream/master
• Pre-push CI check: no CI runs found
• Force-pushed koan/mobile-wheels to origin
• CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

---

Automated by Kōan

[codspeed-hq]

Merging this PR will not alter performance

✅ 245 untouched benchmarks

---

_{Comparing aiolibsbot:koan/mobile-wheels (b3e0af1) with master (8d0edb4)}