Odevio CLI: building and signing iOS apps without a Mac, driven by an AI agent
Build, sign and publish iOS apps from any OS - no Mac, no Xcode. Driven by your AI agent
At a glance
- What is it?
- Odevio is a Python CLI that runs Flutter iOS builds and code signing on remote Macs, and its documented primary interface is an AI agent skill rather than a human operator. The design is coherent, but the README leaves several operational questions open.
- Who is it for?
- Adopt Odevio if you ship Flutter apps and have no Mac in the loop, and you accept that the build and signing step runs on Odevio's remote machines rather than your own hardware. Do not adopt it if you need a fully self-hosted, offline toolchain, or if you want to inspect the code that performs signing.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Who Odevio is aimed at, and what it replaces
The problem Odevio targets is concrete: producing a signed iOS build normally requires macOS and Xcode, which rules out Linux and Windows machines as build hosts. The README frames the project around Flutter specifically, and around developers who want to avoid the iOS ecosystem's paperwork. Its stated mission is to let anyone build and publish an iOS app through an AI agent, without owning a Mac or knowing the iOS ecosystem. That is two audiences in one sentence, and they are not the same. The first is a Flutter developer on Linux or Windows who knows what a provisioning profile is but does not want to maintain a Mac. The second is someone who does not know what a provisioning profile is and wants an agent to handle it. The README addresses both, and the ordering of the sections tells you which one the maintainers expect to grow. Installation and the agent skill come before the manual CLI walkthrough. If you are in the first group, the CLI section is the part that matters to you. If you are in the second, the agent path is the documented default.
The mechanism: a remote Mac, a CLI, and an agent skill
Odevio is a Python CLI installed from PyPI. The build and signing work happens on remote Macs operated by Odevio, not on your machine. That is the whole architecture in one line, and the README does not describe anything beyond it: there is no diagram of the build machine, no statement about which macOS or Xcode versions are available, and no description of how your source reaches the remote host. The README does say Odevio manages certificates, devices, provisioning profiles, bundle IDs and Xcode configuration on your behalf, and that it fixes build failures before hosting the app or shipping it to TestFlight and the App Store. The agent integration is delivered as a skill. Running odevio skill install sets up Claude Code, described as the first AI agent supported, which implies the skill format is intended to extend to others later. Once installed, the documented workflow is that you ask the agent in plain language to put your app on your iPhone, and the agent drives the CLI underneath. The CLI is therefore the substrate and the skill is a wrapper over it, which is a sensible split: anything the agent can do, you can do by hand.
Getting it running: the documented command sequence
Installation is a single pip command: pip install odevio. From there the README gives two paths. The agent path is odevio skill install, followed by a plain-language request inside your Flutter project. The manual path starts with odevio signup to create an account, then odevio build start --build-type configuration, which the README describes as starting a build machine in configuration mode to configure Xcode or test the app in the iOS simulator. For a real build you link an Apple Developer account and create an app identifier. The README gives the exact invocation: odevio apple add --apple-id APPLE_TEAM_ID --name TEXT --key-id APPLE_KEY_ID --issuer-id APPLE_ISSUER_ID --private-key LOCATION_APPLE_PRIVATE_KEY, followed by odevio app mk --name MY_APP_NAME --bundle-id COM.COMPANY.APP_NAME. From there the build type decides the output. ad-hoc produces an IPA for a physical test device, and the README shows odevio build start --build-type ad-hoc followed by odevio build ipa. publication is the App Store path, invoked as odevio build start --build-type publication. Failures are inspected with odevio build logs. Note the shape of the credential flags: --key-id, --issuer-id and --private-key are App Store Connect API key material, and --private-key takes a path to a local file rather than the key itself. That is the safer of the two options, but it also means the key is read from your filesystem and transmitted to Odevio's infrastructure.
What the README does not tell you
The gaps are worth listing plainly, because they are the questions you would ask before putting production credentials into a third-party service. First, the README does not state where the remote Macs run, what macOS and Xcode versions they carry, or whether you can pin a version. Flutter and Xcode version drift is the single most common cause of an iOS build that worked last month failing today, and nothing in the supplied material addresses it. Second, there is no statement about how the App Store Connect private key is stored, whether it is encrypted at rest, or how you revoke access. Third, the README does not say whether odevio build logs persists logs after a build machine is torn down, or how far back it goes; it presents the command without qualification. Fourth, the phrase about fixing build failures is not expanded. It is not clear whether that means the agent edits your source, changes Xcode settings on the remote machine, or something else. That distinction matters a great deal if you need reproducible builds. None of this makes the tool unusable, but each item is a question the documentation should answer before you hand it a signing identity.
Where Odevio is the wrong tool
The clearest mismatch is anyone who needs the signing step to stay on hardware they control. Odevio's value proposition is that the Mac is not yours, which is also its constraint: the private key and the provisioning profile are handled on Odevio's side. If your organisation treats a distribution certificate as something that never leaves an audited machine, this tool is not for you, and no amount of CLI convenience changes that. A second mismatch is non-Flutter projects. The README talks about Flutter throughout, and the contributing section says the repository exists to make Flutter developers' lives easier. Nothing in the material claims support for React Native, native Swift, or Kotlin Multiplatform, so treat Flutter as the supported case. A third is the offline or air-gapped environment, which cannot work here at all since the build host is remote. Finally, if your team already has a working macOS CI runner, Odevio replaces something that is already paid for, and the migration cost is only justified if you are trying to remove Macs from the fleet.
Fastlane and the difference in approach
The repository topics list fastlane-alternative, which invites the comparison. Fastlane is a Ruby toolchain that you run yourself, typically on a Mac or a macOS CI runner, and it automates the same territory: certificates via match, provisioning profiles, TestFlight uploads, App Store submission. The difference is where the machine lives. Fastlane assumes you have a Mac somewhere and gives you a scripted way to drive it. Odevio assumes you do not and rents you one, wrapping the same category of operations behind its own commands and behind an agent skill. That changes who debugs the failure. With Fastlane, a broken signing configuration is your problem on your runner. With Odevio, the README says the tool fixes build failures for you, which is convenient right up until you need to understand why a build failed. The two are not mutually exclusive in principle, but nothing in the supplied material describes using Odevio alongside Fastlane, so do not assume the lanes you already wrote will be reused.
Licence, maintenance and what a version bump costs you
Odevio-CLI is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the CLI code in this repository. It does not cover the remote build service, and the README gives no separate terms for that side, so the licence tells you nothing about the hosted Macs, the account you create with odevio signup, or the pricing. That distinction is easy to miss when a repository is MIT and the product is not. On maintenance: the releases listed are v1.2.0 in November 2023, v1.2.1 in December 2023 and v1.2.2 in February 2024, while the README badge shows version 1.3.1 and the repository's last push is dated 2026. The README also carries an UptimeRobot badge, which suggests the hosted service is monitored, though the badge reports uptime rather than release cadence. The practical cost of upgrading is the part the material cannot settle. Because the build runs remotely, a CLI upgrade and a remote toolchain change can arrive independently, so a version bump that looks minor in the changelog may still alter your build output. Pin the version in your CI and read the release notes before moving it. Nothing here is legal advice; if you are redistributing the CLI or handling other people's signing identities, get your own review.
Editorial conclusion
Adopt Odevio if you ship Flutter apps and have no Mac in the loop, and you accept that the build and signing step runs on Odevio's remote machines rather than your own hardware. Do not adopt it if you need a fully self-hosted, offline toolchain, or if you want to inspect the code that performs signing. Before committing, verify three things in the documentation: what the configuration build type actually exposes for Xcode setup, whether odevio build logs retains history across build machines, and how the Apple Developer credentials passed to odevio apple add are stored and revoked.
Community notes