Codemagic.

Where Codemagic fits on a long engagement.

iOS builds require macOS, which is the constraint that makes mobile CI different from everything else. The alternatives are a hosted macOS runner or a physical Mac somebody maintains, and the second is a single point of failure that is invariably discovered at the worst moment.

Mobile-specific services handle the parts general CI platforms make awkward: signing certificates, provisioning profiles, and publishing to both stores. A general-purpose runner can do all of it, but the configuration is longer and the failure modes are less obvious.

What an assigned team does with Codemagic.

Build minutes on managed macOS are expensive enough that pipeline efficiency is a cost question rather than a convenience one. Caching dependencies and running the right workflows on the right triggers has a directly visible effect on spend.

Treating that as ongoing rather than a setup task is part of how platform capacity is assigned under devops as a service.

What we use Codemagic for.

• iOS builds without owning a Mac Managed macOS runners, so no physical machine is a release dependency.
• Publishing to both stores from one pipeline TestFlight and Play submissions from the same workflow rather than two manual processes.
• Keeping build spend in proportion Caching and trigger discipline, because managed macOS minutes are the expensive resource.

How Codemagic capacity is assigned.

Mobile CI is scoped with the mobile capacity it serves, under the same agreement rather than as a separate engagement.