iOS 11.3 update breaks iPhone 8 devices with third party-repaired screens
theguardian.com
theguardian.com
Edited for clarity
It's likely that negotiation failed in some cases.
That's absolutely crazy for most of us who think "this is a wire, why the hell would it fail?" but this kind of crazy complexity in a 5mm plug is possible nowadays.
As far as the lightning connectors go, that WAS done intentionally. The third party lightning connectors generally don't implement a very specific charging protocol designed to prevent metal migration between the pins and the pads on the connector. They only implement the handshake. But guess who has to honor the warranty if you've used a non-compliant charger cable?
Because a company understands their product in the field and cares about what effect a change might have. Now is that cost justified? arguably no.
When Microsoft breaks a third party app/device with a Windows Service Pack, Microsoft needs to fix this otherwise their customers get angry. When Apple breaks a third party app, they require the customer or third party app provider to fix it, because Apple is inherently a company that wants to control the whole stack and doesn’t embrace an open ecosystem.
Whether Microsoft had no choice and would have been worse if they could in this respect, the fact they they weren't and I think Apple is, and Microsoft was widely lambasted as money driven (e.g. M$) and evil at the time, and Apple largely gets a pass now, is interesting. That could be because Apple is better at managing image, or because people's perceptions and what they expect has shifted, or because there's a lot more bad (and worse) actors out there now that make Apple look better in comparison. It's hard to tell exactly why it's looked upon more favorably now, but I do believe my thoughts on Apple to be accurate, and I'm not sure how to feel about that.
Software companies can do things a bit differently from hardware companies.
I see a company like Tesla taking the same approach.
So that part is not something that’s specific to Apple.
This is 100% bullshit.
https://patents.google.com/patent/US20170272058A1/ https://patents.google.com/patent/US20170124010A1/
You also obviously don't understand what a 'patent troll' is.
> To mitigate these issues, external contacts may typically include a corrosion-resistant coating to the exposed exterior surface… Although temporarily effective, such coatings are subject to frictional wear and may become less effective over the life of a device.
Frictional wear is not a huge problem in practice.
There’re billions of devices with built-in batteries in the world. I’ve been carrying a cell phone, and later sometimes other electronics, since 1999. Never encounter such issues.
Most manufacturers use gold plating, and they advertise reliability for 10000 mating cycles:
https://gct.co/usb-connector https://www.gradconn.com/Products/MicroUSB https://www.molex.com/molex/products/datasheet.jsp?part=acti...
I am pretty sure this is easy, cheap and honest.
Bricking a device is certainly a bad user experience and not at all what the user wishes. Nagging him at least lets him use the phone and keeps him informed.
You cannot assume the user is stupid and not assume the user will not repair the phone outside your network. You cannot have both things at the same time and get away with it.
That is what I think. If the user is stupid, let him be so.
For goodness sake no! Blocking software updates is a terrible thing to do, because most people don't want to install them anyways. You're basically putting people in an already bad situation in a worse situation.
> Nagging him at least lets him use the phone and keeps him informed.
It only takes the user using the sketchy Touch ID sensor once for their fingerprint to be sent out to malicious actors.
> If the user is stupid, let him be so.
That's what you think, but that's not how Apple works. It's their job to make the default work well for those who may not be completely knowledgable about security.
However: where does Apple state that their products may stop working if repaired with different components? (Honest question, I have tried to find it).
> Service Exclusions and Diagnostic Fee. Apple may charge you a diagnostic fee (including shipping charges) as described in the Country Variation table, below (“Diagnostic Fee”), if Apple inspects your product and determines that (i) your product does not require service, (ii) your product has failed due to or has incompatibilities with software or data residing or recorded on your product (iii) service is required due to the failure of parts that are neither supplied by Apple nor Apple-branded, (iii) additional labor or parts are required that were not specified in the original estimated charges and you do not agree to authorize service based on Apple’s revised estimated charges, or (iv) service cannot be performed because the serial number has been altered, defaced or removed or the product has failed due to accident, abuse, liquid spill or submersion, neglect, misuse (including faulty installation, repair, or maintenance by anyone other than Apple or an Apple Authorized Service Provider), unauthorized modification, extreme environment (including extreme temperature or humidity), extreme physical or electrical stress or interference, fluctuation or surges of electrical power, lightning, static electricity, fire, acts of God or other external causes (“Service Exclusions”). Apple will return your product to you without servicing it and may charge you the Diagnostic Fee.
This is from Apple's Repair Terms and Conditions: https://www.apple.com/legal/sales-support/terms/repair/gener.... It doesn't say that the product will stop working, but it does say that Apple isn't responsible for fixing it if it goes wrong. I'm not sure if that could be extended to them not having to support your third party component in software, though.
You see it is really not very noticeable and the writing says nothing about hardware stopping working.
I guess we have both learnt from this exchange.
Thanks a lot.
That sounds like it could be not working, with root cause as bad repair.
I'm a little amazed by how many people in this thread don't understand how much work developing for, testing, and maintaining actual physical devices is.
Conversely, the update just needs to reliably detect if the screen is Apple brand, and abort the update if it's not. If this can be done, then the current driver could be considered generic and working everywhere, and the engineer would just need to maintain the generic and the current version.
That is, if Apple didn't mind to pay for making easier for third parties to get sales instead of Apple. Somehow I don't think that's the case.
If the update wasn't all-or-nothing, now you have to test interoperability between this generic driver and the rest of the system. That might be OK if it was just this one driver, but what if you suddenly have a generic driver for N subsystems? The combinatorics explode quite quickly.
Unless the Pixel 2's touchscreen is so weird that it needs a new driver, this will work for everyone.
As much as open source is a thing for software, it is not for hardware and especially silicon.
I have to agree with you on this. This is not a full hardware specification, it just tells how the hardware should behave up until the driver was released.
Modern open source hardware is still far in the future.
If it works, why change it?
What evidence is there make this claim?
It all seems to boil down to this question. Do you trust that Apple had the user's interests in mind?
> They simply don't QA their releases on repaired phones (because why would they?)
The more important question is why wouldn't they if the customer's experience is what guides their decisions.
From the article:
"A similar thing happened for the iPhone 7 last year. An iOS update prevented the touchscreens from working on iPhone 7s with third-party repaired screens. Apple then released a follow-up software update that made them work again, resolving the issue."
To me, that makes axoltl's explanation far likelier. From Apple's perspective, I get it: they do Q&A on what's officially supported. Trying to pull in all of the unofficial changes is more expensive and potentially restrictive.
Imagine getting upset that an Occulus firmware update didn't work with a knock off HMD that lacked features of the original...
They should have a test to make sure they don't get left in a dust with an update.
This is also another good reminder to postpone the iOS updates as long as possible; I think it's been since v10 when the updates have had a less than stellar record.
How is it their responsibility to support third party hardware? And, where's the line for support?
If I make a very poor knock off screen with a design issue that is made apparent with an iOS update (say, incorrect implementation of a required spec, interface, timing, etc), why should Apple have to support a flawed design?
What if Apple included a feature in the hardware that but the software wasn't ready at release, but would be made available as a standard feature in an upcoming iOS update? Should Apple have to continuously fragment their codebase, resulting in some tree of hacks to support each new half-baked chipset?
To someone in the hardware and software world, this perspective is absurd.
If you could give one example of a company with a custom and proprietary system and chipset supporting third party knock offs I would be very interested. I've never witnessed this during my time in the hardware industry.
They're already doing that for some other things.
For instance, some (mostly cheap) Wifi access points are known to have buggy implementations of 802.11 that require firmware workarounds in phones and laptops. Manufacturers have to support these devices for the benefit of the consumer and to maintain their own reputation. Customers aren't expected to understand that it's some other piece of tech that's at fault.
Granted, it's a bit different since this is a separate device. But this is still one example of Apple (and every other phone manufacturer) supporting other's people buggy code for the benefit of the users.
What your describing is "interoperability testing", and it's ubiquitous in the communication standards world.
Standards sometimes aren't clear, sometimes there are multiple implementations of a feature before a standard is ratified (and a big user base with the now non-standard implementation), and sometimes bugs end up in silicon and firmware.
One company I worked with had a very large lab with hundreds of ethernet cards. A column of robots would cycle through each one and plug a network cable in, make sure the link was up and solid, then move on to the next.
I think this is fundamentally different than Apple supporting third party hardware.
Communication standards are designed to allow chipset a to talk to chipset b. Both have an obligation to get a link up. A failure to get a link up is a failure for both, from the customer perspective.
A closed, proprietary, custom hardware system has no such obligation. Unlike the communication channel, the risk is completely unbalanced. A failure for the knock off hardware design is just directed to Apple (as you see in the comment section here).
Sure, you can't really blame the customer since the knock off parts aren't easily detected or may have been installed by the previous owner. You also can't blame Apple since you've made a custom iPhone with mystery parts, and I think it's unfair to make them stop updating firmware/software so they don't break these mystery parts.
Any sources for this ? I'd like to learn more.
https://patents.google.com/patent/US20170272058A1/ https://patents.google.com/patent/US20170124010A1/
But a quick search yields some interesting research:
http://www.te.com/documentation/whitepapers/pdf/p313-89.pdf
I bet there's much more to find, I'm not a metallurgist.
There is little upside in screwing over millions of existing customers.
Surely, if electromigration is an issue, wouldn't these issues be just as significant? Isn't gold practically immune to electromigration at these energy levels?
Validation generally do not apply when turned off
Yet this rubber is ridiculously brittle and frays almost without fail within 6-12 months meaning you just end up having to by more cables thus using more of the worlds resources anyway than if they had shipped you one cable that didn't fail.
My 17 year old Ti Powerbook cable used daily for 11 years, no fray.
My original iPod cable, no fray.
My iPhone 3G cable, no fray.
My iPhone 4S cable, 5 years use daily, no fray.
Change happened somewhere here, newer cables are more matte and softer feeling
My iPhone 7 cable, frayed within 6 months
My 2014 MBP cable, frayed within 12 months
Replacement cable, frayed within 12 monthsIf they don’t test, components will break. If they don’t change APIs, components won’t be able to improve sufficiently.
In this case, there are only two actual solutions from Apple’s perspective, and they’re both ‘bad’ for customers:
Restrict users of 3rd-party screens from upgrading their devices, even when breakage may not occur, or, let them update and take the risk.
Technical debt, likely caused by time-pressure before releases, is expensive when it can’t be left behind.
Apple also doesn’t have to support much 3rd party hardware because their phones are the only built to run iOS.
I would imagine that Google’s processes are better equipped to support more hardware and for longer durations.
"Actively promote the Apple brand as part of their business along with AppleCare service and support products."
"Service Providers are required to use Apple Certified Macintosh Technicians when conducting diagnostics, Covered Repairs, modifications, alterations and upgrades on Apple products."
" Individuals or sole traders may not apply."
Imagine these kind of restrictions being placed on car repairshops before they were allowed to buy and use replacement parts from manufacterers, there would be a massive lawsuit.
https://www.youtube.com/watch?v=FaR593TrXf8&t=493s
Plus, for TouchID enabled phones you MUST have a special rig in order to re-pair the sensor, and for FaceID you have to have a special rig to re-calibrate the sensor stack every time you open the device!
https://www.theverge.com/platform/amp/2018/3/8/17097256/cali...
In this case, it's just a light version of the article with the same content. That seems objectively better. If AMP wasn't incidentally in the URL path you wouldn't have noticed it was AMP. If the existence of AMP encourages people to write faster, less cruft-y pages, that's a good thing to me.
Yes, the overall user experience is better. It's not that the experience is bad, it's more about the means they're using to reach those ends.
I see AMP as a set of training wheels that Google was able to get publishers to adopt. All the tools were available for publishers and their developers to make performant/clean sites to begin with, they just chose not to do so. AMP is basically a standardized form of "the way they should have built their site in the first place".
My other issue with AMP is that it makes companies focus on performance for mobile, but not for desktop. Why not build a quality, high-performance site for all platforms?
At the end of the day, is AMP a net positive? Maybe, I'm willing to consider the end result, but I don't think it's a problem for us to explore and criticize the means or the reality that necessitated AMP's existence.
AMP isn't a requirement to build small, fast, performant websites. The fact that The Verge ignores those qualities with their non-AMP website is on them.
If there is a bit of code in the OS update along the lines of
if(DisplayID != GenuineApple) { breakPhone(); }
then it's obviously Apple's fault. But it's not at all clear yet exactly what's causing this problem and whether or not it was intentional on Apple's part.https://appleinsider.com/articles/11/05/26/apple_exploring_i...
OS performs a handshake with the target subcomponent and authenticates that the component really is manufactured by the manufacturer that is targeted by the pending firmware update. If the authentication completes successfully, then push the firmware.
A flip-side alternative is for the component to only boot firmware that it recognizes as signed by the correct authority.
In the first case the device has an embedded identity within the hardware. In the second case the device merely needs to validate a signature. Crypto acceleration is becoming very widespread and very cheap so I don't see either of these as difficult to manufacture.
What you're proposing will take roughly 2 years, and be an organizational nightmare. 'Just' having an embedded identity is already complicated:
1. Where do you store the identity? Fuses in the ASIC? Now you need a fuse bank. Not every process node supports fuses, so you may now have to port you entire design to a new process node.
2. Using this new-fangled identity means you can now perform a handshake with the host. Let's 'just' put down an ECDSA accelerator. What do you mean, this increases the die size by 33%? What do you mean it needs to be resistant to differential power analysis? Oh, right, because stealing a single identity means you can make as many clones as you'd like, and we can't revoke identities if we think they're stolen because of laws in China!
Etc. etc. the second option doesn't even work because the cloned device will simply ignore the signature on the firmware.
I used to think this was all trivial too, but having been through this _exact_ wringer 4 or 5 times before I can tell you it is Hard(tm).
- I didn't place the light sensor correctly
- I touched it/ruined it
- the part is defective
- Erase All Content & Settings options is absolutely necessary
Step 1: Buy new car
Step 2: Replace engine with something other than OEM.
Step 3: Complain when car's ECU does not run engine.
1. But new car
2. Replace broken windshield with something other than OEM
3. Complain when car refuses to start because its computer detected a non OEM windshield.
It was not fine. Rain sensing didn't work again for the rest of the time I owned the car.
Step 1: Buy a new car
Step 2: Replace engine with something other than OEM
Step 2.33: Car runs fine
Step 2.66: Manufacturer comes to your house and 'fixes' your ECU while you're asleep
Step 3: Complain when car's ECU does not run engine
I’m asking hypothetically of course...
There are anti-trust laws against 'tying agreements', and forcing consumers to only buy components from Apple (due to tie-in) would be violating those laws.
That said, those laws don't say anything about having to interoperate with an inferior part.
So assuming Apple isn't willfully violating anti-trust laws, we can be fairly sure the change was intended to improve some aspect of the touch controller.
Note: There are exceptions if the tying serves a purpose other than maintaining a monopoly (such as the security pairing between the TouchID sensor and FaceID camera).
It would be perfectly reasonable to not force updates and allow users to continue with the current version forever if that keeps them running. But it's not reasonable to just break people's functional devices with an unavoidable update.
It's not a perfect analogy, but the rules on radio interference with devices spring to mind: you need to cope with some interference and you need to not emit it. This results in a more stable ecosystem, even though you could sensibly argue that if one side is stuck to absolutely, the need for the other wouldn't exist.
Sounds like the early 1990's.
But even if it wasn't, it's not entirely outrageous to predicate continued software support on some terms. The only problem then would be not making those terms clear up-front.