Thank you for supporting Signal and looking for ways to help. Please review this document, as the conventions here may be different from what you're used to even if you've contributed to other open source projects before.
If you've found and confirmed a security vulnerability in Signal, please report it via email to security@signal.org instead of opening a GitHub Issue. Please see SECURITY.md.
Please search both open and closed issues to make sure your bug report is not a duplicate.
The GitHub issue tracker is not used for feature requests, but new ideas can be submitted and discussed on the community forum. The purpose of this issue tracker is to track bugs in the iOS client. Bug reports should only be submitted for existing functionality that does not work as intended. Comments that are relevant and concise will help the developers solve issues more quickly. The "Beta Feedback" category on the community forum is the best place to share beta feedback.
You can reach support by sending an email to support@signal.org or by visiting the Signal Support Center where you can also search for existing troubleshooting articles and find answers to frequently asked questions. Please do not post support questions on the GitHub issue tracker.
Conversations about open bug reports belong here. However, all other discussions should take place on the community forum. You can use the community forum to discuss anything that is related to Signal or to hang out with your fellow users in the "Off Topic" category.
Every time someone comments on an issue, GitHub sends an email to hundreds of people. Bumping issues with a "+1" (or asking for updates) generates a lot of unnecessary email notifications and does not help anyone solve the issue any faster. Please be respectful of everyone's time and only comment when you have new information to add.
We read every issue, but some bugs or features take priority over others. If the issue is open, we're tracking it!
If you believe you've identified the root cause and fix for a bug, you may open a pull request.
Please note that we do not generally accept changes that add new features, involve visual changes, or otherwise change the user experience. We are a small team with a large roadmap of planned UX improvements, and each additional feature (developed internally or externally) adds an additional maintenance burden. The best changes fix bugs in our implementation of the existing user experience.
If you want to proceed with a pull request to fix a bug, please rigorously follow the Contributor Checklist in the pull request template, including:
- Make sure you sign the CLA.
- Make sure your contribution has been thoroughly tested, including testing existing behaviors to avoid regressions.
- Avoid changing existing UX.
- Make sure your commits are rebased onto the latest
mainbranch. - Make sure your commits are well-structured to make review easier.
There are many ways to contribute that don't involve the code at all!
- Help new users learn about Signal. Talk about it with your friends and family: get them to join you in using it!
- Join the beta and test out recently-released features first.
- Try and reproduce or find workarounds for open issues, and leave comments especially if you believe an open issue has been resolved.
- Test a given Signal-iOS behavior against Signal-Android and Signal-Desktop, to see if their behavior matches.
- Donate to Signal.
Signal is made for you. Thank you for your feedback and support. We're a small team, and it means the world to us.