LGAlertView reimplements three UIKit alert classes as one customizable view

Three deprecated UIKit classes, one implementation

LGAlertView describes itself as a customizable implementation of UIAlertViewController, UIAlertView and UIActionSheet, all in one, with the claim that you can customize every detail.

The reason all three are named together is historical and worth understanding, because it explains the shape of the library. UIAlertView was the original iOS alert, a simple modal with a title, a message and buttons, and it was deprecated in iOS 9 in favour of UIAlertController. UIActionSheet, the slide-up panel of options, was deprecated in iOS 8.3 instead. UIAlertController, introduced in iOS 8, absorbed both roles.

So a library that reimplements all three is not confused about its own scope. It is covering the whole family of alert presentations in one component, and the family includes presentations that the modern system controller does not replicate. The blurb ends with the joke that makes the intent clear: make AlertView of your dream.

The primary language is Objective-C, with swift among the repository topics, and the distribution is through CocoaPods and Carthage, with a podspec at the root of the repository. The project is MIT licensed, and the last push was on 2026-09-20 with release 2.4.4 on the same day, following 2.4.3 and 2.4.2 in September 2024.

The repository layout is small and to the point: the LGAlertView/ directory holds the component, the Framework/ directory the framework packaging, the Demo/ directory an Xcode project called LGAlertViewDemo, and LGAlertView.podspec the package definition.

The demo project is where the customization options live

The README is almost entirely screenshots, and that is deliberate. The preview section is organised into named configurations rather than an API reference: a Default Alert View, a Default Action Sheet, a Blurred Alert View, a Blurred Action Sheet, a Custom Alert View and a Custom Action Sheet. Each one is a run of images, with the default variants including an animated preview GIF alongside the still frames.

The default alert view sequence runs to thirteen frames, which suggests a presentation animation being documented frame by frame. The default action sheet runs to eight. The blurred variants are shorter, five frames each, and the custom ones are stills only.

The screenshots come from a separate ReadmeFiles repository pinned to a specific commit, so the images are versioned content rather than files that drift in the main repository. That is a small but telling piece of project hygiene for a component whose main selling point is visual.

The README is explicit that the screenshots are just a few examples of what can be achieved and that you are free to create your own. The Demo/ directory with LGAlertViewDemo.xcodeproj is the place where the actual option surface becomes visible, since the README does not enumerate the property names in the text.

For a component whose value is entirely in its appearance, that is a reasonable documentation strategy, but it is also a limitation: a developer cannot read the README to find out which properties exist, and has to open the demo or the headers to learn them.

Blurring is a first-class variant, not an afterthought

Of the six documented configurations, two are blurred variants, one for the alert view and one for the action sheet. That is a third of the showcase dedicated to a single visual treatment, which tells you something about what this library is for.

The system alert has a fixed visual language. Its background, corner radius, blur, shadow and button styling are not attributes you can set. A design system that wants a different blur, or no blur, or a different corner radius, has no hook in UIKit for that.

LGAlertView supplies one, and the blurred variants are the proof that it works. A blurred alert view and a blurred action sheet, each documented in its own run of frames, means the component can present a modal over blurred content in either of the two alert geometries.

The value of that is proportional to how opinionated the product's design is. An app that ships the stock iOS alert needs none of this. An app with a branded component library, where the alert is one of the few surfaces the user sees and the product team has signed off on a specific blur and radius, has exactly this problem. The cost is that you are now maintaining a view controller that draws itself, and it has to keep working across iOS releases, which is a real ongoing commitment rather than a one-off.

CocoaPods and Carthage are the two supported routes

The distribution story is short because the project is a single component with two well-trodden channels. The README carries a CocoaPods platform badge linking to the pod page and a version badge, a Carthage compatible badge, and a licence badge pointing at the LICENSE file in the repository.

That means the component is consumed the way most iOS libraries are. With CocoaPods, the LGAlertView.podspec at the repository root is the package definition, and the project is added to your Podfile by name. With Carthage, the project is built from the repository and the resulting framework is linked into your project. The Framework/ directory in the repository is the packaging side of that, and the Demo/ directory with LGAlertViewDemo.xcodeproj gives you a working Xcode project to open and read.

There is no Swift Package Manager support listed, and no badge for it. That is the practical detail to check first if your project is SPM-based, because a team that has moved its whole dependency graph to Swift Package Manager will find that the package manager path is not available here, and adding CocoaPods or Carthage to the project for one component is a build-system decision rather than a trivial import.

The project is MIT licensed with the licence text in the LICENSE file at the repository root. For a component you are about to make load-bearing in an app's most visible modal, that licence is the easy part of the decision.

Where LGAlertView is the wrong choice

The first wrong-tool case is the ordinary one. If your requirement is a title, a message and two buttons, UIAlertController does that, does it with the system appearance, and does it with accessibility behaviour you would otherwise have to reimplement. Taking on a custom alert to get a slightly different corner radius is a poor trade, because you inherit the accessibility and presentation behaviour that the system gives you for free.

The second is a Swift-only codebase with no Objective-C in it. The primary language is Objective-C, and while swift appears among the repository topics, the component itself is written in Objective-C. A team that has committed to Swift-only and has no bridging header or mixed-language module in its build is going to have to make a decision about how to consume it that has nothing to do with the alerts.

The third is an app that needs the modern alert features. UIAlertController gained an actionSheet style, text fields in alerts, and the presenter APIs that let you control where an alert appears. A reimplementation of the older classes is a reimplementation of the older classes, and if your product needs the newer system behaviour, a custom view of the older shape is the wrong starting point.

The fourth is a component you intend to keep indefinitely. The release history shows 2.4.2 and 2.4.3 both from 2024-09-06 and then 2.4.4 on 2026-09-20, so the project moves in bursts rather than on a schedule, and it is a single-maintainer component in the LGLibs family. A team that plans to keep this alert for the life of the app should read the source, because the amount of code is small enough to own, and a component this small is cheap to fork and maintain internally if it becomes load-bearing.

Editorial conclusion

LGAlertView fits an iOS team that needs an alert beyond what UIKit's own controllers allow, such as a fully custom background, blur or layout, and it does not fit a project that would be better served by the built-in UIAlertController. Before adopting it, check that the version you pin supports your deployment target, since the most recent release is 2.4.4 from 2026-09-20 and the project is Objective-C rather than Swift, and remember the component is a replacement for the presentation layer only, not for the logic that decides what to present.

Frequently asked questions

Official sources

1. Issues
2. LGLibs/LGAlertView on GitHub
3. License: MIT
4. README
5. Releases