5 ms·

Speaking as an iOS developer, you do not screw with the fruit. > Developer learns iOS > Developer uses private APIs (which is neither easy, or allowed per the

Speaking as an iOS developer, you do not screw with the fruit. > Developer learns iOS > Developer uses private APIs (which is neither easy, or allowed per the terms they agreed to) > Developer sends in app for approval, is rejected for above because duh > Developer whines on the Internet and gets a bunch of people angry at Apple, who likely will not change. You know I feel the need to point out that Apple doesn't lock us out of code to be mean, they do it because it ensures their devices don't suck, because we as developers do not have access to the system level things that can make them suck.

shinratdr 11y ago
None of this is what happened. Here's what actually happened. Developer develops a tweak requiring a jailbreak. It becomes one of the most popular jailbreak tweaks available. Five years pass, Apple inadvertently allows sideloading by giving anyone who wants one a dev certificate. Developers utilize this to create a version of their tweak that can live inside the sandbox & can be signed by end users, but still utilizes private APIs. They develop this and release it, knowing full well that they're doing an end-run around Apple's policies, very similar to requiring a jailbreak. They did not develop it expecting it to be approved. I have no clue where you got that from. The only confusing part is when they caved because Apple complained, knowing full well they would complain at some point.
dnautics 11y ago
They also do it because if they don't, they lose standing for future legal remedies.
- wiml 11y ago
  That applies to trademark cases, but I don't see why it would apply to this. It sounds like legal folklore.
mikeash 11y ago
How does forcing someone to take down an Xcode project hosted on their own web site help to ensure that my iPhone doesn't suck?
- natch 11y ago
  It doesn't help to ensure anything. But having binaries out there that anyone is encouraged to sign and install, with no way to know what hidden features are there in what projects, is not a very well thought out model if Apple wants to make suckage less likely.
  - mikeash 11y ago
    How is it any different than having binaries on the App Store that anyone is encouraged to install, with no way to know what hidden features are there in any of them?
    - natch 11y ago
      As you well know, upon upload for App Store submission, Apple runs processes that scan those binaries for use of private APIs. Admittedly imperfect processes, yes, but different from having no processes whatsoever.
      - mikeash 11y ago
        I get why Apple does it, but this prohibition increases my device's suck rather than decreasing it, since it locks out some potentially-useful apps.
        natch 11y ago
        Yes they are balancing the cost/benefit equation of the untold levels of damage to consumers and to Apple itself potentially done by bad apps on one side, versus the relatively less impactful in their judgement benefits of potentially useful apps on the other side. The assessment that this increases the device's suck relies on an certain assumptions about just how bad the damages could possibly be, assumptions that you make, but that they are reluctant to make on behalf of their users.
        mikeash 11y ago

shinratdr 11y ago

None of this is what happened. Here's what actually happened. Developer develops a tweak requiring a jailbreak. It becomes one of the most popular jailbreak tweaks available. Five years pass, Apple inadvertently allows sideloading by giving anyone who wants one a dev certificate. Developers utilize this to create a version of their tweak that can live inside the sandbox & can be signed by end users, but still utilizes private APIs. They develop this and release it, knowing full well that they're doing an end-run around Apple's policies, very similar to requiring a jailbreak. They did not develop it expecting it to be approved. I have no clue where you got that from. The only confusing part is when they caved because Apple complained, knowing full well they would complain at some point.

dnautics 11y ago

They also do it because if they don't, they lose standing for future legal remedies.

wiml 11y ago
That applies to trademark cases, but I don't see why it would apply to this. It sounds like legal folklore.

mikeash 11y ago

How does forcing someone to take down an Xcode project hosted on their own web site help to ensure that my iPhone doesn't suck?

natch 11y ago
It doesn't help to ensure anything. But having binaries out there that anyone is encouraged to sign and install, with no way to know what hidden features are there in what projects, is not a very well thought out model if Apple wants to make suckage less likely.
- mikeash 11y ago
  How is it any different than having binaries on the App Store that anyone is encouraged to install, with no way to know what hidden features are there in any of them?
  - natch 11y ago
    As you well know, upon upload for App Store submission, Apple runs processes that scan those binaries for use of private APIs. Admittedly imperfect processes, yes, but different from having no processes whatsoever.
    - mikeash 11y ago
      I get why Apple does it, but this prohibition increases my device's suck rather than decreasing it, since it locks out some potentially-useful apps.
      - natch 11y ago
        Yes they are balancing the cost/benefit equation of the untold levels of damage to consumers and to Apple itself potentially done by bad apps on one side, versus the relatively less impactful in their judgement benefits of potentially useful apps on the other side. The assessment that this increases the device's suck relies on an certain assumptions about just how bad the damages could possibly be, assumptions that you make, but that they are reluctant to make on behalf of their users.
        mikeash 11y ago