Paid Tweak Guidelines (Work-in-Progress)

Asking for payment is equivalent to stating "I have made something truly worth paying for". For example, it is groundbreaking or an incredibly useful addition to iOS. In most cases, consider not asking for payment and look towards open-sourcing your work. The 'soul' of making tweaks is to build something for the fun of it, not to run a business.

If you decide to release a paid tweak, it is not a matter of adding a price to your work and putting it on a default repository. You need to ensure the price is justified, and that the tweak matches customer expectations. After that, you also need to provide support and updates when necessary. To be clear: accepting payments means you become liable for handling a lot more than just writing code.

The following guidelines should be used to check that you are within customer expectations. Please note that individual repositories may also add their own expectations if you decide to release through them (e.g. Packix)

General

You SHOULD NOT ask for for payment on something that can be built within a day. A paid tweak should require a significant degree of reverse engineering, or implementation work.
You SHOULD engage with your customers. After all, you're offering a product someone has bought, and you should be open to their feedback.
You MUST ensure that your work is thoroughly tested on multiple devices and iOS versions before initial release. A good place to find willing beta testers is on the /r/jailbreak subreddit.
Release day issues SHOULD be resolved quickly. There is nothing more fustrating for a customer than buying something, and it doesn't work.

Support

Supporting your customers is incredibly important; selling software means that are you are obliged to help users with it. This can be done by providing an email address for users to contact you directly with, responding to questions on Reddit, following up bug reports on Twitter, and so forth.

You SHOULD provide at least 2 years of support.
You SHOULD fix bugs found on the iOS version the tweak is advertised for during the time support is available. If possible, aim to support the next 2 major iOS updates with updates. (Of course, the nature of relying on private APIs doesn't always make this possible.)
If you decide to request payment for a major update that is released as a new package, you SHOULD give a discount to users of the existing version.
You SHOULD be responsive to user queries and feedback. Even if its just a simple "thanks, I know about this", it helps the customer feel listened to.
Refunds SHOULD be offered for a reasonable timeframe after purchase. As a tweak author, you do have the right to deny refunds that appear fraudulent. Consider using a policy where refunds are sent back to the user 5 days after approval; some repositories offer this for you.
You SHOULD provide a public bug reporting system to help track issues. This not only helps you, but also users to find workarounds for common issues before they are fixed. (GitHub issues is useful for this!)
When ending support for a tweak, you MUST make it free to use. In addition, any user who paid for the tweak just before this happens SHOULD be offered a refund if they ask. This is to avoid a situation where a user pays for something that then becomes free days or hours later.

DRM (aka: anti-piracy)

Preface: at best, anti-piracy just increases the time taken before your tweak is 'cracked'. You will never have an 'uncrackable' system. Consider alternative approaches, such as a Patreon account that provides early access to major updates.

Anti-piracy systems SHOULD always give users the benefit of the doubt. If there are multiple ways of checking payment status, then combine them to obtain a 'trust level' for the user.
Your system MUST NOT generate false positives. You MUST heavily test your system to ensure it does not lead to any.
You SHOULD NOT use 'always-online' verification; mobile devices are not always connected to the internet.
If using online verification, DO NOT directly connect to the API of the repository you use. Instead, run a small server in-between to keep your API credentials secure.
If using online verification, you MUST treat a failed connection to your licensing server as 'successful', even for a temporary period of time. This is to handle the case of bad connectivity when doing license checks.
Consider adding a trial period. A lot of piracy occurs when users want to check a given tweak works with their device before purchase.

Legal

You MUST report earnings from paid tweaks to the tax office of your country, if you are above the minimum tax threshold.
If including any code licensed under 'copyleft' licenses (e.g. GPL), you MUST release the source code of your tweak. If in doubt, do some research on software licensing.
You MUST NOT re-package existing free tweaks and sell them as your own. Doing so will get you banned from all default repositories and the main jailbreak community. Instead, contribute to the original project.

Recommendations

To help meet these guidelines, here are some useful tips:

Don't work on too many projects at once. You'll end 'burning out' and need to take time away to recover.
Ask questions to other developers, no matter how 'stupid' they seem. Most (if not all) will be willing to help.
Remember that asking for payment means that you are not building something for yourself. Put yourself in the customer's position when making important decisions.
Try to provide translations in your tweak. Not all users are native English speakers, and its not difficult to make use of iOS' translation APIs.

Matchstic/Paid Tweak Guidelines.md