Siren: prompting iOS and tvOS users to update from inside the app

What Siren actually does for an iOS or tvOS app

Siren answers one question at launch: is the version running on this device older than the version currently in the App Store? The README describes the check plainly, and the result feeds either a language localized alert or a callback your own interface can use. That second path matters more than the first. Many teams already have an in-app message system, and Siren's value there is the comparison logic and the App Store lookup, not the stock alert.

The audience is narrow by design. Siren targets iOS 17+ and tvOS 17+, per the feature list, and it assumes distribution through the App Store, because that is where the version it compares against comes from. If you ship through TestFlight only, a web build, or an enterprise channel, the library has nothing to compare. It also assumes your versioning is sane: the README says Siren is built for Semantic Versioning and supports two-number (1.0), three-number (1.0.0) and four-number (1.0.0.0) forms. A build number scheme outside those shapes is a problem you should resolve before adopting anything.

The project's own note about its maintainer is worth reading before the feature list. The author states he stopped being a proactive iOS engineer in 2021 and will keep the library maintained for the community without proactively adding features. That is a clear, honest boundary. Treat Siren as a finished tool that receives compatibility work, not as a library whose roadmap will follow yours.

How the version check and the alert flow fit together

The mechanism is a launch-time comparison. Your app calls into Siren, Siren reads the installed version, queries the App Store for the current one, and decides whether the installed copy is behind. When it is, the outcome depends on the alert type you configured. The README's screenshots name three: one forces the update, one offers the update as a choice, and one lets the user skip the current update. All three are controlled by the `Rules.AlertType` enum.

That enum is the real configuration surface. The README calls the presentation rules highly customizable and points to the Example project's AppDelegate file as the place where every example lives, with instructions to uncomment the one you want to test. So the flow is: rules decide whether an alert appears at all, the alert type decides how much choice the user has, and the localization layer supplies the strings from the 40+ languages Siren ships.

There is also a device compatibility check in the feature list, which matters for tvOS and for older hardware where a newer App Store version may not run. The README does not spell out the exact behavior when a device is incompatible, so read the source or the Example project before relying on it. One design consequence is worth stating: the check happens when you call it, not on a schedule. Siren does not run in the background. If you call it at launch, users who never relaunch the app never see the prompt.

Installing Siren with Swift Package Manager and the first wail

The README documents Swift Package Manager as the installation path and shows a package dependency with a version requirement. Add it to your package dependencies, resolving from 7.0.0 or later:

.package(url: "https://github.com/ArtSabintsev/Siren.git", from: "7.0.0")

The README's installation table maps Swift versions to branches. Swift 5.9+ uses `master` and will continue to receive updates; the older branches for Swift 5.4, 5.0, 4.2, 4.1, 3.2, 3.1 and 2.3 are marked as no longer updated. If your toolchain is older than 5.9, you are on a frozen branch.

Integration is two lines. The README shows the same pair in either AppDelegate.swift or SceneDelegate.swift, and the call is `Siren.shared.wail()`. Here is the AppDelegate form as the README gives it:

import Siren
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    var window: UIWindow?

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        window?.makeKeyAndVisible()

        Siren.shared.wail()

        return true
    }
}

After that call, the expected result is a localized alert at launch when a newer App Store version exists, using the default rules. To see the other behaviors, open `Example/Example.xcodeproj` or `Example/Example.xcworkspace`. The README notes the sample app links the local Siren Swift package, so there is no `pod install` step, and the customization examples are commented out in the Example AppDelegate file for you to uncomment one at a time. For testing the prompt itself, the README has a Testing Siren Locally section and a Words of Caution section that you should read before pointing the library at a live App Store listing.

The forced-update alert is a product decision, not a default

The most consequential setting in Siren is not technical. Choosing the alert type that forces an update means a user who cannot or will not update is stuck at that screen. The README presents this as one of three screenshot variants, without ranking them, and the choice belongs to your release process. Teams that ship a breaking server API change sometimes want exactly this. Teams that ship a cosmetic update and force it anyway will collect one-star reviews.

The sharper limitation is the delivery channel. Siren reads the App Store version, so it cannot help an app distributed outside the App Store, and it cannot warn about a version that exists only in TestFlight. There is also a timing gap inherent to the App Store: the README's App Submission section covers App Store Review and Phased Releases, which tells you the author expects you to think about the window between submitting a build and it becoming the version users see. During a phased release, only a percentage of users can update at any moment, so a forced alert can push users toward a version the store will not hand them yet. The README does not document a flag that disables prompting during a phased rollout.

Maintenance is the other constraint. The last push to the repository was on 2026-08-16, and the most recent release listed is 7.0.3 on the same date, with 7.0.2 and 7.0.1 before it. The repository is not archived. But the maintainer's own note about not adding features means new capabilities are unlikely to arrive from upstream, and a behavior you need may have to live in your fork.

Siren against Sparkle and against rolling your own check

The closest thing to a sibling in this space is Sparkle, the update framework for macOS apps distributed outside the Mac App Store. The difference in approach is fundamental, not cosmetic. Sparkle ships an appcast feed and downloads and installs the update itself, because a non-App-Store macOS app has to. Siren never installs anything. It compares against the App Store listing and hands the user off to the store, because iOS and tvOS apps cannot self-update. If you are building for macOS outside the store, Siren does not apply, and if you are building for iOS, Sparkle's model is not available to you.

The other alternative is writing the check yourself. The App Store lookup endpoint is public, so a small amount of networking plus a version comparison gets you most of the way. What you would be rebuilding is the comparison tolerance for two, three and four number versions, the localized strings for 40+ languages, the device compatibility check, and the presentation rules behind `Rules.AlertType`. That is a real amount of surface for a feature most teams treat as incidental, which is the honest case for using Siren. The honest case against is that you inherit a library whose feature set is fixed and whose alert design you may want to replace entirely, in which case Siren's main contribution is the comparison and the localization files.

Licence and the cost of staying on Siren

Siren is MIT licensed, which is permissive and places few obligations on how you distribute the compiled app. The usual MIT requirement applies: keep the copyright notice and permission notice with the source distribution. This is not legal advice, and if your organization has a policy on third-party notices, route it through that process rather than treating this paragraph as a clearance.

The upgrade cost is where the maintenance note bites. Swift Package Manager resolves from 7.0.0, so patch releases within 7.x should be drop-in, and the release history shows 7.0.1, 7.0.2 and 7.0.3 clustered in the months before the last push. The risk is a future Swift or iOS release that breaks compilation. Because the maintainer has said he is maintaining rather than extending the library, compatibility fixes are the realistic expectation. Budget for the possibility that you pin a version and stay there. The README's branch table already shows this pattern for older Swift versions, where seven branches are marked as no longer receiving updates. Your project will eventually join that list if your toolchain moves faster than the library does.

Editorial conclusion

Siren fits App Store distributed iOS or tvOS apps that want a localized update prompt without building one, and whose versioning follows two, three or four number schemes. It is the wrong tool for apps distributed outside the App Store, for anyone who needs release cadence guarantees, and for teams unwilling to test the alert rules against real users. Verify first that your version string parses under Siren's Semantic Versioning support, that your language is among the 40+ localizations, and that the alert type you pick matches your review strategy, since a forced update alert blocks the user until they upgrade.

Frequently asked questions

Official sources

1. ArtSabintsev/Siren on GitHub
2. License: MIT
3. Project website
4. README
5. Releases