Answer (1 of 4): It’s possible. Just click on the simulator name on top left of Xcode window. Your device will be shown on the top(Sina’s iPhone). There are a few questions relating to this topic but nothing quite the same when it comes down to the details: We would like to use the iOS Simulator without installing the rest of XCode on a macbook. It is an in-house laptop, and will be used by employees, but not engineers.
How to run an iPhone app in the simulator without using XCode
I spent a lot of time looking around on the Internet for this answer, andthe results were basically nonexistent. The answer is: iphonesim on github. (Despite its name, iphonesim isn't an iPhone simulator; you still need theiPhone SDK to be installed so it can use their simulator.)
The app is named iPhone Simulator.app. Why Apple buried the iPhone Simulator app that deep into a directory, I don’t really know. If you can’t find the iPhone Simulator you may have a different version of the iPhone SDK, or you might only have Xcode installed without the iPhone SDK.
The bad news is there's no obvious way to run your app in a Debugger usingthis system. Hopefully someday it'll be added or I'll figure it out, andthen I'll be rid of XCode for good.
Why the iPhone Simulator is Awesome
While we're here, I'm very impressed by the whole concept on which theiPhone simulator works. Most embedded devices (including Blackberry,Android, and other phones) use software to emulate the embedded CPU, whichthen runs the embedded OS, which then runs your app. This kind of sucks,because the emulator has to work really hard (it often runs at only afraction of the speed of a real device), and if you crash it you have toreboot it. Plus loading apps onto a simulated device is extra crappy,because you have to simulate a slow USB connection, and so on.
The iPhone simulator works nothing like that. Instead, you compile your appfor your native CPU, and they made the iPhone simulator just anative program that runs on your workstation and provides the iPhoneAPI (using native libraries). You simulate and test your program,and when you're finally happy with it, you recompile your app for thetarget CPU that actually runs on an iPhone. Then it won't work on thesimulator anymore.
The result is that the simulator starts instantly and there's noinsane two-layer debugging scheme in which you're running a native debuggerand decoding non-native (and usually JITted) CPU instructions.
Some people would argue that this method is 'less accurate' than preciselyemulating the target CPU, and thus the simulator doesn't add much value,since you'll have to test the native app in the end anyhow. It's true thatsimulating this way is inaccurate and you should do final tests on a realdevice. The misconception, though, is that the old, annoying, slow,'emulate everything' method is any more accurate. In fact, it'sworse.
The fact is, emulators are never perfect. CPU/hardware emulators arereally hard to get right, especially if you're trying to make themrun fast. If you're not trying to make them run fast, you have awhole different set of problems, because now your simulator is way slowerthan the real device, so all the animations/etc will be wrong. Trydebugging an OpenGL app when your framerate is 1/10th what it should be.
By contrast, the iPhone simulator's method seems magically wonderful. Sincethe iPhone OS is MacOS, all the kernel APIs are the same. Thenatively-compiled frameworks, libraries, and display engine are builtfrom the same source code, so you know they're the same too. And yourMac's CPU is a lot faster than the iPhone's CPU, so the simulator can slowdown your program to iPhone speed, which is a lot easier than speeding itup (although admittedly imperfect).
Iphone Simulator Mac Without Xcode Version
In fact, with this method, the only potential sources of incorrectsimulation are a) speed (which they seem to have gotten right); b)cross-platform bugs in gcc (I don't know of any); or c) differences inmemory layout making memory corruption behave differently. (c) could be aproblem, but they seem to provide a lot of debugging tools and you shouldn'tbe depending on memory corruption anyhow.
Incidentally, this design justifies the fact that you have to have a Mac todo iPhone development, and you have to have the latest MacOS (Snow Leopard)to run the latest SDK. This annoyed me when I first heard of it; I thoughtApple was just trying to lock more people into buying a Mac. But now ittotally makes sense: iPhone OS is Snow Leopard, so if you want to run thenative simulator, of course you need Snow Leopard, or the simulator can'tpossibly work.
That's a really brilliant design tradeoff with huge benefits. Andthey get to lock more people into buying a Mac.
Update 2010/04/08: A few people have pointed out that the Blackberry'emulator' is apparently not actually an 'emulator' but in fact runs anatively-compiled version of the Blackberry JVM. Okay, I guess, but that'snot really the point. The point is that it still spends upwards of 30seconds booting the 'virtual Blackberry' before it even gets to thepoint where you can run your program. (And you have to do this everytime you want to run your program.) This is annoying, slow, and pointless,and the (apparently native??) JVM still runs everything horrendously slowly -slower than a real Blackberry. So if it's not a native device emulator,then congratulations, it's somehow even stupider. Yes, I've done realBlackberry development, and the difference between the Blackberry and iPhonesimulators is night and day.
Comments are closed.