Hacker News Reader

Comment by shuckles | Hacker News Reader

The best part is: the EU demands Apple do all the necessary R&D, including an indefinite liability of API maintenance, at no cost to developers.

View on HN

Garmin pays apple already for a developer license to have an app to pair garmin watches.... and yet 90% of the features of the apple watch simply cannot be implemented for a garmin watch, no matter how much they pay, because those APIs are private to apple watch.

Yes, apple did the R&D to figure out how to let their watch filter notifications by app, and it must have cost them so much to be able to filter notifications that it has to be locked into their watch. That's not them being intentionally anti-competitive, it's just R&D costs, sure, I'm sure it cost a ton to make that private API.

Yes, the $99/yr Garmin pays covers the 40 minutes of labor it would take annually for an Apple engineer to support this I'm sure.

You said "no cost to developers", that part's not true. you're of course right that it's not really enough money to be relevant though.

The more cogent argument is that if apple doesn't want to spend money making their phone work with smartwatches, they do not have to make it work with smartwatches.

They want it to work with watches so users buy the phone.

If they want it to work with _only_ their watch, then sure, they make more money, but they also harm the user and market in the long-term by making it so competitors aren't on an even playing field.

Do you just kinda believe anti-competitiveness doesn't exist?

Should apple be allowed to make it so you can't communicate with android users at all to increase sales (which they already more-or-less did)? Should they intentionally make it so you can't play the music you purchased on non-apple devices by breaking "iTunes for windows"?

I mean, even if you assumed that it would actually take 40 minutes (it likely doesn’t), I suspect Apple engineers working on this cost the company more than $249k a year

Wow sounds like the $99/yr the commenter was saying developers "pay" Apple is a trivial amount and cannot be used to justify the development of an entire SDK that maybe a dozen companies will use.

But Apple already justified building a secure, private, on-device SDK that exactly one (1) company will be guaranteed to use.

I see no reason it cannot be a private entitlement similar to the other sensitive entitlements on iOS.

Internal API is not an SDK. It regularly astounds me how many commenters on a so-called hacker forum seem to think it is. Is everyone else publishing their tightly coupled business logic code as API these days? Is that what GraphQL is?

Apple can revoke the entitlement if it's abused, as they've done many times in the past with signed apps. Nobody (including the EU) is demanding that it be an zero-auth free-for-all API, only that competitors can use it. It's not an absurd demand and there is absolutely precedent for Apple individually trusting competitors in this regard.

If you're astounded by hackers asking practical questions, maybe you should stop carrying water for corps and see how your back feels. Let's talk shop, what are the roadblocks Apple faces here?

I would hope that security critical parts of the OS that can't be exposed as an API aren't being used to communicate with the apple watch. Why would the apple watch need access to these APIs that can't be publicly exposed? Is there any reason beyond apple wanting to make sure other smartwatches are second class citizens in their ecosystem?

This isn't exposing business logic, this is an operating system vendor deciding what it exposes to vendors. There is clearly an API that the apple watch is using to communicate with the OS, why shouldn't other vendors be allowed to access this?

The API already exists, they just don't let other people use it because they're greedy. There's no additional maintenance burden.

Technically cost is not zero.

1. Api designed for internal use could take shortcuts and let’s say use secrets that are and should be internal, or run things as root or something.

2. Proper API maintenance includes at least documentation and some kind of update path/schedule. Internally it’s simpler. (E.g. you must be sure not to leak secret stuff in docs)

But in the end I agree with the notion that these changes for Apple are not a huge burden. (Existing behaviour is anticompetitive)

I agree, but IMO they should already have this done if the API is properly designed. It might not be, but if so they should change it anyway.

No, the EU demands that features implemented in the OS to be used by Apple accessories must be made equally available to competing accessory vendors.

This prevents Apple the platform provider and gatekeeper from giving preferential treatment to Apple the Smartwatch/Headphones/Payment/Entertainment provider

Which is what companies like Intel had done for ATX, USB, Thunderbolt, ... They were never required to, but they've done it, and they made money on it.

What Apple do slightly differently is that they half-ass the standardization, and then chuck it in the trash. Amounts of efforts spent is within the ballpark.

Given that Apple already maintains a comprehensive entitlement system[0] they charge EU developers[1] to use, I don't see how that's an issue. Apple's work amounts to swapping out a .plist file, they could be compliant in 10 minutes with an OTA update. If they wanted.

[0] https://developer.apple.com/documentation/bundleresources/en...

[1] https://developer.apple.com/support/compare-memberships/

Ah, so Apple is not selling iPhones but it just gives them out for free?

Reply on news.ycombinator.com