Why the iPhone Simulator is Awesome | Hacker News Reader

Why the iPhone Simulator is Awesome

apenwarr.ca

53 pointsblasdel35 comments

So (as a non IPhone/Apple ecosystem developer), let me ask Iphone devs here, how accurate is the simulator? When something works perfectly on the simulator how often does deployment to the actual device force code changes? Frequently? rarely? never?

Is it possible to get an "almost perfect" IPhone app with just a MacBook Pro?

(Some context: If Apple ever drops its annual developer fees for the Iphone/Ipad, I'll buy an MBP and/or an IPhone or IPad. Just curious as to how much I can get done with just an MBP before buying an IPhone/ IPad.

Apologies in advance if this is a stupid question. I know next to nothing about what development in the Apple ecosystem is like).

You can create an app, but you'll still need to do on-device testing to iron out some rough spots.

- Everything is faster in the simulator, except for OpenGL and (I think) Core Animation.

- Some desktop classes use more memory than the mobile counterparts so memory usage tests are not accurate. OpenGL again here.

- The simulator never runs low on memory that I've noticed. The actual device does, of course.

- Multitouch. You can test a two-finger pinch on the simulator by holding down alt, but the touches arrive in a different order on the device leading to subtle bugs.

- No accelerometer in the sim. You can test rotation the sim, but not put the screen face up or face down.

- Filenames in the sim are not case sensitive, but the device is. Snags many a new developer.

- There are other situations like sleep/wake, iPod interaction / mixing, and phone call interruptions that you can only test on a device.

In short you can get your app running in the simulator, but I would never submit to Apple without testing on a device.

I haven't had a single issue with correctness in my 9 months of development. That is, everything looks and operates exactly the same on the device as it is the simulator.

Performance is obviously the tricky part, along with seeing real hardware in action (GPS, 3G connection speed) and software features (Push Notifications, iTunes integration).

also note that you don't need to buy the developer program to develop and run programs the simulator. the developer program only is needed when you want things to go onto a device

The simulator is about 95 - 99.9% accurate depending on the task in hand.

There are some functions, such as push notification, that can't be simulated (at least from my experience).

If you were going to release an app I would absolutely always test it on at least one physical device before submitting to Apple.

What do you mean by "95 - 99.9% accurate"?

Couple things I noticed when using the simulator:

1) you have almost unlimited memory - if you're not clever with your memory management (eg. UITableView cells) things will look great in the simulator but will crash/run slow on the device

2) some things can't be simulated (push notifications, in app purchase)

3) certain libraries have different binaries for the simulator vs. the device. bugs in one or the other can cause things to work differently

If you submit your app to apple having tested only on the simulator, chances are they will run into a crash/bug when reviewing it causing your app to be rejected. Having said that, it's a great tool for debugging.

It really isn't my business, but why would you care about a $99/yr fee if you are going to be purchasing a new MBP and an iPhone or iPad?

I just don't see why you'd wait for a $99 fee to be dropped before spending at least $2000 on hardware.

"It really isn't my business, but why would you care about a $99/yr fee if you are going to be purchasing a new MBP and an iPhone or iPad?

I just don't see why you'd wait for a $99 fee to be dropped before spending at least $2000 on hardware."

Fair question.

It doesn't have anything to do with the quantum of money (99$,999$ whatever though having to pay 20% of the price of an IPad annually to develop for it is a bit sleazy in my opinion).

I have money to spend on computers. I just don't want to rent my right to develop and deploy on my device (which I already paid full price for) annually from Apple.

Apple should be glad someone chooses to learn, develop for and participate its ecosystem. It isn't a privilege you should have to pay annually for. ( I am sure Steve Jobs thinks it is a privilege for developers to develop for his babies! One of us is wrong but then he is a billionaire and i am just a poor hacker so who is to say? :-P )

I am not opposed to Apple keeping its OS closed. I am fine with the Apple Store distribution "choke point". It sucks a bit but I can see why Apple want to do it that way. I am not even opposed to a small one time payment for the devtools if I feel they are better than emacs + gcc (though I would be happy to avoid it. Asking individual developers to pay for dev tools is a bit weird in this day and age). But once I pay, I should be able to use them forever and not have to renew my right to develop annually.

I don't want to let Apple decide what or when or how long I can and can't code and deploy on my device (as distinct from selling it to others through the Apple Store). If I buy an IPad, want to build and deploy my app on my IPad without Apple getting in the middle. As it stands, you can't deploy an app onto your device without paying Apple an annual fee.

I think the existing structure is good for people who buy a dev license just so they can build and sell apps via the App Store. If I want to code up some small app for personal use (and as a developer I do this all the time), I wouldn't like to have to pay an annual fee for that.

I think Alex Payne expressed this better than I can in his latest blog post on the IPad. As a developer I find Apple's idea that developers have to pay annually to write software for their own devices to be very arrogant and condescending. Even Microsoft in its heyday wasn't that bad.

To be clear, I don't have a problem with anyone choosing to pay an annual dev fee or developing for Apple or whatever. Just answering your question as to why I won't pay.

Yes. $99/year makes sense for everything Apple offers to get your software on the App Store, but that should be the only part that requires a subscription. You should be able to compile code for your own device for free.

Actually, I like the model that would create: If you want to sell your software, just subscribe and Apple makes it easy. If you want to avoid the App Store, then just go open-source, since now anyone can compile what you distribute.

The same tech-savvy audience that doesn't like the "choke point" of the App Store can just go full-on FOSS for iPhone development, which seems like a perfect fit.

> I just don't want to rent my right to develop and deploy on my device

>I am not opposed to Apple keeping its OS closed. I am fine with the Apple Store distribution "choke point".

These two statements contradict each other. A closed OS means that the consumer can only load applications on their device that have been approved by Apple. If people weren't required to rent the right to deploy on the iPhone, then anyone could freely load arbitrary non-Apple approved code. Therefore, by arguing for rent-free development, you are demanding a non-closed OS.

">> I just don't want to rent my right to develop and deploy on my device

>>I am not opposed to Apple keeping its OS closed. I am fine with the Apple Store distribution "choke point".

>These two statements contradict each other. "

They don't. (see below).

"These two statements contradict each other. A closed OS means that the consumer can only load applications on their device that have been approved by Apple."

I am using "closed" as opposed to "Open Source". Linux is Open Source. Windows is closed. I can load anything I want on it without getting permission from Microsoft, though I can't see the source. I don't mind much being able to sell only through AppleStore.

I just want to be able to put my apps on my device without paying anything to anybody, not sell them to you (for which I don't mind going through the App Store if necessary. Iow I don't want to deploy on your device.I have no plans to sell desktop/device sw at present which maybe why I don't care about AppleStore's policies.)

You're actually the prime candidate for jailbreaking your phone. Then you can put your apps on your phone.

The only problem I've had with it was that the simulator does not have access to your iTunes library, so code to run against the MediaPlayer.framework doesn't work. I've not had any cross-compilation issues.

My Mac has a beefier CPU than my iPhone, so you still have to test on the device to check performance. Same story with memory usage. You can simulate a memory warnings from the simulator UI for testing, but you want to make sure that on the device you are not hitting up against real limits to start with. In theory, the simulator doesn't have an email client in the background, so there is always going to be more free space than on the device itself, but in practice I've not had any problems - I don't want to be filling up memory anyway.

The sim is faster, by far.

The sim does oodles more video formats than the phone does

You can't test in-app purchase on the sim

You can't test accelerometer on the sim

You can't test notifications on the sim.

The sim is sometimes faster and sometimes slower. iPad apps using OpenGL are much slower on my MacBook Pro than they are in the simulator.

You mean OpenGL was slower in the sim and faster on a real device, right? That's been my observation too.

Ahh, hadn't done an OpenGL app yet. Nice to know.

Wondering: does every test of an in-app purchase result in a cut to Apple?

No, there is a "Sandbox" in-app purchase store you use when developing in-app purchases. It's actually a bit of a pain the ass, because you have to create a whole new user to use that store and you have to sign out of your real user and into the fake user to test in-app stuff.

They have a similar sandbox for notifications.

I developed a game and it just worked exactly the same in the simulator. I only couldn't really test the multitouch functions (because you only have your single mouse cursor).

You can use iSimulate on your phone to send full touch, motion, attitude, etc events to your code running under the simulator. Pretty nifty.

If you hold down alt while using the iPhone Simulator, you can get two finger multitouch, which can be used for gestures like pinching too.

i strongly disagree

the simulator will run with the performance and memory of your workstation, this is NOT a realistic test of your app. Have seen many devs that run into showstopper memory/or speed problems once they switched to on device debugging ( always test on the device !! )

Moreover you have subtle api inconsistencies, some calls work on the simulator that fail hard on the device ..

stuff life location , rotation , storekit , etc are different ( but that should be rather well understood )

so if you develop on a fast workstation and not a underpowered laptop then you should always prefer a native simulator ...

( my experience is based on working with iphone,j2me,and android emulators )

The Nokia/Symbian SDK emulator works similarly -- to run your application in the simulator you must compile for it separately. And it runs only on Windows. Unlike the iPhone simulator though, Nokia's is painfully slow.

Almost every negative he mentioned for BlackBerry emulation is incorrect. It blows my mind that people write critical articles like this and not do ANY homework on the actual subject.

When you transition to fanboy-condition, it's a given you have precious little experience with any platform other than the object of you fanboyism. Don't expect an Apple fanboy to also have not only a Blackberry, but a BB SDK.

I am somewhat of an exception. I really love Linux (although any X-ish Unix-like with decent package management will do) and I am currently condemned to run a Windows notebook at work.

sigh.

Turns out he does have a Blackberry and the BB SDK: http://apenwarr.ca/log/?m=201004#09

Well... That makes him an atypical fanboy...

You can't even run Virtualbox? That's harsh.

I can, but the VM can't be part of the domain.

I'm working on that. Subversion (not the version control system) is my middle name ;-)

Microsoft do (did?) the same thing with PocketPC development. Their emulator ran natively, as would any apps (which also had to be compiled natively to x86 for the emulator), but you'd then switch to ARM/MIPS/SH3 for release.

"the simulator can slow down your program to iPhone speed" Completely untrue, afaik.

Yes, the simulator has no throttling features, for CPU speed or network bandwidth.

This is why we have a collection of vintage iPhones (4/8GB models). It does not address the issue of network speed though, unless we swap SIMs (which we're not even sure will work).

I think most phone simulators work in the way he's describing, certainly the java based ones.

If they did emulate the CPU it would be better and more accurate though.

His 1st assumption is wrong:

Mos mobile sdk emulators run at device speeds on any 1.5GHZ to 2.8GHZ or higher machine including Android SDK emulator

Even MS Mobile emulators run at device speeds on desktop

Unlike the Apple ipHone emulator I can run most j2me MS Mobile and android emulators at the exact device speed

Reply on news.ycombinator.com