Because the DMA legally obligates them to share those APIs when they are necessary to implement a feature for a connected device. The goal of the regulation is to promote healthy competition for connected devices by outlawing self-preferencing by massive players. Reasonable people can disagree about the goals or the downstream effects of the DMA, but creating Private APIs for connected device features absolutely falls under the umbrella of self-preferencing.
In the same way, the EU could ask manufacturers of wireless headphones to open up and homologise their proprietary “APIs” with which they communicate with the other earpiece so you can mix&match single earpieces from different manufacturers.
The point of this regulation (DMA) is to enable more competition in important market segments. If this exact thing becames somehow very important, sure, it's possible, otherwise it's a bit contrived. What's the point?
Forcing standardization and interop is obviously good for interop, but it's bad for companies trying to innovate, because it ties their hands. The moment apple ships a v1 they have to ship an API, and then they have to support that API and can't change it. When it's private they can figure it out.
Apple already spends years in R&D before releasing anything. Many of their R&D devices never see market. Requiring them to share an API they've actually shipped to paying customers is not a significant additional hurdle. We know how to version APIs now. They can still make improvements to public APIs without hurting anyone.
Which is why DMA only applies to huge, dominant companies (the complete list: Alphabet, Amazon, Apple, ByteDance, Meta, and Microsoft) and there too it does not apply to all technologies, only for those where standardization is important to enable competition. It's much more important to have at least some competition than letting dominant companies monopolise entire markets through 'innovation' with private APIs.
Let's flip this. It's the user's device, providing the user's data to the user's headphones, via an app the user has chosen, that was written by a developer vetted by Apple, who's already reviewed and approved the code that will be running. And it's the law that they have to.
Because the user's device, providing the user's data to the user's Meta headphones, via a Meta app, can then record all the time and exfiltrate all that recorded data to Meta.
Or whatever other shady company wants to make headphones that sell for dirt-cheap in order to get their private spy devices into people's homes and offices.
I'm personally a bit on the fence about whether I think this is a sufficient concern to justify what Apple's doing, but AIUI this is the gist of their objection.
If it violates Apple's views on acceptable privacy practices, why are they approving the app? They already have guidelines against identifying information or collecting more data than absolutely required. The developer data use page is quite frank about the expectations:
Apps on the app store are held to a high standard for privacy, security, and content because nothing is more important than maintaining users' trust.
This is a rhetorical question, obviously. Apple is happy to stand on principle when it benefits them, and more than willing to soften or bend those principles when it'd be too difficult.
If a particular app only demonstrates this undesirable behavior when the phone is paired with a particular subset of headphones (or other hardware), then Apple may never notice it in App Review.
Because (since they control the platform/market) they're giving themselves an unfair advantage over competitors.
Example: iCloud photos backup can upload a photo to iCloud in the background immediately after it was taken. Competing cloud storage providers cannot do this[1], because Apple withholds the API for that. Of course they're saying this is for "privacy" or for "energy saving" or whatever, but the actual reason is of course to make the user experience with competing services deliberately worse, so that people choose iCloud over something else.
[1] There is some weird tricks with notifications and location triggers that apps like Nextcloud or Immich go through to make this work at least somewhat but those are hacks and it's also not reliable.
> Competing cloud storage providers cannot do this[1], because Apple withholds the API for that. Of course they're saying this is for "privacy" or for "energy saving" or whatever, but the actual reason is of course to make the user experience with competing services deliberately worse, so that people choose iCloud over something else.
Which makes Google Photos so much more impressive because it's heads above iCloud in this regard. No idea how they do that, pure magic.
Depends on your definition of a computer engineer. Dealing with strings in Python vs. dealing with character arrays in C is a world of a difference.
The decision to use Python feels like a solid compromise between giving the students a stair step to applied computer science work, while stripping away the cruft and language-specifics that would distract from implementing the more theoretical learning material
Depends on which part of the theory you care about. Lists in Python are a magic structure that can grow and shrink at will. That's a bit too high level to be useful for learning the theory.
Mermaid looks pretty for most applications and is quite easy to work with, but it starts to feel limited once you start playing with sequence diagrams. Had to bit the bullet and go with PlantUML instead for the time being, but rooting for Mermaid to gain a fuller feature set so I can fully move to it
People don't typucally drive at speeds they think are unsafe. When someone is speeding, they generally believe that they are capable of safely operating their vehicle on that stretch of road under the current conditions.
Avoiding the time wasted while pulled over does sound like a reason not to speed but even there it's a tradeoff. How much time do I save off my commute vs how long a stop would take weighted by the probability of being pulled over.
1) Sendwave only provides remittance into Africa (among other continents), but you can't bring funds out of Africa via Sendwave. 2) That's all Sendwave does, just that one service. 3) We offer user's accounts in their country of origin (KES for a Kenyan), plus an account in their country of residence (USD if now residing in the US). Then we allow for instant interaction between the two (so users can send money out of Africa), as well as other services, plus other services to come.
reply