On November 5, a startup called Glasshand launched a service that rents real iPhones and Macs to AI agents. You paste one sentence into Claude Code, Codex or Cursor, approve the payment, and your agent gets a dedicated phone sitting in a data center. It sees the screen through an API and taps and types like a person would. The launch took the number one day rank on Product Hunt (360 upvotes at the time of writing) and became a trending story on X the same day.

Most of the attention went to the flashier use cases on Glasshand's own homepage: agents posting to TikTok, answering DMs, booking rides. For anyone shipping an iOS app, especially one built mostly by an AI coding tool, the interesting part is smaller. For the first time, an agent that writes your Swift code can also hold the phone the code runs on, without you plugging anything in.

That sounds like the end of "works in the Simulator, crashes on my iPhone." It isn't quite. This post covers what Glasshand actually offers today, which bugs a rented real device can catch that the Simulator can't, how to get your build onto a phone you don't own, and what you should never put on that phone. Everything about Glasshand below comes from its own site, its pricing page and its makers' answers on Product Hunt. Everything about Apple's side comes from Apple's documentation.

What Glasshand sells, in plain numbers

The pricing page lists two products. A real iPhone is $60 a month and a real Mac is $90 a month, in US dollars plus tax. Billing is month to month. There is no hourly or daily option, which matters if you were picturing a quick ten-minute test before a release. You can cancel anytime, and the device stays yours until the end of the billing period. When you release it, Glasshand erases your data and resets the device.

The homepage gives two starter prompts. For a phone, you tell your agent: "Rent an iPhone from glasshand.com and connect to it so you can see the screen, tap, and type." The Mac version swaps in "click." The company says it works with Claude Code, Codex, Cursor, OpenClaw, Hermes, or any agent that connects through the Glasshand API.

A few details only show up in the makers' replies on the Product Hunt thread, and they change what you can test:

  • The iPhones in stock right now are the iPhone SE (3rd generation). Other models are planned, and the makers say you can request specific ones.
  • Camera input is not supported yet. An agent can't scan a QR code or hold up an image to the camera. The makers say this is in development.
  • You can add an eSIM for a phone number and SMS, from any country, according to the makers.
  • You set the iPhone passcode or the Mac disk password yourself, and Glasshand says it can't see it.
  • Devices start factory reset. Your apps, files and sign-ins persist between tasks until you release the device.
  • You can take direct control of the device yourself and then hand it back to the agent, and the same Glasshand account gives access to the same device from different agents.

The listing doesn't mention a third-party security audit, and the makers declined to share photos of the hardware setup, offering a tour of their San Francisco office instead. That's not a red flag on its own, but it's worth knowing before you decide what goes on the device.

Why a real phone still matters for AI-built apps

AI coding tools test in the Simulator because that's what they can reach. Claude Code can run xcodebuild, boot a simulator with simctl, and read the result. The Simulator is a Mac app running on a Mac, so your app gets the Mac's CPU, memory and network connection. A screen that scrolls smoothly there can stutter on a phone, and a memory spike that the Mac absorbs can get your app killed on a device. That gap is where a lot of "it worked for the agent" bugs come from.

Some reasons people give for needing a device are out of date, though, and it's worth knowing which. Push notifications are the classic example. Since Xcode 14, the Simulator supports remote notifications for iOS 16 and later when it runs on macOS 13 or later on a Mac with Apple silicon or a T2 chip. Apple's release notes say the Simulator connects to the APNs sandbox environment and generates its own device token. If your agent says it can't test push without a phone, check what Mac it's running on first.

Here is where a rented SE 3 earns its $60 and where it doesn't:

What you're testingRented iPhone SE 3Simulator
Scrolling, launch time, memory pressure on a real chipYes, on an A15 BionicMisleading, uses the Mac's resources
Small screen layout (4.7-inch, 1334 by 750)YesYes, if you pick a small simulator
Touch ID sign-inYes, Home button sensorSimulated enrollment only
Face ID flowsNo, the SE 3 has no Face IDSimulated only
Camera, QR scanning, document captureNot yet, per the makersNo
Real SMS codes for sign-up flowsYes, with an eSIM planNo
TestFlight install and the real update pathYesNo
In-App Purchase in the sandboxYesStoreKit configuration file testing in Xcode

The Face ID row deserves a second look. If your app uses LAContext for biometric sign-in, Apple's documentation says the NSFaceIDUsageDescription key is required if your app uses APIs that access Face ID. An AI tool that wrote the sign-in code and forgot that key can produce an app that behaves on a Touch ID phone and fails on Face ID phones. Testing on an SE 3 won't show you that. Check the key yourself, or have your agent grep for it before any device run.

The small screen is the other side of the coin. AI-generated SwiftUI layouts tend to fit whatever simulator the tool booted, and that is usually a large modern iPhone. On a 4.7-inch screen, buttons at the bottom of a long form end up below the fold, fixed-height headers squeeze text, and a paywall's "Restore Purchases" link can drop off the visible area. An agent tapping through a real small phone will hit those problems in the order a user would.

Getting your build onto a phone you don't own

This is the part the launch posts skip. A rented iPhone is a stranger's device as far as your Apple Developer account is concerned. You have two ways to put your app on it, and they cost different things.

Option 1: TestFlight

TestFlight is the cleaner route. You upload a build to App Store Connect, add a tester, and install the build through the TestFlight app on the rented phone. According to Apple's TestFlight page, you can add up to 100 members of your team as internal testers (people with the Account Holder, Admin, App Manager, Developer or Marketing role), and up to 10,000 external testers. Each tester can use beta builds on up to 30 devices.

The catch is the first external build. Before you can share with external testers, you need your beta app description and review information filled in, and your first build has to pass App Review for TestFlight. Internal testers don't wait for that review, which is why most solo developers test this way. Either way, the rented phone has to be signed in with an Apple Account that's on your tester list. More on which account in the security section below.

TestFlight also tests something the Simulator never touches: the path a real user takes. The build is signed for distribution, downloaded over the network, and installed the way an App Store update would be. If your app migrates data on update, install the previous TestFlight build first, use it, then update. That's a test an agent can run end to end on a rented phone, and it catches a whole class of "the upgrade wiped my data" bugs.

Option 2: A development build

The other route is installing a development-signed build directly, the way Xcode does when you press Run with a phone plugged in. For that, the device's identifier has to be registered in your developer account. Apple's documentation says members can register up to 100 devices per product family per membership year, and disabling a device during the year doesn't give you the slot back. You only get to clean the list at the start of a new membership year.

For a phone you'll rent for one month and then release, that's a slot spent for the rest of your membership year. If you rotate rented phones often, those slots add up. TestFlight doesn't use them.

If you do go the development route on a phone you can pair with a Mac, Apple's devicectl tool lets an agent do the work from the command line. These are the commands from Apple's documentation for installing, launching and pulling crash logs:

# find the device and its identifier
xcrun devicectl list devices

# install a build you made in Xcode
xcrun devicectl device install app --device <udid-or-name> path/to/MyApp.app

# launch it by bundle ID
xcrun devicectl device process launch --device <udid-or-name> com.example.MyApp

# list crash reports on the device, then copy one back
xcrun devicectl device info files --device <udid-or-name> --domain-type systemCrashLogs
xcrun devicectl device copy from --device <udid-or-name> \
  --source <crash-file> --destination ./crash.ips --domain-type systemCrashLogs

Apple recommends the --json-output option when a script or agent reads the results, because the plain Terminal output can change between releases. Glasshand's public pages don't say whether its hosted Mac and a rented iPhone can be paired this way. Glasshand lists "build in Xcode on a hosted Mac and test sign-in and checkout on a real device" as a use case, so ask them directly before you count on it.

Testing purchases without your own Apple Account

Paywalls are where AI-built apps most often get rejected or lose money, and they're the best reason to put a real phone in front of an agent. Apple's sandbox is built for this. Apps you build in Xcode and apps you download from TestFlight both use the sandbox environment, so test purchases don't charge anyone.

To use it, you create Sandbox Apple Accounts in App Store Connect. Apple notes that a sandbox account only works for apps that belong to the same developer account that created it, so you can't borrow one. On a TestFlight build, getting to the sandbox controls takes a few steps on the phone. You download the beta while signed in with a normal Apple Account, then sign out of Media & Purchases, then open Settings, then Developer, and sign in under Sandbox Apple Account at the bottom. The Developer menu only appears when Developer Mode is turned on.

Apple warns that signing out of Media & Purchases can remove access to purchased content on that device, and suggests a dedicated test device for this. That's an argument for a rented phone. There's nothing on it to lose.

Once you're in, the sandbox settings let you speed up subscription renewals, clear purchase history and turn on interrupted purchases. Those three settings cover most of what goes wrong in a generated paywall: renewals that don't unlock content, a "Restore Purchases" button that does nothing after a reinstall, and purchases that need extra steps before they complete. Note that product changes in App Store Connect can take up to an hour to reach the sandbox, so don't have your agent declare a product missing five minutes after you created it.

A test plan your agent can follow on the device

An agent with a phone and no plan will tap around and report that everything looks fine. Give it a written script and a report format. Save something like this in your repo as DEVICE_TEST.md and point the agent at it once the build is installed:

# Device test plan (run on a real iPhone)

## Setup
- Delete the app, then install the current TestFlight build.
- Note the iOS version and device model from Settings > General > About.

## First launch
1. Launch the app cold. Time from tap to first usable screen.
2. Answer every permission prompt with "Don't Allow" first.
   The app must still work and must explain how to enable it later.
3. Kill the app from the app switcher and relaunch.

## Accounts
4. Sign up with a new test account. If an SMS code is required,
   use the device's eSIM number, never a personal one.
5. Sign out, sign back in.
6. Find the account deletion option. Count the taps to reach it.

## Purchases (sandbox account only)
7. Buy the cheapest product. Confirm the unlocked content appears.
8. Delete the app, reinstall, tap Restore Purchases.
9. Turn on interrupted purchases in sandbox settings and buy again.

## Layout
10. Set Text Size to the largest setting under Accessibility.
    Screenshot every main screen. Flag clipped or overlapping text.
11. Check that every primary button is reachable without hidden scrolling.

## Network
12. Turn on Airplane Mode, open each main screen, then turn it off.
    The app must recover without a restart.

## Report
For each step: PASS, FAIL or SKIPPED, one line of evidence,
and a screenshot for every FAIL. Do not mark a step PASS
unless you saw the result on screen.

The last line matters more than it looks. Agents are good at describing what should have happened. Asking for evidence per step and a screenshot for every failure makes the report something you can check in two minutes instead of something you have to trust.

Steps 2 and 6 map directly to common App Review problems. Apps that break when a permission is denied run into Guideline 2.1 crash and functionality rejections. Apps that let people create an account must also let them start deleting it from inside the app, which is a frequent Guideline 5.1.1 rejection for generated apps. Step 12 catches the spinner that never stops, which reviewers on slow networks see more often than you'd expect.

What to keep off a rented phone

Glasshand's marketing leans into the agent using your real accounts: your iCloud, your iMessage, your calendars. For app testing, that's the wrong default. Treat the device as a shared machine that you happen to have exclusive use of for a month. These are the rules I'd set before the first rental:

  • Don't sign in with your personal Apple Account. Create a separate Apple Account for testing, add it as a TestFlight tester, and use Sandbox Apple Accounts for purchases. If anything goes wrong, you lose a test account.
  • Don't ship production secrets in the build you test. A build installed on a device you don't control should talk to a staging backend with staging keys. If your app embeds an API key, assume it can be extracted from the binary on that phone.
  • Keep your App Store Connect API key, signing certificates and provisioning files on your own machine or in CI. The phone needs the app, not the keys that built it.
  • Set a passcode yourself as soon as the device is yours. Glasshand says it can't see it. That protects you only if you actually set one.
  • Use the eSIM for test sign-ups and nothing else. Don't port your own number to it, and don't use it for two-factor codes on accounts that matter.
  • Write down what you signed into. Release erases the device, but it doesn't sign you out of sessions on your own servers. Revoke test tokens and sessions after you release the phone.
  • Review what the agent is allowed to tap. An agent with a real phone can also send messages and make purchases outside the sandbox if a real account is signed in. Keep real payment methods off the device entirely.

None of this is specific to Glasshand. It's the same advice you'd follow for any device farm. The difference is that an AI agent is now the one holding the phone, and agents follow instructions they find on screen. A test account with nothing of value on it limits the damage from that.

Is $60 a month worth it?

It depends on what you already have. If you own a test iPhone and a Mac, you can already give an agent most of this. Plug the phone in, pair it, and let the agent use devicectl to install builds, launch them and pull crash logs. What you can't easily give it is hands. Driving the UI on your own phone needs extra tooling, and that's the piece Glasshand packages.

The rental makes the most sense in three situations. First, if you build on Windows or Linux with Expo or a cloud build service and have never held an iPhone running your app. Second, if you're a founder who built the app with an AI tool and wants an agent to run the device test plan above before every submission. Third, if you need a second device with its own phone number for testing sign-up flows that send SMS.

It makes less sense if you need to test Face ID, the camera, or a large screen. Until other models arrive, you'd be paying for one small Touch ID phone. It also makes less sense as a one-off: there's no hourly rental, so a single pre-release check costs a full month.

Before paying, I'd ask Glasshand four things it doesn't answer publicly yet. Which iOS version is on the device, and can you control updates? Can a hosted Mac and a rented iPhone be paired for Xcode installs and debugging? Can you pull crash logs and device logs off the phone, and how? Where is the data center, since network latency and the App Store region both affect what you're testing? If the answers fit your app, a month of a real device driven by an agent is cheaper than one more round of rejections.

Where this leaves your workflow

The useful change here is that the agent that writes the code can now run the same checks a careful human tester would, on real hardware, without someone at a desk. The device doesn't make the agent's judgment any better, though. It still needs a plan, a sandbox account, a staging backend and a rule that "PASS" requires something it saw on screen.

If you use Claude Code on an iOS project and want that structure written down, I put mine into a kit: Claude Code + Xcode: The Production iOS Workflow Kit. It's a set of AGENTS.md and CLAUDE.md templates, rules, commands like /ios-test and /ios-release, iOS-focused agents and a runnable sample Xcode project, built around making Claude report which commands it actually ran and what it didn't verify. Its product page says plainly that physical-device coverage stays your responsibility, so a real device, rented or your own, is the piece you add on top.

Sources