Open a real iPhone from the computer you already have
A physical iPhone or iPad in your browser tab, driven by hand. Install your own build, set a location, read the logs, capture the bug — on the platform that is hardest to test honestly and easiest to skip.
No Mac required · your own .ipa, no Apple ID of ours · free device-minutes to try it
The platform hardest to test, and easiest to skip
iPhones are costly to keep, iOS updates on Apple's schedule not yours, and Safari never ran on Windows — so iOS testing quietly becomes “whoever owns an iPhone checks it on their own phone.” Open a real iPhone or iPad in your tab instead and drive it by hand: tap, swipe, type, rotate — a physical handset, not a picture of one.
What you can do on a real iPhone or iPad
The phone-side controls — the iOS gaps are answered in the FAQ, not hidden.
Install your own build
Upload an .ipa and it installs for the session — no Apple ID of ours, nothing in a store. Or open the App Store, sign in with your own, and install any app.
Drive it by hand
Tap, swipe, scroll, pinch, rotate and type on the keyboard. The bugs that only show on iOS are the ones you feel, not script.
Set a location
Coordinates on the device itself, so native apps and Safari both see them — for geofences, regional content and delivery areas, without travelling.
Settings, info and logs
Reach the phone's own settings, read its details, and watch the log stream while you reproduce the bug.
Hear the device
Media, in-app sound and alert tones come through to your tab — which matters when silence is the bug.
Capture and file it
Screenshot, record, compare against an approved baseline, and file a bug to your tracker with the evidence attached.
What breaks only on iPhone
Every one of these needs a device, not a resized desktop browser.
The keyboard moving the page
iOS shifts the viewport when the keyboard opens, so fixed footers, chat inputs and pop-ups land in the wrong place.
The address bar hiding
Viewport height changes as you scroll, so full-height sections jump, overlap or leave a gap — the top mobile-Safari complaint.
Logins that don't stick
Safari clears cookies and storage fast. “It signs me out every day” is usually this, and a short test never catches it.
Safe areas and notches
Content slides under the status bar, home indicator or a rounded corner — and the sizes differ across iPhones and iPads.
Gestures fighting the system
Swipe-back and pull-to-refresh collide with your own carousels and drawers. Feel is only testable by hand.
Autoplay that refuses
iOS blocks autoplay and inline video more strictly, so a player that works everywhere else can refuse to start.
Card number
Expiry · CVC
Card number
Expiry · CVC
Pay $48
stuckReal iPhone or simulator?
Both are in the same picker. One hard rule: an .ipa cannot run on a simulator.
Pick a simulator for the web
Testing a site in mobile Safari? An iOS simulator runs real WebKit and opens faster — the better tool while you work on layout or JavaScript.
Pick a real iPhone for your app
Anything with your own app — install, launch, permissions, push — or anything you have to feel: touch, the keyboard, the network. Iterate on a simulator, sign off on hardware.
Frequently asked questions
Yes. Upload your .ipa and it installs on a real iPhone or iPad for the session — no Apple ID of yours is required and nothing is published to a store. You can also open the on-device App Store, sign in with your own Apple ID, and install any released app for testing.
No. An .ipa is compiled for an iPhone's processor and a simulator runs native Mac code, so it cannot execute your build. Simulators are for mobile web and Safari. Every native iOS question is a real-device question.
Largely, yes. Apple requires every browser on iOS to use WebKit, so Chrome and Firefox on an iPhone are Safari's engine with a different interface. Rendering and engine behaviour are the same; the differences are in the surrounding interface, which matters far less than most teams assume.
Yes, at device level, so both native apps and Safari see the coordinates rather than only the browser. That makes geofences, regional content and delivery-radius logic testable without travelling.
No. iOS Live sessions carry no network log — that is a genuine gap against BrowserStack and LambdaTest, both of which capture it. Desktop browsers and real Android devices do have it here.
The device is cleaned before anyone else uses it — signed out, anything you installed removed, data wiped, and fully erased when a light clean is not enough. If you signed into the App Store with your own Apple ID during the session, that on its own triggers an automatic erase.
No. iOS sessions have no developer tools — not for Safari, not for a web view. The practical approach is to reproduce the bug on iOS and then investigate the cause in a Chrome session, which has an embedded DevTools panel.
No. Apple's sandbox blocks dropping a file into another app's storage, so file push is not available on iOS — an industry-wide limit. It does work on Android and desktop browsers.
Yes, but per app rather than for the whole device: the app under test is relaunched in the language you choose, so you can check longer strings and right-to-left layouts. The device's own interface language is not switched. The timezone, by contrast, is set on the device.
Face ID and Touch ID — yes. Turn on Biometric for your build and you answer the prompt yourself, pass or fail, during the session (see our Biometric testing page). Camera image injection, QR scanning, a physical SIM and SMS delivery are still not built here; if those are central to your flows, BrowserStack is the better fit for that work.
Yes. Upload your .ipa and it installs on a real iPad for the session just as it does on an iPhone, or open the on-device App Store, sign in with your own Apple ID and install any app. Safe areas and viewport height behave differently on an iPad, so it is worth checking on the real thing rather than a resized iPhone.
See your product on a real iPhone in the next minute
No handset to buy, no Mac to own, no colleague to borrow from.