edge-react-gui is a multi-currency wallet app, not a component library

This is the wallet itself, on the develop branch

Edge is a multi-currency mobile wallet for Bitcoin, Ethereum, Monero, Dash, Litecoin, Bitcoin Cash, Ripple/XRP, Polkadot, Tron, Solana, Stellar, Fantom, Algorand, Optimism, Zcash, Pirate Chain, and many others.

That list is the feature summary. What the repository actually contains is the complete application, not a reusable piece of it. The package name is edge-react-gui, the description is Edge Wallet React GUI, and the version in the package manifest is 4.52.0. The homepage is edge.app, and the author is Edge, Inc.

The project lists itself as simple, secure, private, decentralized, multi-currency, cross-platform, mobile first and open source. Those are marketing words, but the last three are structural facts you can check. Cross-platform is React Native for both iOS and Android. Decentralized is why there are sixteen chains in that list. Open source is what this repository is.

The default branch is develop, and the getting started section says to check out the develop branch. The build badge points at a Travis build for the develop branch. The recent releases are frequent and small: v4.51.3 on 2026-10-01, v4.51.2 on 2026-09-30 and v4.51.1 on 2026-09-24, three patch releases in eight days. The last push to the repository was on 2026-10-22.

So the release rhythm is continuous, and the branch layout is the usual one where develop is where work lands and releases are cut from it.

The API key is bundled, and it is deliberately rate limited

The single most important operational detail for anyone building this is the API key situation, and the README is unusually blunt about it.

A public API key is built into the edge-core-js which can be used to build and test the Edge app. This key is severely rate limited and should not be used for production. For production use, get an API key by emailing [email protected].

So the repository is buildable out of the box with no account, which is what makes it possible to read the code, run the app and contribute to it. What it is not is a way to run a production deployment of your own without talking to the company.

The key is set in keys.json. The npm run prepare script creates config.json, which is non-secret, and keys.json, which is secret, with defaults. You set EDGE_API_KEY in keys.json to the key you received from Edge, and to use the public API key you leave EDGE_API_KEY blank.

There is a migration path for older checkouts. If you still have a legacy env.json, run npm run split-env-json once to produce the two files. That is a small thing but it is the kind of detail that tells you the project has been around long enough to have accumulated a second generation of config handling.

The key split is also a reasonable design. config.json is checked in, keys.json is not, and the gitignore at the repository root handles the rest.

The build is npm for JavaScript, gradle for Android, Xcode for iOS

Getting the app running takes a React Native toolchain, and the steps are laid out in order.

First, prepare the React Native development tools. The README points at the React Native documentation for detailed instructions on how to prepare your computer for React Native development, and says to follow the instructions in the React Native CLI Quickstart for your specific platform. On a Mac you follow both the iOS and the Android target instructions, and elsewhere you only need the Android target instructions. That last line is a plain statement of fact about the tooling: iOS builds need a Mac.

Then, check out the develop branch and install node_modules. The project uses npm to manage JavaScript dependencies, and npm ships with Node:

    cd edge-react-gui
    npm ci
    npm run prepare

npm ci rather than npm install, because there is a package-lock.json in the tree and the lockfile is the reproducible path.

Then run the bundler:

    npm start

And this bundler process needs to run in the background, so you run it in its own terminal window.

For iOS, run npm run prepare.ios to generate the CocoaPods files, and you need to do this after the first install and any time Xcode produces a sandbox not in sync with the Podfile.lock error. Then open edge-react-gui/ios/edge.xcworkspace in Xcode, choose a target device or simulator and tap Play.

For Android, npm run android builds, installs and starts the app on a simulator or a physical phone with USB debugging. For an APK instead, the gradle path is:

    cd android
    ./gradlew assembleDebug

And the resulting APK is in ./app/build/outputs/apk/debug/app-debug.apk, to be copied to a simulator like Genymotion or to a real device.

The release builds follow the same shape, with assembleRelease for Android producing ./app/build/outputs/apk/release/app-release.apk, and on iOS you open the same workspace in Xcode and switch the Build Configuration to Release, uncheck Debug Executable, and hit Play.

The deploy script handles signing, but only on macOS

The repository includes several utility scripts that can be used in a CI/CD environment to build and deploy a release version of the app. The included Jenkinsfile utilizes all the scripts, but you are free to use them in your own CI environment.

The deploy.ts script automates building, signing and deploying release builds. What it provides is specific: auto sign Android APK with Android keystore files, auto sign iOS IPA with provisioning profiles, build the release version of iOS and Android, and upload the iOS IPA and Android APK files to AppCenter for developer testing.

The version file is handled separately. You set BUILD_REPO_URL to the URL of an empty Git repo that will hold a version file which is auto updated to increment the version and build number, then run npm run gitVersionFile to update a local release-version.json file, and npm run updateVersion to update the project files based on the version in it.

Running the deploy is two commands:

npm run deploy edge ios master
npm run deploy edge android master

The prerequisites list is where the friction is. Set the env var KEYCHAIN_PASSWORD to the keychain password of the current user. Copy the deploy-config.sample.json to deploy-config.json and edit the parameters, and you will need a HockeyApp account to get ids and keys. Download a copy of the Google Bundle tool. Set the bundleToolPath in deploy-config.json to the path to the bundle tool .jar file. Put any Android keystore files into edge-react-gui/keystores/. If using Firebase, put your account's google-services.json and GoogleService-Info.plist into edge-react-gui/.

And the deployment section is headed Deploying (MacOS Only), which is the constraint on all of it.

Fastlane handles certificate renewal so a year-old certificate does not break the build

The iOS signing story is the part of this repository that has the most specific engineering in it, and it is worth understanding before you try to ship anything.

The repo uses Fastlane to automate iOS code signing. The deploy script uses fastlane match to install the signing certificates and provisioning profiles, and to renew them automatically when they expire.

There is a version floor with a specific reason. Fastlane must be version 2.235.0 or newer, installed or upgraded with brew install fastlane. Older versions ignore the --skip_confirmation flag during match nuke, which blocks the automatic certificate renewal on an interactive prompt.

Authentication uses an App Store Connect API key rather than an Apple ID. You place the key JSON at fastlane.json in the repo root, and then set four environment variables: BUILD_REPO_URL for the Git repo used to store encrypted provisioning keys, which is shared with the gitVersionFile.ts script, GITHUB_SSH_KEY as an optional SSH key file when accessing BUILD_REPO_URL, MATCH_KEYCHAIN_PASSWORD to open the current user's keychain, and MATCH_PASSWORD to encrypt profile information before it is saved to BUILD_REPO_URL.

The renewal mechanism handles the failure mode that would otherwise stop a release. Apple signing certificates expire once a year. When fastlane match fails because a certificate is no longer valid, the deploy script automatically nukes that certificate type, revoking it on the Apple Developer Portal and wiping it from BUILD_REPO_URL, and then re-runs match to generate a fresh certificate and provisioning profiles.

So the pipeline is built around the assumption that signing material has a finite life. That is a small design decision with a large effect on whether a release pipeline keeps working unattended.

The repository is a full application, with localization and testing infrastructure

The top-level entry list is a good map of what a wallet app needs beyond the wallet itself.

There is android/ and ios/ for the native projects, src/ for the TypeScript application code, native/ for native modules, and index.ts at the root as the entry point. The build configuration is the standard React Native set: babel.config.js, metro.config.js, react-native.config.js, tsconfig.json, and rollup.config.mjs for bundling the scripts.

Localization is first class. There is a localization/ directory and a crowdin.yml, so translations are managed through Crowdin rather than edited in place. That is the normal arrangement for an app with this many supported languages, and it explains why the README does not describe a manual translation workflow.

Testing spans several layers. jest.config.js and jestSetup.js are for unit tests, there is a maestro/ directory with a maestro.sh script for end-to-end flows on device, and a maestro-disabled/ directory alongside it, which suggests flows that are currently switched off. The .husky/ directory holds the git hooks, and .prettierrc.json and eslint.config.mjs are the formatting and lint configuration.

There are also scripts that hint at the complexity of shipping crypto code. copy-bitcoin.sh and a deployPatches/ directory, plus a patches/ directory, which together suggest the project carries local modifications to dependencies and needs them applied consistently across machines. The AGENTS.md file at the root is a note for coding agents working in the repository.

The CHANGELOG.md and the frequency of the patch releases tell you the application is under active development, with releases cut often enough that the changelog is probably the fastest way to understand what changed.

Where edge-react-gui is the wrong tool

The first wrong-tool case is a team looking for a wallet user interface component. This is the whole application, including its navigation, its currency list, its transaction handling and its release pipeline. There is no published component API here to import, so if you want a send-and-receive screen in your own product, this repository is the wrong shape entirely.

The second wrong-tool case is a team that wants to support a chain Edge does not support. The sixteen listed chains are the result of a lot of work per chain, and the architecture is the thing to look at before assuming a new one is cheap. The repository mentions edge-core-js as the layer that holds the public API key, which suggests the currency implementations live in a separate core library rather than in this GUI, so adding a chain may or may not require touching this repository at all.

The third wrong-tool case is a build environment that is not a Mac and needs iOS output. The deployment section is explicitly macOS only, iOS builds need Xcode and CocoaPods, and the Fastlane and keychain steps assume macOS tooling. A Linux CI runner can produce an Android APK with gradle, but not an iOS IPA.

For the alternative approach, the difference in approach is between an open wallet application and a closed or semi-closed one. A commercial wallet with a different architecture will differ in where the key material lives, how transactions are built and broadcast, and how the seed phrase is handled, and none of those choices are visible from the outside. The difference in approach for this repository specifically is that the code is available for inspection, so you can read how it works rather than trusting a description of it.

The other alternative is to use a different open wallet implementation with a different currency list and a different release process, and for many teams the deciding factor will be which chains and which platforms it covers rather than anything about the code style.

A custom licence file, and a company behind the code

The licence is not a standard identifier. The package manifest records it as SEE LICENSE IN LICENSE, and the repository root has a LICENSE file. The GitHub metadata for the repository lists the licence as BSD-3-Clause, which is a discrepancy worth resolving before you rely on either, since the two point at different documents.

This is a documentation point rather than legal advice, and the practical reason to read the LICENSE file is that the manifest points you at it rather than embedding the terms. If you intend to reuse the code in a product, take the file as the source of truth and check what it says about the trademarks, because a wallet project usually reserves the right to the name and the icon.

The project is backed by a company rather than a foundation. The author is Edge, Inc., and the contributors list names eight individuals with edge.app addresses. The repository is under the EdgeApp organisation, and the homepage is edge.app.

The build and release tooling reflects that commercial structure. There is a Jenkinsfile for CI, a deploy script that uploads to AppCenter for developer testing, HockeyApp account requirements for ids and keys, a Firebase configuration path, and an App Store Connect API key rather than individual Apple ID credentials. There is also a deploy-config.sample.json, which is the pattern of a product with a release engineering function rather than a hobby project.

One more thing to know before you build: the docs/ directory holds the images and documentation, including a readme-cover-photo.png, and the app.json file at the root is the React Native application manifest.

Editorial conclusion

edge-react-gui suits a developer who wants to read or fork the Edge wallet application, or to contribute to a cross-platform multi-chain wallet, and who can set up the React Native toolchain for both iOS and Android. It does not suit someone who wants a wallet UI component to drop into their own app, because this repository is the whole product. Before building, read the API key section carefully, since the bundled key is severely rate limited, and expect the iOS path to need a Mac with Xcode and CocoaPods.

Frequently asked questions

Official sources

1. EdgeApp/edge-react-gui on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases