Blurring is a memory bandwidth and therefore power intensive effect, so it's more costly in terms of battery live on mobile devices than other more local effects like darkening and desaturation. Of all the visual effects today's gui design fads could choose to fetishize, blurring is unfortunately power hungry.

If "Material Design" was intended to conserve battery life, it shouldn't have been so focused on looking blurry. ;) Of course you can draw simple soft shadows without actually blurring the content underneath, but Apple's blurry iOS gui and macOS desktop windows using NSVisualEffectView's "Vibrancy" and blurring effects require a lot of power.

3 Differences – Apple’s HIG vs Google’s Material Design Standards: http://nectardesign.com/3-differences-apples-hig-vs-googles-...

"Apple believes that mobile devices should be seen as a window in to another world. They embrace infinite depth in their applications and use components such as their alert buttons and text messages with blurred background to create the feeling that the items are floating and exist in their own space. Another example of this would be the click wheel for their timer. See how the numbers recede in to the background? That would never happen in material design."

I don't remember the exact link, but I read an article from Apple describing the GPU accelerated blurring and "vibrancy" effects they rolled out in their desktop user interface, which cautioned about how expensive they were, because the more you blur, the wider the region of support of the convolution kernel, therefore the more memory accesses you have to perform per pixel. Even on the desktop, they warned that it had a considerable cost. So it's a pity that blurring has become so trendy on battery operated mobile devices.

Maybe it was this WWDC talk -- it contains lots of useful information about NSVisualEffectView performance:

Adopting Advanced Features of the New UI of OS X Yosemite: http://asciiwwdc.com/2014/sessions/220

"You want to use the active state explicitly, very sparingly.

It can affect performance and battery life, because if you have a lot of visual effect views around they're always active, but you probably want to use it in places where you know that view is always going to be active and maybe it's a panel that can't become key for whatever reason." [...]

"So you notice that blur we had and this may not surprise you but the blur effect isn't exactly free. It does cost something, and that something is graphics performance and battery usage. And sometimes, though, the cost is worth the results. So, something you should be aware of here is you're not trying to not use this effect. You want your app to look beautiful. You just need to pay attention to striking a balance between that appearance and the resource utilization." [...]

"Corbin mentioned that layers are often required, especially for in window blurs, and layer usage is increasing just in general." [...]

"If you add a lot of VisualEffectViews to your app and all of the sudden you notice that maybe your window resizing animations or your full screen transitions have become slow, you can set this [Accessibility Preference / Display Subsection / Reduce Transparency] to Yes, and this will avoid the cost we pay when doing that blur.

So if you notice when this is turned on your performance is fine, and when this is turned off your performance is kind of sluggish, it's probably you're using a VisualEffectView that's too large or too many VisualEffectViews, and that's a cue to dial down the transparency and blurring in the app." [...]

"Something I want to point out about a lot of our drawing here is that the blur effect actually happens out of process, it happens in the Windows Server, and furthermore, it happens on the GPU, and that means that profiling your own process won't necessarily tell you as much as you would hope." [...]

"If you're just doing a lighter development on your app, having activity monitor open can sometimes be useful.

It's certainly not as in-depth as instruments but it will tell you how much CPU you're using and more importantly it'll tell you how much energy your app is taking to do what it's doing.

And if you see that operating a little higher than you're expecting that may be another cue that your VisualEffectView usage has gotten a little excessive." [...]

"And finally, you folks remember like 40 seconds ago we talked a little bit about performance, and I do hope you'll take some of those performance messages to heart when you leave."

This Ars Technica review of OS/X 10.10 also discusses the cost of the blurring and vibrancy effects:
http://arstechnica.com/apple/2014/10/os-x-10-10/4/

"These visual effects aren’t free; they cost CPU and GPU cycles each time the foreground or background changes. Behind-window blending is implemented in the window server, which is responsible for compositing all the visible windows into the final screen image. (This compositing process has been GPU-accelerated since 2002.) Moving a window that uses vibrancy in the behind-window blending mode does not require the application that owns the window to redraw any content; the window server handles the re-compositing as the background changes.

Within-window blending, on the other hand, is handled by each individual application. The system frameworks use Core Animation layers (also GPU-accelerated) to apply the necessary filters, blending, say, the contents of a scrolling view with the toolbar that partially covers it.

Given Apple’s recent focus on energy saving in Mavericks, it’s a bit strange to see Yosemite lean so heavily on a dynamic effect like vibrancy. To keep things from getting out of hand, vibrant views become opaque when inactive. In practice, this means only the front-most window in the currently active application—plus the Dock, menu bar, and any notification alerts that may dance across your screen—will burn cycles artistically blending foreground and background content."