Hacker News Reader

Comment by stagalooo | Hacker News Reader

There is a world of difference between shipping a feature, and shipping an api that anyone can use to ship a feature. It is such a normal progression to make an api and dogfood it internally, iterate until you have something you feel comfortable supporting indefinitely, and then expose that api publicly. It is not reasonable, IMO, to require that every feature you ship has an API that is ready for public consumption.

Granted, Apple generally doesn't do that last part unless forced. I think some kind of timeline on the DMA requirements would be more reasonable. e.g. you have two years to make a feature publicly accessible before fines start accruing.

View on HN

> It is such a normal progression to make an api and dogfood it internally, iterate until you have something you feel comfortable supporting indefinitely, and then expose that api publicly

For a hobbyist? Sure! For a company with half the smartphone market and a trillion dollar market cap? EU doesn't mandate that they define a new standard and support it indefinitely.

You can see the headlines though “Apple skirts interoperability law by deprecating API after only one year”. Maintaining a public API is a cost usually only taken in because it has a benefit to the company.

They are free to do that but they need to deprecate the feature for their own devices as well.

Apple is not required to develop or maintain any feature against their will. The DMA is not written like that, it is much more objective and industry-agnostic.

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

Does DMA allows Apple to do certification? Like Certifies devices for Apple Translation compatible ? Or is that straightly forbidden?

I think it will depend on if it seems like it's anti-competitive gatekeeping or has a legitimate use. The DMA specifically prohibits measure that are meant to gatekeep, but iirc it has allowances for things that have real technical justification.

Certifying devices to make sure they're safe for users, like "this cable is certified as compatible, it won't set your iphone on fire", seems fine.

Requiring your app to be "certified by apple to sell ebooks", and then only granting that certificate to Apple Books, not the Kindle app, that seems anti-competitive.

correct. An example of this is building a WhatsApp client, you need certification from Meta and that seems to legitimate.

Then why not deprecate the API every month? Also do a firmware update every month across their ecosystem.

Why? Because Apple is in the money making business and no one will buy a device where their (expensive) accessories cease working randomly.

Especially when the user finds out the reason.

But you just described the existing Apple ecosystem!

Or, just not block access.

If it’s deprecated then it’s still there, it might just go away someday. Releasing an API and then deprecating it immediately seems sneaky.

A public proprietary API.

If the industry wants better open standards, they the participants should develop those standards and build devices that implement those standards.

What Apple does outside of such standards is nobody else's business - as long as they correctly implement and support the industry standards.

> Granted, Apple generally doesn't do that last part unless forced

which is the point here.

If they made a new feature, something AR based, they are totally allowed to build that and keep it relatively private for a few years. What they can't do is when competition appears, actively keep them off their platform. For example if a device manufacturer manages to make an AR device that works well with android, but its impossible with apple and apple have significant market share, then that would be illegal.

The point of this is to stop thiefdoms and to keep innovation. You're allowed to have a competitive advantage, you're not allowed to build a monopoly.

(if we look at defence, budgets are still very high, but the rate of innovation has plummeted compared to other industries. Its only now with the spur of VC cash into non-traditional backgrounds are we seeing innovation again)

> It is not reasonable, IMO, to require that every feature you ship has an API that is ready for public consumption.

It is, if we're talking about features designed to boost sales of your other products while preventing competitors from offering those features.

Look, even if they're able to compete fairly, those competitors might remain inferior options for other reasons. But Apple having to compete will make their products better. All of their best achievements came from fierce competition as the underdog. Apple's current situation is not good for it.

What if it relies on non-standard changes to Bluetooth and WiFi?

Must they get these passed in the standards committees first?

With Bluetooth they do ruse non standard changes, heavily influenced the development of LE Audio and there is no statement about when if ever they will support LE Audio, possibly never. Apple simply doesn't care

The DMA does not define such details, it is much more simple and agnostic. It identifies if a company creates a market within its own ecosystem, invites others to participate but doesn't offer a fair competitive field.

--> If iOS introduces non-standard changes to Bluetooth and Wi-Fi to compete against Android, this does not concern the DMA.

--> If iOS introduces non-standard changes to Bluetooth and Wi-Fi to create a product of ANOTHER market-segment (Headphones, Watches, Routers,...) they are required to provide interoperability for other brands than Apple as well.

The reason is simple: iOS has such a critical size that it is anti-competitive behavior for Apple to modify iOS in order to beat the competition on e.g. headphones.

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.

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

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

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/

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.

Reply on news.ycombinator.com