# ipaverse: a SwiftUI Mac app for downloading, re-signing and sideloading Apple apps

> ipaverse puts App Store package downloads, IPA re-signing and device installation behind a native macOS interface, with an optional security-testing toolkit gated behind an Evil Mode toggle. It is local-first, MIT-licensed at source level, and honest about FairPlay encryption.

**bahattinkoc/ipaverse** — Download, re-sign, and sideload iOS, iPadOS, macOS, tvOS & visionOS apps without Xcode or Terminal — plus an authorized security-testing toolkit (ATS bypass, Frida injection, static scan, FairPlay dump).

- Repository: https://github.com/bahattinkoc/ipaverse
- Stars: 671 · Forks: 45
- Language: Swift
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/bahattinkoc-ipaverse

## What ipaverse actually solves for iOS developers

Getting an IPA onto a device without Xcode normally means a chain of command-line tools: one utility to fetch the package, another to strip and re-apply a signature, a third to push it over USB. ipaverse collapses that chain into a single native SwiftUI application for macOS. The README describes it as a way to "Search and download App Store packages for iOS, iPadOS, macOS, tvOS, and visionOS" and then "Inspect, re-sign, and install compatible IPAs" from the same window.

The audience is narrow and specific. You need an Apple Silicon Mac running macOS 14.6 (Sonoma) or later. You need a certificate and provisioning profile if you intend to re-sign anything. This is a developer and researcher tool, not a consumer sideloading utility.

The README is unusually direct about the central constraint, and it is worth quoting because it defuses the most common misunderstanding: "App Store downloads normally remain FairPlay-encrypted, including free apps; downloading an app does not decrypt it." An original download will only launch with its associated Apple Account and license. Re-signing requires a self-built, DRM-free, or lawfully decrypted IPA. That sentence should be the first thing anyone reads before installing.

## How the download, re-sign and install pipeline fits together

The architecture is a local-first Mac app that talks to Apple services for acquisition and does everything else on disk. Authentication uses Apple's GrandSlam SRP-6a flow. According to the README, the raw password is used locally to produce the SRP proof and is not sent directly, and anisette headers are generated locally with macOS's AOSKit rather than through an external anisette service. That last detail matters: many tools in this space depend on a third-party anisette server, which means handing session material to someone else's machine. ipaverse does not.

Around that auth layer sits a library. Downloaded, imported, re-signed and decrypted copies live together with source tags, so you can tell an original App Store pull from something you re-signed an hour ago. Account management supports multiple Apple IDs and storefront switching, and version history is browsable.

Installation to a device has two paths. The primary one uses Xcode's `xcrun devicectl` through the CoreDevice framework. A bundled libimobiledevice fallback covers older devices over USB. Wi-Fi installation is supported, but the README is explicit that the device must be paired over USB first and Connect via network must be enabled in Xcode's Devices window. That is a real prerequisite, not a footnote, and it is the step people skip.

Credentials go to macOS Keychain. A password is retained for quick login only when Remember Me is enabled; non-secret profile metadata and preferences sit in UserDefaults. Certificates, provisioning profiles and IPA contents are not uploaded by ipaverse, and the project operates no authentication relay, analytics service or telemetry backend.

## Installing ipaverse with Homebrew and signing your first IPA

The README gives a single Homebrew command for the released build:

```bash
brew install --cask ipaverse
```

After it completes, ipaverse appears in your Applications folder. Launch it, sign in with an Apple Account, and the App Store search field becomes usable. Searching returns catalog entries across iOS, iPadOS, macOS, tvOS and visionOS. ipaverse can acquire licenses for free apps; paid apps must already be licensed to the active Apple Account.

If you would rather build from source, the README points at the Xcode project directly and recommends the latest stable Xcode:

```bash
git clone https://github.com/bahattinkoc/ipaverse.git
cd ipaverse
open ipaverse/ipaverse.xcodeproj
```

For re-signing, the workflow is import-then-sign. Import an IPA into the library, open it in the Re-sign window, and apply your own certificate and provisioning profile. The README notes that IPA properties and files can be edited in the same window, and that a standalone Resign window exists for signing without going through the full library view. Remember the constraint from the top of the README: the IPA you feed in has to be self-built, DRM-free or lawfully decrypted, or the signature will not produce something that launches.

For device installation, connect an iPhone or iPad over USB. ipaverse routes through `xcrun devicectl` on current setups and falls back to libimobiledevice for older hardware. To go wireless, pair over USB first and tick Connect via network in Xcode's Devices window before disconnecting.

## The security-testing toolkit and the Evil Mode guardrail

The second half of ipaverse is aimed at authorized iOS security testing, and the README frames it as such: bug bounty programs, contracted pentests, or apps you own. The feature list includes a Security Testing Mode toggle that disables App Transport Security for MITM proxying, Frida Gadget injection, a Dump Decrypted Copy tool for FairPlay apps, and a Reverse Engineer area with local static analysis, an Objective-C class browser, and live Frida tools for bypasses, method tracing, `NSURLSession` interception, UI hierarchy inspection and app-data inspection.

The gating mechanism is worth understanding because it is a design decision, not a checkbox. These features, along with Move to New Identity in the Re-sign window, stay disabled until Evil Mode is switched on from the main toolbar. The README calls this "a deliberate UI guardrail, not a substitute for authorization." That is the correct framing. A toggle cannot make an action lawful; it can only make it deliberate. Anyone treating Evil Mode as a permission slip has misread it.

Frida Gadget and `libfrida-core` are not bundled. They are downloaded from the repository's GitHub Releases on first use, verified against pinned file sizes and SHA-256 digests, and cached in Application Support. The digest check is the right call for a binary fetched at runtime, though it does mean the first use of any Frida-backed feature requires network access and depends on the release assets still being reachable. Dumping a decrypted copy requires a jailbroken USB device with `frida-server` running and the target app open, so that particular feature is unavailable on a stock device by design.

In the data tools, NSUserDefaults string and number values are editable. Keychain output is limited to item metadata, not secret values, and matching sandbox files can be listed and downloaded.

## Where ipaverse stops being the right tool

The largest limitation is the one Apple imposes rather than the one ipaverse chooses. Downloading an app does not decrypt it. If your goal is to run a paid App Store application on a device under a different account, ipaverse will not get you there, and no amount of re-signing will change that. The README says so plainly, and the honesty is a point in the project's favour.

The second constraint is platform. Apple Silicon only, macOS 14.6 or later. There is no Windows or Linux build, and the description of the project as a native SwiftUI app means one is not coming. If your workflow runs on a Windows machine with an iPhone attached, this is the wrong tool entirely.

The third is the jailbreak dependency for decryption. Dump Decrypted Copy needs a jailbroken device with `frida-server` running. On a current, unjailbroken iPhone that feature is simply unavailable, which narrows the security-testing side of the app considerably for anyone working on modern hardware.

Finally, the Frida tooling depends on runtime downloads from GitHub Releases. If you are testing in an air-gapped environment, or if the release assets move, the live tooling will not initialize. The app itself still works for download and re-signing, but the security-testing half degrades.

On licensing, the README is careful and worth repeating: the original source is MIT, but distributed builds contain or load third-party components under their own terms. Unicorn Engine 2.1.4 is statically linked for the App Store signing challenge and is distributed under GPL-2.0. The README states that the app as distributed should not be described as MIT-only. If you plan to redistribute a build, that distinction is the one to check, and a lawyer is the one to check it with.

## How ipaverse differs from command-line IPA tooling

The closest alternative in practice is a command-line IPA manipulation tool, of which several exist in this space. The difference is not capability so much as surface area and state. A CLI tool typically takes an IPA path, a certificate and a profile, and emits a signed IPA. It has no library, no account management, no storefront switching and no device installation step. It also has no UI guardrail for destructive or sensitive operations.

ipaverse keeps the whole lifecycle in one application: search, license, download, import, edit, re-sign, install, and optionally analyze. That is a genuine difference in approach. It means the tool holds state, which is why credentials go to Keychain and why the app contacts Apple directly rather than through a relay. It also means you are trusting a GUI application with your Apple Account session, which is a different trust decision than running a script you can read in full.

For a one-off re-sign of an IPA you already built, a CLI tool is lighter and easier to script into CI. For iterating on a device, switching accounts or storefronts, and keeping a tagged library of what you have downloaded and signed, the GUI approach removes a lot of manual bookkeeping. Neither is strictly better; they optimize for different things.

## Maintenance, releases and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-07. Release v2.4.0 landed the same day, following v2.3.0 on 2026-09-01. There is also a separate tag, frida-deps-17.17.0, dated 2026-09-02, which the release notes label as internal Frida runtime dependencies rather than an app release. That separation is sensible: it lets the Frida binaries update on their own cadence without implying a new app version.

The upgrade cost for users is low. Homebrew handles the cask, and the app's own library lives in Application Support and the macOS Keychain rather than in a project directory, so a version bump does not disturb downloaded or re-signed artifacts. The one thing to watch on upgrade is the pinned SHA-256 digests for Frida Gadget and `libfrida-core`. When those change with a new dependency tag, the previously cached binaries are re-verified against the new pins, which is the intended behaviour but does mean an upgrade can trigger a fresh download.

On licence, the split between MIT source and GPL-2.0-linked components is the practical implication. Using ipaverse locally is straightforward. Redistributing a build, or bundling it into a product, is where the third-party terms start to matter, and the README's own wording is that the distributed app should not be described as MIT-only.

## Conclusion

ipaverse is for Mac-based iOS developers and security researchers who want a GUI for downloading, re-signing and installing IPAs without dropping into Terminal, and who accept that re-signing needs a self-built, DRM-free or lawfully decrypted package. It is not for anyone looking to install paid App Store apps they have not licensed, and it is not a Windows or Linux tool. Before adopting it, confirm your Mac is Apple Silicon on macOS 14.6 or later, check that your signing certificate and provisioning profile are already in place, and read USAGE.md for the Frida prerequisites, which require a jailbroken USB device with frida-server running.

## FAQ

### What is the ipaverse app for?

ipaverse is a native macOS SwiftUI app that searches and downloads App Store packages for iOS, iPadOS, macOS, tvOS and visionOS, then lets you inspect, re-sign and install compatible IPAs on an iPhone or iPad. It also includes an authorized security-testing toolkit behind an Evil Mode toggle.

### How do I install ipaverse on macOS?

The README gives a Homebrew cask install, brew install --cask ipaverse, or you can clone the repository and open ipaverse/ipaverse.xcodeproj in Xcode to build from source. Either way you need an Apple Silicon Mac running macOS 14.6 or later.

### Does ipaverse decrypt App Store downloads?

No. The README states that App Store downloads normally remain FairPlay-encrypted, including free apps, and that downloading an app does not decrypt it. Re-signing requires a self-built, DRM-free or lawfully decrypted IPA.

### What is required to use the Frida tools in ipaverse?

Frida Gadget and libfrida-core are not bundled; they are downloaded from the repository's GitHub Releases on first use, checked against pinned file sizes and SHA-256 digests, and cached in Application Support. Dumping a decrypted copy additionally requires a jailbroken USB device with frida-server running and the target app open.

### Can ipaverse install an IPA over Wi-Fi?

Yes, but the README notes the device must be paired over USB first and Connect via network must be enabled in Xcode's Devices window. USB installation goes through xcrun devicectl, with a bundled libimobiledevice fallback for older devices.

## Sources

- [bahattinkoc/ipaverse on GitHub](https://github.com/bahattinkoc/ipaverse)
- [Issues](https://github.com/bahattinkoc/ipaverse/issues)
- [License: MIT](https://github.com/bahattinkoc/ipaverse/blob/main/LICENSE)
- [README](https://github.com/bahattinkoc/ipaverse/blob/main/README.md)
- [Releases](https://github.com/bahattinkoc/ipaverse/releases)

---

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