# SCLAlertView: an Objective-C alert replacement for iOS apps

> SCLAlertView is an MIT-licensed Objective-C alert view that replaces UIAlertView and UIAlertController with animated, styleable alerts. Here is how it installs, how the builder API works, and where it stops being the right choice.

**dogo/SCLAlertView** — Beautiful animated Alert View. Written in Objective-C

- Repository: https://github.com/dogo/SCLAlertView
- Stars: 3,492 · Forks: 517
- Language: Objective-C
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/dogo-sclalertview

## What SCLAlertView replaces, and for whom

SCLAlertView targets a narrow but real gap: iOS apps written in Objective-C that need alert dialogs more expressive than the system default. The README describes it as "Animated Alert View written in Swift but ported to Objective-C, which can be used as a `UIAlertView` or `UIAlertController` replacement." That sentence carries the whole positioning. UIAlertView is deprecated, and UIAlertController is the modern replacement, but neither offers custom imagery, custom colours, timer buttons or a text field with a validation block in the same call. SCLAlertView does.

The audience is therefore maintainers of older Objective-C codebases, internal enterprise apps, and SDKs that still ship Objective-C headers. If your project is Swift-only, the port exists but the ergonomics are Objective-C shaped: dot-syntax builders, selector targets, and block callbacks. Nothing here is wrong, but you are paying a translation cost for a library whose primary language is not yours. The repository's topics list both `objective-c` and `uialertcontroller`, which reflects that dual framing.

## How the builder API and alert styles fit together

The library exposes two layers. The simple layer is a single SCLAlertView instance with convenience methods such as `showSuccess:title:subTitle:closeButtonTitle:duration:` and siblings for error, notice, warning, info, edit, custom, waiting and question. The duration argument controls auto-dismiss; passing `0.0f` means the alert stays until the user acts.

The second layer is a set of builders. SCLAlertViewBuilder accumulates buttons, text fields and animation types, while SCLAlertViewShowBuilder carries presentation concerns: style, image, colour, title, subtitle, close button title and duration. The README states the fluent style explicitly with `SCLAlertViewBuilder *builder = [SCLAlertViewBuilder new]` followed by chained calls, and notes that presentation can be written either as `[showBuilder showAlertView:builder.alertView onViewController:self.window.rootViewController];` or as `showBuilder.show(builder.alertView, self.window.rootViewController);`. Two call styles for the same operation is a small thing, but it tells you the API grew rather than being designed once.

Buttons can be added three ways: a selector target, an action block, or a validation block paired with an action block. The validation variant is the interesting one. It lets a button refuse to fire until a condition holds, which is how the README's phone-code example gates confirmation on a text field value. That is a genuine capability UIAlertController does not give you in one API.

## Installing SCLAlertView and showing a first alert

The README surfaces two distribution routes through its badges: CocoaPods, with the pod name SCLAlertView-Objective-C, and Carthage, marked compatible. A Package.swift file also sits at the repository root, so Swift Package Manager is present in the layout even though the README does not walk through it. The podspec file SCLAlertView-Objective-C.podspec is the CocoaPods manifest.

After installing through CocoaPods, the README's own quick start is the shortest path to a visible result. It creates an alert and shows a success style that waits for the Done button because the duration is 0.0f:

```Objective-C
// Get started
SCLAlertView *alert = [[SCLAlertView alloc] init];

[alert showSuccess:self title:@"Hello World" subTitle:@"This is a more descriptive text." closeButtonTitle:@"Done" duration:0.0f];
```

If you have no view controller to hand, the README documents a window-based initializer, `[[SCLAlertView alloc] initWithNewWindow]`, with a matching set of show methods that omit the view controller argument. Custom width is available through `initWithWindowWidth:` and `initWithNewWindowWidth:`. Buttons are added on the same instance, either through a selector or a block:

```Objective-C
SCLAlertView *alert = [[SCLAlertView alloc] init];

//Using Selector
[alert addButton:@"First Button" target:self selector:@selector(firstButton)];

//Using Block
[alert addButton:@"Second Button" actionBlock:^(void) {
    NSLog(@"Second button tapped");
}];
```

## Where SCLAlertView stops being the right tool

The README does not document what happens to an alert when its presenting view controller is dismissed mid-animation, and it does not describe a rollback or cancellation path. That silence matters in apps where alerts are shown from background callbacks, network completions or deep links, because the presenter may no longer be on screen. You are relying on the library's internal handling rather than a documented contract.

A second constraint is language. The project is Objective-C, and the README's examples are Objective-C throughout. If your team writes Swift, you can bridge it, but you inherit selector-based targets and Objective-C naming in a Swift file. The related searches around `sclalertview swift` and `sclalertview objective c` suggest people arrive expecting both; only the Objective-C path is documented.

A third point is scope. This is an alert view, not a general presentation framework. It does not claim to handle sheets, banners, toasts or queued notifications. If your requirement is a global message queue with priorities, SCLAlertView is the wrong shape of tool.

Maintenance is worth stating plainly: the last push to the repository was on 2026-07-27, and the most recent release listed is 1.4.2 from 2025-11-30. The repository is not archived. Those are the facts available; the README does not publish a support policy or a deprecation timeline.

## How SCLAlertView differs from Swift alert libraries

The related searches point at SwiftMessages, SwiftEntryKit, PopupDialog and Presentr. The distinction is not cosmetic. SwiftMessages and SwiftEntryKit are message and presentation frameworks: they model banners, cards and queued presentation across the top or bottom of the screen, with an emphasis on non-blocking notifications. SCLAlertView models one thing, a modal alert, and gives it many visual styles.

That difference changes integration. A presentation framework usually asks you to register a configuration and then post messages into it; SCLAlertView asks you to construct an object and call a show method on a view controller, or on a new window. The window path in SCLAlertView is the closest analogue to a global presenter, but it is still one alert at a time by construction.

PopupDialog sits nearer to SCLAlertView in intent, a styled modal, but it is Swift and its API is written for Swift call sites. Presentr is a presentation controller wrapper, a different abstraction again: it customises how you present a view controller rather than providing the alert content itself. If you want an alert with a validation-gated button and a timer on that button, none of these four is described in the same terms, and SCLAlertView's `addTimerToButtonIndex:reverse:` is a concrete feature the README documents.

## Licence, upgrade cost and what to check before adopting

The licence is MIT, per the repository metadata and the LICENSE file at the root. MIT is permissive: it allows use in closed-source products provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; if your organisation has a policy on attribution in shipped binaries, apply it.

Upgrade cost is the harder question. The release history shows 1.4.0, 1.4.1 and 1.4.2 within roughly a month of each other, which suggests patch-level churn rather than a stable long-term line. The repository carries a CHANGELOG.md, so version-to-version changes are recorded there rather than in the README. There is a Gemfile, a mise.toml and a .github directory, which indicates CI and tooling configuration live in the repository, so a fork is not starting from zero.

Before you adopt, check three things. First, that the podspec version matches the release you intend to pin. Second, that the animation types you plan to use, such as `SCLAlertViewShowAnimationFadeIn` and `SCLAlertViewHideAnimationFadeOut`, are present in the version you pull. Third, whether your app's minimum iOS deployment target is compatible with the SCLAlertViewFramework target in the repository layout, since the README does not state a minimum version.

## Conclusion

Adopt SCLAlertView if you maintain an Objective-C iOS codebase and want styled alerts without rewriting your UI layer in Swift, and if you can accept that the README does not document rollback or persistence behaviour. Do not adopt it if your app is already Swift-first and you want a maintained Swift library with an active feature roadmap; the README shows no deprecation path and no migration guide. Before integrating, verify the podspec version against release 1.4.2, confirm the develop branch state, and check that SCLAlertViewShowBuilder supports the animation types your screens rely on.

## FAQ

### How do I install SCLAlertView in an iOS project?

The README shows CocoaPods and Carthage badges, and the pod is named SCLAlertView-Objective-C. A Package.swift file also exists at the repository root, though the README does not walk through Swift Package Manager.

### Is SCLAlertView available for Swift projects?

The library is written in Objective-C and the README's examples are all Objective-C, so Swift use means bridging through the generated header. The README does not document a Swift-specific API.

### Can SCLAlertView show an alert without a view controller?

Yes. The README documents `[[SCLAlertView alloc] initWithNewWindow]` with show methods that omit the view controller argument, and a matching `initWithNewWindowWidth:` for custom widths.

## Sources

- [dogo/SCLAlertView on GitHub](https://github.com/dogo/SCLAlertView)
- [Issues](https://github.com/dogo/SCLAlertView/issues)
- [License: MIT](https://github.com/dogo/SCLAlertView/blob/develop/LICENSE)
- [README](https://github.com/dogo/SCLAlertView/blob/develop/README.md)
- [Releases](https://github.com/dogo/SCLAlertView/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dogo-sclalertview