Archive for January 19, 2018

Friday, January 19, 2018 [Tweets] [Favorites]

Tim Cook Talks iPhone Batteries

I was not impressed by this interview (via Wojtek Pietrusiewicz):

When asked about the incident, Cook apologized to Apple users who believe that the company deliberately slowed the processors down in older models.

He hypothesized that when Apple released software updates to slow down older devices in older models to keep up with the new features, people may not have been “paying attention” when they explained what it was.

“Maybe we weren’t clear,” he said. “We deeply apologize for anyone who thinks we have some other kind of motivation.”

I’m not sure where the part about keeping up with new features came from. It’s not in the clip, so I’ll give Cook the benefit of the doubt that he didn’t say that nonsense.

However, the part about people not “paying attention” is in the clip, and I don’t find that credible at all. The press coverage of iOS 10.2.1 at the time did not explain this, and there’s some dispute as to whether the press was even told. Customers certainly weren’t.

Adam Engst:

The fact that Apple was doing something to address those shutdowns wasn’t a revelation. The company had said it was looking into the problem and claimed it had implemented a fix in iOS 10.2.1, back in early 2017. There was some dispute as to whether that actually happened since Apple included nothing in the release notes about it at the time (see “Apple Releases macOS Sierra 10.12.3, iOS 10.2.1, tvOS 10.1.1, and watchOS 3.1.1,” 23 January 2017). Subsequently, however, Apple amended iOS 10.2.1’s release notes to say:

It also improves power management during peak workloads to avoid unexpected shutdowns on iPhone.

If you didn’t somehow figure out that Apple had amended the release notes and decode that “power management” means they’re slowing down your phone, you weren’t “paying attention.” That’s the message from Apple’s CEO?

The article continues:

Cook said it was “rational” to offer the less expensive battery option -- instead of free batteries -- considering that “most people kind of expect to get a [new] battery at some point in time.”

I don’t think that’s the case, either. Most people didn’t know the batteries could even be replaced. And Apple’s own marketing VP said they wouldn’t need to be:

“Most iPhone users will realize, as most iPod customers realized, that they never needed to replace their batteries,” Joswiak said.

Is Apple’s position now that iPhone customers should expect to have to go to an Apple Store, pay $79, and wait an hour or two for a technician to replace their battery?

Previously: Apple’s Message to Customers About iPhone Batteries and Performance.

Update (2018-02-06): Juli Clover:

In a recent inquiry, Senator John Thune, chairman of the Senate Commerce Committee, asked Apple why there was a discrepancy between the time that the update was introduced and the time when Apple explained what was in the update, a question Apple answered today.

Apple says that iOS users were not immediately informed about the power management features in iOS 10.2.1 because it first needed to confirm that the update successfully solved the problem causing unexpected shutdowns.

[…]

In February 2017, we updated our iOS 10.2.1 Read Me notes to let customers know the update “improves power management during peak workloads to avoid unexpected shutdowns.” We also provided a statement to several press outlets and said that we were seeing positive results from the software update.

Update (2018-02-26): Joe Rossignol:

Apple currently faces 59 putative class actions across 16 district courts in the United States. The total includes 30 before Judge Edward J. Davila in the Northern District of California, where the lawsuits will likely be centralized given their overlapping claims, according to court documents obtained by MacRumors.

BBEdit Codeless Language Module for Swift

I’ve posted a fork of Curt Clifton’s BBEdit CLM for Swift. My version adds support for some newer Swift keywords, triple-quoted string literals, and class functions. The main improvement is that functions inside of classes (and structs, extensions, and protocols) are now indexed and available for BBEdit’s function pop-up.

Previously, only top-level functions were indexed. This was a direct consequence of the way CLMs require a single regex to match the “function” name and its body (in curly braces). If an entire class is consumed all at once, the functions inside become invisible, as there is no nested matching. This was not very useful for me because I mostly write member functions rather than global ones. Aidan Dysart’s CLM solves this problem by only indexing functions. But I want the other types to be indexed, too. It turns out that this is possible by changing the regex so that it only consumes the body for functions; for other types it stops matching after the name.

My first thought was to implement this by having separate alternations in the pattern for matching functions with content in braces and “functions” without bodies. However, this didn’t work because the function name has to be marked with (?P<function_name>), and you are only allowed to use that once. The solution I found was conditional matches, whereby the braces after the “function” name only match if the keyword before the “function” name was func. The main downside to this approach is that since non-func functions no longer have any braced content, they cannot be folded. However, I think that’s a small price to pay for getting them indexed. I mostly want to fold function bodies rather than whole classes, anyway.

Two-factor Authentication for Old Apple TVs

I’ve been using two-factor authentication with my Apple ID for a while now, and I found that this prevented me from signing into the account on my Apple TV 2. I would enter and submit my password, and then it would ask for the two-factor verification code. The map and code would indeed pop up on my iPhone, but there was nowhere on the Apple TV to enter the code. There was just an OK button, which would take me back to the login screen.

The solution comes from Apple forum reader appmacwmm: you can go to Settings ‣ iCloud on your phone to get the verification code first, then enter it into the Apple TV after your password (in the same text box) before it asks for the verification code. It’s a convoluted procedure that I can’t imagine most users figuring out on their own, and the Apple TV’s interface prompts are of no help.

Previously: Strange Apple ID Sign-In Locations.

Update (2018-01-22): See also: Dan Masters.

Simplifying Swift Framework Development

Dave DeLong:

@_exported will make an import-ed module visible to the entire module into which its been imported. This means you don’t have to import Dependency in every file you need it. You just @_exported that dependency once, and you’re good to go in any file in that module.

[…]

Second, I define a public constant that is the name of the framework, and whose value is the Bundle for that framework. I use the class-based look up (ie, find the bundle that declares this class), because it’s one of the few convenient Bundle initializers that doesn’t return a Bundle?, and thus I don’t have to deal with unwrapping. And then I use a special marker class for making that lookup resilient in the face of other functionality changes.

What Happens to the Traffic You Send to the App Store?

iA:

No matter how good your product is, you need to be found. We send all our traffic to the stores. In return, we get higher sales and higher rankings. Recently, some of the numbers left us guessing. The more traffic we get the higher the sales. But, somehow, our ranking suffers.

[…]

The good news is: Blogging pays off. The traffic you create on your side does translate into higher sales. But if it results in sudden spikes you get punished. Most probably the anti-spam algorithm kicks in assuming that you want to game the rankings and ranks you down. In consequence, you do not get proportionally more sales, when at the same time you fall in the rankings. A sudden spike in traffic and sales gets punished, no matter whether its real or fake traffic. There is not much we can do about that but whine. Or is there?

Using the App Store, you do not have much control over your sales process. You need to experiment and see what sticks. If you figure it out you still depend on Apple’s good will. Your most successful marketing campaign might result in a down-ranking, and, who knows, cause as much damage as it helps. This is probably not voluntary. Apple is a control freak, but this can’t be intended. It’s frustrating nevertheless.

[…]

The only thing you can do against the App Store algorithm punishing you for sending people to the Store is selling your app directly.

Dictation Eases Data Entry

Adam C. Engst:

And you know what? Dictation in iOS was way better than on the Mac, and no matter which of the variants I used, it formatted the number right every time. In subsequent testing, I discovered that saying “dot” instead of “point” prevented a few spurious spaces from creeping in.

[…]

In fact, I’d suggest that dictating numbers into iOS might be the most accurate way of entering them manually. It’s easy to make mistakes when transferring your gaze back and forth between a sheet of paper and the keyboard, and it’s also easy to tap a wrong key accidentally. But when you’re dictating, you can devote all your attention to reading and speaking the numbers, eliminating both context-switching and typing mistakes.