FXBlurView: a deprecated iOS 5 blur view and what to use instead

What FXBlurView solved, and for whom

Apple shipped the realtime background blur in iOS 7, and it was tied to that release. Apps that still supported iOS 5 or iOS 6 had no equivalent. FXBlurView filled that gap: a UIView subclass that reproduces the same visual effect on older systems. The README states the design goal plainly, that it is "designed to be as fast and as simple to use as possible".

The audience was narrow and specific. If your deployment target was iOS 7 or above, you already had the platform effect and did not need this class. The people who needed it were shipping to iOS 5 or iOS 6 and wanted a blurred panel, an overlay, or a translucent toolbar that looked consistent with the newer OS. That is a historical audience now, which is exactly why the README opens with a deprecation notice stating the project "will not receive any future updates or bug fixes".

The README also documents the compatibility boundary. The supported build target is iOS 8.4 with Xcode 6.4 and Apple LLVM compiler 6.1. The earliest supported deployment target is iOS 7.0, and the earliest compatible deployment target is iOS 4.3. The README distinguishes the two words: supported means tested, compatible means it should work because it does not rely on unavailable SDK features but is no longer tested and may need tweaking.

Static and dynamic rendering, and the CPU bill

FXBlurView has two modes, controlled by the dynamic property, which defaults to YES. In dynamic mode the view redraws itself on a background thread as often as it can. In static mode it renders once when added to a superview, and you refresh it yourself with setNeedsDisplay or updateAsynchronously:completion:.

The cost sits in dynamic mode. The README calls dynamic blurring "extremely cpu-intensive" and advises disabling dynamic views immediately before an animation to avoid stuttering. Two class methods exist for that: +setUpdatesDisabled and +setUpdatesEnabled, which toggle updates for all dynamic instances at once. The README warns that calls can be nested but must be balanced, or updates will be left permanently enabled or disabled. That is a real footgun: an unbalanced pair leaves every blur view in the app frozen or burning CPU, and nothing in the API surfaces the mistake.

Two properties tune the trade-off. updateInterval is the seconds between updates in dynamic mode and defaults to zero, meaning update as fast as possible. The README notes that zero yields the best frame rate but is extremely CPU intensive and may degrade the rest of the app, particularly on older devices, and suggests increasing the value. iterations defaults to 2; more iterations means higher quality and lower performance. blurRadius defaults to 40 points, described as similar to the iOS 7 effect.

There is also a global kill switch, +setBlurEnabled:, for disabling the effect on every instance, which the README suggests for testing or for turning blur off on iPhone 4 and below to match iOS 7 behaviour. A per-instance blurEnabled property exists too, but the class-level setting overrides it.

Installing FXBlurView and rendering a first blur

There is no package manager step in the README. Installation is manual: drag the class files into your project and add the Accelerate framework. You can create instances in code, or drag an ordinary UIView in Interface Builder and set its class to FXBlurView.

If you create the view in Interface Builder, the README says to set the custom properties either through an IBOutlet in code or through the User Defined Runtime Attributes feature introduced in Xcode 4.2 for iOS 5 and later.

ARC matters here. As of version 1.3 FXBlurView requires ARC. In a non-ARC project you add the compiler flag to the implementation file through Build Phases, Compile Sources:

-fobjc-arc

The README describes double-clicking FXBlurView.m in the Compile Sources list and typing that flag into the popover. If you would rather convert the whole project, the README says to comment out the #error line in FXBlurView.m and then run Edit > Refactor > Convert to Objective-C ARC, making sure the files you want converted, including FXBlurView.m, are checked.

For a static blur, set dynamic to NO and trigger a redraw when your content changes. The method takes a boolean for whether the work happens off the main thread and an optional completion block:

- (void)updateAsynchronously:(BOOL)async completion:(void (^)())completion;

Calling setNeedsDisplay instead is described as more or less equivalent to updateAsynchronously:NO completion:NULL, so it blocks on the main thread. If you only need a blurred UIImage rather than a live view, the UIImage extension avoids the view entirely:

- (UIImage *)blurredImageWithRadius:(CGFloat)radius
                         iterations:(NSUInteger)iterations
                          tintColor:(UIColor *)tintColor;

The README notes that this returns a new image without modifying the original, that more iterations means higher quality, and that the alpha component of the tint color is ignored.

Where the design breaks down

The tint colour is the clearest rough edge. The README repeats twice that the alpha component of tintColor is ignored, and says that varying the intensity of the tint means using brighter or darker colours instead. That is unusual if you are used to alpha-based overlays, and it means a designer's semi-transparent tint value will not behave as written.

The update model is the second problem. Because dynamic mode redraws as fast as it can by default, the default configuration is the most expensive one. The README says so directly, but the defaults are what most people ship with. On a screen with several blur views, the README recommends +setUpdatesDisabled over flipping each view's dynamic property, which tells you that per-view control does not scale.

The third issue is that this is the wrong tool for anything but a legacy target. On iOS 8 and later, UIVisualEffectView is part of UIKit and gets the platform's own blur, including whatever efficiency work Apple does behind it. FXBlurView reimplements that effect in application code, on the CPU, and the README's own deprecation notice says it will get no bug fixes. Choosing it for a new app means taking on a maintenance liability for an effect the operating system already provides.

The README does not document rollback or uninstall steps, which matters less here than for a server component: removing the class files and the Accelerate dependency is the whole removal.

UIVisualEffectView is the replacement, and the difference is not cosmetic

The direct alternative on iOS 8 and later is UIVisualEffectView with a UIBlurEffect. The difference is architectural rather than visual. UIVisualEffectView is a system view that composites the blur in the render pipeline, so the blur is produced by the platform rather than by a UIView subclass sampling and filtering its backdrop on the CPU. That removes the updateInterval and iterations tuning knobs entirely, because there is no per-frame application-side loop to tune.

FXBlurView's advantage was reach: it worked where the platform effect did not exist. Once your deployment target reaches iOS 8, that advantage disappears and only the cost remains. The README's own advice points the same way, telling users to migrate to another solution.

There is one case where the FXBlurView approach still has something to offer: the UIImage extension. If you need a blurred image as data, for example to render once and cache, blurredImageWithRadius:iterations:tintColor: is a single call that returns the result without touching the view hierarchy. UIVisualEffectView is a view, not an image producer, so the two are not interchangeable for that specific job.

Maintenance status, licence and the cost of staying

The README's first line after the header is a deprecation warning: the project "will not receive any future updates or bug fixes". That is the maintenance answer, and it comes from the project itself rather than from inference. The repository is not archived, but the README's statement about future updates is the relevant fact for anyone deciding whether to build on it.

Staying on FXBlurView has a compounding cost. You own the class files, so any bug you hit is yours to fix, and the README explicitly rules out upstream fixes. You also carry the ARC configuration, either the -fobjc-arc flag on FXBlurView.m or a project-wide conversion, and you carry the Accelerate framework dependency. None of that is heavy on its own. The problem is that it is permanent, because there is no upgrade path that does not involve replacing the class.

The licence file is LICENCE.md at the repository root, and the repository metadata reports the licence as NOASSERTION rather than a recognised SPDX identifier. That means you should read LICENCE.md yourself before shipping, since a machine-readable licence field is not a substitute for the text. Nothing here is legal advice; the point is that the licence field does not resolve the question for you.

Editorial conclusion

Adopt FXBlurView only if you maintain an app that still targets iOS 5 or 6 and cannot move, and accept that the README states it will receive no future updates or bug fixes. Do not adopt it for new work; UIVisualEffectView covers iOS 8 and later with a system-supported blur. Before committing either way, verify your deployment target, whether your project builds with ARC or needs the -fobjc-arc flag on FXBlurView.m, and whether your blur sits behind an animation that would need +setUpdatesDisabled.

Frequently asked questions

Official sources

1. Official README
2. Project repository