Developing for Android on an 8-Year-Old MacBook Air: A Survivor's Guide

All tests run on an 8-year-old MacBook Air (Intel). This isn't a nostalgic flex—it's a constraint that shaped every architectural decision in my toolchain.

"Your hardware is too old." I've heard this from every tool's system requirements page. But an Intel MacBook Air from 2018 with 8GB of RAM still has a dual-core i5 and an SSD. The machine isn't the problem—the software running on it is. Here's how I develop Android tools full-time on hardware most people consider obsolete.

TL;DR

• Tauri v2 uses ~25MB RAM per app vs. Electron's ~350MB—critical when you only have 8GB total.
• Custom Rust engines avoid the overhead of general-purpose libraries, cutting compile times by 40%.
• Built HiyokoBar specifically to monitor system resources in real-time from the menu bar.
• Profiling with sysinfo crate and Activity Monitor keeps memory leaks from killing productivity.

Know Your Budget

On an 8GB machine, every megabyte matters. Here's my typical memory breakdown during a development session:

macOS system:       ~2.5 GB
Xcode/Terminal:     ~1.2 GB
VS Code:            ~800 MB
Android Emulator:   NOT AN OPTION (2GB+ alone)
Remaining for apps: ~3.5 GB

This means my entire suite of development tools needs to fit in that 3.5GB window alongside whatever I'm actually working on. An Electron app eating 350MB just to show a file list is out of the question.

Lean Backends: Tauri over Electron

The single biggest decision was choosing Tauri v2 over Electron. On my machine, the difference isn't marginal—it's the difference between a usable system and a frozen one.

// tauri.conf.json — optimized for minimal footprint
{
  "app": {
    "windows": [
      {
        "width": 900,
        "height": 600,
        "resizable": true,
        "decorations": true
      }
    ]
  },
  "bundle": {
    "active": true,
    "targets": ["dmg"],
    "macOS": {
      "minimumSystemVersion": "10.15"
    }
  }
}

Tauri uses the system WebView (WKWebView on macOS), so the binary ships without a bundled browser engine. My apps average 8-12MB on disk. An equivalent Electron app starts at 150MB before you write a single line of business logic.

Custom Engines over Bloated Libraries

Standard libraries often include everything. When you're building an MTP file manager, you don't need a library that also supports PTP, USB audio, and printer protocols. By writing focused Rust engines, I only pay for the features I actually use.

The compile-time impact matters too. On my dual-core i5:

# Compile time comparison on MacBook Air (Intel i5, 2 cores)
# Full libmtp wrapper crate:  ~4 min 20 sec (pulls in C dependencies)
# Custom focused MTP engine:  ~2 min 35 sec (pure Rust, nusb-based)

# For 10 apps sharing a workspace, this adds up fast
cargo build --release -p hiyoko-mtp  # 2m 35s
cargo build --release -p hiyoko-shot # 1m 48s
cargo build --release -p hiyoko-clip # 1m 22s

Real-Time Monitoring with HiyokoBar

I built HiyokoBar out of necessity. When a background process starts leaking memory, I need to know before the UI starts lagging—not after the system forces a reboot.

use sysinfo::System;

fn collect_system_metrics() -> SystemSnapshot {
    let mut sys = System::new();
    sys.refresh_all();

    let cpu_usage = sys.global_cpu_usage();
    let used_mem = sys.used_memory();    // in bytes
    let total_mem = sys.total_memory();

    // Trigger warning when memory pressure exceeds 85%
    let mem_ratio = used_mem as f64 / total_mem as f64;
    let pressure_alert = mem_ratio > 0.85;

    SystemSnapshot {
        cpu_usage,
        mem_used_mb: used_mem / 1_048_576,
        mem_total_mb: total_mem / 1_048_576,
        pressure_alert,
    }
}

HiyokoBar polls every 2 seconds and displays CPU, memory, and disk I/O in a translucent menu bar popover. When memory pressure crosses 85%, it highlights red. On an 8GB machine, this early warning has saved me from hard resets more times than I can count.

Survival Tips

After three years of daily-driving this setup:

1. Never run the Android Emulator. Use a physical device over USB or Wi-Fi ADB. The emulator alone consumes more RAM than my entire toolkit.
2. Kill IDE language servers you're not using. Rust-analyzer is heavy. If I'm in a React-only editing session, I disable it.
3. Profile before optimizing. The sysinfo crate and instruments on macOS tell you what's actually slow, not what you think is slow.
4. Incremental builds only. Full cargo clean && cargo build is a 15-minute commitment. Structure your workspace so incremental builds touch only the crate you changed.

Don't let your hardware define your productivity. With the right architecture and a focus on native performance, an 8-year-old Mac can outperform a modern machine drowning in unoptimized software.

What's the oldest hardware you're still actively developing on? I'm curious how others handle the constraints.

---

If this was helpful, check out HiyokoBar — macOS menubar HUD for engineers with Gemini AI error analysis.

Built with Rust + Tauri v2. Tested on an 8-year-old MacBook Air.