ipaverse: a SwiftUI front end for App Store downloads, re-signing and sideloading
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).
At a glance
- What is it?
- ipaverse wraps App Store catalog search, IPA re-signing, USB and Wi-Fi device install, and an authorized security-testing toolkit in a native macOS app. The interesting part is not the download button, it is the local-first credential handling and the deliberately gated Evil Mode.
- Who is it for?
- Adopt ipaverse if you are on an Apple Silicon Mac running macOS 14.6 or later and your workflow is importing IPAs you already have the right to modify, re-signing them with your own certificate, and pushing them to a paired iPhone or iPad. Do not adopt it if you expected the download feature to produce a runnable, unencrypted app, because FairPlay means a fresh App Store download stays bound to the Apple Account that licensed it.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ipaverse fills between Apple Configurator and a shell script
Getting an IPA onto a device normally means either living inside Xcode, or assembling a chain of command-line tools for extraction, signing, and installation. ipaverse puts that chain behind a SwiftUI window on macOS. The README describes the app as a way to search and download App Store packages for iOS, iPadOS, macOS, tvOS and visionOS, then inspect, re-sign and install compatible IPAs from the same Mac. The audience is narrow and specific: iOS developers who need to test a build on hardware without a full Xcode session, and security researchers who already have authorization to examine a target app. It is not aimed at end users who want free paid apps. The README states plainly that downloading an app does not decrypt it, that App Store downloads remain FairPlay-encrypted even when free, and that an original download may only launch with its associated Apple Account and license. Re-signing requires a self-built, DRM-free, or lawfully decrypted IPA. That constraint shapes everything else in the tool.
How the authentication and download path actually works
The security section of the README is more informative than most projects of this type, and it is the part worth reading closely. Authentication uses Apple's GrandSlam SRP-6a flow. The raw password is used locally to produce the SRP proof and is not sent directly. Anisette headers are generated locally through macOS's AOSKit, with no external anisette service in the loop. That last detail matters, because a number of sideloading tools route anisette generation through a third-party server, which means someone else sees a device-identifying blob. ipaverse does not. Account and session credentials go into the macOS Keychain. A password is retained for quick login only when Remember Me is enabled, and non-secret profile metadata and preferences sit in UserDefaults. App Store search, license acquisition, and download requests talk directly to Apple services, as does artwork loading and the initial SAP asset fetch. The README states there is no project-operated authentication relay, analytics service, or telemetry backend. IPA extraction, patching, signing, static analysis, and report generation all run locally, and certificates, provisioning profiles, and IPA contents are not uploaded. GitHub is contacted only for an explicit update check and for on-demand Frida downloads. Multiple Apple ID accounts, storefront switching, and version history browsing are supported, with the caveat that ipaverse can acquire licenses for free apps while paid apps must already be licensed to the active account.
Installing from source, and the device install path
The README gives two installation routes. The first is a Homebrew cask: brew install --cask ipaverse. The second builds from source: git clone https://github.com/bahattinkoc/ipaverse.git, then cd ipaverse, then open ipaverse/ipaverse.xcodeproj. Building from source requires Xcode, with the latest stable release recommended. The hardware floor is an Apple Silicon Mac (arm64) running macOS 14.6 Sonoma or later, which rules out Intel Macs entirely. Device installation targets iPhone and iPad. The CoreDevice path uses Xcode's xcrun devicectl, and a bundled libimobiledevice fallback covers older devices over USB. Wi-Fi installation has a prerequisite that trips people up: the device must be paired over USB first, and Connect via network must be enabled in Xcode's Devices window. There is no separate pairing UI in ipaverse for that step, so Xcode still has to be installed and opened at least once to set it up. The library keeps downloaded, imported, re-signed, and decrypted copies in one place with source tags, and re-signing can be done inline or from a standalone Resign window.
Evil Mode is a guardrail, not an authorization check
The security-testing features are gated behind a toggle called Evil Mode, switched on from the main toolbar. Until it is on, Security Testing Mode, Frida Gadget injection, Dump Decrypted Copy, the Reverse Engineer tools, and Move to New Identity in the Re-sign window all stay disabled. The README is explicit that this is a deliberate UI guardrail and not a substitute for authorization. That framing is honest, and it is also the correct one, because a toggle cannot verify that you have permission to test a given app. What the toolkit contains: Security Testing Mode disables App Transport Security to allow MITM proxying, Frida Gadget injection works with the live Frida tools, and Dump Decrypted Copy targets FairPlay apps but requires a jailbroken USB device with frida-server running and the target app open. Reverse Engineer covers local static analysis, an Objective-C class browser, and live tools for bypasses, method tracing, NSURLSession interception, UI hierarchy inspection, and app-data inspection. In the data tools, NSUserDefaults string and number values are editable, Keychain output is limited to item metadata, and matching sandbox files can be listed and downloaded. Frida Gadget and libfrida-core are not bundled. They are fetched from the repository's GitHub Releases on first use, checked against pinned file sizes and SHA-256 digests, then cached in Application Support. The README carries a warning that these tools are for bug bounty programs, contracted pentests, or apps you own, and that misuse may violate Apple's terms of service or the law.
FairPlay is the wall, and the README does not pretend otherwise
The single largest limitation is stated in the first blockquote of the README, and it is worth repeating because it is the most common misunderstanding about tools in this category. App Store downloads remain FairPlay-encrypted, including free apps. Downloading an app does not decrypt it. An original download may only launch with its associated Apple Account and license. So the download feature is not a path to a runnable modified app. It is a path to a licensed copy that works for the account that licensed it, plus a library entry you can inspect. To produce something you can re-sign and install under a different identity, you need a self-built IPA, a DRM-free IPA, or a lawfully decrypted one. The Dump Decrypted Copy tool exists for that last case, but it requires a jailbroken device with frida-server active, which is a materially higher setup cost than the rest of the app. A second limitation is platform scope: the app is macOS-only and Apple Silicon-only, so a Windows or Linux researcher gets nothing here. A third is that Wi-Fi install depends on Xcode having done the initial pairing. If you want a fully self-contained sideloading setup with no Xcode installation, ipaverse is the wrong tool.
Where ipaverse sits against a plain codesign and devicectl script
The obvious alternative is not a competing GUI. It is the shell: unzip the IPA, swap in your embedded.mobileprovision and signing identity, run codesign over the frameworks and the app bundle, then push with xcrun devicectl. That approach has real advantages. It is scriptable, it runs in CI, it produces a log you can diff, and it has no UI state to reason about. ipaverse trades that away for discoverability: version history browsing, storefront switching, multi-account management, source tags on library entries, an Objective-C class browser, and a Resign window that shows you what is being changed. The difference in approach is that ipaverse holds persistent state (accounts in Keychain, a library on disk, cached Frida binaries in Application Support) while a shell script holds none. For a one-off re-sign on a machine you control, the script is faster to reason about. For repeated work across several accounts and storefronts, or for a researcher who wants static analysis and live instrumentation in the same window as the signing step, the app earns its footprint. The honest split is that ipaverse is a workstation tool, not a pipeline component. Nothing in the README describes a headless mode or a CLI.
Licence, third-party components, and what upgrades cost you
The original ipaverse source in the repository is MIT. The README is careful to add that distributed builds also contain or load third-party components whose own terms continue to apply, and that the app as distributed should not be described as MIT-only. That distinction matters if you plan to redistribute a build. The named example is Unicorn Engine 2.1.4, statically linked for the App Store signing challenge and distributed under GPL-2.0. A statically linked GPL-2.0 component inside a distributed binary is a different licensing situation from MIT source, and the README points to the vendor license file under ipaverse/Vendor/ for the rest of the list. This is not legal advice; if you intend to ship a modified build, read those files. On maintenance: the release cadence visible in the repository is roughly a minor version every few weeks, with v2.4.0 on 2026-09-07 following v2.3.0 on 2026-09-01. There is also a separate release stream for Frida runtime dependencies, tagged frida-deps-17.17.0 and marked in the release list as internal and not an app release. That stream is a maintenance signal in itself: because Frida Gadget and libfrida-core are downloaded on demand and verified against pinned sizes and SHA-256 digests, every Frida bump requires the project to republish those pinned values. If the project stalls, Frida injection breaks even though the rest of the app keeps working. Budget for that: the download path, re-signing, and device install do not depend on the Frida stream, but the live instrumentation tools do.
Editorial conclusion
Adopt ipaverse if you are on an Apple Silicon Mac running macOS 14.6 or later and your workflow is importing IPAs you already have the right to modify, re-signing them with your own certificate, and pushing them to a paired iPhone or iPad. Do not adopt it if you expected the download feature to produce a runnable, unencrypted app, because FairPlay means a fresh App Store download stays bound to the Apple Account that licensed it. Before relying on it, verify three things yourself: that your Mac meets the arm64 and macOS 14.6 floor, that your target device appears under xcrun devicectl or the bundled libimobiledevice fallback, and that you have read the license section, since distributed builds carry GPL-2.0 Unicorn Engine alongside the MIT source.
Community notes