XDAG iOS Wallet
This project is based on XDAG C implementation, and developed for iOS platform.
XDAG iOS Wallet is maintained by xdagger community developers, the official XDAG iOS Wallet.
Status
Building
- git clone sources
git clone git@github.com:XDagger/xdag-ios.git
- run pod install in project root directory.
pod install
- Open
.xcworkspace
URI scheme for QRCode
URI scheme for making xdag payments
xdagurn = "xdag:" xdagaddress [ "?" xdagparams ]
xdagaddress = *base64
xdagparams = xdagparam [ "&" xdagparams ]
Requirements
- iOS 8.0+ / macOS 10.10+
- xcode 9
- Swift 4.0
How to contribute
Want to contribute on XDAG iOS Wallet? Awesome! Here are the instructions to get you started. They are not perfect yet. Please let us know what feels wrong or incomplete.
This is an Open Source project and we welcome contributions of all sorts. There are many ways to help, from reporting issues, contributing code, and helping us improve our community.
Reporting Issues
If you find bugs, mistakes, inconsistencies in the XDAG Wallet project's code or documents, please let us know by filing an issue at the appropriate issue tracker (we use multiple repositories). No issue is too small.
The main issues for bug reporting are as follows:
Implementation Design
When considering design proposals for implementations, we are looking for:
- A description of the problem this design proposal solves
- Discussion of the tradeoffs involved
- Discussion of the proposed solution
Translations
This community moves very fast, and documentation swiftly gets out of date. For now, we are encouraging would-be translators to hold off from translating large repositories. If you would like to add a translation, please open an issue and ask the leads for a given repository before filing a PR, so that we do not waste efforts.
If anyone has any issues understanding the English documentation, please let us know! We are very sensitive to language issues, and do not want to turn anyone away from hacking because of their language.
Git
We use a simple git branching model:
master
must always workdevelop
is the branch for development- create feature-branches to merge into
develop
- all commits must pass testing so that git bisect is easy to run
Just stay current with develop
(rebase).
Commit messages
Commit messages must start with a short subject line, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
Code
Write clean code. Universally formatted code promotes ease of writing, reading, and maintenance.
Documentation
Update documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness, as well as a clean documentation build.
Pull Requests
Pull requests descriptions should be as clear as possible. Err on the side of overly specific and include a reference to all related issues. If the pull request is meant to close an issue please use the Github keyword conventions of closes, fixes, or resolves. If the pull request only completes part of an issue use the connects keywords. This helps our tools properly link issues to pull requests.
Code Review
We take code quality seriously; we must make sure the code remains correct. We do code review on all changesets. Discuss any comments, then make modifications and push additional commits to your feature branch. Be sure to post a comment after pushing. The new commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Merge Approval
We use Thank you for your efforts.
in comments on the code review to indicate acceptance. A change requires Thank you for your efforts.
from the maintainers of each component affected. If you know whom it may be, ping them.
Support Developers
Solar (XDAG 4f1Sp/UD55JX5+kQCevUCpyenaPwqmpC)