3 ms·

iOS is not particularly different from OSX. That's why Apple developers get to use a super fast simulator instead of the dog slow emulator we Android developers

iOS is not particularly different from OSX. That's why Apple developers get to use a super fast simulator instead of the dog slow emulator we Android developers are stuck with.

monocasa 8y ago
Except in multitasking UX. Yes, technically there isn't anything stopping you from running a compiler on iOS, but there's so much more to having a relevant development platform than "does llvm technically run".
- saagarjha 8y ago
  > Yes, technically there isn't anything stopping you from running a compiler on iOS, but there's so much more to having a relevant development platform than "does llvm technically run" You can't run unsigned code on iOS (with a few exceptions), and I don't believe that anyone has come up with a viable solution to codesign code on the fly on-device.
  - monocasa 8y ago
    Sure, but that's easy for Apple to fix if they want. The lack of true, useful multitasking on iOS is the much bigger issue.
- my123 8y ago
  iOS development builds actually have the compiler installed by default. It can also be installed on jailbroken devices via Cydia too.
  - monocasa 8y ago
    Sure, but my point is that's easy. The hard part is converting iOS to a point where you can get real multitasking work done. Even just switching back and forth between an IDE and a web browser is super painful compared to a desktop/laptop.
Reason077 8y ago
Similarities between iOS and macOS don't have much to do with it. The reason the Android emulator is slow is that it is actually emulating an ARM CPU. The iOS simulator, on the other hand, is running an iOS natively built for x86, and Xcode targets the x86 architecture when you build your app for the simulator.
- kitsunesoba 8y ago
  It certainly doesn’t hurt that the simulator only needs to run the iOS front end on top of macOS Darwin instead of a full copy of iOS, though. Couldn’t something similar be done with Android on Linux, running x86 Android and using the host system’s kernel?
  - monocasa 8y ago
    There's a lot of Android specific kernel interfaces that'd have to be added to the desktop. Stuff like the binder IPC. It's doable, but work.
  - saagarjha 8y ago
    > It certainly doesn’t hurt that the simulator only needs to run the iOS front end on top of macOS Darwin instead of a full copy of iOS, though. Uh, no. The simulator literally boots an entire copy of iOS, with its own libraries, frameworks, and utilities, that's entirely separate from the host OS.
    - Reason077 8y ago
      That is incorrect. The iOS simulator is not a virtualized environment. It's not running it's own kernel etc, rather it's just a set of iOS libraries and frameworks built for x86 and a thin compatibility layer so that they run on macOS. You can actually see your running iOS applications, and all of the iOS daemons etc show up as first class processes on you Mac if you run "ps". iOS apps running in the simulator are not separate from the host OS at all - they're running on the host OS, just like any other process. Try killing "Springboard" from your Mac command line and watch what happens inside the simulator...

iOS is not particularly different from OSX. That's why Apple developers get to use a super fast simulator instead of the dog slow emulator we Android developers are stuck with.

monocasa 8y ago

Except in multitasking UX. Yes, technically there isn't anything stopping you from running a compiler on iOS, but there's so much more to having a relevant development platform than "does llvm technically run".

saagarjha 8y ago
> Yes, technically there isn't anything stopping you from running a compiler on iOS, but there's so much more to having a relevant development platform than "does llvm technically run" You can't run unsigned code on iOS (with a few exceptions), and I don't believe that anyone has come up with a viable solution to codesign code on the fly on-device.
- monocasa 8y ago
  Sure, but that's easy for Apple to fix if they want. The lack of true, useful multitasking on iOS is the much bigger issue.
my123 8y ago
iOS development builds actually have the compiler installed by default. It can also be installed on jailbroken devices via Cydia too.
- monocasa 8y ago
  Sure, but my point is that's easy. The hard part is converting iOS to a point where you can get real multitasking work done. Even just switching back and forth between an IDE and a web browser is super painful compared to a desktop/laptop.

Reason077 8y ago

Similarities between iOS and macOS don't have much to do with it. The reason the Android emulator is slow is that it is actually emulating an ARM CPU. The iOS simulator, on the other hand, is running an iOS natively built for x86, and Xcode targets the x86 architecture when you build your app for the simulator.

kitsunesoba 8y ago
It certainly doesn’t hurt that the simulator only needs to run the iOS front end on top of macOS Darwin instead of a full copy of iOS, though. Couldn’t something similar be done with Android on Linux, running x86 Android and using the host system’s kernel?
- monocasa 8y ago
  There's a lot of Android specific kernel interfaces that'd have to be added to the desktop. Stuff like the binder IPC. It's doable, but work.
- saagarjha 8y ago
  > It certainly doesn’t hurt that the simulator only needs to run the iOS front end on top of macOS Darwin instead of a full copy of iOS, though. Uh, no. The simulator literally boots an entire copy of iOS, with its own libraries, frameworks, and utilities, that's entirely separate from the host OS.
  - Reason077 8y ago
    That is incorrect. The iOS simulator is not a virtualized environment. It's not running it's own kernel etc, rather it's just a set of iOS libraries and frameworks built for x86 and a thin compatibility layer so that they run on macOS. You can actually see your running iOS applications, and all of the iOS daemons etc show up as first class processes on you Mac if you run "ps". iOS apps running in the simulator are not separate from the host OS at all - they're running on the host OS, just like any other process. Try killing "Springboard" from your Mac command line and watch what happens inside the simulator...