5 ms·

A fun read and on the face of it, Apple's stance does seem obstinate/bizarre... but on the other hand, with my testing hat on: how can you claim to support an u

by frio 8y ago

A fun read and on the face of it, Apple's stance does seem obstinate/bizarre... but on the other hand, with my testing hat on: how can you claim to support an unreleased phone? There's not even a cloud testing service yet...

saagarjha 8y ago
Xcode ships with a simulator for these phones.
- threeseed 8y ago
  Simulator being the key point here. It is not emulating the actual phone itself. It merely translates the iOS calls into OSX ones. It is not accurate in all cases and can be wildly off when it comes to performance.
  - saagarjha 8y ago
    Ok, but for many apps the only thing that really changes is the new screen size. For example, I will be pushing out updates to my app without testing on the new devices themselves, since it really does not rely on any new features.
  - pentae 8y ago
    In a perfect world all app devs would have 10 iPhones To be able to test across all different hardware. Of course, that would be ridiculous.
    - tspike 8y ago
      It's even worse: one of each device for every OS version supported, which Apple themselves make exceptionally difficult as it's nearly impossible to downgrade to older OS versions.
    - village-idiot 8y ago
      That’s actually pretty common. The cost of testing hardware is much much lower than the cost of the developer making the app.
  - xenadu02 8y ago
    > It merely translates the iOS calls into OSX ones That is not an accurate description of what the simulator does. It is a separate userspace running on the same kernel, in this case the iOS userspace running side-by-side but isolated from the macOS userspace. The simulator uses entirely iOS binaries, built for x86/x86-64. This includes UIKit, Foundation, libc, libdispatch, etc. It does not use the macOS ABI, nor the macOS libc/Objective-C/Swift runtimes. Each individual simulated device is its own isolated mach bootstrap, with its own separate launchd, daemons, and XPC services. With the exception of a few libraries like the syscall interface and libpthread, which are tightly bound to the kernel.
    - CodeWriter23 8y ago
      And still, the simulator is not the same as running on-device. Much of the iOS security model is non-existent in the simulator. If you’ve ever written an AppEx using a shared container, you know that. (Or you’re running to verify your code works on-device right now) The simulator has to render the screen via the macOS display device, and I can tell you my trusty Radeon 5870 is only up for rendering about 5 frames per second in the simulator. I’m pretty sure any Metal apps will be wildly different in the simulator. I don’t even consider myself an expert iOS Programmer at this point, and I can come up with three examples off the top of my head. I’m sure there are plenty more. And there’s a reason every single iOS library or widget on GitHub requires all bug reports to be made only after testing on-device.

by frio 8y ago

saagarjha 8y ago

Xcode ships with a simulator for these phones.

threeseed 8y ago
Simulator being the key point here. It is not emulating the actual phone itself. It merely translates the iOS calls into OSX ones. It is not accurate in all cases and can be wildly off when it comes to performance.
- saagarjha 8y ago
  Ok, but for many apps the only thing that really changes is the new screen size. For example, I will be pushing out updates to my app without testing on the new devices themselves, since it really does not rely on any new features.
- pentae 8y ago
  In a perfect world all app devs would have 10 iPhones To be able to test across all different hardware. Of course, that would be ridiculous.
  - tspike 8y ago
    It's even worse: one of each device for every OS version supported, which Apple themselves make exceptionally difficult as it's nearly impossible to downgrade to older OS versions.
  - village-idiot 8y ago
    That’s actually pretty common. The cost of testing hardware is much much lower than the cost of the developer making the app.
- xenadu02 8y ago
  > It merely translates the iOS calls into OSX ones That is not an accurate description of what the simulator does. It is a separate userspace running on the same kernel, in this case the iOS userspace running side-by-side but isolated from the macOS userspace. The simulator uses entirely iOS binaries, built for x86/x86-64. This includes UIKit, Foundation, libc, libdispatch, etc. It does not use the macOS ABI, nor the macOS libc/Objective-C/Swift runtimes. Each individual simulated device is its own isolated mach bootstrap, with its own separate launchd, daemons, and XPC services. With the exception of a few libraries like the syscall interface and libpthread, which are tightly bound to the kernel.
  - CodeWriter23 8y ago
    And still, the simulator is not the same as running on-device. Much of the iOS security model is non-existent in the simulator. If you’ve ever written an AppEx using a shared container, you know that. (Or you’re running to verify your code works on-device right now) The simulator has to render the screen via the macOS display device, and I can tell you my trusty Radeon 5870 is only up for rendering about 5 frames per second in the simulator. I’m pretty sure any Metal apps will be wildly different in the simulator. I don’t even consider myself an expert iOS Programmer at this point, and I can come up with three examples off the top of my head. I’m sure there are plenty more. And there’s a reason every single iOS library or widget on GitHub requires all bug reports to be made only after testing on-device.