Unstoppable Wallet iOS: a non-custodial multi-wallet written in Swift

The problem it takes on: custody and the single chain silo

Most wallet apps in the store ask you to hand your keys to a company that keeps them on a server. The alternative is a self-custodied app, and the second alternative is the app that only supports one chain, so holding a token from a newer network means switching tools. Unstoppable Wallet for iOS targets the gap between those two positions. The project describes itself as a non-custodial multi-wallet for Bitcoin, Ethereum, Binance Smart Chain, Avalanche, Solana and other blockchains, with storage for both cryptocurrencies and NFTs.

The audience is therefore a user who holds assets across several networks and does not want to hold them on a centrally managed account, and an engineer who wants to see how such an app is put together. The project also markets a decentralized exchange, meaning swaps are described as on-chain rather than as a broker quoting a price, and it claims analytics for cryptocurrency and NFT markets across thousands of tokens.

Two architectural claims are worth separating from the marketing. The first is that there are no centrally managed servers behind the wallet, so the app is peer-to-peer and is not routed through a company that could be pressured or blocked. The second is the non-custodial storage itself, where only the holder of the keys can move the funds. Those two claims are what make the repository interesting to read even for someone who will never ship an iOS app.

How the app is put together, from the repository layout

The repository is a Swift project rather than a script collection, so there is no single command that produces a working wallet. The top-level entries show the shape of the work: an application directory named Unstoppable/, a packages/ directory for the modular code, a workspace file named Wallet.xcworkspace, a docs/ directory, a fastlane/ directory for release automation, and tool configuration files such as .swift-version, .swiftformat, .semgrep.yml, .coderabbit.yaml and a Gemfile with a Gemfile.lock.

That structure is the architectural answer to the multi-chain requirement. Rather than one target absorbing five blockchain stacks, the layout suggests the chain-specific pieces sit in the packages/ directory and the application layer in Unstoppable/, joined by the workspace file. A .swift-version pin and a .swiftformat config indicate the project is meant to be opened and built with a defined toolchain, and the presence of a .semgrep.yml points to static analysis being part of the workflow.

The topic list on the repository matches the chain claim and adds two further signals: hd-wallets, which points to hierarchical deterministic key derivation, and the crypto-sdk, defi-sdk and ethereum-sdk labels, which describe libraries rather than a single application. The documentation does not describe the internal data flow in any detail, so how a transaction is built and signed, or how a swap route is selected, is not stated. The layout tells you the code is split, not how the pieces talk to each other.

Cloning the project and supplying the missing Config.xcconfig

The installation section is three steps, and the middle one is the one that trips people up. The first step is a plain clone of the repository:

git clone [email protected]:horizontalsystems/unstoppable-wallet-ios.git

That command uses SSH, so a machine without a registered key on GitHub will fail here, and the README offers no HTTPS fallback. The second step is a configuration requirement rather than a command: the build expects a file named Config.xcconfig to exist in a specific location inside the application directory.

Unstoppable/Unstoppable/Configuration

The file itself is not in the tree, so a fresh clone cannot build until you create it. The project says you can start from the sample configuration kept in a template file:

Config.template.xcconfig

In practice the template has to be copied over the real name inside that Configuration directory before the Xcode build will resolve its settings, and what the template contains, which keys it defines and which values a release build needs are not described anywhere in the README. The third and final step is simply to open the project in Xcode and run it.

The project also ships fastlane/ and a Gemfile with a Gemfile.lock, which is the usual shape for iOS release automation, and RELEASE.md at the top level. The documentation does not document how a release is cut from that tooling, and it does not document the App Store submission path, so a first build is the only step a reader can reproduce end to end.

The build depends on a configuration file the repository does not ship

This is worth separating from the setup steps, because it changes what the repository is for. Most open source application code can be cloned and run with a documented set of commands. Here, the clone is not enough: the build requires a file that is intentionally absent, and the only guidance is one sentence telling you that a template version exists.

The gap is normal in the iOS ecosystem, where signing identifiers, bundle identifiers and API endpoints are per-developer and often per-environment. It is still a real constraint for anyone assessing the project. You cannot check out the default branch and produce a running app without making a judgement call about what belongs in Config.xcconfig, and there is no documented list of the keys that file is expected to hold. A developer who needs the exact key names will have to read the Xcode project settings and the code that reads the configuration.

The same pattern shows up with the distribution channel. The project points to an App Store listing for download, so the wallet reaches users through a curated mobile storefront rather than as a self-hosted binary. For a project whose stated values include censorship resistance and the absence of centrally managed servers, a distribution step that depends on a platform gatekeeper is a tension worth naming rather than skipping. It does not change the on-chain custody model, but it does change who can install the app and on which hardware.

Release numbering moved from 0.50 to 0.52 in two months

The published releases are 0.50 on 2026-08-25, 0.51 on 2026-09-09 and 0.52 on 2026-10-08. The version stays below 1.0 across all three, which usually signals an app that is still changing shape rather than a stable library contract. The repository is not archived, and the last push was on 2026-10-19, so the code in the tree is closer to the 0.52 tag than to anything older.

The pace of those three tags is uneven, and it is better to state the dates than to draw a schedule from them. Between 0.50 and 0.51 there is a gap of just over two weeks, and between 0.51 and 0.52 a little under a month. The tags are numbered with a two-part scheme that starts at 0 rather than 1, and the release notes in the repository are not reproduced in the README, so what changed in any of them cannot be told from what is available here.

For an engineer judging adoption, the practical point is narrow. The app store version and the repository version are separate artifacts, and nothing in the README states that the published app corresponds to the latest tag. The .swift-version pin and the .swiftformat configuration are the more useful anchors for a build, because they are the files that decide which compiler and which formatting rules the code expects.

Where the non-custodial promise runs out of documentation

The core promise is that only the holder of the keys controls the money. The documentation around that promise is where the project is thinnest, and it is thinnest in the place a non-custodial wallet has to be most careful.

There is no documented flow for backing up a recovery phrase, for what happens when a device is lost, or for how a user verifies that a displayed seed matches what the app generated. The documentation never mentions multi-device backup, address validation, or how the app derives addresses, beyond the hd-wallets topic tag implying hierarchical derivation. For a wallet that advertises a decentralized exchange, there is also no explanation of where swap liquidity comes from, whether a route is quoted from an on-chain source, or what happens when a transaction fails midway and a swap is left half settled.

The MIT licence also deserves a plain statement without legal advice. The licence permits use, modification and redistribution, including in a closed product, and it requires the copyright notice to be kept. It does not create any obligation on a downstream party to keep the wallet non-custodial, keep the app peer-to-peer, or publish source changes, so a fork is legally unconstrained by the project's stated values. Anyone embedding the packages/ code in a product of their own should read the LICENSE file directly and decide for themselves what obligations they take on.

How this compares with a plain single-chain wallet

The comparison that matters for this project is not against another vendor but against the alternative shape of application. A single-chain wallet application is small, has a narrow attack surface, and usually has a straightforward restore path, because the app only has to derive addresses for one derivation path and one network format. Unstoppable Wallet for iOS takes on five named networks and others besides, and each added chain means another address encoding, another transaction format and another signing convention to get right inside a single application.

The alternative approach is the opposite one, where the app is a thin client over a platform that already speaks many chains, or where the chain logic lives in separate modular packages that a host app composes. The packages/ directory in this repository points toward that second approach, but the README does not describe the package boundaries, so whether the chain implementations are genuinely reusable or tightly coupled to the app cannot be confirmed from what is published.

That difference has a cost for adopters. A multi-chain wallet in one codebase has more surface to test and more places where a key handling mistake can hide. An integrator who cares more about shipping a Bitcoin experience correctly on a deadline will find less of use here, while a team that genuinely needs several chains in one key hierarchy will find very few open source alternatives written in Swift.

Editorial conclusion

Teams that need a readable Swift reference for a multi-chain, non-custodial wallet can use this repository as one, provided they accept that only the iOS target is documented and that the Config.xcconfig file is not shared in the tree. A wallet team shipping to multiple platforms, or anyone who needs a documented key recovery and backup flow, should treat the gaps in this repository as something to solve themselves before building on it.

Frequently asked questions

Official sources

1. horizontalsystems/unstoppable-wallet-ios on GitHub
2. License: MIT
3. Project website
4. README
5. Releases