How Spirit Airlines Used a Force-Update API to Announce Their Shutdown

On Saturday, May 2, 2026, Spirit Airlines ceased all operations.

While the news covered the grounded flights and the sudden end of the budget carrier, I was curious about how a company handles its mobile app when the underlying business shuts down overnight.

It turns out they repurposed their existing mandatory app update screen.

The approach

Intercepting the traffic from the Spirit app on startup reveals an interesting workaround. The app pings a single initialization endpoint (mobile/init-prod) to fetch feature flags and check if the current app version is still supported.

Here is the payload published at 2:35 AM on the day of the shutdown:

{
  "name": "init-prod",
  "published": "20260502T02:35:19",
  "data": {
    "type": "xml",
    "init": {
      "supportedVersions": {
        "android": {
          "supported": [
            "8.10.2",
            "8.10.3"
          ],
          "latestVersion": "8.10.2",
          "storeUrl": "[https://spiritrestructuring.com](https://spiritrestructuring.com)"
        },
        "ios": {
          "supported": [
            "8.10.2",
            "8.10.3"
          ],
          "latestVersion": "8.10.2",
          "storeUrl": "[https://spiritrestructuring.com](https://spiritrestructuring.com)"
        },
        "upgradeMessage": "We regret to inform you that all Spirit flights have been cancelled, effective immediately. Guests with previously confirmed Spirit tickets should not go to the airport. While we are not able to help rebook your flight on another airline, we will automatically issue refunds for any flights purchased through Spirit with a credit or debit card to the original form of payment. For more information about the wind-down process, please visit spiritrestructuring.com.",
        "buttonText": "Learn more"
      }
    }
  }
}

The workaround

Looking at the supportedVersions block, the usual upgrade configuration was completely replaced. Instead of a generic message prompting users to download the latest version, the upgradeMessage string was swapped out for the entire flight cancellation notice.

Furthermore, the storeUrl values for both iOS and Android were modified. Rather than pointing to the App Store or Google Play, the URLs redirect directly to https://spiritrestructuring.com.

When the app parses this payload, it assumes the user’s current version is obsolete. This triggers a full-screen, unavoidable modal overlay. The button that typically says “Update” simply redirects all traffic to the restructuring website.

From a development perspective, this is a highly practical solution. Pushing a new, dedicated “service closed” UI state through App Store review takes time that isn’t available during an immediate wind-down. Using an existing remote-config tool solves the problem instantly across all installed clients.

Frozen state

What stands out the most is the rest of the payload. The API still returns the standard feature flags for a functioning airline.

• "enableSeatMapBundleUpsell": { "android": "true", "ios": "true" }
• "enableTravelGuardQuote": { "android": "true", "ios": "true" }
• "enableMyTripsBundleUpsellBanner": { "android": "true", "ios": "true" }

The flags are still set to true. The system is technically still configured to sell carry-on bags and travel insurance, but those checkout flows are entirely trapped behind the forced-update modal. It is a fascinating artifact of how software systems freeze in place, returning standard runtime configurations even as the physical operations they support come to a complete halt.