How to test an iPhone app without an iPhone (or a Mac)

By Sigsten Gustavii· 26 October 2026· 8 min read

Testing an iPhone app used to need two expensive things: a Mac to run Apple's tools and an iPhone to run the app. If you have neither, it can look as if you cannot even see your own app before it ships.

You can. The iOS Simulator, the same tool iPhone developers use every day, can run in a data centre and appear in your browser. This guide explains what the simulator is, the ways to reach one without a Mac, what to test, and the few things only a real phone can tell you.

What the iOS Simulator is, and is not

The iOS Simulator is part of Apple's Xcode. It runs a real copy of iOS on a Mac and opens your app inside a picture of an iPhone or iPad. The app is compiled the same way as for a phone, from the same Swift code, so its screens, layouts, navigation, data and logic behave like the real thing.

It is a simulator, not an emulator: it does not pretend to be iPhone hardware. That is why it starts in seconds and why a few hardware features, like the camera, are not there. For almost everything else, it is how professional iOS developers test day to day.

Ways to test an iPhone app without owning an iPhone

Borel's simulator in your browser

Every app you make in Borel opens in Apple's iOS Simulator on Borel's Mac, streamed into your browser. You click to tap, scroll with your mouse or trackpad, and type with your keyboard. The app is your real Swift app, compiled with Xcode a moment earlier. When you ask for a change, the simulator shows the new build.

You can switch the device too: the small iPhone SE, an iPhone 12, the large iPhone 18 Pro, an iPad or a 12.9-inch iPad Pro, all on iOS 27. That is the quickest way to see whether a layout survives a small screen. The simulator is free on every plan; Pro removes the daily limit on minutes. More on the iPhone simulator in your browser.

Xcode on a Mac

If you have a Mac, Xcode includes the simulator for free. You need to build the project yourself, and the Mac needs enough memory and disk for Xcode, which is large.

Streamed simulator and device services

Services such as Appetize and BrowserStack stream simulators or real devices to a browser. They are built for development teams who already have an app file to upload, and their pricing reflects that. They are useful for checking an app on many devices, less so for someone making their own app.

TestFlight on someone else's phone

If a friend has an iPhone, TestFlight, Apple's beta app, can put your build on it. That needs a developer account and an app already uploaded to App Store Connect, so it fits late in the process rather than every day.

How to test your app in the browser, step by step

Step 1: Build the app

Describe your app in Borel. When it is ready, it opens in the simulator on its own. If you have not made one yet, the guide on how to make an iPhone app with AI covers it.

Step 2: Walk through it as a newcomer

Pretend you have never seen the app. Can you tell what to do on each screen? Does every button do something? Is anything cut off or overlapping?

Step 3: Try the paths people forget

These are where apps break, and they take minutes to check:

• Empty states: delete everything. What does the list look like with nothing in it?
• Long text: type a very long name or note. Does it wrap, cut off neatly, or break the layout?
• Restart: close and reopen the app. Is your data still there?
• Wrong input: leave a required field empty, type letters where a number goes.
• Small screen: switch to the iPhone SE and look at every screen again.
• Dark mode and larger text: if your app supports them, check both.
• Sign-up and sign-in: if the app has accounts, create one, sign out and sign back in.

Step 4: Describe what is wrong, one thing at a time

When something is off, say exactly what you did and what happened: "On the Add screen, if I leave the name empty and tap Save, nothing happens. Show a short message instead." Then test that one change before asking for the next.

Step 5: Check it on a real phone when you can

When the app feels right in the simulator, try it on an iPhone if there is one near you. With Borel Companion and a free Apple ID, it installs on your own phone from Windows or a Mac. On someone else's phone, TestFlight is the way.

I tested the app in the simulator. Please fix these, one at a time:
1. On [screen], when I [did this], [this happened]. It should [expected result].
2. On the iPhone SE, the [element] on [screen] is cut off. Make it fit.
3. With no items, [screen] is blank. Show a friendly empty state with a button to add one.

Testing an app with accounts and shared data

Apps where people sign in and see each other's content need a few more checks, because two people are involved. In the simulator you can play both parts yourself:

1. Create an account and add some content.
2. Sign out, create a second account, and check what the second person can and cannot see.
3. Change something as one person and confirm the other sees the change after a refresh.
4. Delete the second account from inside the app, and make sure its content goes with it.
5. Sign back in as the original person and check nothing of theirs was lost.

Do this with throwaway email addresses you control. It is the fastest way to catch an app that shows one person's data to another, which is the kind of mistake you never want to find after publishing.

Testing AI features inside your app

If your app uses AI, for example to answer questions, summarise notes or describe a photo, test it with awkward inputs as well as easy ones. Ask it something off-topic, send an empty message, paste a very long text. Check that the app explains itself when the AI cannot help, instead of showing a blank screen. AI calls run in the simulator just as they will on a phone. More on what Borel can add in built-in AI.

A short test plan you can reuse

What only a real iPhone can tell you

The simulator covers screens, logic and data. A few things depend on the hardware, and a short session on a real phone is worth it before you publish:

Common testing mistakes

• Only testing the happy path. Real people make typos, cancel halfway and come back later.
• Testing on one screen size. An app that looks great on a large iPhone can be cramped on a small one.
• Asking for many fixes in one message. One fix at a time is easier to check and less likely to break something else.
• Leaving sample data in. Clear example rows before you publish.
• Skipping the real device entirely. If your app uses the camera or haptics, try it on a phone before Apple's reviewers do.

From testing to publishing

Once the app passes your own tests, the next step is either your own phone or the App Store. Read how to publish an app to the App Store without a Mac if the app is for other people, and how to install your own iOS app from Windows if it is for you.

Tapping through the real app in a browser is still the part of Borel I use most. Try to break your app on purpose; it is the quickest way to make it good.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.