Apple has no such enforcement capabilities for USB as they don't have any rights to that trademark.
That is misbehavior from Apple, because it adds a cost to the consumer. MiFi is absolutely not free.
The consumer friendly option is allowing the use of a perfectly good USB-C cable (from J5 Create, for example) that doesn't have the MiFi tax without artificial restrictions.
The only thing being codified here is that if you happen to use a janky cable Apple didn't certify, the results are on you.
All that, to my mind, is totally reasonable. You can use a certified cable. You can use a non certified cable. The consumer is totally free to make any choice s/he chooses. They only warrant that if you use the certified cable, your phone won't blow up.
> Shrimp states that Apple will limit data and charging speed for cables connected to iPhone without the MFi certification.
To me (and I'd wager it's the same for most folks), that's Apple implementing a technical block on the cables separate from their actual capabilities.
With respect to the cables, that's part of the USB C spec. Not the spec to which you are referring.
The whole point of the E Mark is to signal that it is safe to send otherwise dangerously high speeds and wattage down the cable. So they're just saying that they promise to follow the spec for cables they certify.
Now the accessories, you're right, but I don't know the rules for accessories. I do know them for the cables.
Remember, a USB-C cable not just a bunch of wires hooking two connectors together. It's two SOCs which negotiate the cable's capabilities with the devices on either end before allowing the flow of power or data across the cable itself. In fact, there is no spec on what the cable itself consists of - it could be a fiber optic cable for all the USB-C spec cares.
It's why you can use an expensive DP USB-C cable and not get thunderbolt support - because the chipsets in the cable itself have to support the thunderbolt spec.
It's why it's entirely plausible that Apple can specify that you can only use MiFi compatible cables if you want full charging or data transfer capabilities.
"Janky" is inserted by you. I can use high quality cables that aren't certified and perfectly capable of handling power, and such. With this comes the implication that any manufacturer who is not willing to give Apple a cut of their cable sales is something inferior and subpar.
> They only warrant that if you use the certified cable, your phone won't blow up.
I guarantee you that they warrant no such thing. And that they'll point you at the cable manufacturer if something damages your phone.
Paying for MFI might be a problem for your local Brooklyn usb-c cable artisan but not for your high volume low margin Asian cable manufacturer.
It was $10 (or 10% of the cost) prior to that.
Quoting the article:
> According to leaker ShrimpApplePro on Twitter, Apple will be requiring MFi certification for products connecting to the iPhone 15.
If there's such a huge pool of potential trouble brewing with a 20W phone, why do they even allow such maleficent third party malfeasance?
/s
... which is roughly what's being proposed here for iPhone. Since some Samsung devices charge at 45W and require 3A (hence e-marked) cables, one can infer Apple wants to do something similar for iPhone in the future.
Edit: I should add that it is possible for a fully complaint combination of devices to not charge at max(sink power, source power), because not all possible combinations of voltage and current may be supported. For example a 60W charger may support 20V@3A, but if the 60W sink only supports 12V charging, it needs 5A and this combination won't support 60W charging. In practice this should be rare though, it would be terrible product design.
Re: your edit. There is this exact kind of profile incompatibility between the Leviton T5636 and the HomePod mini when two devices are plugged in. The outlet should support 30W for each receptacle, which is more than enough to provide the 18W/20W the HomePod mini requires. But for some PD profile incompatibility reason (9V/3A probably), it does not get enough power.
And it is in fact terrible product design. Leviton is pointing the finger at Apple but in reality, who knows.
IMO it's harder for the source to be flexible with voltage, and especially current limit, so I'd put somewhat more blame on the sink here for not being flexible enough. Generally a sink should expect to be plugged into an 'unknown' source, so should at least make an effort to support multiple voltages.
Designing a multiport power source with a shared power limit is a bit of a tricky problem.
I can assure you that counterfeit Thunderbolt cables don't work at Thunderbolt speeds.
Also, power delivery is defined by USB standards, not Thunderbolt.
> I'm going to contend this isn't so much subverting EU rules but rather trying to ensure that Apple won't get blamed when someone uses a cable that can't handle the power when plugged in given that there's not a good standard out there for this and no enforcement of the "ok, there's something - try this..."
Two questions:
1. (Given Apple fanboy view of world, then) why can I charge an Apple laptop with a random USB-C cable?
2. Why would that logic not apply to iPhones too?
> (Given Apple fanboy view of world, then) why can I charge an Apple laptop with a random USB-C cable?
Not that I appreciate the tone here, but yes, you could charge an Apple laptop with what you would call "random" USB-C cable, as long as it delivers the necessary wattage. That is not the issue at hand, though.
> Why would that logic not apply to iPhones too?
It could.
But there are orders of magnitude more phones than laptops, and laptop users tend to use, well, their laptop chargers for the most part. Still, I have seen one or two laptop motherboards essentially melted, because they were overdrawing power.
By the way, I never argued that Apple should create a new standard, or a new certification program. What I originally said was that I wish that Apple would prevent cables that are not PD compliant from working with their devices, because USB-IF sucks at enforcing this.