u/UsefulPomegranate150

I've been thinking about where software can actually reduce environmental impact beyond using less electricity.

The Green Software Foundation describes three broad areas:

• Energy efficiency
• Hardware efficiency
• Carbon awareness

Most discussions focus on the first one.

I maintain an open source project called tapflow that lets teams run iOS simulators and Android emulators in a browser. It can't test camera, NFC, or biometrics, so it reduces how many devices a team needs rather than removing them entirely. We built it to avoid maintaining piles of test devices and paying for hosted device clouds — not because of carbon.

That made me curious about the hardware side.

I compared a team using four dedicated test devices with one using four simulators on a Mac they already owned.

• Devices: 68.2 kg CO₂e/year (55.5 manufacturing, 12.7 electricity)
• Existing Mac: 17.9 kg CO₂e/year (0 manufacturing, 17.9 electricity)

The interesting part is that the Mac actually uses more electricity than charging four phones. The reduction comes almost entirely from manufacturing, because no additional devices are produced.

That raises a question I haven't found a good answer to.

The SCI specification (ISO/IEC 21031:2024) accounts for the hardware a piece of software runs on, but not hardware that was never purchased. Avoided emissions are intentionally outside the model.

So should "hardware that didn't need to be bought" count as an environmental benefit of software?

My intuition is yes — the manufacturing never happened. But I also understand why standards avoid giving software credit for hypothetical purchases.

I'd be interested to hear how others think about this.

• Full calculations: https://github.com/jo-duchan/tapflow/blob/main/contributing/sustainability-carbon-math.md

Have you heard of Suwon Hwaseong, a UNESCO World Heritage Site?

I visited last weekend, and it was one of the most impressive historical places I've been to in Korea. The fortress walls are well preserved, and you can walk along them while looking out over the city.

If you're ever visiting Korea, I'd definitely recommend adding it to your itinerary.

Hi everyone,

I've been working on an open-source project called tapflow, and I'm looking for some early feedback.

The idea is simple: it lets your team use iOS simulators and Android emulators from a browser, so people like PMs, designers, or QA can test mobile builds without installing Xcode or Android Studio.

Current features:

• Self-hosted (your app builds stay on your own infrastructure)
• Browser access to iOS simulators and Android emulators
• Low-latency streaming with touch and keyboard input
• Session recording
• MIT licensed

Current limitations:

• A Mac is required as the simulator host (Apple limitation)
• It works with simulators and emulators, not physical devices
• It's still in v0.x and there's still a lot to improve

I'm curious about a few things:

• Is this something your team would actually use?
• Would self-hosting be a dealbreaker, or a benefit?
• What would be missing before you'd consider trying it?
• If you tried the setup, was anything unclear?

GitHub:
https://github.com/jo-duchan/tapflow

If you have a few minutes to look through it, I'd love to hear what you think. Any kind of feedback is helpful.

PMs, designers, and backend engineers on our team often needed to check a staging build. Sometimes they wanted to verify a layout, sometimes reproduce a bug, or just confirm that an API change behaved the way they expected.

Sending the build wasn't the hard part.

Actually running it was.

Most people didn't have Xcode or Android Studio set up, and asking them to install everything just to check one build wasn't realistic. The alternative was usually asking a mobile developer to install the app or share their screen, which happened more often than we'd have liked.

We looked at services like Appetize and BrowserStack, but they didn't really fit how we work. We already had Macs available internally, and we weren't comfortable uploading app binaries to an external service just so teammates could review a staging build.

So I started building an open-source tool that runs iOS simulators and Android emulators on a Mac and streams them to the browser.

The idea wasn't to replace TestFlight or Appetize. I just wanted an easier way for teammates to review staging builds without needing a mobile development setup.

It's still early (v0.x), but building it has taken me into a lot of areas I hadn't worked on before—video streaming, low-latency input forwarding, simulator orchestration, and React Native QA workflows.

I'm curious how other React Native teams handle this.

How do non-mobile developers on your team review staging builds?

• TestFlight?
• Internal APKs?
• BrowserStack or Appetize?
• Something else?

If you're interested, here's the project:

https://github.com/jo-duchan/tapflow

Seoul Forest is one of the largest parks in Seoul. I like working here from time to time. It's a nice place to get some fresh air and focus for a few hours.