Hacker News Reader

Comment by talldayo | Hacker News Reader

Apple makes famously insane margins off each iPhone sold. I don't think they can legitimately fall back on the "but we can't support it otherwise", since they already do. The cost of developing new iOS builds is amortized by the hardware they sell and the profit they rake in. Even when service revenue was a shadow of what it is today and Apple was far less liquid, they had no problem supporting their hardware.

In professional industries like avionics, automation and fabrication, open tooling and security maintenance is the baseline expectation. It's only in captive consumer markets that businesses can convince their customers that they don't want the freedom to use what they paid for.

View on HN

>I don't think they can legitimately fall back on the "but we can't support it otherwise", since they already do. The cost of developing new iOS builds is amortized by the hardware they sell and the profit they rake in.

Those costs are amortized over the hardware sales specifically based on the current revenue model of the iOS platform. If you force a change in the model, or force them to produce new APIs and SDKs they had no intention of making and therefor no need to amortize, then I think yes they can fall back on "we can't support it otherwise".

The real simple question that has been never been answered in this entire discussion over and over again is what is the fair market value of Apple's SDKs, access to their platform and the support that provide for that platform if its not amortized over hardware sales and current revenue split agreements? Forget even trying to answer that for the entire iOS platform. If Apple puts NFC chips in their phones, and then:

1) Has to write an entire public SDK they weren't intending to write

2) That allows access to those chips outside their specific sanctioned and envisions use case

3) That requires providing ongoing support for that SDK and the uses of it outside their specific sanctioned use case

4) Expands their security threat surface for the underlying secure hardware that SDK will interact with and requires more development to secure it

How much money is that worth in cold hard cash up front per developer per update per hardware revision?

Apple is selling a platform to end users and they hold durable market power with that platform, due to high switching costs and minimal alternatives. End users consume services by various third parties on the platform. In addition Apple is also offering services on the platform that compete with those third parties.

It's entirely fair to say to Apple (and companies in similar oligopoly positions) that if you want to compete with third parties on your platform then you need to do so on a level playing field.

It's not then about forcing Apple to build a feature at no cost, but rather declaring that Apple built their NFC feature improperly, by building it in a way that prevented competitor use, illegally privileging their own competing services. They can either remove the feature or build it properly, according to relevant law.

I think the problem from Apple's perspective is the assumption they're building this platform to compete with 3rd parties. NFC payments is a perfect example of this, where I think from their perspective it wasn't "built improperly" because it was never built with the intention of 3rd parties accessing it directly, any more than Amazon storage provisioning tools are built incorrectly because AWS users can't build their own S3 competitor on top of those tools.

Edit:

I've talked about this in a previous discussion, but we have a sort of arbitrary line we draw on what should or shouldn't be a service / integral part of an OS / Platform and what should be, for lack of a better term, hot swappable by the end users.

On the one hand, you have the sort of "GNU Maximalist / Microkernel" approach, where everything is replaceable. On the other you have the "iOS / Video Game Console" approach, where the system is largely a black box and you get an API and can do things with that API but you can't swap out anything not controllable by the API. There's no objective place to draw that line though, it's all dependent on the experience your platform is designed to provide. Why is "displaying text to the screen" a service we delegate to the OS? Why does Linux consider window management an "application" to be swapped out, but Windows and macOS consider it an integral part of the OS platform? Why do we expect an OS to provide a TCP/IP stack these days, and no one complains that they can't implement their own TCP/IP stack in their mobile app? Clocks are widgets in linux, and an integral part of the OS in windows and macOS. Heck even down to the programming language level we don't have consistency. Is C necessarily better or worse than say Python or Javascript because it doesn't have a native String type and you can pick your String library?

Reply on news.ycombinator.com