What it takes to test an app on your own phone, and why only the iPhone route has a fee.

Three routes, and which one you are stuck with

There are three ways a build reaches a phone you are holding. A computer pushes it over a cable or the local network. A store delivers it to a tester, which means TestFlight on iOS or an internal test on Google Play. Or, on Android only, the APK lands on the phone and the phone installs it.

Xcode runs on macOS and nowhere else, so the free way to run your app on your iPhone needs a Mac. On Windows or Linux with an iPhone there is no free path at all: the only route left is a build delivered by TestFlight, and TestFlight requires the paid membership. That one fork is why this question has a $99 answer for one person and a nothing answer for the next.

Before you spend anything, check whether you need the handset yet. Apple's Xcode documentation, read on 3 October 2026, says simulators do not replicate the performance or features of a physical device, that some hardware specific features might not be available in one, and that you should run on a physical device to test the feature itself. Layout and logic are fine in a simulator. Performance, sensors and real networks are not, so test the build on a real device before you trust a green simulator run.

Putting your own build on your own iPhone

Start with the free route, because it works and most pages skip it. Sign in to your Apple Account in Xcode and, with no program membership attached, Xcode calls it a Personal Team and manages your App IDs, devices, certificates and profiles itself. Apple's limits, stated on its developer account overview page, are 10 App IDs, 3 devices and 3 apps per device, all expiring after 7 days, with provisioning profiles expiring 7 days from issuance and a rebuild and reinstall needed after that. The same page lists on device testing using Xcode as available to anyone registered for free, and lists App Store Connect, TestFlight and Xcode Cloud as Apple Developer Program only.

The current Xcode interface is not the one older tutorials describe. Apple's documentation now routes pairing through Device Hub: open it with Manage Devices from the run destination pop-up menu, or Xcode then Open Developer Tool then Device Hub, then add the handset with the Add Device button and Pair Nearby Device. Wireless pairing needs iOS or iPadOS 27 or later; below that, use a cable. A tutorial that routes pairing through Window then Devices and Simulators is describing an older Xcode. That window still exists and Apple's own crash log documentation still sends you to it, but pairing a new phone now starts in Device Hub.

Then there is Developer Mode, which trips up nearly everyone. On the phone, turn on the Developer Mode switch in Privacy and Security settings under Security, confirm the alert, restart, then tap Enable and enter the passcode. The part people miss, and Apple states it plainly, is that on a device you are pairing for the first time the setting may not appear at all until you begin pairing in Device Hub. If the switch is missing, you have not started pairing yet.

The paid route is TestFlight, and it is the only way onto an iPhone with no computer involved. Upload the build to App Store Connect, open the app, click the TestFlight tab, use the add button next to Internal Testing, then Invite Testers. Apple lists the required role as Account Holder, Admin, App Manager, Developer or Marketing, caps an internal group at 100 App Store Connect users with access to your content, and says a build can be tested for up to 90 days. Internal testing does not wait for review. The full walkthrough is in ios testflight.

Apple, Developer account overview, read 3 October 2026

Putting your own build on your own Android phone

Find Build number in Settings. Google's own table of locations, read on 3 October 2026, gives Settings then About phone then Build number for a Pixel and for a OnePlus 5T or later, and Settings then About phone then Software information then Build number for a Samsung Galaxy S8 or later. Tap Build number seven times until the phone says you are now a developer. Developer options then appears at the bottom of the previous screen.

Then turn on debugging. Google documents USB debugging at Settings then System then Advanced then Developer Options then USB debugging on Android 9 and higher, and wireless debugging at Settings then System then Developer options then Wireless debugging on Android 16 and higher. Wireless deployment needs Android 11 or higher, and you pair once from Android Studio using Pair Devices Using Wi-Fi, with either a QR code or a six digit pairing code. Run adb devices to confirm the phone is listed, then click Run to install the app on your phone and test it. No account is created anywhere in that sequence and nothing is charged.

One policy did change, which is why this page carries a date. Android developer verification took effect on 30 September 2026, when protections began for users installing apps from participating stores in Brazil, Indonesia, Singapore and Thailand on certified devices running Android 7 or higher, and Google says it expands globally in 2027. It does not touch what you are doing here. Google's FAQ answers the question twice: as a developer you are free to install apps without verification with ADB, and apps installed using ADB will not require verification even when you modified the APK yourself. To share with a few people without an identity check, limited distribution accounts cover up to 20 specific devices at no cost.

Going through the store instead costs US$25 once. Google's get started page states a US$25 one time registration fee, paid by credit or debit card, with prepaid cards not accepted and a minimum age of 18. Internal testing then reaches up to 100 testers. If you need more people than that, or a track that behaves like a real release, move up to google play closed testing.

Google, Android developer verification FAQ, read 3 October 2026

When someone else has to hold the phone

The moment a second person needs the build, both platforms want an account and the numbers matter. On iOS, Apple caps internal testers at 100 App Store Connect users with access to your content and external testers at 10,000 people. Testers install the free TestFlight app, accept an email invitation or a public link, and lose the build after 90 days. External testing is where review enters: the first build you add to a group goes to App Review against the App Review Guidelines, review is required only for that first build, and testing starts once it is approved.

On the Google side, internal testing lives at Test and release then Testing then Internal testing in Play Console, where you create an email list under the Testers tab or upload a CSV with one address per line and no commas. Google says internal tests might not be subject to standard Play policy or security reviews, and that testers can install paid apps for free on an internal test. That is the closest Android gets to the speed of an internal TestFlight group.

The next tier up is bigger than most people expect: Google documents closed testing as up to 200 email lists, each holding up to 2,000 users, with up to 50 lists per track. One figure neither store publishes is a per tester device limit. Apple's TestFlight pages state the 100 and 10,000 tester caps and the 90 day window, but none of the three read for this article sets a number of devices one tester may install on, so treat any page that quotes one with suspicion. For the Android equivalent of a TestFlight link, and the ways it does not behave like one, see the Android side.