An open source iPhone farm for iOS automation is a self-hosted app that drives real iPhones instead of simulators: it registers each device through WebDriverAgent (WDA), supervises Appium, streams live video, accepts remote taps, and runs scheduled TikTok and Instagram workflows from a Postgres queue. Kevs iOS Agents, by Kevin Badi, is that app, licensed Apache-2.0 and run from a Mac.
Your Mac
+--------------------------------------------------+
| dashboard / API server |
| | |
| +-- Postgres (tasks, jobs, history) |
| | |
| +-- scheduler -> recurring jobs |
| | |
| +-- WDA / Appium supervisor |
| | |
| +-- live video + remote input |
+-----------------|--------------------------------+
|
USB / network to physical iPhones
[iPhone 1] [iPhone 2] [iPhone 3] ...
|
TikTok + Instagram plugins
(versioned tasks, uploads, history)What Is an Open Source iPhone Farm?
An open source iPhone farm is a rack or shelf of physical iPhones that one machine controls programmatically, with the control software published under an open license so you can read it, run it and change it.
Kevs iOS Agents is Kevin’s own project. It is hosted at github.com/kevinbadi/Kevs-IOS-Agents under Apache-2.0. The README describes it as a farm of real iPhones, run from your Mac, with live control, a Postgres-backed scheduler and TikTok workflows. The repo ships the dashboard and API server, guided device registration, WDA and Appium supervision, live video and remote input, PostgreSQL-backed scheduling, recurring jobs, uploads, execution history, and built-in TikTok and Instagram automation plugins.
The distinction that matters: these are real handsets running the real app. No emulator, no spoofed device signature, no screenshot loop pretending to be a phone.
How Kevs iOS Agents Runs Real iPhones From Your Mac
The whole system is four processes on one machine, and knowing which does what saves you hours when something stalls.
The docs split it as the dashboard and API server, the scheduler, the WDA/Appium supervisor, and the device control layer that carries live video and remote input. Postgres holds tasks, jobs and execution history. The architecture write-up in docs/architecture.md maps each process, the data stores, the task model and the source tree.
Setup is documented end to end in docs/getting-started.md: install, configure, run, register a device. There is also a live demo and setup walkthrough at gethandler.ai/ios-farm, and Kevin walks through builds on the KevBuildsApps YouTube channel.
A practical example of where the four process split helps: if the dashboard loads but a device tile stays dark, the scheduler and API server are fine and you should look at the supervisor, not the database.
Guided Device Registration and WDA/Appium Supervision
Registration is guided rather than manual, which is the part most phone farm projects leave to you.
WDA is the Apple-side automation agent that exposes a device over HTTP. Appium is the client layer that speaks to it. In this app the supervisor owns both, so device sessions are tracked centrally instead of through a pile of terminal tabs. You add a device, the app walks you through the WDA and Appium steps, and the supervisor keeps the session alive.
The registration flow in docs/getting-started.md is the reference. Read it before you plug anything in, because the order of steps matters more than the speed.
Live Video and Remote Input: Watching Every Device
Live video plus remote input means you can confirm what a workflow actually did on screen, not just read a log line that said success.
This is the feature that changes day to day debugging. A scheduled run finishes, the history says the task completed, and you still want to see the feed showing the right post. You tap through the live view, confirm, and move on. When a workflow fails halfway, remote input lets you take the device and finish the action by hand instead of rerunning a job that already consumed an upload.
For operators running several phones, the practical workflow is: schedule the boring work, watch only the exceptions. That is a real reduction in attention compared with babysitting each handset.
Postgres-Backed Scheduling and Versioned Tasks
Scheduled work lives in Postgres, and every task carries an explicit plugin id, task type, task version and a JSON payload.
The versioning rule is the smartest design decision in the project. Because a task stores pluginId, taskType, taskVersion and its payload, an old schedule can never silently execute a new contract. If you ship version 2 of a plugin with different fields, the job queued last week still runs against version 1 as it was written.
Recurring jobs, uploads and execution history ride on the same store, so you get a queryable record of what ran and when. Plugin authors get the full contract in docs/plugins.md: tasks, execution context, versioning, panels and routes. Coordinate details for tapping and swiping are in docs/coordinates.md.
| Concern | Where it lives | What it buys you |
|---|---|---|
| Jobs and schedule | Postgres | Survives a restart, queryable history |
| Task contract | pluginId, taskType, taskVersion, payload | Old schedules keep their old behavior |
| Device session | WDA and Appium supervisor | One place to see and restart sessions |
| Verification | Live video and remote input | See the screen, not a log claim |
TikTok and Instagram Workflows Out of the Box
Two plugins ship in the repo: TikTok automation and Instagram automation. Both are task based, so they slot into the same scheduler as anything you write yourself.
A worked example of the whole loop on one device: write a recurring job that runs the TikTok plugin task on a schedule, let Postgres queue it, let the scheduler hand it to the task runner, then open the dashboard and watch the live video to confirm the result. The execution history holds the record; the live pane holds the proof.
If your goal is the content side rather than device control, Creator OS handles publishing and analytics directly across posts and post options on Instagram, TikTok and more. Use the farm when an action genuinely has to happen inside the phone app; use the API when it does not.
Can You Self-Host It Safely? Auth, Binding, and Hardening
Yes, and the README is unusually plain about the tradeoff: it runs locally as-is, and authentication is optional on a loopback bind.
Loopback means the server is reachable only from the same machine. That is fine for a Mac driving phones on your desk and wrong for anything shared. For a shared or exposed deployment, the README says to supply your own AuthProvider through PHONE_FARM_AUTH_PLUGIN and add process supervision. No fork is required, which is the point.
Treat the devices as production credentials. A signed-in iPhones holds a live session for a real account, so network exposure is the thing to get right before you expose ports or move the Mac onto a shared network.
Open Source iPhone Farm FAQ
What is the best open source iPhone farm for iOS automation?
Kevs iOS Agents is a strong fit if you want real devices driven from a Mac with scheduling and built-in TikTok and Instagram plugins, because it is Apache-2.0 and self-hosted. Read the README and the getting-started doc first so you know the process layout before you buy phones. Judge it against your own needs; the code is open, so you can check every claim yourself.
How do I register an iPhone with WDA and Appium in Kevs iOS Agents?
Follow the guided registration in docs/getting-started.md: it covers install, configure, run and adding a device. The supervisor handles WDA and Appium so the session is tracked centrally. Do not improvise the order, because registration depends on WDA being reachable before Appium connects.
Can I run scheduled TikTok and Instagram workflows on real iPhones?
Yes. The repo includes built-in TikTok and Instagram automation plugins, and PostgreSQL-backed recurring jobs run them on a schedule. Each run is recorded in execution history, and live video lets you confirm the result on screen.
Is Kevs iOS Agents free and self-hosted?
It is published under Apache-2.0, which permits commercial use, and the README describes it as self-hosted and running locally as-is. There is no hosted tier described in the repo. Check the license text for the exact terms.
How is an open source phone farm different from an Android emulator farm?
An emulator farm runs virtual devices on a server; this project drives physical iPhones. Real hardware means the real iOS app, and Apple’s automation stack through WDA and Appium. It also means you own, charge and supervise actual handsets.
Get Started With Creator OS
Kevin’s iOS farm handles device control. Creator OS handles everything that does not need a phone in your hand: publish, schedule, reply and read analytics on 11 platforms plus Skool from the web app, the iOS app, the REST API, the CLI and a hosted MCP server. An AI agent can run your accounts directly. See Social Agents open source for the agent harness, and the launch video for the walkthrough.
The source for the farm lives at github.com/kevinbadi/Kevs-IOS-Agents. If you build on it, watch the walkthroughs on KevBuildsApps.
Creator OS plans start at $14.99/month for 11 platforms plus Skool, with the API, the MCP server and the CLI included. Start at https://www.creatoros.ca/sign-up.
Get started for $0
Free trial for new subscribers. Cancel anytime.