Archive for December 22, 2017

Friday, December 22, 2017

Energy Efficiency: A New Concern for Application Software Developers

Gustavo Pinto and Fernando Castor (via Jeremy W. Sherman):

One of the main challenges of software energy consumption research is to bring analysis to the static level. Currently, software energy consumption instrumentation can only be conducted at runtime. This approach has several limitations; such as sophisticated (and expensive) hardware equipment or applicability only to specific hardware configurations. This fact has the potential of limiting the usability of software energy consumption tools.


Pinto et al. observed that just updating from Hashtable to Concurrent HashMap in a Java program can yield a 3.5x energy savings. In particular, this transformation yields a 1.4x and a 9.2x energy savings in CPU and DRAM, respectively. As another example, Pathak et al. observed that I/O operations consume more energy partly because of the tail energy phenomenon. According to the authors, bundling I/O operations together can mitigate this tail energy leak. These results have a clear implication: Tools to aid developers in quickly refactoring programs can be useful if energy is important.


Li et al. discussed how to improve energy efficiency by favoring darker colors instead of lighter ones for smartphones with OLED displays. Using a search-based multi-objective approach, Linares-Vasquez et al. automatically optimized energy consumption and contrast, while using consistent colors with respect to the original color palette. Oliveira Jr. et al. analyzed the energy consumption of Android app development approaches, Java, JavaScript, and Java + C++, in both benchmarks and real apps. In both scenarios it was observed that different approaches have different impacts on energy. In particular, combining different approaches can yield more than an order of magnitude energy savings in compute-intensive apps.


Pathak et al. focus on understanding and monitoring system calls that are related to I/O operations. As a results, they found that most of the energy consumed in free apps is related to third-party advertisement modules (which can be responsible for up to 75% of the overall energy consumed by an app).

WKWebView Workarounds

Brent Simmons:

WebView — good ’ol trusty friend — has a bunch of things that WKWebView is missing.

The new web view has no built-in support for finding text, for instance. I’m not sure what I’m going to do about this, since the ability to hit cmd-F and look for some text is a pretty fundamental thing, and I can’t skip it.

It also has no delegate method for when you mouse over a link. Seems like another fundamental thing, right? Any browser offers you a status bar or some way to see the URL of the link your mouse is over.

Given the level of progress over the last 3.5 or so years, it seems like WKWebView is the future, and too bad for you if you need more features. Maybe you can hack some of them together using JavaScript. With Apple no longer dogfooding WebView, how much longer will it be supported? This is the sort of thing that worries me about iOS APIs coming to the Mac.

Update (2018-05-14): Howard Oakley:

That may be true, but when I had implemented that in LockRattler, which runs on El Capitan and later, Xcode decided that I couldn’t use WKWebView because of implementation bugs. It only works in Sierra and later, not in El Capitan.

Apple Narrows Ban on Templated Apps

Sarah Perez (MacRumors):

The company’s revised wording now states:

4.2.6 Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences.

Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.

This is Apple’s attempt to clarify how it thinks about templated apps.

Core to this is the idea that, while it’s fine for small businesses and organizations to go through a middleman like the app templating services, the app template providers shouldn’t be the ones ultimately publishing these apps on their clients’ behalf.

Instead, Apple wants every app on the App Store to be published by the business or organization behind the app. (This is something that’s been suggested before). That means your local pizza shop, your church, your gym, etc. needs to have reviewed the App Store documentation and licensing agreement themselves, and more actively participate in the app publishing process.

This makes sense to me.

Brian Stucki:

Happy to see this update. 1) I like it when I load a random app and it’s a design I’m already familiar with and 2) makes apps affordable for small business and 3) the services that build and sign these apps are a popular customer for @MacStadium Mac clouds. Win-win-win.

Previously: Apple Widens Ban on Templated Apps.

Update (2017-12-22): See also: John Voorhees.

Update (2018-02-22): Matt Long:

Apple drops another bomb WRT white label apps. Grandfathered apps must be transferred to customer app store account if updated after April 1.

Apple Confirms That It Throttles iPhones With Degraded Batteries

Matthew Panzarino (Hacker News):

Here’s a statement that Apple provided when I inquired about the power profile that people were seeing when testing iPhones with older batteries:

Our goal is to deliver the best experience for customers, which includes overall performance and prolonging the life of their devices. Lithium-ion batteries become less capable of supplying peak current demands when in cold conditions, have a low battery charge or as they age over time, which can result in the device unexpectedly shutting down to protect its electronic components.

Last year we released a feature for iPhone 6, iPhone 6s and iPhone SE to smooth out the instantaneous peaks only when needed to prevent the device from unexpectedly shutting down during these conditions. We’ve now extended that feature to iPhone 7 with iOS 11.2, and plan to add support for other products in the future.

John Gruber:

Prior to adding this feature to iOS last year, iPhones with older declining batteries were shutting down unexpectedly when taxed at peak performance. That’s obviously not good. So now, iPhones with older declining batteries are throttled, when necessary, to keep them running. But now Apple faces accusations that they’re deliberately slowing these devices down to convince people to buy new iPhones.

Jason Koebler:

iFixit teardown engineer Jeff Suovanen performed similar tests with iFixit employees’ phones and shared the data with Motherboard.

Suovanen found that iPhone 6S devices that still had their original batteries (they are about two years old now) had benchmark scores that were up to 57 percent lower than the GeekBench average. Replacing the battery instantly improved the benchmark scores drastically; he saw 70 percent swings in benchmark performance after swapping the old battery for a new one.

“Everyone came back a day later and said, ‘Wow, it works so much faster,’” Suovanen told me on a phone call.


What makes it worse is that Apple does not make it easy to replace the battery yourself, discourages third party repair, and doesn’t have the first party repair infrastructure to handle large numbers of in-store battery swaps, especially in states that don’t have lots of Apple Stores.

Andrei Frumusanu:

Capacity and supply voltage of a battery decreases over time as a function of charge cycles and charging behaviour (Higher charging currents causing more degradation per cycle). This causes the total useable battery capacity before the cut-off voltage to decrease.

The problem facing the iPhones as Apple explains it is however two-fold; the issue at hand happens only during load spikes in which the battery isn’t able to maintain a high enough voltage for the PMIC to reliably be able to use as a source.

SoC blocks such as CPUs and GPUs can have very short transitions from idle to load causing steep transients and load spikes going above the +10W ranges. As batteries degrade over time and the cell impedance also rises also in function of the state of charge and temperature, the current flow becomes restricted and the cell is no longer able to satisfy the power requirement at a high enough operating voltage.


If this is the case then another question rises is if this is indeed just a transient load issue why the power delivery system was not designed sufficiently robust enough to cope with such loads at more advanced levels of battery wear? While cold temperature and advanced battery wear are understandable conditions under which a device might not be able to sustain its normal operating conditions, the state of charge of a battery under otherwise normal conditions should be taken into account during the design of a device (Battery, SoC, PMIC, decoupling capacitors) and its operating tolerances.

If the assumptions above hold true then logically the issue would also be more prevalent in the smaller iPhone as opposed to the iPhone Plus models as the latter’s larger battery capacity would allow for greater discharge rates at a given stable voltage. This explanation might also be one of many factors as to why flagship Android and other devices don’t seem to exhibit this issue, as they come with much larger battery cells.

Jacob Kastrenakes (Hacker News):

There is some good reason for Apple to do this. By their nature, lithium-ion batteries degrade over time, storing less and less of a charge. This happens very quickly on a device we use 24/7. So it's not a bad idea for Apple to limit speeds on older phones, such that they don't push things too far on a depleted battery. That absolutely makes the phone more useable — it apparently helps stop random shutdowns, which are a major pain. And I would think it helps with battery life in general as well.

But it also speaks to a really enormous problem with the iPhone: this $700 to $1,000-plus product, as designed, isn't able to function near its peak after just a year of use. That should be unacceptable.

Slowing down the phone is one way to work against aging issues, but there are other, more obvious things Apple could do here. It could put larger batteries in the iPhone in the first place, so that they last longer before this kind of adjustment needs to kick in.

Some of my thoughts:

Previously: Does iOS Throttle CPUs When Using a Degraded Battery?.

Update (2017-12-22): Rene Ritchie describes additional power management that slows down the CPU separately from the protection during load spikes.

More lawsuits have been filed.

Kirk McElhearn recommends iMazing for checking your battery’s health.

Update (2017-12-23): I already find the iPhone 6–8 thin enough that I need a case to hold them comfortably. I’d much rather carry extra battery than inert plastic.

After the Reddit story broke, an Apple genius told Michael Glenn that iOS does not throttle when the battery is degraded; he was able to fix the performance issues on his iPhone by wiping and restoring it, which got rid of a “rogue system process that somehow persisted through upgrades and restarts” (via John Gruber).

Update (2017-12-28): See also: Accidental Tech Podcast.

Apple has posted a statement.

Update (2018-01-01): Antonio Fonseca:

It seems the SoC team needs to interact more with the battery / engineering team and all of them with the industrial design team. It seems like things are a bit out of sync when it comes to goals for the iPhone project.

Nilay Patel:

Processor speed is just one piece of the battery- and performance-management puzzle, according to Apple: iPhones with older batteries may also more aggressively dim their screens, have lower maximum speaker volumes, and even have their camera flashes disabled when the system needs more peak power than the battery can provide. But other core features, like the cell radio, GPS, and camera quality, aren’t affected, Apple says. The whole approach actually quite clever, but cleverness isn’t a great substitute for speed.

In any event, Apple has a long way to go rebuilding trust with its customers — this story broke well past the tech press and hit TV morning shows and local news with zero nuance about “smoothing instantaneous peaks” and battery chemistry degradation. A lot of people already believed that Apple slowed down their iPhones, and this wave of news was a big data point confirming that for them. It’s going to be a difficult road back.

Ian Spencer:

Key phrase is “whose battery needs to be replaced”. In my experience Apple is loathe to admit a device (iPhone or Mac) has battery problems.

Mitchel Broussard:

In response, iFixit has decided to match that price point and lower the cost of every DIY iPhone battery fix kit to $29 or less.

Rene Ritchie:

No #iPadSlow: Basically, the iPad battery is so big there’s much less concern over power spikes and so Apple hasn’t added them to the same advanced power management system that iPhone 6, iPhone SE, iPhone 6s, and iPhone 7 are on.

dwc1 (via Jon Maddox):

I went to the Genius Bar yesterday and got a walkin appointment for my T-Mobile purchased 6s. The wait time was quoted as 1 hour but took 20 mins. They ran very deep diagnostics to see if I qualify for the $29 offer which I was not expecting since I thought you could just ask for replacement on demand. They told me my battery was working well enough and almost turned me down. I had to press hard that the battery just does not hold the charge long enough anymore. The tech found a workaround by prompting me to sort of claim that the device shuts down unexpectedly on occasion. Once I said yes to shutdown issue that they replaced the battery for FREE. It looks like Apple will be sort of strict about these $29 battery replacements. I also had to leave my phone for the actual repair for about 90 mins wait time while they did the work.