4 ms·

One thing about Jobs... he was good at saying, "XYZ is a bad idea" right up until the day he announces "we're doing XYZ and it will change the world". Once App

One thing about Jobs... he was good at saying, "XYZ is a bad idea" right up until the day he announces "we're doing XYZ and it will change the world". Once Apple can get iOS working well on x86, they'll do the same.

Judson 14y ago
From what I understand, the problem with x68 is the lack of processors that can compete with ARM on battery life, which is one of the most important aspects of a portable device.
- freehunter 14y ago
  Intel has and is shipping x86 SoC processors which can compete (perhaps not beat) with ARM power efficiency. [1] On the flip side, ARM doesn't scale as well as x86 to higher power outputs. [1] https://en.wikipedia.org/wiki/Atom_%28system_on_chip%29 https://en.wikipedia.org/wiki/Atom_%28system_on_chip%29
sjwright 14y ago
> Once Apple can get iOS working well on x86 I'd be willing to bet a lot of money that iOS already works well on x86 and has never not worked well on x86. After all, the core OS maintains ongoing heritage with an x86 OS, and every single app in the store has already been successfully compiled for x86...
- someperson 14y ago
  > every single app in the store has already been successfully compiled for x86 Really!?
  - peterkelly 14y ago
    Theoretically it would be possible develop your app in Xcode and only ever compile it for ARM and test on the actual device. But if you use the iOS simulator to develop/test your app (which I imagine every developer does), then you're running your iOS app natively on OS X, linked against a version of all the iOS libraries compiled for x86.
  - rsynnott 14y ago
    No, actually. There are a couple of third-party development tools for iOS which only compile to ARM (and which therefore can't run in the iOS simulator), notably Adobe Air for mobile, and that Delphi for iOS thing. 99.999%, though; anything written in Xcode, and anything written with the majority of third-party tools, has been run in the simulator.
- stcredzero 14y ago
  Every app that has been run in the "simulator" has been compiled on x86. The simulator is not one. It's really a cross-compiling trick.
  - masklinn 14y ago
    > The simulator is not one. It's really a cross-compiling trick. Uh? No, that's the exact opposite, the simulator is exactly a simulator. What it's not is an emulator: it does not emulate an ARM device, it simulates an iPhone by running iOS/x86.
    - nitid_name 14y ago
      Possibly a naive question: what's the difference between a simulator and an emulator? Presumably an emulator copies the actual instruction set, while a simulator... only pretends to copy the instruction set?
      - sjwright 14y ago
        An emulator does exactly as it says: it emulates. It creates an environment that appears to a running program to be identical to the real thing. This is done by emulating the hardware (e.g. BSNES), emulating the runtime environment for a native binary (e.g. VMware), or most commonly, a mixture of both. A simulator -- at least in the world of Apple iOS development -- does not attempt to emulate iOS hardware, or even the iOS operating system. All the simulator does is provide a virtual display and launches an instance of Launchpad.app. Your app then runs within that virtual display, and talks with natively compiled copies of the iOS APIs, but otherwise it's a normal Mac OS X process that can be viewed and poked with Activity Monitor, or top, or whatever. The simulator doesn't need to "boot up". There are no virtual drivers. There's no memory management. There's no emulated silicon whatsoever. The only downside to this approach I can see is that the simulator can't be used to test some things like resource limits, and some things behave very differently, like OpenGL. But you have to test on real hardware anyway, and Apple have made native testing just as easy as simulated.

Judson 14y ago

From what I understand, the problem with x68 is the lack of processors that can compete with ARM on battery life, which is one of the most important aspects of a portable device.

freehunter 14y ago
Intel has and is shipping x86 SoC processors which can compete (perhaps not beat) with ARM power efficiency. [1] On the flip side, ARM doesn't scale as well as x86 to higher power outputs. [1] https://en.wikipedia.org/wiki/Atom_%28system_on_chip%29 https://en.wikipedia.org/wiki/Atom_%28system_on_chip%29

sjwright 14y ago

> Once Apple can get iOS working well on x86 I'd be willing to bet a lot of money that iOS already works well on x86 and has never not worked well on x86. After all, the core OS maintains ongoing heritage with an x86 OS, and every single app in the store has already been successfully compiled for x86...

someperson 14y ago
> every single app in the store has already been successfully compiled for x86 Really!?
- peterkelly 14y ago
  Theoretically it would be possible develop your app in Xcode and only ever compile it for ARM and test on the actual device. But if you use the iOS simulator to develop/test your app (which I imagine every developer does), then you're running your iOS app natively on OS X, linked against a version of all the iOS libraries compiled for x86.
- rsynnott 14y ago
  No, actually. There are a couple of third-party development tools for iOS which only compile to ARM (and which therefore can't run in the iOS simulator), notably Adobe Air for mobile, and that Delphi for iOS thing. 99.999%, though; anything written in Xcode, and anything written with the majority of third-party tools, has been run in the simulator.
stcredzero 14y ago
Every app that has been run in the "simulator" has been compiled on x86. The simulator is not one. It's really a cross-compiling trick.
- masklinn 14y ago
  > The simulator is not one. It's really a cross-compiling trick. Uh? No, that's the exact opposite, the simulator is exactly a simulator. What it's not is an emulator: it does not emulate an ARM device, it simulates an iPhone by running iOS/x86.
  - nitid_name 14y ago
    Possibly a naive question: what's the difference between a simulator and an emulator? Presumably an emulator copies the actual instruction set, while a simulator... only pretends to copy the instruction set?
    - sjwright 14y ago
      An emulator does exactly as it says: it emulates. It creates an environment that appears to a running program to be identical to the real thing. This is done by emulating the hardware (e.g. BSNES), emulating the runtime environment for a native binary (e.g. VMware), or most commonly, a mixture of both. A simulator -- at least in the world of Apple iOS development -- does not attempt to emulate iOS hardware, or even the iOS operating system. All the simulator does is provide a virtual display and launches an instance of Launchpad.app. Your app then runs within that virtual display, and talks with natively compiled copies of the iOS APIs, but otherwise it's a normal Mac OS X process that can be viewed and poked with Activity Monitor, or top, or whatever. The simulator doesn't need to "boot up". There are no virtual drivers. There's no memory management. There's no emulated silicon whatsoever. The only downside to this approach I can see is that the simulator can't be used to test some things like resource limits, and some things behave very differently, like OpenGL. But you have to test on real hardware anyway, and Apple have made native testing just as easy as simulated.