DEV Community: ArshTechPro

Maestro Deep Dive: Testing a SwiftUI App End to End

ArshTechPro — Tue, 27 Oct 2026 19:13:41 +0000

In Part 1 we covered what Maestro is, how it works and how it compares to Appium, XCUITest, Detox and the paid device clouds. Now it is time to write real tests.

In this article we will:

Build a small SwiftUI app with a login screen and a to-do list.
Make it testable with accessibility identifiers.
Write a Maestro suite with reusable sub-flows, environment variables, conditional logic, JavaScript and tags.
Run it locally, generate reports and debug failures.
Look at how the same test would look in XCUITest, and where AI agents fit in.

Everything here uses the free, open-source Maestro CLI. The full app is about 120 lines of Swift, so you can copy it into a new Xcode project and follow along.

Prerequisites

macOS with Xcode 16 or newer and an iOS 17+ Simulator runtime
Java 17 or newer (java -version)
Maestro CLI:

curl -fsSL "https://get.maestro.mobile.dev" | bash
maestro --version

This article was written against Maestro CLI 2.10.0.

Part A: The sample app

Create a new Xcode project:

Template: iOS > App
Product name: TodoDemo
Organization identifier: com.example
Interface: SwiftUI
Minimum deployment: iOS 17

That gives the bundle ID com.example.TodoDemo, which Maestro uses as the appId.

The app has two screens:

Login: email, password, a "Log In" button and an error message for wrong credentials. The valid credentials are demo@example.com / password123.
My Tasks: add tasks, tap to complete them, swipe to delete, see a progress label, and log out. After login it asks for notification permission, which gives us a system dialog to deal with.

`TodoDemoApp.swift`

import SwiftUI

@main
struct TodoDemoApp: App {
    @AppStorage("isLoggedIn") private var isLoggedIn = false

    var body: some Scene {
        WindowGroup {
            if isLoggedIn {
                TodoListView()
            } else {
                LoginView()
            }
        }
    }
}

The login state is stored in UserDefaults through @AppStorage. That matters for testing: it survives an app restart, so we will need to clear app state between tests.

`LoginView.swift`

import SwiftUI

struct LoginView: View {
    @AppStorage("isLoggedIn") private var isLoggedIn = false
    @State private var email = ""
    @State private var password = ""
    @State private var errorMessage: String?

    var body: some View {
        NavigationStack {
            Form {
                Section {
                    TextField("Email", text: $email)
                        .keyboardType(.emailAddress)
                        .textInputAutocapitalization(.never)
                        .autocorrectionDisabled()
                        .accessibilityIdentifier("emailField")

                    SecureField("Password", text: $password)
                        .accessibilityIdentifier("passwordField")
                }

                if let errorMessage {
                    Text(errorMessage)
                        .foregroundStyle(.red)
                        .accessibilityIdentifier("loginError")
                }

                Button("Log In", action: logIn)
                    .accessibilityIdentifier("loginButton")
                    .disabled(email.isEmpty || password.isEmpty)
            }
            .navigationTitle("Welcome")
        }
    }

    private func logIn() {
        // Demo only. A real app would call an auth service here.
        if email.lowercased() == "demo@example.com" && password == "password123" {
            errorMessage = nil
            isLoggedIn = true
        } else {
            errorMessage = "Invalid email or password"
        }
    }
}

`TodoListView.swift`

import SwiftUI
import UserNotifications

struct TodoItem: Identifiable {
    let id = UUID()
    var title: String
    var isDone = false
}

struct TodoListView: View {
    @AppStorage("isLoggedIn") private var isLoggedIn = false
    @State private var items: [TodoItem] = []
    @State private var newTitle = ""

    private var doneCount: Int { items.filter(\.isDone).count }

    var body: some View {
        NavigationStack {
            VStack(spacing: 12) {
                HStack {
                    TextField("New task", text: $newTitle)
                        .textFieldStyle(.roundedBorder)
                        .onSubmit(addItem)
                        .accessibilityIdentifier("newTaskField")

                    Button("Add", action: addItem)
                        .accessibilityIdentifier("addTaskButton")
                        .disabled(newTitle.trimmingCharacters(in: .whitespaces).isEmpty)
                }
                .padding(.horizontal)

                if items.isEmpty {
                    ContentUnavailableView(
                        "No tasks yet",
                        systemImage: "checklist",
                        description: Text("Add your first task above.")
                    )
                } else {
                    List {
                        ForEach($items) { $item in
                            Button {
                                item.isDone.toggle()
                            } label: {
                                HStack {
                                    Image(systemName: item.isDone ? "checkmark.circle.fill" : "circle")
                                    Text(item.title)
                                        .strikethrough(item.isDone)
                                }
                            }
                        }
                        .onDelete { items.remove(atOffsets: $0) }
                    }

                    Text("\(doneCount) of \(items.count) done")
                        .font(.footnote)
                        .foregroundStyle(.secondary)
                        .accessibilityIdentifier("progressLabel")
                }
            }
            .navigationTitle("My Tasks")
            .toolbar {
                ToolbarItem(placement: .topBarTrailing) {
                    Button("Log Out") { isLoggedIn = false }
                        .accessibilityIdentifier("logoutButton")
                }
            }
            .task {
                _ = try? await UNUserNotificationCenter.current()
                    .requestAuthorization(options: [.alert, .sound])
            }
        }
    }

    private func addItem() {
        let title = newTitle.trimmingCharacters(in: .whitespaces)
        guard !title.isEmpty else { return }
        items.append(TodoItem(title: title))
        newTitle = ""
    }
}

Run it once in the Simulator from Xcode to make sure it works.

Why the accessibility identifiers?

Maestro can find elements by visible text (tapOn: "Log In"), and that is often fine. But text changes: a designer renames "Log In" to "Sign In", or you test in German. Identifiers do not change with copy or locale.

A practical rule:

Static controls (buttons, fields, labels you assert on): give them an accessibilityIdentifier and target them with id.
Dynamic content (task titles, user names, server data): target by text, because the text is the thing you are verifying.

You can see exactly what Maestro sees with:

maestro hierarchy

or by opening the Maestro Studio desktop app and clicking on elements in the live device view.

Part B: Build and install for the Simulator

Maestro tests the Simulator build of your app (.app). You can install it by running from Xcode, or from the command line, which is what CI will do:

# Boot a simulator (the device name depends on your installed runtimes)
xcrun simctl boot "iPhone 16" || true

# Build for the simulator
xcodebuild \
  -project TodoDemo.xcodeproj \
  -scheme TodoDemo \
  -configuration Debug \
  -sdk iphonesimulator \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  -derivedDataPath build \
  build

# Install the .app on the booted simulator
xcrun simctl install booted build/Build/Products/Debug-iphonesimulator/TodoDemo.app

Part C: The test suite

Here is the structure we are going to build:

.maestro/
├── config.yaml
├── subflows/
│   ├── login.yaml
│   └── dismiss_permission_dialog.yaml
└── flows/
    ├── 01_login_invalid.yaml
    ├── 02_login_success.yaml
    ├── 03_add_and_complete_tasks.yaml
    ├── 04_delete_task.yaml
    └── 05_session_and_logout.yaml

flows/ contains the tests. subflows/ contains reusable building blocks that are never run on their own.

`config.yaml`: the workspace configuration

# Only files matching these patterns are treated as tests.
# Sub-flows live outside flows/, so they are not run directly.
flows:
  - "flows/*"

When you run maestro test .maestro/, Maestro reads this file to decide which flows belong to the suite.

Sub-flow 1: `login.yaml`

appId: com.example.TodoDemo
---
- tapOn:
    id: "emailField"
- inputText: ${EMAIL || 'demo@example.com'}
- tapOn:
    id: "passwordField"
- inputText: ${PASSWORD || 'password123'}
- tapOn:
    id: "loginButton"

Two things to notice:

Everything inside ${...} is JavaScript. EMAIL || 'demo@example.com' means "use the EMAIL variable if someone passed one, otherwise fall back to the default". That lets the same sub-flow handle valid and invalid logins.
There are no waits. After tapOn: { id: "emailField" }, Maestro waits for the screen to settle before typing.

Sub-flow 2: `dismiss_permission_dialog.yaml`

appId: com.example.TodoDemo
---
- runFlow:
    when:
      visible: "Allow"
    commands:
      - tapOn: "Allow"

This is a conditional flow. If the system notification dialog is on screen, tap "Allow". If it is not, do nothing and continue. Because Maestro drives the whole device rather than just your app process, it can tap system alerts that in-process frameworks cannot reach directly.

We will mostly avoid the dialog entirely by pre-granting permissions in launchApp, but this sub-flow is a safety net for cases where you cannot.

Test 1: `01_login_invalid.yaml`

appId: com.example.TodoDemo
name: Login fails with wrong credentials
tags:
  - auth
  - regression
---
- launchApp:
    clearState: true
- assertVisible: "Welcome"
- runFlow:
    file: ../subflows/login.yaml
    env:
      EMAIL: "wrong@example.com"
      PASSWORD: "not-the-password"
- assertVisible:
    id: "loginError"
    text: "Invalid email or password"
- assertNotVisible: "My Tasks"

clearState: true wipes the app's data before launching, so every test starts logged out. This is the single most important habit for a reliable suite: never let one test depend on what a previous test left behind.
runFlow with env overrides the variables for that sub-flow only.
The selector { id: "loginError", text: "..." } matches an element that has that identifier and that text.

Test 2: `02_login_success.yaml`

appId: com.example.TodoDemo
name: Login succeeds with valid credentials
tags:
  - smoke
  - auth
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml
- assertVisible: "My Tasks"
- assertVisible: "No tasks yet"
- takeScreenshot: after_login

permissions: { notifications: allow } grants the permission before the app starts, so the dialog should never appear. takeScreenshot saves a PNG, which is useful for reviewing UI in CI artifacts.

Test 3: `03_add_and_complete_tasks.yaml`

appId: com.example.TodoDemo
name: Add tasks and mark one as done
tags:
  - smoke
  - tasks
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml

- tapOn:
    id: "newTaskField"
- inputText: "Buy milk"
- tapOn:
    id: "addTaskButton"

- tapOn:
    id: "newTaskField"
- inputText: "Write Maestro article"
- tapOn:
    id: "addTaskButton"

- assertVisible: "Buy milk"
- assertVisible: "Write Maestro article"
- assertVisible:
    id: "progressLabel"
    text: "0 of 2 done"

- tapOn: "Buy milk"
- assertVisible:
    id: "progressLabel"
    text: "1 of 2 done"

Notice how the test reads almost exactly like a manual QA script. That readability is the main reason teams adopt Maestro.

Test 4: `04_delete_task.yaml` (loops, JavaScript and swipes)

appId: com.example.TodoDemo
name: Delete a task with swipe
tags:
  - tasks
  - regression
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml

# Create "Task 1", "Task 2" and "Task 3" using a loop and a JS counter
- evalScript: ${output.counter = 0}
- repeat:
    times: 3
    commands:
      - evalScript: ${output.counter = output.counter + 1}
      - tapOn:
          id: "newTaskField"
      - inputText: "Task ${output.counter}"
      - tapOn:
          id: "addTaskButton"

- assertVisible: "Task 3"

# Swipe left on the row to reveal the system Delete action
- swipe:
    from:
      text: "Task 2"
    direction: LEFT
- tapOn: "Delete"

- assertNotVisible: "Task 2"
- assertVisible: "Task 1"
- assertVisible: "Task 3"
- assertVisible:
    id: "progressLabel"
    text: "0 of 2 done"

output is a JavaScript object Maestro provides for storing values across steps.
repeat runs a block a fixed number of times (it also supports a while condition).
swipe with from starts the gesture on a specific element, which is how you trigger SwiftUI's .onDelete.

Use loops and scripts sparingly. If a flow starts to look like a program, consider seeding data through a test backend or launch arguments instead.

Test 5: `05_session_and_logout.yaml`

appId: com.example.TodoDemo
name: Session persists across restarts until logout
tags:
  - auth
  - regression
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml
- assertVisible: "My Tasks"

# Restart without clearing state: the user should still be logged in
- stopApp
- launchApp
- assertVisible: "My Tasks"

# Log out and confirm we are back on the login screen
- tapOn:
    id: "logoutButton"
- assertVisible: "Welcome"
- assertVisible:
    id: "loginButton"

This test checks behavior that crosses an app restart, something that is awkward to do in many in-process frameworks.

Part D: Running the suite

Make sure the Simulator is booted and the app is installed, then from the project root:

# Run the whole suite
maestro test .maestro/

# Run a single flow
maestro test .maestro/flows/02_login_success.yaml

# Run only smoke tests
maestro test --include-tags smoke .maestro/

# Exclude slow tests
maestro test --exclude-tags regression .maestro/

# Pass variables from the command line
maestro test -e EMAIL=qa@example.com -e PASSWORD=secret .maestro/flows/02_login_success.yaml

Faster authoring with continuous mode

While writing a flow, use continuous mode. Maestro reruns the flow every time you save the file:

maestro test -c .maestro/flows/03_add_and_complete_tasks.yaml

Combined with Maestro Studio for finding selectors, this gives you a feedback loop of a few seconds.

Validate syntax without a device

maestro check-syntax .maestro/flows/04_delete_task.yaml

Useful as a pre-commit hook or a quick CI step.

Reports and artifacts

# JUnit XML, understood by most CI systems
maestro test .maestro/ --format junit --output build/maestro-report.xml

# HTML report for humans
maestro test .maestro/ --format html --output build/maestro-report.html

# Put screenshots, logs and per-flow artifacts in a known folder
maestro test .maestro/ --test-output-dir build/maestro-artifacts

When a flow fails, the artifacts include a screenshot before each step, the view hierarchy at the moment of failure, device logs and crash reports. Start debugging there, not in the terminal output.

Running on several simulators in parallel

If you have more than one simulator booted, you can split the suite across them:

maestro test --shard-split 2 .maestro/

--shard-split divides the flows between devices. --shard-all runs every flow on every device, which is useful for testing several iOS versions or screen sizes at once.

Part E: The same test in XCUITest

To make the comparison from Part 1 concrete, here is roughly what Test 2 (successful login) looks like in XCUITest:

import XCTest

final class LoginUITests: XCTestCase {
    override func setUp() {
        continueAfterFailure = false
    }

    func testLoginSucceeds() {
        let app = XCUIApplication()
        app.launchArguments = ["-isLoggedIn", "NO"]   // reset @AppStorage
        app.launch()

        let email = app.textFields["emailField"]
        XCTAssertTrue(email.waitForExistence(timeout: 5))
        email.tap()
        email.typeText("demo@example.com")

        let password = app.secureTextFields["passwordField"]
        password.tap()
        password.typeText("password123")

        app.buttons["loginButton"].tap()

        // System alerts live in SpringBoard, outside the app under test
        let springboard = XCUIApplication(bundleIdentifier: "com.apple.springboard")
        let allow = springboard.buttons["Allow"]
        if allow.waitForExistence(timeout: 3) {
            allow.tap()
        }

        XCTAssertTrue(app.navigationBars["My Tasks"].waitForExistence(timeout: 5))
        XCTAssertTrue(app.staticTexts["No tasks yet"].exists)
    }
}

XCUITest is not bad. It is fast, it is Apple's own tooling and it runs on physical devices. But compare the two:

	Maestro	XCUITest
Lines for this test	About 10 (plus a reusable sub-flow)	About 30
Explicit waits	None	`waitForExistence` on most steps
System dialogs	`tapOn: "Allow"`	Separate SpringBoard app handle
Resetting state	`clearState: true`	Launch arguments or custom reset code
Rebuild after change	No	Yes, test target recompiles
Reusable on Android	Often, with the same flow	No, rewrite in Espresso
Physical iPhones	Not officially, see Part 1	Yes

Many teams use both: XCUITest or unit tests for detailed component behavior, Maestro for end-to-end user journeys.

Part F: Writing flows with an AI coding agent

Maestro ships an MCP server inside the CLI. It lets an AI coding agent see the simulator, inspect the view hierarchy, run flows and read the results. To connect it, add this to your agent's MCP configuration:

{
  "mcpServers": {
    "maestro": {
      "command": "maestro",
      "args": ["mcp"]
    }
  }
}

Most agents also have a one-line command. For example, with the Codex CLI:

codex mcp add maestro -- maestro mcp

and with the Gemini CLI:

gemini mcp add maestro maestro mcp

Then you can ask something like: "Write a Maestro flow that logs in to TodoDemo, adds three tasks, completes the second one and checks the progress label. Run it and fix it until it passes."

Troubleshooting checklist

Symptom	What to check
`Element not found`	Run `maestro hierarchy` or open Studio. Is the identifier set on the element you think it is? Is the text an exact match?
Tap lands on the keyboard	The keyboard may cover the target. Add `- hideKeyboard` or scroll first with `scrollUntilVisible`.
Test passes locally, fails in CI	CI machines are slower. Use `extendedWaitUntil` with a longer timeout for slow screens, and increase `MAESTRO_DRIVER_STARTUP_TIMEOUT`.
Tests affect each other	Use `launchApp: { clearState: true }` at the start of every flow.
Long animations break assertions	Add `- waitForAnimationToEnd` before the assertion.
`.ipa` will not install	Maestro needs a Simulator build (`.app`) built with `-sdk iphonesimulator`.
Flags stopped working after an upgrade	Check the changelog. `--ios-version` is being replaced by `--device-os`.

Example of a longer explicit wait for a slow screen:

- extendedWaitUntil:
    visible:
      id: "progressLabel"
    timeout: 15000   # milliseconds

Best practices summary

One user journey per flow. Short flows fail for one clear reason.
Reset state at the start of every flow with clearState: true.
Use identifiers for controls, text for content.
Extract repeated steps into sub-flows (login, onboarding, navigation).
Keep logic out of YAML where possible. Seed data through APIs or launch arguments.
Tag your flows (smoke, regression, feature names) and run smoke tests on every PR, the full suite nightly.
Pin the Maestro version in CI and upgrade on purpose.
Always keep artifacts from failed runs.

Ending

With about 120 lines of Swift and five short YAML files, we have a test suite that covers login, error handling, adding, completing and deleting tasks, session persistence, logout and system permission dialogs. It runs locally in under a couple of minutes, runs in GitHub Actions without changes, and can move to a device cloud with one command.

That is Maestro's real value: the distance between "we should test this" and "it is tested in CI" is very short.

Resources

GitHub: mobile-dev-inc/maestro

Maestro: Mobile UI Testing Without the Pain - Introduction

ArshTechPro — Tue, 27 Oct 2026 19:10:57 +0000

If you have ever written mobile end-to-end tests, you probably know the routine. You set up Appium, fight with drivers and capabilities, write a test that passes locally, and then watch it fail in CI because an animation took 200ms longer than expected. You add a sleep(2). Then another. Six months later nobody trusts the suite.

Maestro is an open-source framework built to make that experience less painful. This article covers what it is, how it works, what you should know before adopting it, and how it stacks up against the other free and paid options.

This is Part 1 of a two-part series. Part 2 is a hands-on deep dive with a small SwiftUI app and a complete test suite.

What is Maestro?

Maestro is a UI and end-to-end testing framework for Android, iOS and web apps. Instead of writing tests in Java, Kotlin, Swift or JavaScript, you describe user journeys (called Flows) in YAML:

appId: com.example.myapp
---
- launchApp
- tapOn: "Sign in"
- tapOn: "Email"
- inputText: "jane@example.com"
- tapOn: "Password"
- inputText: "hunter2"
- tapOn: "Continue"
- assertVisible: "Welcome, Jane"

That is a complete, runnable test. No page objects, no driver setup code, no explicit waits.

How Maestro works (and why it matters)

Maestro is a black-box tool. It does not link into your app, does not need an SDK, and does not need your source code. It drives the device the way a user would, and it reads the screen through the platform's accessibility layer and view hierarchy.

On iOS, Maestro installs a small XCTest-based driver on the simulator. On Android, it installs a driver app that talks to UIAutomator. The CLI sends commands to the driver, reads back the UI hierarchy, and decides what to do next.

Three design choices make it feel different from older tools:

1. Automatic waiting. After each command, Maestro waits for the screen to settle before moving on. If you tapOn: "Continue" and the button is not visible yet, it keeps looking for a while before failing. In practice this removes most of the sleep() calls you would write elsewhere.

2. Flakiness tolerance. Mobile UIs are noisy: taps sometimes do not register, elements shift during animations, keyboards appear and disappear. Maestro's commands are designed to retry and re-check rather than fail on the first miss.

3. Interpreted, not compiled. Flows are read at runtime. Change a YAML file, rerun, and see the result in seconds. There is no test target to rebuild.

Because it operates "at arm's length", Maestro can also do things in-process tools cannot: tap system permission dialogs, open Safari or Settings, and come back to your app in the same flow.

The ecosystem: CLI, Studio, MCP and Cloud

Maestro is more than one binary. Here is what each piece does and what it costs.

Component	What it does	Cost	Open source?
Maestro CLI	Runs flows locally and in CI. The core of everything.	Free	Yes (Apache 2.0)
Maestro Studio (desktop)	Visual IDE: inspect elements, record interactions, build flows without the terminal. Available for macOS, Windows and Linux.	Free	No
Maestro MCP	Built into the CLI (`maestro mcp`). Lets AI coding agents such as Claude Code, Cursor, Copilot, Codex and Gemini run flows, inspect the screen and write tests.	Free	Yes
Maestro Cloud	Hosted parallel execution on managed simulators, emulators and browsers.	Paid	No

A note on Studio: older versions of the CLI shipped a browser-based Studio (maestro studio). That was removed in CLI 2.6.0 in favor of the desktop app. If you find older tutorials using maestro studio, that is why they no longer match.

A note on AI: the old maestro chat command was discontinued in 2.7.0. The supported path for AI-assisted test authoring is now Maestro MCP.

Getting started in five minutes

1. Install

You need Java 17 or newer.

java -version

Then install the CLI on macOS, Linux or Windows (WSL):

curl -fsSL "https://get.maestro.mobile.dev" | bash

Or, on macOS with Homebrew:

brew tap mobile-dev-inc/tap
brew install maestro

Verify:

maestro --version

2. Start a device

For iOS you need Xcode with at least one Simulator runtime installed. For Android, an emulator from Android Studio. Maestro can also start one for you:

maestro list-devices
maestro start-device --platform ios

3. Write a flow

Save this as contacts.yaml. It uses the built-in iOS Contacts app, so you do not need your own app yet:

appId: com.apple.MobileAddressBook
---
- launchApp
- tapOn: "Add"
- tapOn: "First name"
- inputText: "Ada"
- tapOn: "Last name"
- inputText: "Lovelace"
- tapOn: "Done"
- assertVisible: "Ada Lovelace"

Button and field labels in Apple's built-in apps can change between iOS versions. If a step fails, open Maestro Studio or run maestro hierarchy to see the exact labels on your simulator.

4. Run it

maestro test contacts.yaml

You will see each step printed as it runs, with a pass or fail marker. On failure, Maestro saves a screenshot, the view hierarchy and logs so you can see what was on screen at the moment it broke.

What is important for developers to know

These are the things that are easy to miss in the marketing material but matter once you adopt Maestro on a real project.

1. iOS testing targets Simulators

Maestro's officially supported local iOS target is the Simulator. You need a Simulator build (.app), not an App Store or Ad Hoc .ipa. Support for physical iPhones has been one of the most requested features in the repository for a long time. Today, if you need real iOS hardware, your options are third-party projects or device clouds that have added Maestro support on physical devices (TestingBot is one example). Check the current docs before you plan around real devices.

Android has no such limitation: emulators and USB-connected physical devices both work.

2. Accessibility identifiers make tests stable

Maestro can find elements by visible text, which is great for getting started. For a test suite you plan to keep, add stable identifiers:

SwiftUI / UIKit: accessibilityIdentifier
Android: resource-id / testTag
React Native: testID
Flutter: Semantics(identifier: ...) or keys exposed through semantics

Then target them with id:

- tapOn:
    id: "loginButton"

Text selectors break when copy changes or when you test in another language. IDs do not.

3. YAML is simple until it isn't

For linear user journeys, YAML is a joy. For complex logic (loops with conditions, computed data, calling a backend to seed state), you will reach for Maestro's JavaScript support (runScript, evalScript, ${...} expressions and an http client). It works, but it is not a full programming language with an IDE, types and a debugger. If your test strategy depends on heavy logic, factor that into your choice.

4. Black-box means no app internals

You cannot call into your app's code, stub a network layer from inside the process, or read internal state. If you need that, it has to happen outside Maestro: a test backend, launch arguments, or a debug-only screen. Maestro's own built-in network mocking was deprecated years ago.

5. It is not a replacement for unit or in-process UI tests

Maestro is excellent for high-level user journeys: sign-up, checkout, onboarding, critical paths. It is not the right tool for testing every state of a single component. Keep XCTest/XCUITest, Espresso or your framework's widget tests for that.

6. CI is straightforward, scaling is the hard part

Running Maestro in CI is just maestro test plus JUnit or HTML reports. Scaling is where costs appear. iOS Simulators need macOS machines. Locally you can shard across several simulators (parallel iOS simulator execution became reliable in CLI 2.6.0), but at some point teams either buy more Mac runners or move to a cloud.

7. The project moves fast

The CLI ships frequently, and some releases deprecate flags. For example, --ios-version and --android-api-level are being replaced by --device-os and --device-model. Pin your Maestro version in CI and read the changelog when upgrading.

How Maestro compares to other tools

Free and open-source frameworks

Tool	Platforms	Test language	Approach	Setup effort	Best for
Maestro	iOS, Android, Web	YAML (+ JS)	Black-box	Minutes	Cross-platform user journeys, mixed teams, fast feedback
Appium	iOS, Android, Web, Windows, more	Java, JS/TS, Python, C#, Ruby	Black-box (WebDriver)	Hours to days	Large cross-platform suites, teams with existing Selenium skills
XCUITest	iOS only	Swift / Obj-C	In Xcode, separate test process	Low (built into Xcode)	iOS-only teams who want native tooling and real-device support
Espresso	Android only	Kotlin / Java	Gray-box, in-process	Low	Android-only teams, fast and stable component-level UI tests
Detox	iOS, Android (React Native)	JS / TS	Gray-box, syncs with RN internals	Moderate to high	React Native apps that need tight synchronization
Flutter integration_test / Patrol	iOS, Android (Flutter)	Dart	In-process, Patrol adds native interaction	Moderate	Flutter teams who want tests in Dart

Maestro vs Appium. Appium is the most flexible and the most mature: any language, any platform, huge ecosystem, real iOS devices. It is also the most work to set up and maintain, and tests tend to need explicit waits. Maestro trades flexibility for speed of authoring and lower flakiness. Many teams that move from Appium to Maestro do so because test maintenance, not test execution, was their bottleneck.

Maestro vs XCUITest. XCUITest is Apple's own framework. It is fast, deeply integrated with Xcode and supports real devices. But tests are Swift code that needs a test target, compilation and more boilerplate, and it only covers iOS. If you ship on both platforms, you would also need Espresso and two separate suites. Maestro gives you one suite, often with shared flows across platforms.

Maestro vs Detox. Detox is gray-box: it knows when React Native is idle, which makes it very stable for RN apps. That same coupling makes setup harder and limits it to React Native. Maestro works with any framework but synchronizes based on what is on screen rather than JS thread state.

Paid platforms and device clouds

Most paid offerings are infrastructure: they run tests you have already written on hosted devices. Prices below are list prices published at the time of writing (October 2026). Always confirm on the vendor's pricing page.

Service	What you get	Pricing model	Maestro support
Maestro Cloud	Official hosted runner for Maestro flows, parallel execution, artifacts, notifications	$250 per device per month for iOS or Android, $125 per browser per month for web; enterprise plans available; 7-day free trial	Native
BrowserStack App Automate	Large real-device cloud for Appium, Espresso, XCUITest and more	Per parallel session; App Automate starts around $199 per parallel per month billed annually	Yes, via integration
Sauce Labs	Real devices and emulators, enterprise features	Per parallel test with unlimited users and minutes	Check current docs
TestingBot	Real devices and simulators, Maestro CLI integration	Subscription	Yes, including physical iOS devices
DeviceCloud (devicecloud.dev)	Maestro-focused cloud runner	Pro plan from $25 per month including test credits, usage on top	Yes
AWS Device Farm / Firebase Test Lab	Pay-as-you-go device access from the major clouds	Metered usage with free tiers or trials	Possible with custom setup, not first-class
AI-native testing tools (for example Drizz, Autosana)	Natural-language or vision-based test authoring and self-healing	Subscription, usually quote-based	Not applicable; they are alternatives

A simple way to think about it:

Authoring cost (how long tests take to write and maintain): Maestro is among the lowest.
Execution cost (where tests run): free on your own machines, then you pay either for Mac CI runners or for a device cloud. The cloud choice is mostly about price per parallel, device coverage (real vs virtual) and where your data is allowed to go.

When to choose Maestro

Maestro is a strong fit if:

You ship on both iOS and Android, or plan to.
You want end-to-end coverage of critical user journeys without building a test framework.
QA engineers, product people or designers should be able to read and contribute to tests.
Flaky tests are a bigger problem for you than raw test speed.

Look elsewhere, or combine tools, if:

You must run iOS tests on physical devices in your own lab with official support.
Your tests need deep access to app internals or in-process mocking.
You need thousands of fine-grained UI assertions per component (use XCUITest, Espresso or framework tests for those).
Your organization already has a large, healthy Appium suite.

Wrapping up

Maestro's pitch is simple: describe what a user does, in plain YAML, and let the framework handle the waiting and retrying. For most teams the biggest win is not execution speed but the fact that tests are quick to write, easy to read and less likely to become the flaky suite nobody trusts.

In Part 2, we will build a small SwiftUI app with a login screen and a to-do list, then write a full Maestro suite for it: stable selectors, sub-flows, environment variables, conditional logic for permission dialogs, tags, reports and a GitHub Actions workflow.

Resources

GitHub: mobile-dev-inc/maestro

Xcode 27.2: What Developers Need to Know (Including the New JSON Project Format)

ArshTechPro — Fri, 23 Oct 2026 11:15:00 +0000

Xcode 27.2 is a point release, but it ships one change that will affect almost every team sooner or later: a new JSON-based project file that replaces the old project.pbxproj. The rest of the release is a mix of small features, a solid batch of Device Hub and Previews fixes, and a few known issues you should know about before you upgrade your CI machines.

This post walks through what matters, in order of how likely it is to affect your day.

Note: This is based on Apple's Xcode 27.2 release candidate notes. Details can still shift before the final release, so check the official notes linked at the end before making team-wide decisions.

TL;DR

Requirements: macOS Tahoe 26.6 or later. Ships with Swift 6.4 and the 27.2 SDKs for iOS, iPadOS, macOS, tvOS, watchOS, and visionOS.
Biggest change: a new JSON project format (.xcproj) that is readable, diff-friendly, and much less prone to merge conflicts. It is the default for new projects and opt-in for existing ones.
Compatibility gotcha: .xcproj projects open in Xcode 27 and later only. Anyone still on Xcode 26 cannot open them.
Coding Assistant: a new GetCodeCoverage MCP tool so agents can read coverage from your latest test run.
Previews: a new Display group in the canvas overrides picker for alternate displays, plus several reliability fixes.
Device Hub: many input-related fixes, including iOS 17 simulator input.
Watch out for: a deployment-target bug in the non-iOS SDKs, Mac Catalyst compile errors with iOS 27.1-only APIs, and a few simulator quirks (workarounds below).

Requirements and platform support

Item	Xcode 27.2
Host macOS	macOS Tahoe 26.6 or later
Swift	6.4
SDKs	iOS, iPadOS, tvOS, watchOS, macOS, visionOS 27.2
On-device debugging	iOS 17+, tvOS 17+, watchOS 10+, visionOS

If your build machines are still on an older macOS, update them first. That is usually the step that blocks CI upgrades, not Xcode itself.

Apple also notes that the iOS SDK and simulator support for iPhone Duo come from a separate download on the Apple Developer downloads page, so grab that if you are targeting the new hardware.

The headline: a JSON project format (`.xcproj`)

If you have ever resolved a merge conflict in project.pbxproj, this is the section you care about.

What changed

An .xcodeproj bundle has always contained a project configuration file called project.pbxproj. It is an old-style property list full of generated 24-character object IDs, cross-references, and comments. It works, but it is hard to read, hard to review, and famously painful to merge.

Starting in Xcode 27.2, Xcode can store that configuration as a JSON file named project.xcproj instead. According to Apple, the new file is:

Smaller and hierarchical. Structure is nested rather than a flat table of objects pointing at each other by ID.
Self-describing. You can open it and understand what you are looking at.
Easier to review. Changes in a diff line up with what you actually did in Xcode, so a pull request that adds one file shows a small, readable change.
Less conflict-prone. Configuration changes are more isolated, so two people adding files to the same target are far less likely to collide.
Agent-friendly. Coding assistants (Xcode's own or external ones over MCP) can edit it reliably instead of guessing at pbxproj IDs.

The outer .xcodeproj folder stays the same. Only the file inside it changes:

Before:
MyApp.xcodeproj/
  project.pbxproj
  project.xcworkspace/
  xcshareddata/

After:
MyApp.xcodeproj/
  project.xcproj        <- new JSON file
  project.xcworkspace/
  xcshareddata/

So scripts and tools that just point at MyApp.xcodeproj (for example xcodebuild -project MyApp.xcodeproj) keep the same path. Tools that open and parse project.pbxproj directly are a different story; more on that below.

Is it the default?

New projects created in Xcode 27.2 use the JSON format by default.
Existing projects keep using project.pbxproj until you switch them.

Xcode 27 and later understands both formats, so there is no forced migration.

How to convert an existing project

Open the project in Xcode 27.2.
Select the project in the Project navigator.
Open the File inspector (right sidebar).
Under Project Document, set Project Format to JSON.
If a confirmation dialog appears, click Continue.

Xcode removes project.pbxproj and adds project.xcproj inside your .xcodeproj.

How to undo it

If you use source control, reverting is simple: discard the change that deleted project.pbxproj and added project.xcproj. For example, with Git:

git restore MyApp.xcodeproj/project.pbxproj
rm MyApp.xcodeproj/project.xcproj

My recommendation: do the conversion as its own commit with nothing else in it. That makes it trivial to review and trivial to roll back.

Compatibility: read this before converting a shared project

This is the part that can bite a team.

.xcproj projects open in Xcode 27 and later, including earlier Xcode 27.x releases.
They do not open in Xcode 26 or earlier.

Before converting a shared repository, check:

Every developer on the team is on Xcode 27 or later.
Every CI runner (GitHub Actions, Xcode Cloud, Bitrise, self-hosted, and so on) uses an Xcode 27 image.
Release branches that still build with an older Xcode are not affected. Convert on your main branch, not on a maintenance branch that must keep building with Xcode 26.

Check your tooling

A lot of iOS tooling reads or writes project.pbxproj directly. Common examples include project generators, dependency managers that patch your project, release automation, and linters that inspect build settings or file membership. Until those tools announce support for .xcproj, assume they may not understand it.

Practical approach:

Convert on a branch.
Run your full pipeline: dependency install, build, tests, signing, and any scripts that touch the project.
Only merge once everything passes.

If you generate your project from a spec (for example with a project generator), you may not need to convert at all; keep generating whatever format your tool supports and revisit later.

Apple open sourced the format

Apple published the format as an open source Swift package, xcode-project-format (Apache 2.0). It models the whole project (targets, groups, file references, build phases, build rules, and more) as typed Swift values under an XCSchema namespace, and it includes a small CLI called xcprojformatter.

That matters because tool authors no longer need to reverse-engineer the format. If you maintain internal scripts that poke at project files, this is the library to build on.

Add it to a package:

dependencies: [
    .package(url: "https://github.com/apple/xcode-project-format/", from: "0.1.0")
]

A quick script that prints every target in a project:

import Foundation
import XcodeProjectFormat

let url = URL(fileURLWithPath: "MyApp.xcodeproj/project.xcproj")
let data = try Data(contentsOf: url)
let project = try XCSchema.Project(jsonRepresentation: data)

for target in project.targets {
    print(target.name)
}

The package requires Swift 6.1 or later and macOS 14 or later, and also builds on non-Apple platforms, which is handy for Linux-based CI checks.

Should you switch now?

Switch now if:

Your whole team and CI are already on Xcode 27.
You regularly fight project.pbxproj merge conflicts.
You use coding agents to add files, targets, or build settings.

Wait if:

Anyone still needs to open the project in Xcode 26.
You depend on tools that edit the project file and have not confirmed .xcproj support.
You generate the project from a spec and the generator does not output .xcproj yet.

Coding Assistant: code coverage over MCP

Xcode 27.2 adds a GetCodeCoverage MCP tool. It reports code coverage from your most recent test result, and you can filter it by target or by file.

Why it is useful: an agent can now run your tests, check which lines are not covered, and write tests for exactly those gaps, all without you exporting coverage reports by hand. If you use an external agent connected to Xcode over MCP, it gets access to this tool too.

Related fix: the RenderPreview MCP tool now returns the list of available render destinations and lets the caller choose which one to render on. Agents that render SwiftUI previews can now target a specific device instead of whatever the default happens to be.

Previews

New: the canvas overrides picker now has a Display group, so you can preview content on a device's alternate display. If you are building for hardware with more than one screen (such as iPhone Duo), this is how you check the second display without running the app.

Fixed:

Previews no longer fail in source files that use Windows-style CRLF line endings. If you share code with Windows-based tooling or have files that came through a cross-platform repo, this one may have been silently breaking your canvas.
If another user account on the same Mac owns the Previews JIT directory, Xcode now shows a clear error with recovery steps instead of a vague failure. Shared build Macs and multi-user setups hit this.
Clearer error when the selected platform cannot show a preview's content.
Selecting a preview from a preview group's thumbnail grid on macOS now reliably opens the right one.

Device Hub and Simulator fixes

Device Hub got a lot of input-handling fixes. If you mirror and control devices or simulators from Xcode, most of these will feel like things just started working:

Keyboard and mouse input now works for simulators running older OS versions (before iOS 18, tvOS 18, watchOS 11, and visionOS 2).
Device Hub now supports input to iOS 17 simulators.
Device Hub no longer stops sending touch and button input to a connected device after it has been idle for a while.
Disconnecting a physical device while Simulate Hardware Keyboard was on no longer leaves it stuck in hardware keyboard mode (which used to hide the software keyboard for up to two minutes).
Modifier keys (Shift, Control, Option, Command) now go to the right device when multiple device windows are open.
Holding Escape now exits keyboard capture mode.
Deleted simulator runtimes are now fully removed, instead of reappearing after a reboot.

Known issues to plan around

These are the ones most likely to cost you time.

SDK deployment target bug (macOS, watchOS, tvOS, visionOS)

The macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly list 27.1 as a valid deployment target. If you pick it, builds and other features may behave unexpectedly. Mac Catalyst builds with a 27.1 or 27.2 deployment target may also be unable to use newly introduced APIs.

What to do: do not set your deployment target to 27.1 on those platforms with this Xcode. Stick with the target you already had, or 27.2 if you need the new APIs and are not building for Catalyst.

Mac Catalyst: compile errors with iOS 27.1-only APIs

Projects that use APIs specific to iOS 27.1 can fail to compile for Mac Catalyst with errors like "undeclared identifier", "has no member", or "cannot find".

Workaround: wrap the affected code in a compile-time check.

Swift:

#if !targetEnvironment(macCatalyst)
// iOS 27.1-only API usage here
#endif

Objective-C:

#if !TARGET_OS_MACCATALYST
// iOS 27.1-only API usage here
#endif

Simulator runtime shows as unavailable after reinstalling

If you delete a simulator runtime and reinstall it, Xcode may still show it as unavailable.

Workaround: restart the CoreSimulator service.

killall -9 com.apple.CoreSimulator.CoreSimulatorService

Device Hub crashes when selecting a Vision Pro simulator without a runtime

If no visionOS runtime is installed, selecting a Vision Pro simulator in Device Hub can make Device Hub quit.

Workaround: install the matching visionOS runtime from Xcode, or delete that simulator device.

Smaller ones

Simulate Memory Warning (Device menu) does not work. If you test memory-pressure handling, trigger it another way for now.
iPhone Duo screenshots and recordings can come out black for up to a few minutes after the device boots. Wait a bit before capturing App Store screenshots.
Cloning a 27.2 simulator device can fail due to incorrect file permissions. If you script simulator cloning for parallel tests, watch for this.
Accessibility tools (VoiceOver, Accessibility Inspector) cannot read screen content on iPhone Duo inside Device Hub. Test accessibility on a physical device or a regular simulator window.
CarPlay in Device Hub needs a USB-connected device. Network-connected devices and the iOS Simulator are not supported for CarPlay.

Upgrade checklist

Update build Macs to macOS Tahoe 26.6 or later.
Install Xcode 27.2 side by side with your current Xcode first, and run your full test suite.
If you target iPhone Duo, download its SDK and simulator support separately.
Check your non-iOS deployment targets are not set to 27.1.
If you ship Mac Catalyst, look for iOS 27.1-only API usage and add #if !targetEnvironment(macCatalyst) guards.
Decide on .xcproj: convert only when the whole team and CI are on Xcode 27, and do it as a standalone commit.
If you use coding agents, try GetCodeCoverage to have them target untested code.

Wrapping up

Most of Xcode 27.2 is polish: better Device Hub input, sturdier Previews, and a couple of handy MCP tools for agents. The JSON project format is the real story. It fixes one of the oldest pain points in Apple development, and because it is open source, the tooling ecosystem can catch up quickly. Give your CI and tools a test run on a branch, and once everything is green, the days of untangling project.pbxproj conflicts are over.

References

Xcode 27.2 Release Notes

Supabase in 2026: Is This Open Source Backend Worth a Try?

ArshTechPro — Tue, 20 Oct 2026 11:35:33 +0000

If you have ever started a side project and spent the first weekend wiring up a database, user sign-ups, file uploads and an API before writing a single feature, Supabase was built for you.

In this article we will look at what Supabase actually is, how it works under the hood, how to get a project running in a few minutes, and whether it is worth adding to your toolbox.

What is Supabase?

Supabase describes itself as "the Postgres development platform." The short version: you get a real Postgres database, plus the backend pieces most apps need, without having to build them yourself.

Out of the box you get:

A hosted Postgres database (a full one, not a limited abstraction)
Authentication with email, magic links, OAuth providers and more
Auto-generated APIs (REST and GraphQL) based on your tables
Realtime subscriptions to database changes over websockets
Storage for files like images and documents
Edge Functions for custom server-side logic
Vector support through pgvector for AI and embeddings work
A dashboard with a table editor, SQL editor and logs

It is often called an open source Firebase alternative. The big difference is that Supabase is built on SQL and Postgres instead of a proprietary NoSQL store, so your data model is relational and portable.

The project is very active: the main repository has over 100k stars on GitHub and is licensed under Apache 2.0.

How it works under the hood

One thing I like about Supabase is that it is not a black box. It is a collection of open source tools, glued together:

Piece	What it does
Postgres	The database at the center of everything
PostgREST	Turns your database schema into a REST API
GoTrue (Auth)	JWT-based sign-up, login and sessions
Realtime	An Elixir server that broadcasts database changes over websockets
Storage API	S3-compatible file storage, with permissions handled in Postgres
pg_graphql	A Postgres extension that exposes a GraphQL API

Because everything sits on top of Postgres, permissions are handled with Postgres Row Level Security (RLS). That means your security rules live next to your data, not scattered across your app code.

Getting started in 5 minutes

1. Create a project

Your project URL
Your publishable (anon) key

2. Create a table

Open the SQL editor in the dashboard and run:

create table todos (
  id bigint generated always as identity primary key,
  user_id uuid references auth.users not null default auth.uid(),
  title text not null,
  done boolean default false,
  created_at timestamptz default now()
);

alter table todos enable row level security;

create policy "Users can manage their own todos"
on todos for all
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

That last part matters. With RLS enabled and this policy in place, each user can only see and edit their own rows, even though the frontend talks to the database directly.

3. Install the client

npm install @supabase/supabase-js

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://your-project.supabase.co',
  'your-publishable-key'
)

4. Sign up a user

const { data, error } = await supabase.auth.signUp({
  email: 'dev@example.com',
  password: 'a-strong-password',
})

5. Read and write data

// Insert
await supabase.from('todos').insert({ title: 'Write a dev.to article' })

// Select
const { data: todos } = await supabase
  .from('todos')
  .select('*')
  .order('created_at', { ascending: false })

No API routes, no ORM setup, no controller files. The REST API already exists because the table exists.

6. Listen for changes in realtime

supabase
  .channel('todos-changes')
  .on(
    'postgres_changes',
    { event: 'INSERT', schema: 'public', table: 'todos' },
    (payload) => console.log('New todo:', payload.new)
  )
  .subscribe()

That is enough to build a live-updating todo app, chat, or dashboard.

Local development

You do not have to develop against the cloud. The Supabase CLI runs the whole stack locally with Docker:

npx supabase init
npx supabase start

This gives you a local database, auth, storage and dashboard. You can write migrations, test them locally, and push them to your hosted project when you are ready. It also generates TypeScript types from your schema, which makes the client fully typed:

npx supabase gen types typescript --local > database.types.ts

If you want to avoid cloud hosting entirely, Supabase can also be self-hosted with Docker.

Client libraries

Official clients exist for JavaScript/TypeScript, Flutter, Swift and Python. The community maintains clients for C#, Kotlin, Go, Ruby and others. So whether you are building a Next.js app, a mobile app or a Python backend, you are covered.

The good and the not-so-good

What works well

It is just Postgres. You can use SQL, joins, views, triggers, extensions and any Postgres tool you already know. If you ever leave, you take a standard Postgres database with you.
Very fast to start. Auth, storage and an API in minutes is not marketing speak; it really is that quick.
Open source. You can read the code, self-host it, and avoid hard lock-in.
Strong docs and community. The docs are good, and the Discord and GitHub discussions are active.
Good fit for AI apps. pgvector support means you can store embeddings next to your regular data.

What to watch out for

You need to learn RLS. If you forget to enable Row Level Security or write a loose policy, your data can be exposed. Take the time to understand it.
Logic in the database is a mindset shift. Policies, functions and triggers in SQL can feel unfamiliar if you are used to keeping all logic in your backend code.
Free tier limits. The free plan is generous for learning and prototypes, but inactive free projects can be paused, and real production apps will usually need a paid plan. Check the pricing page for current details.
Self-hosting takes effort. It is possible, but running the full stack yourself in production means you own upgrades, backups and monitoring.

So, is it worth a try?

Yes, for most developers it is.

Supabase is a great choice if you:

Want to ship a side project, MVP or SaaS quickly
Prefer SQL and relational data over document databases
Are building frontend-heavy or mobile apps and do not want to write a custom backend
Want an AI-ready database with vector search built in

It may not be the best fit if you need a highly custom backend architecture, have strict requirements that rule out managed services and do not want to self-host, or your team has no interest in learning Postgres.

The best way to decide is to build something small. Spin up a free project, create one table, turn on RLS, and connect a frontend. In an afternoon you will know whether Supabase fits the way you like to work.

Useful links

GitHub: github.com/supabase/supabase

A Free Prerequisite Graph of Everything Kids Learn: Exploring Marble's os-taxonomy

ArshTechPro — Tue, 20 Oct 2026 09:09:20 +0000

If you have ever tried to build anything in education tech, you have probably hit the same wall: curriculum data is either a flat list of standards in a PDF, or it is locked inside someone's product.

A flat list tells you what a child should learn in Year 2. It does not tell you what they need to know first. And that second question is the one that matters if you are building adaptive practice, a tutoring app, a learning-path generator, or an AI tutor that needs to know where a kid is stuck.

os-taxonomy from Marble is an attempt to fix that. It is an open dataset that breaks primary and elementary learning into small, teachable ideas and connects them with prerequisite edges. It has picked up around 4.8k stars, which is a lot for a pure data repo.

Here is what is in it, how to use it, and whether it is worth your time.

What you actually get

It is a graph, shipped as plain JSON.

1,591 micro-topics (nodes). Each is one teachable idea, like "Building sentences" or "Apparent brightness of stars".
3,225 prerequisite edges. "Topic X depends on topic Y", each tagged hard or soft, with a one-line reason.
Curriculum alignment. Topics link to the standards they came from: Common Core, NGSS, the UK National Curriculum, the C3 social studies framework, and IB PYP.
176 domain clusters. Short, parent-friendly summaries per subject, domain, and age band.
Teaching research. 1,051 records on how to teach Science and Mathematics topics, with activities, feedback ideas, and assessment guidance. More on this below.

Coverage is weighted toward the core subjects:

Subject	Topics
Science	547
Mathematics	504
English	286
History	90
Personal & Social Development	88
Life Skills	37
Computing	21
Learning to Learn	18

There is no runtime, no package, and no dependencies. You clone the repo and read JSON files.

The data model

Everything lives in data/:

File	Contents
`topics.json`	The micro-topics (nodes)
`dependencies.json`	Prerequisite edges
`curriculum-standards.json`	Source standards, grouped by curriculum
`clusters.json`	Domain summaries
`teaching-research.json`	Teaching guidance per topic (about 23 MB)
`manifest.json`	Counts and SHA-256 checksums

JSON Schemas for each file are in schema/.

A topic looks like this (trimmed):

{
  "id": "mt_N8CpN1EJrP",
  "type": "CONCEPTUAL",
  "subject": "English",
  "domain": "Grammar & Punctuation",
  "name": "Building sentences",
  "ageRangeStart": 4,
  "ageRangeEnd": 6,
  "centrality": 0.257,
  "evidence": [
    "Distinguish between complete sentences and fragments",
    "Compose a complete sentence with a subject and verb"
  ],
  "assessmentPrompt": "If {{name}} says something like \"The dog\", can they tell you...",
  "standards": ["ccss-ela:L.K.1f", "uk-nc-2013:Eng.App2.Y1.Sent.1"]
}

A few fields are worth calling out:

type classifies the kind of knowledge: conceptual, procedural, representational, language, or meta.
evidence is a list of observable mastery criteria. This is the useful bit for anyone building assessments.
centrality gives you a rough sense of how connected a topic is in the graph.
assessmentPrompt is a natural-language check with a {{name}} placeholder for the child's name. Replace or strip it before showing it to anyone.

And an edge:

{
  "topicId": "mt__00ZSLnB7p",
  "prerequisiteId": "mt_VBl1T1sFCM",
  "strength": "hard",
  "reason": "Must understand vibrations make sound before finding volume patterns"
}

Read it as "topicId depends on prerequisiteId". Flip it and you get "unlocks".

Getting started in five minutes

git clone https://github.com/withmarbleapp/os-taxonomy.git
cd os-taxonomy
node scripts/validate.mjs   # checks structure, references, and checksums

Find the direct prerequisites of a topic

This uses JSON import attributes, so use a recent Node version (22 or newer is safest):

import topics from './data/topics.json' with { type: 'json' };
import deps from './data/dependencies.json' with { type: 'json' };

const byId = new Map(topics.topics.map(t => [t.id, t]));

const prereqsOf = id =>
  deps.dependencies
    .filter(d => d.topicId === id)
    .map(d => byId.get(d.prerequisiteId));

// "Addition and subtraction word problems"
console.log(prereqsOf('mt_yJmvUCCym7').map(t => t.name));
// [ 'Representing Addition and Subtraction' ]

Build a full learning path

The interesting thing about a prerequisite graph is that you can walk it. Since the graph is a DAG (no cycles), a depth-first walk gives you every topic a learner needs before the target, in an order they could actually study them:

const edgesByTopic = new Map();
for (const d of deps.dependencies) {
  if (!edgesByTopic.has(d.topicId)) edgesByTopic.set(d.topicId, []);
  edgesByTopic.get(d.topicId).push(d);
}

function learningPath(targetId, { hardOnly = true } = {}) {
  const seen = new Set();
  const order = [];

  function visit(id) {
    if (seen.has(id)) return;
    seen.add(id);
    for (const d of edgesByTopic.get(id) ?? []) {
      if (hardOnly && d.strength !== 'hard') continue;
      visit(d.prerequisiteId);
    }
    order.push(byId.get(id));
  }

  visit(targetId);
  return order; // prerequisites first, target last
}

for (const t of learningPath('mt_yJmvUCCym7')) {
  console.log(`${t.ageRangeStart}-${t.ageRangeEnd}  ${t.subject}  ${t.name}`);
}

Running it on "Addition and subtraction word problems" prints:

4-6  Mathematics  One-to-one counting
4-6  Mathematics  How Many in Total?
4-6  Mathematics  Addition as combining or putting together two
4-6  Mathematics  Subtraction as taking away or separating
4-6  Mathematics  Representing Addition and Subtraction
4-6  Mathematics  Addition and subtraction word problems

That is a sensible sequence: count, combine, take away, represent it, then solve word problems.

The hardOnly flag is handy. Hard edges are true blockers. Soft edges are "helpful to know", so include them when you want a gentler path and drop them when you want the shortest one.

Prefer Python?

Same idea with networkx:

import json
import networkx as nx

topics = {t["id"]: t for t in json.load(open("data/topics.json"))["topics"]}
deps = json.load(open("data/dependencies.json"))["dependencies"]

G = nx.DiGraph()
for d in deps:
    G.add_edge(d["prerequisiteId"], d["topicId"], strength=d["strength"])

target = "mt_yJmvUCCym7"
needed = nx.ancestors(G, target) | {target}
path = list(nx.topological_sort(G.subgraph(needed)))

for tid in path:
    print(topics[tid]["name"])

Once it is in networkx, you also get the usual graph tools for free: finding the most "foundational" topics, spotting bottlenecks, or checking which topics unlock the most downstream learning. Note that this version follows soft edges too, so it can return a longer path than the JavaScript one.

Add the teaching guidance

The newest file, teaching-research.json, covers what to do with a topic. Each record joins to a topic by topicId and includes a teaching summary, concrete activities with feedback ideas, common misconceptions, assessment guidance, and sources.

import research from './data/teaching-research.json' with { type: 'json' };

const guidanceByTopic = new Map(research.records.map(r => [r.topicId, r]));
const guidance = guidanceByTopic.get('mt_yJmvUCCym7');

console.log(guidance?.learn.summary);
for (const a of guidance?.learn.activities ?? []) console.log('-', a.title);
// - Story-modelling with counters and a mat
// ...

Only Science and Mathematics are covered so far. For English and the other subjects, guidance will be undefined, so keep that ?. in place.

What you could build with it

Adaptive practice. When a kid fails a topic, walk back one hard edge and test the prerequisite instead of repeating the same question.
AI tutors. Give an LLM the topic, its evidence list, its prerequisites, and (for maths and science) its teaching activities as structured context. That grounds the model far better than "teach my kid fractions".
Placement and diagnostics. Use evidence and assessmentPrompt to build quick checks, then use the graph to infer what a child probably already knows.
Curriculum mapping. Because topics link to both Common Core and the UK National Curriculum, you can roughly map content between the two systems.
Visualizations. The repo includes a 3D graph render, and Marble has an interactive version where you can click a topic and see everything that leads to it.

The caveats, honestly

The licensing needs a careful read. This is the most important part. The dataset has three layers with different terms:

The database (structure, IDs, relationships) is under ODbL 1.0.
Marble's written text (names, descriptions, evidence, prompts, reasons) is under CC BY-SA 4.0.
curriculum-standards.json is not Marble's to license. Each source keeps its upstream terms.

So, is it worth a try?

If you work anywhere near education tech, yes. It takes minutes to load, and a well-structured prerequisite graph with mastery criteria is the kind of thing teams usually spend months building internally. Even if you do not use it as-is, it is a good reference model for how to structure learning data.

It is especially useful as grounding data for AI tutoring tools, where the hard problem is often not generating explanations but knowing what to teach next.

Just read the license section before shipping anything commercial, and treat v1 as a strong foundation that you validate, not a finished curriculum.

A good first experiment: pick a topic your own kid (or a niece, nephew, or student) is struggling with, run learningPath() on it, and see whether the prerequisites match what you see in real life.

Links

Repository: github.com/withmarbleapp/os-taxonomy

CLI-Anything: Turning Desktop Software into Tools Your AI Agent Can Actually Use

ArshTechPro — Tue, 20 Oct 2026 04:52:40 +0000

If you have used an AI coding agent like Claude Code, Codex, or Cursor for more than a week, you have probably noticed something: agents are great in a terminal and pretty bad everywhere else.

Ask an agent to refactor a Python module and it does fine. Ask it to cut a video in Shotcut, add a layer in GIMP, or export a diagram from Draw.io, and things fall apart. The usual workaround is GUI automation: take a screenshot, guess where the button is, click, take another screenshot, repeat. It is slow, expensive in tokens, and breaks the moment a dialog moves.

CLI-Anything from the Data Intelligence Lab at the University of Hong Kong (HKUDS), takes a different route. Instead of teaching agents to use GUIs, it gives the software a proper command-line interface that agents can call directly.

This article covers what it is, how to try it quickly, and whether it is worth your time.

The core idea in one paragraph

Most "GUI" applications are really a user interface sitting on top of an engine. Blender has bpy. LibreOffice can run headless. Shotcut and Kdenlive render through MLT and melt. Inkscape works on SVG. CLI-Anything analyzes an application's codebase, finds that underlying engine, and generates a Python CLI (built on Click) that exposes the real functionality as commands. Every generated CLI supports --json output for agents, a human-readable mode for you, an interactive REPL, and project state with undo/redo.

So instead of an agent clicking through menus, it runs something like:

cli-anything-gimp project new --width 1920 --height 1080 -o poster.json
cli-anything-gimp --json layer add -n "Background" --type solid --color "#1a1a2e"

Structured input, structured output, no screenshots.

Two ways to use it

The project has two distinct entry points, and it helps to know which one you want before you start.

You want to...	Use
Use CLIs that already exist (GIMP, Blender, LibreOffice, OBS, Zotero, n8n, and many more)	CLI-Hub, the package manager
Generate a new CLI for software that is not covered yet, including your own internal tools	The CLI-Anything plugin for your coding agent

Most developers should start with the first one.

Option 1: Install ready-made CLIs with CLI-Hub

You need Python 3.10 or newer.

pip install cli-anything-hub

# See what is available
cli-hub list
cli-hub search image

# Install one and inspect it
cli-hub install gimp
cli-hub info gimp
cli-hub launch gimp

One thing that trips people up: these CLIs wrap the real software. If you install the Blender CLI, you still need Blender installed on your machine. The CLI is the interface, not a replacement for the application.

Let your agent pick the tool

If your agent supports skills (Claude Code, Codex, OpenClaw, and others), you can install a "meta-skill" that teaches it to search CLI-Hub, install what it needs, and read the usage docs on its own:

npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill -g -y

Then just describe the task:

Find appropriate CLI software in CLI-Hub and complete the task: convert
all .docx files in ./reports to PDF and merge them into one file.

Each generated CLI also ships with a SKILL.md file describing its commands, so the agent gets documentation in a format it understands without you writing any prompts.

Option 2: Generate a CLI for something new

This is the more ambitious part of the project. You point the plugin at a codebase (a local folder or a GitHub URL), and your coding agent runs a seven-phase pipeline:

Analyze the source and map GUI actions to backend APIs
Design command groups, state model, and output formats
Implement the Click CLI with REPL, JSON output, and undo/redo
Plan tests in a TEST.md file
Write tests, both unit and end-to-end against the real software
Document the results
Publish a setup.py so the CLI installs onto your PATH

In Claude Code, setup looks like this:

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything

/cli-anything ./gimp

You can also pass a repo URL, for example /cli-anything https://github.com/blender/blender.

When the first pass is done, the refine command looks for gaps between what the software can do and what the CLI covers, then adds commands and tests for them:

/cli-anything:refine ./gimp "batch processing and filters"

Then install and use the result like any Python package:

cd gimp/agent-harness && pip install -e .
cli-anything-gimp --help
cli-anything-gimp          # no arguments opens the REPL

The plugin is available for Claude Code, Cursor, Codex, OpenCode, GitHub Copilot CLI, Pi, Qodercli, OpenClaw, Hermes, and Reasonix. Several of these are marked experimental or community-maintained, so expect the Claude Code path to be the most polished.

A note for Windows users: Claude Code runs shell commands through bash, so install Git for Windows or use WSL, otherwise you will hit cygpath: command not found.

Where it is genuinely useful

A few use cases where this approach makes a lot of sense:

Media and document pipelines. Batch converting documents with LibreOffice, rendering scenes in Blender, cutting and captioning video. These are tasks agents previously could not do reliably at all.
Wrapping messy APIs. You can feed API docs or an SDK to the generator and get one stateful CLI instead of dozens of raw HTTP calls. Fewer tool calls usually means fewer tokens and fewer mistakes.
Internal tools. If your team has an internal app with a decent codebase but no API, this is a fast way to make it scriptable for both agents and humans.
Testing and benchmarks. Once software has a CLI, you can generate agent tasks and evaluators in code rather than through screen recordings.

The repo's demos are worth a look. One shows an agent building a full HTTPS handshake diagram in Draw.io purely through commands. Another shows an agent assembling a rover model in FreeCAD with a live preview updating at each step.

The honest caveats

The project is popular (over 51k stars at the time of writing) and moves fast, but go in with realistic expectations.

Generation is not free. The seven-phase pipeline is a long agent run: reading a large codebase, writing an implementation, then writing and running tests. On a big project like Blender, that is a lot of tokens and time. Treat the output as a solid first draft that you review, not a finished product.

Coverage depends on what was exposed. A CLI is only as good as the commands it has. When a task needs something the harness does not expose, the agent cannot fall back to "just clicking it" the way a GUI agent could. This is a real trade-off: structured interfaces are more reliable when they cover the task and more brittle when they do not. The refine command helps, but it is not magic.

Quality varies across the registry. The core harnesses (GIMP, Blender, LibreOffice, Inkscape, Audacity, and others) have substantial test suites, and the repo reports more than 2,000 passing tests overall. Newer community contributions are thinner. Check the test count and last update before relying on a specific one.

You still need the real software. This is a feature, since it means you get real rendering and not a toy reimplementation, but it also means setup involves installing the upstream app and sometimes configuring it (for example, an API key or a local server).

Mind what you install. Like any community registry, review what a CLI does before giving an agent permission to run it, especially ones that touch credentials, file systems, or remote services. The maintainers have been fixing issues like path injection and unsafe XML parsing, which is a good sign, but it also tells you the attack surface is real.

So, is it worth a try?

Yes, with a clear scope.

If your agent work touches anything outside the code editor, such as documents, media, diagrams, or a desktop app your team relies on, CLI-Hub is a low-effort win. A pip install, one cli-hub install, and your agent can do things it simply could not do before. That takes about ten minutes to evaluate.

The generator is worth trying if you have a specific tool you want agents to control and you are willing to review and refine the output. It is less appealing if you just want to experiment casually, because the token and time cost of a full generation run is real.

The bigger idea behind the project is also worth paying attention to: rather than making agents better at pretending to be humans in front of a screen, give software an interface designed for agents in the first place. Whether or not CLI-Anything becomes the standard way to do that, it is a practical, working example of the approach today.

A good first experiment:

pip install cli-anything-hub
cli-hub search office
cli-hub install libreoffice

Then ask your agent to convert and merge a folder of documents, and compare how that feels against doing it through GUI automation.

Links

Repository: github.com/HKUDS/CLI-Anything

TokenSpeed: A New LLM Inference Engine Built for Coding Agents.

ArshTechPro — Thu, 15 Oct 2026 22:42:25 +0000

If you self-host large language models, you have probably settled into one of two camps. You use vLLM or SGLang because they are easy to run, or you use TensorRT-LLM because it squeezes the most out of NVIDIA hardware and you are willing to pay for that in setup pain.

TokenSpeed wants to end that trade-off. It is an open-source (MIT) inference engine from the LightSeek Foundation that targets TensorRT-LLM-level performance with vLLM-level usability, and it is tuned specifically for agentic workloads like coding assistants.

In this post we will cover what it is, why "agentic" changes the problem, how to get a server running in a few minutes, and whether it deserves a spot in your stack.

What problem is it solving?

Most inference benchmarks look like chat: a short prompt, a short answer, done. Coding agents look nothing like that.

A typical agent session has:

Very long contexts. Prompts regularly pass 50K tokens once you include files, tool output, and history.
Many turns. The same conversation comes back dozens of times, each time slightly longer.
A hard speed floor. If tokens stream slowly, the agent feels broken. The TokenSpeed team targets around 70 tokens per second per user as a minimum, sometimes 200+.

So the goal is not just "maximum throughput." It is maximum throughput per GPU while every user still gets fast generation. That framing drives most of TokenSpeed's design choices.

How it works (the short version)

You do not need to understand the internals to use it, but four pieces are worth knowing about:

Modeling layer. Instead of hand-writing tensor-parallel communication code for every model, developers annotate where data should live at module boundaries, and a small static compiler generates the collective operations. Less custom parallelism code means fewer bugs when adding new models.
Scheduler. The control plane is written in C++ as a finite-state machine. Request lifecycle and KV cache ownership are modeled explicitly, and the type system catches unsafe KV cache reuse at compile time instead of at 3 a.m. in production. The execution side stays in Python so it is still easy to hack on.
Kernels. Kernels live in their own pluggable package with a registry, so NVIDIA and AMD backends can sit side by side. Their MLA (Multi-head Latent Attention) kernel for Blackwell is fast enough that vLLM has adopted it.
Entrypoint. Requests come in through an OpenAI-compatible server built on their SMG project, keeping CPU-side overhead low.

Getting started

What you need

An NVIDIA GPU host (CUDA 13 for the nightly wheels), or an AMD host with ROCm 7.2
Python 3.11 to 3.13
Docker with GPU support if you want the easy path

Option 1: Docker (recommended)

The project ships a runner image with everything preinstalled:

docker pull lightseekorg/tokenspeed-runner:latest

docker run -itd \
  --shm-size 32g \
  --gpus all \
  --ipc=host \
  --network=host \
  -v ~/.cache:/home/runner/.cache \
  --name tokenspeed \
  lightseekorg/tokenspeed-runner:latest \
  /bin/bash

Mounting your cache directory means model weights survive container restarts.

Option 2: pip (nightly wheels)

On a CUDA 13 machine:

python -m pip install --upgrade tokenspeed \
  --extra-index-url https://lightseek.org/whl/nightly

Nightlies are versioned by date, so you can pin one for reproducibility:

python -m pip install "tokenspeed==0.1.0.post20260930" \
  --extra-index-url https://lightseek.org/whl/nightly

AMD users should follow the ROCm instructions in the getting started guide, since you need to install ROCm PyTorch first and use a separate wheel index.

Check that everything is in place:

tokenspeed env
tokenspeed serve --help

Launch your first model

GPT-OSS 20B fits on a single GPU and is a good smoke test:

tokenspeed serve openai/gpt-oss-20b \
  --served-model-name gpt-oss-20b \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1

Call it like OpenAI

Because the server speaks the OpenAI API, your existing client code works with only a base_url change:

from openai import OpenAI

client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")

response = client.chat.completions.create(
    model="gpt-oss-20b",
    messages=[{"role": "user", "content": "Explain KV caching in two sentences."}],
    max_tokens=200,
)
print(response.choices[0].message.content)

Or with curl:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-oss-20b",
    "messages": [{"role": "user", "content": "Hello!"}],
    "max_tokens": 100
  }'

That is the whole loop. Anything that already talks to OpenAI, including most agent frameworks, can point at this server.

Going bigger

For large MoE models the flags will look familiar if you have used vLLM. Here is the shape of a Kimi K2.5 launch on four Blackwell GPUs:

tokenspeed serve nvidia/Kimi-K2.5-NVFP4 \
  --served-model-name kimi-k2.5 \
  --trust-remote-code \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --quantization nvfp4 \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --reasoning-parser kimi_k25 \
  --tool-call-parser kimik2 \
  --host 0.0.0.0 --port 8000

The model recipes page has tested launch commands for DeepSeek V4, Qwen3 and Qwen3.8, GLM 5.x, MiniMax M3, Kimi K3, Nemotron-3 Super, and more. Start from a recipe rather than tuning flags from scratch.

What about performance?

The team's headline numbers, all self-reported:

On Kimi K2.5 running on NVIDIA B200 with a real coding-agent trace (SWE-smith, evaluated with EvalScope), TokenSpeed beat TensorRT-LLM across the whole latency/throughput curve. That works out to about 9% faster at batch size 1 and about 11% more throughput at around 100 tokens per second per user.
Their MLA decode kernel cut latency roughly in half versus TensorRT-LLM's on typical speculative-decoding workloads.
They reported up to 580 tokens per second on Qwen3.5-397B-A17B for agentic workloads.

These are vendor benchmarks, so treat them as a reason to test, not as a guarantee. The good news is the benchmark harness is in the repo under test/agentic_benchmark, so you can reproduce it on your own traffic.

Is it worth a try?

Yes, if:

You serve large MoE models (DeepSeek, Kimi, Qwen, GLM, MiniMax) for coding agents or other long-context, multi-turn workloads.
You run on recent NVIDIA hardware (Hopper, and especially Blackwell) or AMD MI350-class GPUs, and you care about cost per token.
You have been eyeing TensorRT-LLM for speed but do not want its build and setup overhead.
You want day-zero support for new frontier open models. TokenSpeed shipped launch-day support for Kimi K3 and Thinking Machines' Inkling.

REA: Let Your AI Agent Reverse Engineer the App Features You Wish You Had

ArshTechPro — Thu, 08 Oct 2026 11:28:11 +0000

You are using an app and notice a feature that just works. Instant offline search. A clever sync behavior. A smooth update flow. You want something similar in your own product, but you have no source code, no docs, and no idea where to start.

Traditionally, the answer was "learn reverse engineering." That means picking a disassembler, learning its API, digging through strings and symbols, following call graphs by hand, and copying findings between tools. It is a deep skill, and most application developers never have the time to pick it up.

REA takes a different approach: it hands that work to your AI coding agent.

In this post we will cover what REA is, how it works, how to set it up, and whether it is worth your time.

What is REA?

REA is an open-source (MIT) tool, written in TypeScript, that gives AI agents a consistent way to investigate software. It ships as:

A CLI (rea) you can run from your terminal
An MCP server that agents like Claude Code, Cursor, Codex, Gemini CLI, Windsurf, and Claude Desktop can call directly

The pitch is simple: point your agent at an app, ask how a feature works, and the agent uses REA to inspect the app, explain the feature with evidence, and then build a version adapted to your stack.

The mental model: Decompile, Understand, Recreate

REA frames every investigation in three stages:

Decompile - open the app and recover readable code, strings, symbol names, and other clues.
Understand - follow the code from one part of the app to another until the agent can explain how the feature actually works.
Recreate - turn what was learned into a feature for your own product, in your language and framework.

One thing worth stating up front: REA does not claim to recover the original source code, and it does not clone apps. It gives the agent pseudocode, assembly, symbols, strings, and relationships, and it shows the evidence behind every conclusion.

What a real investigation looks like

Say you ask your agent:

Reverse engineer the Notes app. Find how offline search works, explain it,
and build a version for my project using TypeScript and SQLite.

Behind the scenes, the agent works through roughly these steps using REA tools:

Step	What the agent does	Example REA tools
1	Opens and identifies the binary	`open_binary`, `binary_overview`
2	Looks for search-related clues	`search_strings`, `search_procedures`, `list_names`
3	Connects clues to actual code	`find_xrefs_to_name`, `xrefs`, `procedure_callers`
4	Rebuilds the control flow	`get_call_graph`, `procedure_callees`
5	Decompiles the important functions	`procedure_pseudo_code`, `batch_decompile`
6	Writes the feature in your project	Your agent's normal editing and test tools

REA handles steps 1 through 5. Step 6 is your agent doing what it already does well: writing code.

If you have done any manual reverse engineering, you will recognize this workflow. The difference is that the agent drives it instead of you.

How it works under the hood

REA itself is not a disassembler. It is an orchestration layer that sits between your agent and real analysis tools.

Agent / Terminal
      |
      v
  REA (CLI + MCP server)
      |
      +--> Deep analysis providers: Hopper, Ghidra
      +--> Native macOS utilities (Mach-O, code signatures, plists, Swift demangling)
      +--> Artifact provider (ZIP, APK, IPA, ASAR, MSIX inventory)
      +--> Browser provider (passive Chrome DevTools Protocol observation)
      +--> Process capture provider (controlled terminal sessions)
      |
      v
  Evidence records you can export, compare, and reuse

A few design choices stand out:

Providers do the heavy lifting. Hopper is the main deep-analysis provider, and Ghidra is supported as a read-only, bring-your-own option on Linux (plus an experimental Windows x64 mode).
Everything produces evidence. Each successful result is stored as a structured "Evidence v2" record that includes the provider, confidence, and known limitations. You can export these bundles, import them later, and diff them across app versions.
Unknowns stay unknown. REA is strict about not presenting guesses as facts. Static inference and runtime observation are labeled separately, and incomplete data is reported as incomplete.
Local by design. There is no hosted analysis service. The app you analyze stays on your machine (though your AI model provider still has its own data policy).
Same engine for CLI and MCP. Whatever your agent can do, you can also do from the terminal.

What it can analyze today

Native binaries get the deepest support, but REA covers more than that:

Native apps: Mach-O, ELF, PE, and macOS .app bundles, including Swift and Objective-C metadata
Packages and archives: ZIP, APK, IPA, ASAR, plus file-level inventory without extraction
Electron and JavaScript apps: static mapping of entry points, modules, IPC channels, preload scripts, and source maps, without executing anything
Websites: passive observation of a browser you already control, over a local Chrome DevTools endpoint
.NET (managed PE/CLI): execution-free triage of metadata, members, and native boundaries
Version diffs: compare two releases of an app and get a report of what changed

Getting started

Requirements

macOS 12+, or Ubuntu 24.04+, Fedora 41+, or 64-bit Arch Linux (Windows x64 is experimental and Ghidra-only)
Node.js 22.19+ or 24.11+
A deep-analysis provider: Hopper (setup can install it, and the free demo mode works) or your own Ghidra 12.1.2 with JDK 21

Install and run setup

The quickest path:

npx --yes rea-agents@latest setup

Or install the CLI globally:

npm install --global rea-agents
rea setup

Setup is careful. It detects which agents you have installed, asks which capabilities you want, shows the exact files it will change, and defaults to "No" before applying anything. Use rea setup --dry-run if you want to preview the plan first.

When setup finishes, restart your agent so it picks up the new MCP server.

Check your environment

rea doctor

This tells you whether something is missing, misconfigured, or unsupported on your machine.

Try it from the terminal

rea analyze /Applications/Notes.app
rea search /Applications/Notes.app "offline"
rea trace /Applications/Notes.app "offline"

Or just ask your agent

Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.

Manual MCP configuration

If your agent supports local MCP servers but is not auto-detected, add this to its config:

{
  "mcpServers": {
    "rea": {
      "command": "npx",
      "args": ["-y", "rea-agents@3.1.0", "mcp"]
    }
  }
}

Pin to the latest published version from npm.

Safety and permissions

Reverse-engineering tools can be risky if they run code you do not trust. REA leans heavily toward caution:

Dynamic features (process capture, browser observation, runtime inspection) are disabled by default and need explicit environment variables plus per-call approval.
File-based evidence commands only work inside directories you approve, using variables like REA_EVIDENCE_ROOTS_JSON.
Static JavaScript analysis parses code without running it.
REA never calls sudo, and it uses authenticated local sockets for provider communication.

The flip side: providers and launched targets still run with your user permissions. REA is not a security sandbox, so do not treat it as one when handling malware.

Is it worth a try?

Yes, if:

You are on macOS or Linux and already use an MCP-capable agent like Claude Code or Cursor.
You want to understand how a feature works in an app you use, especially a native or Electron app.
You are curious about reverse engineering but never had time to learn Hopper or Ghidra.
You need to document an undocumented file format, protocol, or interface for interoperability.
You maintain software and want to diff behavior across versions.

Maybe hold off if:

You are on Windows. Support there is experimental and limited.
You want a quick, zero-config tool. REA has a lot of opt-in switches and environment variables, which is good for safety but takes time to learn.

A few practical notes:

Hopper is separate commercial software. The demo mode works, but has vendor-defined limits.
Deep investigations can use a lot of agent tokens, so watch your model costs.
Respect the law and the software license. Reverse engineering for learning and interoperability is common, but some license agreements and jurisdictions restrict it. Recreate ideas and behavior, not copyrighted code or assets.

Summary

REA turns reverse engineering from a specialist skill into something you can delegate to your coding agent. You describe the feature, the agent investigates the app, shows you how it reached its conclusions, and then helps you build your own version.

GitHub: github.com/morluto/rea

Trying e2e: Write End-to-End Tests with Plain English and Real Assertions

ArshTechPro — Tue, 06 Oct 2026 13:27:49 +0000

End-to-end tests are valuable and painful in equal measure. Selectors break when someone renames a class. Mobile tests need their own tooling. A flow that takes one sentence to describe takes fifty lines to script.

e2e is an open source framework that tries to fix this by mixing two styles in one test: plain-English steps run by an agent, and normal locators and assertions you already know. Here is what it does and whether it deserves a spot in your stack.

What is e2e?

e2e is an end-to-end testing framework for web and mobile apps. You describe a goal in natural language, and an agent interacts with the app to complete it. When you need exact checks, you use regular locators and assertions in the same test.

It is built by the TesterArmy team and released under the Apache-2.0 license.

A first look

This is what a test looks like:

// tests/checkout.e2e.ts
import { test, expect } from 'e2e';

test('a member upgrades to Pro', async ({ app, agent, screen }) => {
  await app.open('/settings/billing');

  await agent.act('upgrade the workspace to the Pro plan');
  await agent.assert('the invoice preview shows a prorated amount');

  await expect(screen.getByRole('status')).toContainText('Pro');
});

There are three kinds of steps here:

app.open navigates to a page.
agent.act and agent.assert take plain-English instructions and checks.
expect(screen.getByRole(...)) is a precise, deterministic assertion.

The agent handles the part that is tedious to script, such as clicking through a billing flow. Your own assertion verifies the result. The test reads like a description of the feature, and you still get an exact check at the end.

Getting started

Setup is one command:

npx e2e init

From there, the docs at e2e.tester.army/docs cover the quickstart, writing tests, mobile, and the full reference. The e2e package also ships every docs page in node_modules/e2e/docs, so coding agents can read them offline.

The part that matters: replay

The obvious worry with AI-driven tests is cost and flakiness. Calling a model on every run is slow and expensive, and results can vary.

e2e's answer is replay. According to the README, when an agent step is verified by a later assertion, the framework records the actions it took. The next run replays them with no model calls, until the app changes. Tests without agent steps need no model at all.

In practice this means you pay for the model when a flow is new or has changed, not on every CI run. You can also bring your own subscription, API key, or local model.

Packages

e2e is split into small packages, so you only install what you need:

Package	Purpose
`e2e`	SDK, runner, and CLI
`@e2e-dev/web`	Browser engine
`@e2e-dev/mobile`	iOS and Android engine
`@e2e-dev/github`	Pull request comment reporter
`@e2e-dev/kernel`	Hosted browsers for the web engine
`@e2e-dev/eas`	Hosted iOS simulators and Android emulators

If you are coming from another tool, the docs include migration guides for Playwright, Cypress, Selenium, Detox, and Maestro.

Is it worth trying?

It is a good fit if:

You have a critical flow (checkout, onboarding, billing) that is expensive to script and easy to break.
You test mobile and want something simpler than a separate toolchain.
You like the idea of readable tests but still want exact assertions.

Be aware of a few things:

The project is young, so expect rough edges and changes. Start with one or two flows rather than migrating a whole suite.
It comes from a company that also sells a testing platform. The framework is open source, but keep that context in mind.
Agent steps depend on a model, so check how replay behaves on your own app before trusting it in CI.

Verdict

e2e is a practical take on AI in testing: use the agent for the tedious parts, use real assertions for the checks that matter, and replay recorded runs so you are not paying for a model on every build.

Try it on one flow this week. If it saves you from maintaining a brittle script, expand from there.

Repo: github.com/tester-army/e2e

Caveman: Make Your AI Coding Agent Talk Less (and Save Tokens)

ArshTechPro — Fri, 02 Oct 2026 14:22:14 +0000

If you use an AI coding agent every day, you have probably noticed how much of its output is padding. Phrases like "The reason this is happening is likely because..." or "I'd recommend that you consider..." appear before the useful part of the answer. You pay for those tokens, and you spend time reading them.

Caveman is an open source project that fixes this. Its tagline is "why use many token when few do trick", and it does what it says: your agent answers in short, blunt sentences without the filler.

What it does

Here is the example from the README. The question is why a React component keeps re-rendering.

Normal agent (69 tokens):

The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object.

Caveman agent (19 tokens):

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.

The diagnosis and the fix are the same. Only the throat-clearing is gone.

Code, commands, file paths, and exact error messages are never rewritten. Only the prose around them gets shortened, so the answers stay accurate and copy-pasteable.

Install in one command

The simplest version is a skill, which is a rule file your agent loads:

npx skills add JuliusBrussee/caveman

It works with 30+ agents, including Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Cline, and Copilot. If your agent does not pick it up automatically, type /caveman in the chat.

Intensity levels and commands

You control how terse the agent gets:

/caveman lite
/caveman full
/caveman ultra
/caveman off

The skill also adds a few useful commands:

/caveman-commit writes short Conventional Commit messages.
/caveman-review gives one-line, actionable code review comments.
/caveman-compress <file> shrinks Markdown memory files and keeps a backup of the original.
/caveman-stats shows local token usage and estimated savings in Claude Code.

The numbers

The author ran ten ordinary coding prompts through the Claude API, with and without the skill. Output tokens dropped by 65% on average. The range is wide, though:

Task	Normal	Caveman	Saved
Implement React error boundary	3454	456	87%
Set up PostgreSQL connection pool	2347	380	84%
Explain git rebase vs merge	702	292	58%
Refactor callback to async/await	387	301	22%

The pattern is simple. When the agent would have written an essay, you save a lot. When the answer was mostly code, you save very little.

Read this before quoting the 65%

The project is unusually honest about its limits, and you should be too:

The skill only shortens output. Input and reasoning tokens do not change.
The skill's own rules add roughly 1 to 1.5k input tokens on every turn.
Whole-session savings will be lower than the benchmark table, and on work that was already terse you can end up paying more.

The README says speed and readability are the real product, and the discount is a bonus. Measure your own setup before promising anyone a 65% cut on the bill.

The optional proxy

There is also a second, bigger piece: a local proxy that sits between your agent and the AI provider. It shrinks what the agent reads, such as logs, diffs, and test output, before each call, and it keeps a backup of every original on your machine.

npm install -g @caveman-ai/cli && caveman setup --install
caveman claude

In a 54-run Claude Code benchmark, total input tokens dropped by about 33%. One case, an HTML dashboard, actually got 9.9% worse, and the README leaves that row in the table. It is a bigger commitment than the skill, so start with the skill.

Things to know before you install

Telemetry: the caveman CLI sends anonymous usage stats by default (commands run and token counts, never prompts or code). Turn it off with caveman telemetry off or DO_NOT_TRACK=1. The skill itself runs entirely on your machine.
Licensing: the skill and CLI are MIT. The engine and proxy are BSL-1.1, which is source-available but not OSI open source. Self-hosting for your own use is fine.

Is it worth trying?

Yes, with realistic expectations. The skill is a one-line install, easy to turn off, and does not touch your code. If your agent is wordy, you get faster, easier-to-scan answers right away. Treat any token savings as a bonus and check them with /caveman-stats.

Repo: github.com/JuliusBrussee/caveman

Impeccable: Stop Your AI Coding Agent From Building the Same Ugly UI

ArshTechPro — Fri, 02 Oct 2026 06:45:50 +0000

Impeccable is a design skill for AI coding agents. It started from Anthropic's frontend-design skill and extends it with three things:

A single setup step. /impeccable init inspects your project and writes a PRODUCT.md file with your audience, purpose, constraints, and voice. Later commands use it as context.
24 commands that give you and the agent a shared design vocabulary.
61 deterministic detector rules that flag common AI design mistakes. They run without an LLM or an API key.

It works with Claude Code, Cursor, Codex CLI, Gemini CLI, GitHub Copilot, and a long list of other tools.

Install in two commands

From your project root:

npx impeccable install

The installer detects which AI tools you use and asks whether to install for the project or globally. Reload your tool, then run:

/impeccable init

If you use Claude Code, you can also install it as a plugin with /plugin marketplace add pbakaus/impeccable.

The commands worth knowing

You do not need all 24. These cover most daily use:

Command	What it does
`/impeccable craft`	Plan, then build a new surface with visual iteration
`/impeccable critique`	UX review of hierarchy, clarity, and tone
`/impeccable audit`	Technical checks for accessibility, performance, and responsiveness
`/impeccable polish`	Final pass before shipping
`/impeccable distill`	Strip a design down to what matters
`/impeccable harden`	Error states, text overflow, i18n, edge cases

Each command takes a target, so you stay in control of scope:

/impeccable audit the header
/impeccable polish the checkout form
/impeccable harden checkout

You can also describe what you want in plain language, for example /impeccable redo this hero section. If you use one command a lot, /impeccable pin audit turns it into a standalone /audit.

The part that works without AI: the detector

This is the feature I would try first. The CLI can scan your code, or a live URL, for design problems with no model involved:

npx impeccable detect src/
npx impeccable detect https://example.com
npx impeccable detect --json .

It catches things like purple gradients, bounce easing, tiny touch targets, skipped headings, and cramped padding. The --json flag and exit codes make it easy to add to CI. Because the rules are deterministic, the results are repeatable, which is hard to get from asking an AI to review the design.

The README is honest about the limits too: a clean run is evidence, not proof, and it does not replace looking at the page on real viewports.

The design hook

On Claude Code, Cursor, Codex, GitHub Copilot, and Grok Build, the installer can add a hook that runs the detector whenever the agent edits a UI file. The agent sees the findings and can fix them in the same session. On Cursor it can block a bad write before it lands. This catches problems while the code is being written, instead of in review.

Things to check before adopting

Hooks run on their own. In Claude Code, installed hooks run independently of tool approval, and the first run may download a binary into ~/.impeccable/bin/. Review the hook before using it in unattended runs.
Live mode is for local development only. Do not inject it into a deployed production site.
Ignore the right files. The repo provides a .gitignore block for the .impeccable/ folder, so screenshots and caches do not get committed. Keep the shared config and design files tracked.
Opinionated by design. It discourages fonts like Inter and Arial and warns against nested cards. If your brand uses Inter, you can add an ignore rule with a reason:

npx impeccable ignores add-value overused-font Inter --reason "Brand font"

Is it worth trying?

Yes, for most developers who build UI with AI tools. The setup takes a couple of minutes, nothing locks you in, and you can try the detector alone without letting an AI touch your code.

It is most useful if you:

ship side projects or MVPs and do not have a designer
are tired of every AI-generated page looking the same
want automated design checks in CI

Repo: github.com/pbakaus/impeccable

NVIDIA OpenShell Explained: A Safer Runtime for AI Agents

ArshTechPro — Wed, 30 Sep 2026 11:53:47 +0000

AI agents are getting genuinely useful. They can read your files, install packages, call APIs, and run shell commands. That is exactly what makes them risky.

If you have ever pasted an API key into an agent's environment and then held your breath while it ran, this article is for you. NVIDIA has an open source project called OpenShell that tries to solve this problem. Let's look at what it is, how it works, and whether it is worth your time.

The problem in one paragraph

An agent is only useful if it can do things. But every capability you give it is also a capability that can go wrong: a prompt injection in a web page, a hallucinated rm -rf, a dependency that phones home, or a leaked token in a log. Most of us handle this today by running the agent in a Docker container and hoping for the best. That helps, but a container by default does not know the difference between "download a package from PyPI" and "send your credentials to a random server."

What OpenShell is

According to the project, OpenShell is "the safe, private runtime for autonomous AI agents." In practical terms, it is:

A CLI you use to create and manage sandboxes.
A gateway that acts as the control plane for sandboxes, policies, and access.
A sandbox where the agent actually runs, isolated from your host.
A policy system where you declare what the agent can access.

You write the rules. OpenShell enforces them. The agent does not get to negotiate.

How it works

The README describes two main ideas.

1. Enforcement at the kernel level

Each agent runs in its own isolated sandbox. Kernel-level controls restrict which files the agent can open and which system calls it can make. Every network connection goes through a policy check before it leaves the sandbox.

2. Formally verified policy changes

Agents often need new access as they work. Maybe your agent suddenly wants to reach a new host. Normally you would either approve everything (unsafe) or approve each request by hand (exhausting).

A mental model that helps

Think of it like a building with a security desk.

The sandbox is the room the agent works in.
The policy is the visitor list and the set of doors the agent's badge opens.
The provider is a mail clerk who attaches the real stamp (your credential) to an approved letter, so the agent never holds the stamp itself.
The gateway is the security office that manages all of it.

Getting started

Requirements from the README: Linux, macOS on Apple Silicon, or Windows with WSL 2 (marked experimental). You also need Docker, Podman, or host virtualization.

Install and create a sandbox:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

The installer sets up the CLI and a local gateway. The default sandbox image is a minimal Ubuntu with no agent installed, so you are starting with a clean, locked-down box.

As always with a curl | sh installer, read the script before running it on a machine you care about.

To run a real agent, the docs have a "Run Your First Agent" walkthrough. It runs OpenCode against a free OpenRouter model and shows how to approve new access as the agent asks for it. That walkthrough is the best way to see the policy loop in action.

Talking to it from code

If you want to integrate OpenShell into your own application, there are SDKs that connect to a gateway:

Language	Install
Python	`uv add openshell`
TypeScript	`npm install @nvidia/openshell-sdk`
Go	`go get github.com/NVIDIA/OpenShell/sdk/go@latest`
Rust	`cargo add openshell-sdk --git ... --tag <release-tag>`

Note that the SDKs do not install the CLI. You still need a gateway running, and the project recommends using the same release for both.

There is also a set of "agent skills" you can install so your coding agent learns how to drive the OpenShell CLI and write policies for you:

npx skills add NVIDIA/OpenShell

Other things worth knowing

Kubernetes support. You can deploy the gateway with Helm. Your CNI must enforce NetworkPolicy.
Extensibility. The docs mention middleware, interceptors, and compute drivers.
GPU support. The sandbox docs cover GPUs, which matters if your agents run local models.
License. Apache 2.0.
Telemetry. Anonymous telemetry is on by default and limited to operational categories and counts. The README says it does not collect prompts, file paths, credentials, or model names. You can turn it off with OPENSHELL_TELEMETRY_ENABLED=false on the gateway.

Reasons to try it

It targets a real problem. Credential leakage and over-permissioned agents are the most common ways agent setups go wrong. Keeping real secrets out of the agent's reach is a strong design choice.

Policy as configuration. Being able to declare "this agent can read this folder and call these two APIs" and have it enforced is far better than relying on prompt instructions like "please do not touch anything else."

Good signs of a serious project. The repository has around 10k stars, 1.4k forks, and over 1,500 commits. It ships SDKs in four languages, has an RFC process, a governance document, and a security policy. This is not a weekend demo.

It comes from NVIDIA. That is not a guarantee of quality, but it does suggest ongoing investment and attention to GPU-heavy agent workloads.

If you are...	Should you try it?
Running autonomous agents with real credentials or access to sensitive data	Yes. This is the target use case.
Building an agent platform or internal tooling for a team	Yes. The policy and gateway model fits well.
Experimenting with agents on your laptop, mostly for fun	Maybe. A plain container may be enough for now.
Building a simple chatbot with no tool access	No. You do not need it.
Needing production stability today with no tolerance for change	Wait a bit. Watch the releases and let it mature.

My short answer: yes, it is worth an afternoon of your time, especially if you are giving agents access to anything you would be upset to lose. Follow the "Run Your First Agent" guide, watch how the policy approvals work, and then decide whether the extra structure pays for itself in your setup. Just go in knowing it is a young project.

DEV Community: ArshTechPro

Maestro Deep Dive: Testing a SwiftUI App End to End

Prerequisites

Part A: The sample app

TodoDemoApp.swift

LoginView.swift

TodoListView.swift

Why the accessibility identifiers?

Part B: Build and install for the Simulator

Part C: The test suite

config.yaml: the workspace configuration

Sub-flow 1: login.yaml

Sub-flow 2: dismiss_permission_dialog.yaml

Test 1: 01_login_invalid.yaml

Test 2: 02_login_success.yaml

Test 3: 03_add_and_complete_tasks.yaml

Test 4: 04_delete_task.yaml (loops, JavaScript and swipes)

Test 5: 05_session_and_logout.yaml

Part D: Running the suite

Faster authoring with continuous mode

Validate syntax without a device

Reports and artifacts

Running on several simulators in parallel

Part E: The same test in XCUITest

Part F: Writing flows with an AI coding agent

Troubleshooting checklist

Best practices summary

Ending

Resources

Maestro: Mobile UI Testing Without the Pain - Introduction

What is Maestro?

How Maestro works (and why it matters)

The ecosystem: CLI, Studio, MCP and Cloud

Getting started in five minutes

1. Install

2. Start a device

3. Write a flow

4. Run it

What is important for developers to know

1. iOS testing targets Simulators

2. Accessibility identifiers make tests stable

3. YAML is simple until it isn't

4. Black-box means no app internals

5. It is not a replacement for unit or in-process UI tests

6. CI is straightforward, scaling is the hard part

7. The project moves fast

How Maestro compares to other tools

Free and open-source frameworks

Paid platforms and device clouds

When to choose Maestro

Wrapping up

Resources

Xcode 27.2: What Developers Need to Know (Including the New JSON Project Format)

TL;DR

Requirements and platform support

The headline: a JSON project format (.xcproj)

What changed

Is it the default?

How to convert an existing project

How to undo it

Compatibility: read this before converting a shared project

Check your tooling

Apple open sourced the format

Should you switch now?

Coding Assistant: code coverage over MCP

Previews

Device Hub and Simulator fixes

Known issues to plan around

SDK deployment target bug (macOS, watchOS, tvOS, visionOS)

Mac Catalyst: compile errors with iOS 27.1-only APIs

Simulator runtime shows as unavailable after reinstalling

Device Hub crashes when selecting a Vision Pro simulator without a runtime

Smaller ones

Upgrade checklist

Wrapping up

References

Supabase in 2026: Is This Open Source Backend Worth a Try?

What is Supabase?

How it works under the hood

Getting started in 5 minutes

`TodoDemoApp.swift`

`LoginView.swift`

`TodoListView.swift`

`config.yaml`: the workspace configuration

Sub-flow 1: `login.yaml`

Sub-flow 2: `dismiss_permission_dialog.yaml`

Test 1: `01_login_invalid.yaml`

Test 2: `02_login_success.yaml`

Test 3: `03_add_and_complete_tasks.yaml`

Test 4: `04_delete_task.yaml` (loops, JavaScript and swipes)

Test 5: `05_session_and_logout.yaml`

The headline: a JSON project format (`.xcproj`)