Link Search Menu Expand Document
Havoc Docs

Havoc Seller Guidelines

1. Policies that affect all packages on Havoc:

1.1 Support - This mainly applies to paid packages but really should apply to even free packages. You must have at least 1 form of updated contact information listed in your developer profile and should respond to your customers in a timely manner. If we receive multiple complaints from customers that you are not responding to support requests, you risk the chance of getting banned from the platform.

  • 1.1.1 If a user contacts you about a bug and you are already aware of it, it is suggested that you inform the user of such and that you are working on fixing it. This not only shows that you are on top of things but also tells the customer that they are not being ignored.

  • 1.1.2 On launch day, make sure your schedule is clear and be ready to fix bugs. There is nothing more frustrating for a customer than buying something and having it not work properly. Be sure to keep an eye on your socials (Email, Twitter, Reddit, Discord) to see if customers are trying to contact you.

  • 1.1.3 Any content you post to your support platforms should abide by the obscene content guidelines (1.11) as to not show the user something that will be offensive or inappropriate. It may be suggested in the case of providing support through Twitter to make a separate account solely for support.

1.2 Updates - This only applies to paid packages: When you release a paid package, customers are expecting to use it for a while. We expect you to provide compatibility updates for a minimum of 2 “major” iOS versions (Example: iOS 13, iOS 14). Of course, the nature of relying on private APIs does not always make this possible.

  • 1.2.1 You are expected to fix bugs found on the major iOS version that the tweak was released on. While not required, we kindly ask that you fix bugs on future iOS versions as well.

  • 1.2.2 Some developers release new packages instead of updates for every major iOS version - while we discourage this (unless it was a major rewrite), you should take advantage of Havoc’s “Discounts” feature which allows you to give buyers of the previous version discounts on the new package or give it to them completely free.

  • 1.2.3 It is expected that the initial release of your package works well on all devices you claim to support (you can find beta testers on r/jailbreak and the Jailbreak Discord server.) If you are not able to do this in the initial release, it should be one of your main priorities for your first update.

1.3 DRM - Developers often use DRM to discourage pirates from installing their packages. While Havoc is a supporter of developers using DRM - we also caution against going too extreme.

  • 1.3.1 Your DRM should never prevent a paying customer from using their purchase. If you see this happening, remove the DRM until it can be fixed.

  • 1.3.2 Your DRM should not impede the normal usage of a pirate’s device in any way - a simple message stating “This is pirated, please buy it from Havoc” and disabling the tweak is a nice and efficient way of handling this.

  • 1.3.3 Your DRM will not store any personal data without the consent of the user - to respect GDPR guidelines and other regional privacy laws (CCPA, etc…). If it does store personal data the user must be given a way to delete the information from your server and download a copy of their data.

  • 1.3.4 You should be careful about making connections from SpringBoard. We heavily discourage making DRM requests after every respring or on a time-based event. We encourage you to move DRM connections to the preferencebundle.

  • 1.3.5 If your DRM transmits device identifiers to a server, the server must be communicating over HTTPS and must hash any identifiers received if they are stored, otherwise, they need to be discarded after they are processed.

  • 1.3.6 Consider making a trial package - many times, people pirate a package to test it out before buying but forget to end up buying the real package because they are used to the pirated version.

  • 1.3.7 Your DRM should not affect the device in any way that limits the stock functionality of the device for DRM purposes.

  • 1.3.8 Your DRM should allow the user to use the package if a network connection is not available for a reasonable amount of time.

  • 1.3.9 Your DRM should only have to run once per month as to not require a constant network connection from the user. You can use a signed license file with signature verification to do this.

  • 1.3.10 When you are given an API key from Havoc you should use a middle man connection to make the API request. You should not store your Havoc API Key in the package’s code.

1.4 Pricing - When you make a paid package, one of the things you need to decide on is the price. While at the end of the day, Havoc gives you plenty of price options to choose from, here are some things to take into account. All prices are shown in USD.

  • 1.4.1 The price should fit the package - If this is a package you have been working on for months, it is understandable that you would want to charge a little more than usual. But if this is something that took you a day or two, you should consider making it free or very inexpensive.

  • 1.4.2 If it is a theme and it is a bundle of different variants, you can charge slightly more than if you were just selling one variant.

  • 1.4.3 The maximum price for a single package on Havoc is $14.99 USD.

1.5 Refunds - Users may contact you for refunds through your linked support options and you can manually issue refunds to them through the dashboard.

1.6 Behavior - Whether it is responding to a customer or a tweet on Twitter, we expect our sellers to act in a proper fashion. If we are made aware of anyone acting in a manner that is unbefitting of a Havoc seller, we may revoke your seller access.

  • 1.6.1 Illegal Activities - If we find that you are involved in any illegal activities, we will revoke your seller access and ban you from the platform.

  • 1.6.2 Hate speech - While everyone is entitled to free speech, we will not tolerate our sellers making racist, sexist, homophobic, transphobic, anti-Semitic, etc. remarks.

  • 1.6.3 Respectfulness - When communicating with a customer, you should always take the high ground and be respectful (even if they are not.) At the end of the day, they are the ones paying you and we expect our sellers to be the bigger person.

1.7 Dual-Hosting - If you are hosting a package with us on Havoc, you are not allowed to host the same package on another repo. You are allowed to host different packages on different repos, just not the same package.

  • 1.7.1 We do make exceptions if it is a free tweak and the other repository is your personal one.

1.8 Changelogs - When submitting an update, you must include a changelog. Try being descriptive and not just stating “bug fixes.” Do not add the changelog to the package description.

1.9 Version numbers - If your package version has “debug” in it, we will automatically decline it. (4.8+debug) Additionally, if we reject your update with version “4.6,” you will NOT need to resubmit a higher version number, you can resubmit a revised .deb with the same version. See here for how to build a package properly.

  • 1.9.1 Betas - Havoc will allow you to host beta packages that are free. Additionally, the version number should state that this is a beta version. (Example: 2.1-b1) If the package is paid and in beta, you will be unable to upload it until it is complete.

1.10 Package Metadata - If your package does not have a detailed description and/or screenshots, we will decline it with the exception of developer libraries. See here for tips on how to write a good description.

  • 1.10.1 Name

    • 1.10.1.1 The package title should not be “distracting.” Do not put unusual Unicode characters or emojis in the package title.

  • 1.10.2 Identifier

    • 1.10.2.1 The package identifier usually takes the form of “com.sellername.packagename”. All characters in the package identifier must be lowercase.

  • 1.10.3 Description

    • 1.10.3.1 Should be used to highlight a few key features you think will convince the user that they need the package.

    • 1.10.3.2 Must describe most if not all features your package includes.

    • 1.10.3.3 Should be clean and easy to follow, do not use conflicting font sizes that make it difficult to read.

  • 1.10.4 Screenshots

    • 1.10.4.1 Should primarily only contain content or modifications from your package. Try to keep everything else as Stock iOS as possible as to not mislead the user about the functionality of the package.

    • 1.10.4.2 Screenshots should be the same size overall. (landscape and portrait screenshots may differ from one another). Another exception is if you are providing screenshots for both iPhone and iPad.

    • 1.10.4.3 They must not contain any personal information.

    • 1.10.4.4 Should highlight the functionality and content of your package and should not be obscured by marketing text or other graphical content that does not pertain to your package’s functionality or appearance.

    • 1.10.4.5 All content in your screenshots must abide by our Obscene Content guidelines (1.11) as well.

  • 1.10.5 Section

    • 1.10.5.1 When submitting a new package, you must list it under one of the following: (Alphabetical Order)
      • Applications
      • Development
        • Developer frameworks/libraries
        • Tools used for development
        • Packages that are not meant for the average user
        • Shared Libraries for your packages
      • Themes
        • Icon themes
        • UI themes
      • Tweaks

  • 1.10.6 Supported iOS Versions

    • 1.10.6.1 The listed iOS version support must be accurate and kept up to date periodically.

1.11 Obscene Content - If your package contains any of the following, we will most likely decline it:

  • 1.11.1 NSFW - Havoc is a family-friendly repo, we will not tolerate any nude, sexual, suggestive, or pornographic material anywhere. Whether it’s in the package itself or if is in the description/screenshots.

  • 1.11.2 Encourages harassment, discrimination, racism, physical or mental harm.

  • 1.11.3 Threats towards anything or anyone.

  • 1.11.4 Tweaks or Applications that promote gambling, smoking or drinking.

  • 1.11.5 If you can’t say or draw it in public without making someone justifiably upset you can’t have it on Havoc.

1.12 Restricted Packages - We will not allow the following types of packages on Havoc:

  • Fonts
  • Multiple jailbreak detection bypasses
    • You are allowed to host one jailbreak detection bypass package - if you want to offer support for multiple apps, you must bundle it all into one package.
  • Keypad Themes
    • These are allowed if it’s included in a full theme, but not as their own separate package.
  • Localization - A package with the sole purpose to offer support for other language(s)
  • LockPlusPro Content
  • Respring Logos
  • Ringtones
  • Sound Packs
  • Sticker Packs
  • Wallpaper Packs
  • Dynamic Wallpaper Packs

This list is not conclusive; we may add to it at a later date.

1.13 Branding - Here, you can find a variety of Havoc assets and graphics that you may use in your promotional content. If you plan on using the Havoc logo in any promotional content, you may not alter or modify it in any way.

1.14 Multiple Accounts - You are not allowed to submit work under multiple accounts.

  • 1.14.1 You may not collaborate with sellers who are banned from Havoc.

1.15 Delisting Packages - If your package(s) is taken down, existing customers will still be able to access their purchase(s) but new customers will not be able to purchase them. This can be avoided by doing one of the following:

  • Transfer the package(s) to a new repo along with all the purchases (To do this, have the other repo’s maintainer contact Havoc Support) so all of your customers still have access to their purchase.

  • Cover the costs of refunding all of your customers from the past 180 days.

1.16 Install Scripts - A package’s install script should not contain anything that’s unnecessarily purely aesthetic. Packages that are found to be in contradiction to this will be rejected until the issue is resolved.

1.17 Native Checkout - If your package is paid, it must use Havoc’s checkout system. Packages that require purchase outside of our marketplace (i.e within settings) will be denied.

2. Tweaks

Tweaks in a sense are “extensions of iOS” - they allow you to do more with your device than Apple normally would allow. This could range from huge improvements to how your device looks and feels, or it could be a small quality of life improvement such as hiding the homebar on an iPhone X. While Havoc is always accepting new developers onto its platform, we want to ensure that the tweaks we host are of good quality.

2.1 Small Tweaks - Many developers offer a variety of tweaks but some of these tweaks can be pretty small - like moving the dock up 1 pixel. So we encourage all developers to put more effort into their tweaks (free or paid) and make it something that you would expect users to constantly ask you for an ETA for on Twitter. We will not be accepting these “small tweaks” on Havoc.

2.2 Piracy - Piracy or any other illegal content is not permitted on Havoc. This includes but is not limited to:

  • 2.2.1 Using code that you do not have permission to use.

  • 2.2.2 Unlocking in-app purchases (Method used does not matter) - This means enabling a feature that the app offers for an in-app purchase.

If you are found to be hosting piracy on Havoc, your tweak will be declined, your sales may be refunded, and you risk being banned from Havoc.

2.3 Similar Tweaks - Competition is always a good thing but if there are already 2 tweaks on Havoc that do similar things, we most likely will decline your package. One exception to this rule is if your similar package offers new or improved functionality over the other package’s feature set. Try developing new ideas that do not exist yet. You can get some good inspiration from the [Request] tag on r/jailbreak or you could check r/TweakBounty.

2.4 User Data - Tweaks should not store or transmit user data to a server without the user’s explicit consent. If you have the user’s consent, you must also have a way for the user to delete and download their data. Additionally, you must adhere to all regional privacy guidelines at all times.

  • 2.4.1 Your package should explicitly list in the description if it transmits any user data over the internet and what that data is.

2.5 Tweak Changes - Tweaks should not make changes that persist outside of the jailbreak without getting explicit consent from the user.

  • 2.5.1 Your tweak should not be changing system files. If it does, you must get explicit consent from the user.

2.6 Hidden Features - Tweaks should work as advertised, there should be no “hidden” features, functionality, or unexpected behavior.

2.7 Update Frequency - If you are pushing updates too frequently with minimal substance or to abuse the update feed in package managers, your ability to push updates may be rate-limited.

3. Themes:

Themes are custom app icons that can create a whole new look for your device. Themes are usually applied using Anemone (By Coolstar) or Snowboard (By SparkDev). Some themes go beyond just app icons and can also customize different UI elements on your device such as the settings app and many other stock/3rd party applications. Havoc is proud to host a variety of different and unique themes, but we also want to upkeep some form of quality control.

3.1 Theme Variants - Many designers create an awesome theme and then go on to create variants of the theme such as; “light,” “dark,” or the same theme in a different color. These are then listed on Havoc as individual paid packages. While Havoc does have the restriction for buying another package, that does not solve the issue of spam and quality control. We ask that if you planned on doing this, you should instead bundle all the color variants into one package which will be much more enticing for customers. If you think about it, if someone already has the “dark” version of your package, they are not going to want to buy a “light” version. But by bundling the two together, you are creating a much more desirable package. We will decline any theme if it is found to be a variant of an existing package.

3.2 Low-Quality Submissions - Many times we will come across a theme (either from our seller applications or from the submission queue) that does not have many icons in it. This shows us that you have not put much effort into your theme and we will most likely decline it. There is a minimum of 100 icons for a new theme and a 25 (subject to change) icon minimum for theme updates. We will decline any theme or update if it does not meet this requirement.

3.3 Icon Source - We insist that all designers create their icons themselves and do not steal icons from the internet or others. Anyone found stealing icons will be permanently banned from Havoc and all sales will be refunded if not caught immediately.

3.4 Update Frequency - We encourage all designers to spend time working on updates to their themes, so to prevent low quality work and people trying to game the system, every theme is limited to at most 1 update per every 7 days.

3.5 User Interface (UI) Themes - In order for a UI theme to be accepted on Havoc, it must theme all the following:

  • Status Bar Elements
  • Settings Icons
  • System Elements (Example: Back Arrows, New Message, Share)
  • Switches/Toggles
  • Stock iOS Application’s UI elements
  • Optional: Control center icons
  • Optional: Popular Application’s UIs
  • Optional: Keypad/Keyboard themes

3.6 Icon Requests - One of the things that really make a theme stand out from others is the number of icons it has. You should take icon requests from verified buyers. Some ways of doing this are providing an email in the description for them to send you their requests or you can go the easy way and provide a Google form. While taking icon requests isn’t mandatory, it is highly suggested.

Havoc has the right to remove any package and suspend or ban any seller account if we deem fit, even for reasons not stated above.