5 ms·

Lots of people use iPhones with Windows computers. What actual benefit does this completely arbitrary restriction give to anyone other than Apple?

kartickv 10y ago
It's not an arbitrary restriction. All the tools will have to be reimplemented. Take the simulator, for example. It's implemented by translating iOS system calls into OS X system calls. It's not an entire OS running on a emulated CPU. That won't work on Windows. Will Apple have to implement an emulator? But that will be slower for developers using a Mac. Should have they to support both? There are significant downsides. You can argue that the upside is still worth it, but you can't dismiss the downsides as "completely arbitrary".
- sjtgraham 10y ago
  AFAIK this is incorrect the simulator runs x86/x86-64 binaries and links against x86/x86-64 versions of Apple's frameworks (including UIKit). There is no translation of syscalls happening, the instruction for a syscall, e.g SVC 0x80 on ARM wouldn't be happening in your binary but in a framework your binary (indirectly) links to. Also the simulator is basically an x86 version of iOS, look inside for yourself and see. Someone correct me here but I don't see why it would be impossible to for apple to ship a simulator for Windows, n.b. how MS has shipped the Linux ABI translation.
  - kitsunesoba 10y ago
    The simulator doesn't run a full x86 version of iOS; it runs an x86 version of the iOS userland on top of the host kernel (Darwin) and components shared between OS X and iOS. A port of the simulator would be possible but it'd be a good deal heavier than its OS X counterpart since it'd be running the entire OS instead of just the topmost layer.
    - sjtgraham 10y ago
      Both platforms share the same core OS (Darwin) and Kernel (XNU), so when I say the simulator is basically an x86 iOS I think that's fair.
      - kartickv 10y ago
        You're again missing the point that that would be heavier and so perhaps not as good for developers that choose to use macOS. The question is not whether "the simulator is basically an x86 iOS". The point is that requiring macOS to build iOS apps is not an arbitrary restriction — it's a tradeoff. You can argue for or against Apple's decision, but you can't argue that it's an arbitrary restriction on Apple's part.
- douche 10y ago
  Why is the simulator not simply a VM loaded with iOS, like with Android, or Windows Phone, or most of the other targets that you can cross-compile and test for from Windows or Linux?

kartickv 10y ago

It's not an arbitrary restriction. All the tools will have to be reimplemented. Take the simulator, for example. It's implemented by translating iOS system calls into OS X system calls. It's not an entire OS running on a emulated CPU. That won't work on Windows. Will Apple have to implement an emulator? But that will be slower for developers using a Mac. Should have they to support both? There are significant downsides. You can argue that the upside is still worth it, but you can't dismiss the downsides as "completely arbitrary".

sjtgraham 10y ago
AFAIK this is incorrect the simulator runs x86/x86-64 binaries and links against x86/x86-64 versions of Apple's frameworks (including UIKit). There is no translation of syscalls happening, the instruction for a syscall, e.g SVC 0x80 on ARM wouldn't be happening in your binary but in a framework your binary (indirectly) links to. Also the simulator is basically an x86 version of iOS, look inside for yourself and see. Someone correct me here but I don't see why it would be impossible to for apple to ship a simulator for Windows, n.b. how MS has shipped the Linux ABI translation.
- kitsunesoba 10y ago
  The simulator doesn't run a full x86 version of iOS; it runs an x86 version of the iOS userland on top of the host kernel (Darwin) and components shared between OS X and iOS. A port of the simulator would be possible but it'd be a good deal heavier than its OS X counterpart since it'd be running the entire OS instead of just the topmost layer.
  - sjtgraham 10y ago
    Both platforms share the same core OS (Darwin) and Kernel (XNU), so when I say the simulator is basically an x86 iOS I think that's fair.
    - kartickv 10y ago
      You're again missing the point that that would be heavier and so perhaps not as good for developers that choose to use macOS. The question is not whether "the simulator is basically an x86 iOS". The point is that requiring macOS to build iOS apps is not an arbitrary restriction — it's a tradeoff. You can argue for or against Apple's decision, but you can't argue that it's an arbitrary restriction on Apple's part.
douche 10y ago
Why is the simulator not simply a VM loaded with iOS, like with Android, or Windows Phone, or most of the other targets that you can cross-compile and test for from Windows or Linux?