Archive for November 20, 2019

Wednesday, November 20, 2019 [Tweets] [Favorites]

Guilherme Rambo Locked Out of Apple Developer Account

Guilherme Rambo (tweet, Hacker News):

After about two weeks of waiting, I decided to call developer support, which sounds easy, but I couldn’t find any phone number to reach them anywhere on the public part of the developer site. The only way to get on the phone with developer support is to visit a page within the developer portal where you can enter your phone number for them to call you later. The problem is that I couldn’t even visit that page because it also redirected me to the aforementioned contact form.

[…]

Like I mentioned before, the problem began in August. So far I’ve tried every possible private communication channel before deciding to make this story public. It’s worth mentioning that I didn’t get any e-mail or call from Apple warning about any sort of action being taken against my developer account. Apple always says that “running to the press doesn’t help”. Unfortunately, they haven’t responded in any way, even when I tried reaching out through internal contacts that I have. So the only option I have left now is to “run to the press”.

I’ve read about developers having their accounts shut down for all sorts of alleged reasons. The most recent case happened to my friend Ying, who got his account terminated for “fraud”, which he didn’t commit. After he shared his story publicly, Apple reinstated his account.

With notarization required for Catalina, even distributing apps outside the App Store requires a developer account. Not stated: he’s probably violated the Apple Developer Agreement. Personally, I don’t think publishing publicly available (though hidden) information should be grounds for banning. And, regardless, he should be able to get a straightforward and prompt answer about his account status.

John Gruber:

Rambo is extraordinarily talented at what I would describe as digital spelunking — he explores the internals of beta OS releases and pokes at beta APIs and he finds things that weren’t supposed to have been exposed. And when he does, he publishes his findings. It would be quite a coincidence if that’s not the conflict at the center of his account having been disabled — that someone at Apple got pissed off and impetuously ordered Rambo’s account disabled, and now they don’t want to explain it.

Jason Snell:

Would be a real shame if Apple suspended his account because they don’t like that he’s smart enough to uncover things they’ve accidentally shipped publicly. That would be petty retaliation.

Rob Lorenz:

It would be terrible, but I think it’s almost better than the alternative. They’ve locked him out for months and won’t tell him how to restore his account. If that isn’t retaliation, what is it? They’re just totally incompetent at account management and developer relations?

Previously:

Update (2019-11-25): Jason Snell:

There are many angles to this story. Rambo’s sources are not limited to software—over the past year he’s written stories that suggest human sources, he’s outguessed Apple at how it named URLs for forthcoming public events, and yes, he’s found hints of future products in beta releases of Apple’s operating systems.

That last one is, without a doubt, against the letter of the law of section 9 of Apple’s developer license agreement[…]

[…]

It is literally impossible for disclosures like this to remain secret on today’s Internet. The right move is what Apple’s been doing the past few years, namely attempting to keep the real secrets locked up in Cupertino and assume that anything given to developers will leak.

Guilherme Rambo:

My Apple developer account issues have been resolved.

No word on whether Apple provided an explanation or imposed any conditions for reinstating his account.

Are Apple Repairs Profitable?

Matthew Gault (via Jason Koebler, MacRumors):

Tuesday, Kyle Andeer, Apple’s Vice President of Corporate Law, answered those questions. In its testimony, Apple repeatedly denied accusations it was making it hard for people to repair their own phones and protecting a virtual repair monopoly. But its answers often didn’t align with reality.

[…]

Safety obviously isn’t Apple’s primary concern. If it were, it’d provide easy access to training and manuals it claims would prevent injury.

[…]

Apple also seemed incapable of answering basic questions about the repair market it insists it must tightly control. When the Congressional committee asked Apple how many technicians it had, it claimed there were tens of thousands. When the Committee asked how much revenue Apple generated from repairs, Apple claimed that “For each year since 2009, the costs of providing repair services has exceeded the revenue generated by repairs.”

The idea that Apple is losing money on repair is wild, and a curse of its own making. The answer by Apple seems vague on purpose. Throughout the years, Apple has had to offer many “service programs” for defective products. Most notably, Apple has had to replace a large number of MacBook and MacBook Pro devices for free because it designed an unrepairable keyboard that breaks easily and with normal use. Rather than replacing a few keys on those devices, Apple has to replace half of the computer. If Apple is including warranty repairs and service program repairs in addition to standard retail repairs, well, then, it is quite simply misleading the public and Congress.

I wonder if AppleCare plans are counted in the revenue. I actually do think it’s possible that repairs are not profitable. But there’s also room for a lot of creative accounting, e.g. for the portions of retail stores dedicated to repair.

Previously:

Update (2019-11-25): Chris Carr:

Apple repairs are not profitable. At least I’m pretty darned sure they weren’t when I was there. AppleCare (the organization) would be happy to just break even.

Update (2019-11-26): Kevin Purdy:

Apple answers the question we’ve been chasing for the last fifteen years, “Why prevent access to repair content?” with: Our content makes repairs safer and easier. Which is not only not an answer, it also seems to be a very solid reason to distribute parts and manuals. In Apple’s mind, there’s a straight line between untrained techs and unsafe repair, which is a dubious claim to be sure–but if they believe it, shouldn’t they be trying to prevent that danger, not exacerbate it?

The charitable view is that this close-to-the-vest practice can be chalked up to Apple’s obsession with vertical integration of the customer experience. But that hasn’t really panned out.

[…]

Apple’s answer is, essentially, no. In full: “Apple does not take any actions to block consumers from seeking out or using repair shops that offer a broader range of repairs than those offered by Apple’s authorized technicians. Customers are free to obtain repairs from any repair shop of their choice.”

Apple’s answer is false.

Where to Get Apple Products Repaired

Speaking of outsourcing and contracting what should be a core competency, scott writes:

It’s important to know that once you drop your devices off at the Apple store, they’ll ship them off to a subcontractor for repairs. These facilities are run like sweatshops.

themobfoundmeguilty:

I work at an Apple repair depot, a company called CSAT Solutions.

[…]

Recently, they have begun to hire more people because their retention rate is horrible. The problem is that most of the people they hire are incredibly incompetent. You could have never worked on a computer before and as long as you can read and write English you’re in. The result is you have a bunch of people that don’t know even the basics of troubleshooting computers repairing $2000+ machines. These people also can’t handle the workload so it puts incredible pressure on veteran techs that not only have to worry about their work but other’s work as well. To add insult to injury, these new technicians are being given a $750 bonus for staying with the company for 3 months. All the while technicians that have been at the company for a decade haven’t seen another penny.

[…]

In the end you’ll get a refurbished motherboard that will most likely fail again because the company that repairs them does a shitty job. Sometimes the “new” board we’re gonna use looks worse than the one you sent your unit in with. I have received boards with corrosion and we are told to use them and cannot change it unless it fails for something.

Every aspect of this company is a joke. Their shopfloor system is always crashing. And they still expect us to finish the work. We get the units in the morning and they’re supposed to ship out at night.

1-800-275-2273:

I work for AppleCare. If OP, or any of the technicians in the repair depot flag a device for “unauthorized modifications” (like a screen or battery that isn’t Apple’s), we deny warranty service to the customer. Guess how many times the “unauthorized modifications” are wrong?

Literally every day. And then I have a customer screaming to me how they’ve never had the phone or MacBook serviced by anyone other than Apple. And there’s nothing we can do about it. We send the device back, and lose the customer.

MarblesAreDelicious:

I’ve worked at two AASPs now as an ACMT/ACiT and I’m beginning to think AASPs are perhaps a better solution for people to get their Apple stuff fixed. Our locations have to meet Apple’s standards and we have been always overly cautious to ensure we do as to not lose our certification and the customer base it provides. Because it is our company’s money and reputation on the line for every repair, we make for damn certain we follow the procedures and read the service guides until we are completely familiar with them.

The only two issues with some AASPs is that they can and will charge beyond Apple’s guidelines for pricing. My company does not for certain services, but does for others. The other being turnaround time; we don’t stock parts and cannot replace devices on the fly. Turnaround time can be days because of this. But I feel the offset is that we will make sure it’s done correctly every step of the way.

I have typically done mail-in repairs because they are faster than waiting a week or so for the local shop to have availability and then receive parts. I also don’t want to be charged extra when I’m already paying for AppleCare. I’ve generally been happy with the results, though several times the Macs have come back with damage that wasn’t initially there.

Michael Brice-Saddler (via Alex Stamos):

Upon arriving, she handed her phone to an employee who began “messing around with it for quite a while,” she wrote the next day.

“I didn’t really pay any mind to it because I just figured he’s doing his job, looking into my insurance info or whatever,” she wrote to Facebook. “He asked for my passcode TWICE in that time frame which I, at the time, didn’t think anything of.”

It turns out Fuentes’s initial concerns were legitimate. When she got home, Fuentes turned on her phone and noticed a text that had been sent to an unknown number, she wrote. The message’s contents were even more harrowing: Fuentes alleged that the Apple employee had gone through her photos, retrieved a private picture and texted it to himself.

ChrisLTD:

Apple store employees have always confirmed that I’ve deleted all my data before I drop off a device that is being sent to a repair center.

scott:

For me it was always just give them the password and turn off Find My Phone. But then again I always wiped my devices ahead of time. It’s also been years since I’ve taken a Mac in. I’m dreading going to get my keyboard replaced, I’ve put that off for four years.

I think I’ve always been instructed to give them the password, which I never do. But backing up, wiping, and restoring a Mac (or even an iPhone) is very time consuming.

See also: The Talk Show.

Previously:

How Swift Achieved Dynamic Linking Where Rust Couldn’t

Alexis Beingessner (tweet, Hacker News):

For those who don’t follow Swift’s development, ABI stability has been one of its most ambitious projects and possibly it’s defining feature, and it finally shipped in Swift 5. The result is something I find endlessly fascinating, because I think Swift has pushed the notion of ABI stability farther than any language without much compromise.

So I decided to write up a bunch of the interesting high-level details of Swift’s ABI. This is not a complete reference for Swift’s ABI, but rather an abstract look at its implementation strategy. If you really want to know exactly how it allocates registers or mangles names, look somewhere else.

Also for context on why I’m writing this, I’m just naturally inclined to compare the design of Swift to Rust, because those are the two languages I have helped develop. Also some folks like to complain that Rust doesn’t bother with ABI stability, and I think looking at how Swift does helps elucidate why that is.

Patrick Walton:

I should mention that Rust tried in its early days to do witness tables (“type descriptors”/“tydescs”). I wrote a lot of that code.

Ironically, one of the big reasons we ripped it out was because of code bloat.

IIRC switching to monomorphization actually reduced code size by quite a bit.

Though the biggest reason was just performance: we couldn’t get type descriptor overhead below 20% of the program runtime or so, which was unacceptable.

Doug Gregor:

I still think that Swift’s library evolution story (ties in with the ABI) is the only novel feature of the Swift language. Everything else is lovingly borrowed and integrated from other languages

Joe Groff:

Reabstraction might also be a novel implementation technique. Some papers on levity polymorphism in Haskell declared the problem unsolvable without a JIT

Previously: