Appirater for iOS in 2026: Why It's Deprecated and What to Use Instead

Appirater was once the default answer for prompting iOS app reviews. Drop in the library, set a launch count threshold, and let it handle the rest. For years, that was enough.

It is not enough now. Appirater is unmaintained, incompatible with current App Store policy, and has been superseded by Apple's own API. If your codebase still references it, that is a compliance risk — not just a technical debt item.

This article explains what changed, why Appirater no longer works as intended, and what the correct replacement looks like in 2026.

---

What Appirater Was

Appirater was an open-source Objective-C library created by Arash Payan. It tracked app launches and days since install, then presented a custom UIAlertView asking the user to rate the app on the App Store.

The library was practical for its time. Before Apple provided a native review API, third-party libraries were the only option. Appirater filled that gap cleanly.

That gap closed in 2017 when Apple shipped SKStoreReviewController. Appirater has not had a meaningful update since. The repository is effectively archived.

---

Why Appirater Is Deprecated in 2026

App Store Policy Conflict

Apple's App Store Review Guidelines prohibit apps from directing users to a review prompt through any mechanism other than SKStoreReviewController or its successor AppStore.requestReview. Custom alert views that ask for a rating — or that gate the native prompt behind an "are you enjoying the app?" pre-screen — violate guideline 5.6.1.

Appirater's core mechanic is a custom UIAlertView. That mechanic is now a rejection risk.

UIAlertView Is Removed

UIAlertView was deprecated in iOS 9 and removed in later SDKs. Any Appirater integration that has not been patched will either fail to compile or behave unpredictably on current iOS targets. The library predates UIAlertController, async/await, Swift concurrency, and SwiftUI entirely.

No Swift or SwiftUI Support

Appirater is Objective-C. Bridging it into a Swift codebase requires an Objective-C bridging header — added friction and a maintenance surface with no upside. There is no SwiftUI-native version.

The Repository Is Unmaintained

The last substantive commit to the Appirater repository is years old. No one is patching it for new iOS SDK changes, new App Store policy updates, or new Swift language versions. Depending on it is depending on a stopped clock.

---

The Correct Replacement: SKStoreReviewController and AppStore.requestReview

Apple's native review API has two forms depending on your target.

UIKit:

import StoreKit

SKStoreReviewController.requestReview(in: windowScene)

SwiftUI:

import StoreKit

@Environment(\.requestReview) var requestReview

// call at the right moment
requestReview()

Both invoke the same system-managed prompt. Apple controls the presentation, the throttling (maximum three prompts per 365-day period per app per device), and the UI. Whether the prompt appears on any given call is not your decision. That is intentional and correct.

What You Do Control

You control when you call the API. That is the entire implementation surface. Pick a moment that follows a completed user action — not an app launch, not an arbitrary timer.

Good trigger points:

• After a user completes a task that represents core value delivery
• After a milestone (the tenth session, or the first successful sync)
• After a positive outcome the app produced

Bad trigger points:

• On app launch
• After a settings change
• After an error or a loading state

The pre-screen pattern ("enjoying the app? yes/no") is explicitly prohibited. Do not build one. Do not use a third-party library that builds one for you.

---

Migration from Appirater

If your codebase uses Appirater, the migration is straightforward.

1. Remove the Appirater dependency from your Podfile, Package.swift, or manual file inclusion.
2. Remove the bridging header entry if Appirater was the only Objective-C dependency.
3. Find every call site: [Appirater appLaunched:YES], [Appirater userDidSignificantEvent:YES], and similar.
4. Replace significant-event call sites with SKStoreReviewController.requestReview(in:) or the SwiftUI requestReview environment action.
5. Remove launch-based triggers entirely. Do not replicate them with the native API.

For a codebase that used Appirater in a standard configuration, this is typically under an hour of work. The result: a smaller dependency surface, no bridging header, and full App Store compliance.

---

What About Other Third-Party Review Libraries?

Several libraries emerged as Appirater alternatives before Apple's native API matured. Most are in the same position — unmaintained, policy-adjacent at best, and unnecessary.

The pattern to avoid is any library that:

• Shows a custom pre-prompt before calling the system API
• Tracks sentiment and only calls the review API for "positive" responses
• Presents its own UI for the review flow

All of these violate guideline 5.6.1. The system API is the only compliant path. Any abstraction on top of it that alters user-facing behavior is a rejection risk.

---

Timing Strategy in 2026

The three-prompts-per-year limit means every call costs something. Wasting a prompt on a user who just launched the app for the first time is a poor use of that budget.

A practical approach for most apps:

• Track a "meaningful actions completed" counter in UserDefaults or your local store
• Trigger on the third or fifth completion of the core action
• Add a minimum days-since-install guard (14 days is a reasonable floor)
• Do not trigger during onboarding, error states, or first-run flows

This is not Appirater's launch-count logic repackaged. The trigger is tied to value delivery, not time or session count.

For apps with local-first architecture, this counter lives entirely on-device. No server call, no analytics event, no privacy surface. The state is private by default.

---

App Store Compliance in the Broader Context

Review prompts are one compliance surface — rarely the only one. Apps in health, fintech, or legal verticals face additional requirements around data handling, privacy manifests, and entitlement declarations that interact with how and when you surface system UI.

If you are building an iOS app from scratch or auditing an existing codebase, review prompt compliance belongs in the same pass as privacy nutrition labels, NSPrivacyAccessedAPITypes declarations, and App Store metadata accuracy.

The AI-Native iOS App Architecture Checklist at 3Nsofts covers 20 architecture and compliance points relevant to production iOS apps, including App Store submission requirements.

---

If Your Codebase Has Deeper Issues

Appirater in a 2026 codebase is usually a signal, not an isolated problem. It suggests the dependency audit has not run recently. Other Objective-C bridging headers, deprecated API calls, or policy-adjacent patterns may be present.

A structured audit surfaces these before they become rejection events. The codebase audit at 3Nsofts delivers 12–20 prioritized findings across architecture, AI readiness, and App Store compliance in 5 business days, starting from 1,440 euros. The findings are specific: named files, named APIs, named policy references. Not a general report.

Learn more at 3nsofts.com.

---

FAQs

Is Appirater still safe to use in 2026? No. Appirater uses UIAlertView, which is removed from current iOS SDKs, and its custom prompt mechanic conflicts with App Store Review Guideline 5.6.1. Using it risks App Store rejection and will likely cause build failures on current SDK targets.

What replaced Appirater? Apple's native SKStoreReviewController.requestReview(in:) for UIKit apps, and the requestReview environment action for SwiftUI apps. Both are part of the StoreKit framework and are the only compliant way to prompt for a review.

Can I show a pre-prompt before calling the native review API? No. Showing a custom "are you enjoying the app?" screen before calling the system API is explicitly prohibited by App Store Review Guideline 5.6.1. Apple can and does reject apps that use this pattern.

How many times can I prompt for a review per year? Apple throttles the native review prompt to a maximum of three times per 365-day period per app per device. You do not control whether the prompt appears on any given call — Apple's system manages the display logic.

How do I migrate from Appirater to the native API? Remove the Appirater dependency and bridging header entry. Replace userDidSignificantEvent: call sites with SKStoreReviewController.requestReview(in:) or the SwiftUI requestReview action. Remove any launch-based triggers. The migration is typically under an hour for a standard integration.

Does the native review API send any user data to Apple's servers? The system prompt is managed by iOS. The call itself does not transmit your app's user data. Your app's responsibility is to not pass user-identifiable context into the trigger logic.

What is a good trigger point for the native review prompt? Trigger after a user completes a core value action — not on launch, not after a timer. A counter tracking meaningful completed actions, stored locally in UserDefaults, with a minimum days-since-install guard (14 days is reasonable), is a compliant and effective pattern.