iOS Simulator

Anyone writing an app for the iPhone has to keep trying it out. The iOS Simulator is a program for Mac computers that recreates an iPhone on the screen for this purpose. You see a window in the shape of a phone, with a home screen, settings, and the app you’re currently working on. Clicking is done with the mouse, typing with the computer keyboard. The program is part of Xcode, Apple's free development environment, meaning the software used to write iPhone apps. The simulator doesn’t fully replace the real device, but it replaces it for most moments of the working day.

Why developers don’t work on a real iPhone

While programming, you change a line, restart the app, and check the result. This happens hundreds of times a day. Over a cable to a real iPhone, each cycle takes noticeably longer. In the simulator, the app starts within a few seconds, directly on the same computer.

The second reason is device variety. Apple sells phones with very different screen sizes, plus tablets in several formats. An app has to look good on all of them. Nobody buys twenty devices just for that. In the simulator, you switch the model in a menu and immediately see if a button slips out of the frame.

Then there are situations that are hard to reproduce on a real device. You can set a different language, choose very large text, or pretend the phone is in Tokyo. A common misconception is that the simulator is only meant for beginners. Even large companies develop in it for almost the entire day.

Recreation, not imitation: what happens inside

It’s important to understand the difference between a simulator and an emulator. An emulator fully pretends to be different hardware and recalculates every instruction of the foreign chip. That is slow. The iOS Simulator does not do this. It runs the app directly on the Mac’s processor, as fast as any other Mac program.

This is possible because Apple provides a special version of the iPhone system software for the simulator. This version is compiled for Mac processors. So when testing, the app is not built in the version that later ends up in the App Store, but in a second version for the simulator. This is invisible to the developer; Xcode handles it in the background.

This leads to the catch. Anything that requires real hardware is missing or only approximated. The camera produces no image, Bluetooth doesn’t work, and the simulator doesn’t reveal how fast the app really runs: the Mac is more powerful than a phone. Payment processes and push notifications also behave differently. That’s why, before release, testing on a real device is still always necessary.

From promotional video to automated testing

Even people who never write an app still see the simulator regularly. Many screenshots and videos of apps are recorded in it, because the picture can be captured cleanly and without reflections. Tutorials on YouTube also usually show a simulator rather than a real phone.

In companies, it’s also part of automated quality control. After every code change, test programs run on servers that click through the app in the simulator on their own. If a test fails, the system reports the error before users notice it. On a server, you couldn’t easily control a shelf full of real iPhones.

For Android, there’s a counterpart, the Android Emulator, which actually does recalculate foreign hardware and is therefore often slower. And anyone who wants to take a look themselves doesn’t need a programming course: Xcode is free in the Mac App Store, and the simulator starts even without a project of your own.