Back to News & Insights
Web Development August 10, 2026 · 8 min read

Most of a test phone's carbon is emitted before the first test runs

There is a drawer in most mobile teams' offices. Mine had fourteen phones in it. Two iPhones were...

Most of a test phone's carbon is emitted before the first test runs

There is a drawer in most mobile teams' offices. Mine had fourteen phones in it.

Two iPhones were frozen on old iOS versions with updates blocked, because you can't roll iOS back. An iPad nobody had charged in months. A few Android devices we kept around because one manufacturer had shipped an interesting bug.

And the drawer only helped people who could already build the app. Everyone else had to interrupt a mobile developer just to see a build running.

We looked at hosted device clouds first and stopped before signing up. The price scaled with the team, and our app binary would have to leave our network. So we built tapflow instead: an open-source, self-hosted tool that streams iOS simulators and Android emulators into the browser, so anyone on the team can test a build from a URL.

But while working on it, I realized that if the answer to "we don't have enough test devices" is "buy fewer test devices," there's another consequence besides the budget. Most of a phone's carbon footprint is already there before anyone starts using it.

| Device | Total LCA | Production share | | ------------------------ | --------: | ---------------: | | iPhone 17 (256 GB) | 55 kg | 76% | | iPad (A16, 128 GB) | 74 kg | 74% | | Mac mini (M4) | 32 kg | 74% | | MacBook Pro 14" (M2 Pro) | 243 kg | 79% |

Three quarters or more of each device's lifetime footprint comes from production.

That changes how I think about test hardware. Using a phone more often doesn't make its manufacturing footprint worse, and leaving it in a drawer doesn't make it better. That carbon was already emitted when the device was manufactured.

So a test phone used twice a month is particularly inefficient from a hardware-utilization perspective: almost the full manufacturing footprint, for very little actual use.

Test devices get replaced because of OS support windows and the need to validate new releases. That's the same reason two iPhones in my drawer had their updates permanently blocked.

A machine hosting simulators has less of that pressure. It's mostly memory-bound, runs headless, and can stay in service until its macOS version can no longer run the Xcode version you need.

Over eight years, replacing four test devices accounts for 444 kg of manufacturing carbon. One MacBook Pro accounts for 196.8 kg once.

So the question I became interested in wasn't how efficiently we test. It was how much hardware we had to buy to test at all.

Take a team that needs coverage equivalent to four test devices — say three iPhones and an iPad.

They can buy those devices, or run four simulators on a Mac they already own. Four is about the practical ceiling on a 32 GB host.

Manufacturing carbon comes from Apple's per-product environmental reports, divided by expected service life using Apple's own assumptions: three years for an iPhone, four years for an iPad and a Mac.

The model assumes 1,000 session hours per year, with 30% of that time spent actively interacting with the app. The active power figure is measured rather than estimated; the commands to reproduce that measurement are near the end of this post.

| | 4 physical devices | tapflow (Mac already owned) | | ------------------------- | -----------------: | --------------------------: | | Manufacturing, annualised | 55.5 kg | 0 kg | | Electricity | 12.7 kg (30.4 kWh) | 17.9 kg (42.9 kWh) | | Total | 68.2 kg/yr | 17.9 kg/yr |

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation