Version 1.2 | Last Updated: April 11, 2021
Packix has been serving the jailbreak community since 2017 and is the home of many iconic tweaks and themes. We are honored that hundreds of sellers trust us to distribute their work and we pride ourselves on providing a safe and easy way for customers to download their favorite packages. As part of our continuing mission to provide the best experience for both our customers and our sellers, we have created these seller expectations and guidelines.
Table Of Contents:
- 1. Policies that affect all packages on Packix
- 1.1 Support
- 1.2 Updates
- 1.3 DRM
- 1.4 Pricing
- 1.5 Refunds
- 1.6 Behavior
- 1.7 Dual-Hosting
- 1.8 Changelogs
- 1.9 Version Numbers
- 1.10 Package Metadata
- 1.11 Obscene Content
- 1.12 Restricted Packages
- 1.13 Branding
- 1.14 Multiple Accounts
- 1.15 Delisting Packages
- 2. Tweaks
- 3. Themes
- 4. Widgets
1. Policies that affect all packages on Packix:
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 (Can be set here) 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 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 12, iOS 13). 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 Packix's "Discount Offers" 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 Packix 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 Packix" 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. 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 Packix you should use a third party as a middle man to make the API request. You should not store your Packix 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, you have total control over what price you want to set, 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 average package price is between $1.49 - $2.49
1.4.4 The maximum price for a single package on Packix is $10.00 USD. Some users may choose to bundle packages for a special sale, in this case, the maximum is $50.00 USD.
1.5 Refunds - Read here for more info and tips regarding refunds.
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 Packix seller, we may revoke your seller access.
1.6.1 Piracy - If you are involved in the piracy community we may ban you from the platform as we do not want to associate with pirates.
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 Packix, 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, (See here for how to correctly add a changelog.) We will decline an update if it does not have a changelog after a few hours. Later on, we will define what a changelog should include based on package type.
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 need to resubmit the new version as "4.6.1" or "4.7" - you can not submit the same version again. See here for how to build a package properly.
1.9.1 Betas and Alphas - While Packix does allow you to host beta and alpha packages, you must clearly state at the top of the description that it is indeed a beta/alpha. Additionally, the version number should state that this is a beta version. (Example: 2.1-b1)
1.10 Package Metadata - If your package does not have a detailed description and/or screenshots, we most likely will decline it. See here for tips on how to write a good description.
18.104.22.168 The package title should not be "distracting." Do not put unusual Unicode characters or emojis in the package title.
22.214.171.124 The package identifier usually takes the form of “com.sellername.packagename”. All characters in the package identifier must be lowercase.
- 126.96.36.199 Can be used to highlight a few key features you think will convince the user that they need the package.
- 188.8.131.52 Must describe most if not all features your package includes.
- 184.108.40.206 Should be clean and easy to follow, do not use conflicting font sizes that make it difficult to read.
- 220.127.116.11 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.
- 18.104.22.168 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.
- 22.214.171.124 They must not contain any personal information.
- 126.96.36.199 Should highlight the functionality and content of your package not be obscured by marketing text or other graphical content that does not pertain to your package's functionality or appearance.
- 188.8.131.52 All content in your screenshots must abide by our Obscene Content guidelines as well.
- 184.108.40.206 We will be merging many package categories into six. When submitting a new package, you must list it under one of the following: (Alphabetical Order)
- Control Center Modules
- Activator Plugins
- Developer frameworks/libraries
- Tools used for development
- Packages that are not meant for the average user
- Shared Libraries for your packages
- Anything else not mentioned on this list
- Icon themes
- UI themes
- Status bar themes*
- Widget Packs
- 220.127.116.11 We will be merging many package categories into six. When submitting a new package, you must list it under one of the following: (Alphabetical Order)
*New packages no longer allowed on Packix
**Only VERY high-quality widgets can be submitted as separate packages.
1.11 Obscene Content - If your package contains any of the following, we will most likely decline it:
1.11.1 NSFW - Packix 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 Apps 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 Packix.
1.12 Restricted Packages - We no longer will allow the following types of packages, however, we will accept updates to existing packages that fit these criteria.
- Localization - A package with the sole purpose to offer support for other language(s)
- LockPlusPro Content
- Respring Logos
- Sound Packs
- Sticker Packs
- Wallpaper Packs
- Dynamic Wallpaper Packs
- 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.
This list is not conclusive; we may add to it at a later date.
1.13 Branding - Here, you can find a variety of Packix assets and graphics that you may use in your promotional content. If you plan on using the Packix 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 Packix.
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 Packix 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.
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 Packix 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 Packix.
2.2 Piracy - Piracy, unfortunately, is a common occurrence in the jailbreaking community but we will not tolerate any form of it on Packix. 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 Packix, your tweak will be declined, your sales may be refunded, and you risk being banned from Packix.
2.3 Similar Tweaks - Competition is always a good thing but if there are already 2 tweaks on Packix 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 GDPR 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.
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. Packix 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 Packix as individual paid packages. While Packix 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 15 icon minimum for theme updates. We will decline any theme or update if it does not meet this requirement.
3.3 Icon Source - Recently, there has been an unfortunate uptick in the number of themes found to be using icons/glyphs from Google Images. 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 Packix and all* sales will be refunded if not caught immediately.
*From past 180 days
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 week.
3.5 Status Bar Themes - We will no longer accept status bar themes as individual packages, instead, these need to be included in icon or UI 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.
4.1 Widget Packs - We will strongly be enforcing widgets being put into packs rather than each being an individual package. Packs will mostly be grouped based on the type, style, and function of the widgets. We will also be enforcing much higher quality standards for widgets.
4.1.1 Sellers will be allowed to submit up to one update per week per widget package.
4.1.2 Widgets in a widget pack should be of high quality and not something you just pulled off of GitHub and bundled into a package. On this note you may not pass off other's work as your own of course. If you are caught doing this you will be banned from Packix and your sales refunded.
4.1.3 Your widget pack's name should reflect what is in it and not only one of the widgets present in it.
4.2 Remote Connections - We want to ensure all connections your widget makes to the outside world keep security and privacy in mind.
4.2.1 When possible your widget should make connections to the internet over HTTPS
4.2.2 Widgets may not transmit any user data remotely, all processing of user-data must be done locally on the device.
4.3 Dependencies - Your package should use the Depends field of the control file to list the proper identifiers for the HTML/Information engines your package relies on like XenHTML or XenInfo.
Packix has the right to remove any package and suspend or ban any seller account if we deem fit, even if not stated above.
Part of this document is based on Matt Clarke's "Paid Tweak Guidelines"