Dynastic Repo is a trusted source for installing packages. Customers can download and purchase with confidence that their packages will work as expected, provide a great experience, and be safe. This doesn’t just benefit the users installing your packages, but developers directly: safe and trustworthy marketplaces reward everyone involved.
While other repositories have unspecified or entirely discretion-based requirements, we believe that communication with our developers is essential and have decided to make a document outlining our guidelines for your convenience.
To ensure that your package is approved and as successful as possible, use the following guidelines.
Table of Contents
- 1.2 Bugs and Crashes
- 2.2 Performance
- 2.3 Compatibility
- 2.4 Spam
- 2.5 User Experience
- 3.4 Functionality
- 5.2 Accuracy
- 5.2.1 Package Name
- 5.2.2 Description
- 5.2.3 Screenshots
- 5.2.4 Changelog
- 5.2.5 Known Issues
- 5.2.6 Header Images
- 5.2.7 Additional Information
- 5.3 Restrictions
- 5.4 Pricing
Users should be able to expect a certain level of functionality when they install your package. The following section outlines the minimum functionality that you should aim to provide while creating your package.
1.1 Required Functionality
Every package on Dynastic Repo — whether free or paid — must provide a minimum level of functionality. Dynastic Repo is home to only for high-quality packages. Packages that provide completely new experiences are preferred, rather than minimal tweaks. Before submitting, ask yourself whether or not many users would find your creation useful.
Novelty or joke packages will not be accepted, nor will packages that can only be used by a small number of people, such as members of an invite-only service.
We expect packages submitted to be unique. Packages that are blatant clones, copycats, or recreations of other releases, planned or past, are not suitable for Dynastic Repo. We encourage creativity, not minor iteration.
1.2 Bugs and Crashes
Your package, if it contains programmed functionality, such as a tweak or application, will be tested for obvious bugs and crashes during the review process. If your package includes showstopping or otherwise glaring bugs, such as missing content or the device or package’s functionality being rendered useless, it will be rejected. Similarly, if the package cannot be used without encountering crashes on different device models with a minimal selection of common tweaks, it will be rejected.
1.3 User Safety
Packages that are malicious or otherwise dangerous to the user in nature are not permitted on Dynastic Repo.
Packages that are intended to cause either temporary and permanent damage to the user’s device or surrounding devices will be rejected. Software or modifications meant to harm the operation of any of the device’s hardware or software components will be rejected. This includes software that purposely and unexpectedly disrupts or prevents user action or normal operating procedures.
1.3.2 Unexpected Functionality
Packages that intentionally provide functionality that users would not expect or find to be annoying will be rejected. This includes packages that cause purposeful random occurrences, such as randomly playing sounds or changing strings or images around the system. If a user would not reasonably expect your package to perform in such a way, it is not suitable for Dynastic Repo.
If your package accesses user, device, or otherwise confidential information, it should never leave the device in any form, without the user’s consent. This includes the user’s personal information (such as name, birthday, email, phone address number, or personal files), current or past user locations, contact data, photo library data, app credentials, device identifiers or configuration information. In addition:
- (i) Device information, such as UDID, serial number, and other unique identifiers, should never be transmitted to remote servers, without the user’s awareness. For paid packages, you may submit the UDID to a remote server for the purpose of Digital Rights Management (DRM), as long as it is either hashed or discarded once it reaches the server.
- (ii) Packages may transmit the specified data as long as the user explicitly confirms its transmission. For this to be considered, all information being sent to the server must be shown. If this information will be transmitted more than once after approval, you must notify the user when this will be done in the future prior to permission being granted.
- (iii) You may not transmit the personal information of a user under 13 years of age to a remote server under any circumstances.
- (v) Any non-anonymized transmitted data must never be distributed to third-parties without the user’s consent. If a user requests that you delete their data, third-parties must also delete any received data.
- (vi) You may not authenticate directly using a user’s Dynastic Account.
- (vii) You may not access location, photos, or camera data without user consent or the expectation that it would. For example, a tweak that takes photos using both cameras incorrect passcode attempts.
1.3.4 Physical Harm
If your package behaves in a way that risks physical harm to the user, it will be rejected. This includes packages that instruct users to perform potentially dangerous actions, as well as modifications to the device that may cause it to present any physical danger to any person or animal.
1.4 Remote Configurability
Packages that receive instructions on how to operate from remote servers or other devices must be limited in access.
- (i) Your package’s main functionality may not be determined by the response of a remote server. For example, a tweak that changes status bar icons may not suddenly change app icons instead based on server response.
- (ii) Your package may not allow the execution of arbitrary commands based on the response of a remote server, such as shell commands or server-specified file operations. Your package may take instructions from a server, but they may not be arbitrary or dangerous.
- (iii) Packages may not execute covert actions based on the response of a server, such as attacking another device or website.
- (iv) Your package may not download over 5 MB of data per day in the background, in cases where it is not the primary and expected functionality of the tweak.
Packages are exempt from the above if the server providing commands is owned and controlled by the end-user.
1.5 Prohibited Package Types
The following types of packages are not permitted on Dynastic Repo, and will be instantly rejected upon review:
- Developer tools (excluding libraries)
- Novelty or joke packages
- Localization packages
- LockPlus Pro content
- XenHTML content
- Respring logos
This list is not exhaustive and may be amended to include more types at a further date.
Packages that do not require hosting on Dynastic Repo will not be accepted. This includes:
- Software that could be made available for sale on the App Store.
- Software which is well-suited as web applications.
- Packages which do not require a download.
- Software which is a clone of other commercial products on any marketplace.
You may not host any software which competes with Dynastic Repo, any product or service offered by Apple, or any paid application made available for sale on the App Store.
1.7 Additional Information
Ensure that your package follows the below best practices to increase your chances of being approved:
- (i) Your package (UI, preference panes, etc.) should be free of grammatical errors.
- (ii) You should refer to iOS features using their accepted names, rather than vague short forms (such as typing Control Center, rather than CC).
Customers expect your packages to improve their devices with a great experience. The following section outlines a few requirements to ensure this experience for your users.
2.1 Incomplete Packages
As Dynastic Repo only accepts high-quality packages, ones that are unfinished will not be accepted. This includes packages that are marked as alpha, pre-release, or beta. If your package is missing important functionality or does not feel like a finished product, it will be rejected. You should ensure that your package does not contain any temporary placeholder data and that all settings work.
Themes intended for more than system-wide theming must include assets for most stock iOS apps found across all device models and configurations. This includes apps such as Weather (not available on iPad) and the Activity app (only shown with an Apple Watch).
Any packages that slow down or otherwise degrade the performance of the user’s device will be rejected. Ensure your package does not contain any memory leaks, threading errors, or modifications that degrade device performance.
You should always aim to ensure that your tweak works on every possible iOS device supported on the versions you would like to support. If your tweak does not work on certain devices, you must specify this in the description.
To prevent confusion, Dynastic Repo only accepts packages that work on the latest major widely-jailbreakable version of iOS.
Your package should not prompt or notify users unnecessarily. A welcome message to introduce your package is fine, but should only be shown once. You may not prompt the user asking for donations after the package is first installed.
If you have many packages with similar purposes, consider uploading them as one. We will not be accepting multiple tweaks that perform identical functions with minor variations.
2.5 User Experience
When you are creating a package, you should set out to offer your customers the best experience you can. Your package should bring delight to every user who downloads it. If you make a truly great package, people will use it, and the best advertising is word of mouth, so impress every user. As a rule of thumb, packages that exhibit any of the following traits will be declined:
- Confusing or unexplained features.
- An unfinished or careless (e.g. ugly or unpleasant) user interface.
- Annoying pop-ups, notifications, or other alerts.
- Visually impeded functionality.
To distribute packages on Dynastic Repo, you must follow a few practices in regards to how you conduct business.
Your package may not accept payments in any fashion after the initial download from Dynastic Repo. Neither free or paid packages can accept or request payments using external payment-processors, other than excepted below.
3.1.1 Donation Links
As an exception, you may allow donations using a service such as PayPal.me, but you may not solicit donations in return for features, future products or services, or any other perks. You must also follow the guidelines in Section 2.4 (Spam) when implementing your donation link.
3.1.2 Third-Party Systems
You may not attempt to bypass this by instructing the user to pay in a browser on a dedicated website. You also may not enable features selectively, based on the payment status of their account in an external service, including those operated by you.
When including advertising in your package, you must adhere to the following guidelines:
- (i) You may not place advertisements on user-interface elements that were not created by your package (barring the ad). For example, you may not place advertisements over the Home or Lock Screen, or in system or third party apps. You can, however, put them in the settings screen of your package or as part of your package’s UI (such as in an application).
- (ii) You may not place advertisements that block over 30% of the content on the screen or position them away from the edge of the display.
3.2.2 Feature Restrictions
You may not restrict or lock features of your package based on whether or not a user has viewed an advertisement. Examples of this include offering users an extended feature set in exchange for watching a video advertisement.
3.2.3 Paid Packages
Paid packages distributed on Dynastic Repo may not display advertisements. Customers do not purchase packages with the expectation of encountering more advertisements. If you have a high-quality package and do not think that purchases will sustain your development, you should consider increasing the price.
3.3 Professional Conduct
All developers using Dynastic Repo must conduct themselves in a professional matter when dealing with users and while discussing the package. This is especially true for paid packages; selling products is a business, and you treat it as such.
All customers deserve to be treated with respect. While corresponding with customers or publicly about your content, you must meet a certain behavioural standard, refraining from impoliteness. In addition, swearing, harassment, and other similar unacceptable behaviours will not be tolerated. If you wouldn’t be okay with being treated a certain way in a retail store by a manager, don’t treat your users that way.
When a user asks for support, you should always do your best to help them get the problem resolved. You do not have to deal with every user or repeat the same thing over and over again, but you should put in the effort to help users who are having issues. If there is a widespread issue, make an effort to notify users, such as by tweeting about it publicly.
You can specify a Twitter account, Discord server, and email address for support in your package’s metadata. You must provide at least one of these support methods for users who are experiencing problems with your package. At least one method of support must be also accessible from within your package, such as on its preferences page.
It’s always better to have happy customers who enjoy your product than ones who couldn’t refund it. Sometimes users aren’t satisfied with what they have purchased. Whether it be due to them disliking the tweak or it not working for them, you should make an effort to decide refund requests quickly and fairly. While we allow you to use your discretion while providing most refunds, we ask that you refund purchases that do not work, after attempting to help the user out. We may step in if we sense that you are abusing the system by ignoring or declining refund requests unfairly. Repeated abuses of this system will result in you being barred from using Dynastic Repo.
Your package must always function on the version it was advertised for, in cases where a server is not involved. If your package is intended to only work for a limited time, it will be rejected. Customers should have confidence that their purchase will work on the device they bought it without time limitations.
Users should have confidence when downloading packages that they will not contain offensive or objectionable content. While Dynastic Repo does not have strict age ratings, packages that would not be suitable for children under 13 years old are prohibited.
4.1 Objectionable Content
Dynastic Repo aims to be a safe marketplace for everyone. Your package may not include any of the following:
- Real or cartoon depictions of nudity, including sexual and pornographic material.
- Any content that encourages, advocates for, or celebrates violence, including displays of abuse, torture, killing, or content that otherwise contains graphic violence.
- Discriminatory, defamatory, or otherwise mean-spirited content.
- Targeted harassment or abuse towards any individual or group of people, including individual members of the group, based on their race, religion, gender, sexuality, gender identity, nationality, ethnicity, or other similar traits, whether directly or implied.
- Content that encourages harassment, abuse, or bullying.
- Any political or otherwise controversial commentary or opinions.
- Any threats towards others, including individuals, a group of people, geographic region, government, whether physical or otherwise.
- Content that aims to objectify people.
- Material that encourages of alcohol, tobacco, or drug use.
- Any offensive symbols or depictions, such as those relating to terrorism, racism, sexism, or otherwise intended to offend others.
- Content that promotes self-harm or suicide.
These restrictions also apply to any content referenced or linked to from inside your package.
4.1.1 Offensive Symbols or Terms
There has always been debate over the offensiveness or acceptability of some historically-controversial symbols or terms. Instances with many different or evolving meanings throughout history are not up for debate. As a rule of thumb, if you think many people would be offended by a symbol or term, it is not appropriate for Dynastic Repo. While we won’t provide specific examples, you should be able to use your best judgement to decide whether or not to include content.
4.2 User-Generated Content
While we understand that it is hard to moderate user-generated content, you must provide a system to prevent abuse of your service.
- Regular moderation of content readily available or featured in the service.
- A way for users to report offensive or threatening material.
- The ability for individuals to block abusive users.
- A method to contact someone who can take appropriate action.
Services that exist solely for objectionable reasons will be rejected. This includes services intended to encourage abuse, targeted harassment, or other violations of Section 4.1 (Objectionable Content).
4.3 References to Dynastic
In most cases, your product should not need to reference Dynastic and its products or services. If you reference Dynastic or any of its products or services, you may not portray them in a negative light, nor in a false or libellous way.
You should adhere to the branding that is used consistently throughout Dynastic’s products and services. When referring to our repo service, it should be called Dynastic Repo, and not any shortenings or other variations of the name. Unacceptable uses of Dynastic Repo’s branding include Dynastic repo, dynastic Repo, dynastic repo, DDRepo, DDR, DD Repo, Dynastic’s Repo, and similar variations. When referring to Dynastic itself, it should simply be called Dynastic.
Failure to follow these guidelines may result in removal of your package without prior notice.
4.4 References to Other Services
You may not make any references to another general purpose user-uploadable package management or hosting repositories in your package or metadata. However, you may reference other repositories, such as a personal one for small tweaks or beta packages.
Metadata is the information that you provide alongside your package, such as its name, description, screenshots, and icon. Consider anything inside inputted into the Developer Panel or specified your
control file to be metadata.
5.1 Acceptable Content
Please ensure that your metadata conforms to every guideline under Section 4. (Content) before submission.
5.1.1 Additional Content Restrictions
In addition to the rules specified above your package’s metadata must not include a few more items, such as:
- Any instances of coarse language.
- References to alcohol, tobacco or illicit drug use.
If your package contains any of the items listed above, you must offer a disclaimer in your package’s description to warn users.
The information described in your metadata should accurately represent your package and the experience that it offers so that potential customers know what they are downloading or buying.
5.2.1 Package Name
Your package name is what most people will remember it by. Choose something both unique and memorable. Having a name that relates to the functionality of your package will also help users discover it.
The package name should be creative, and not a copy or variation of an existing package’s name.
Your description is not only a space for you to let your users know what your package does, but entice them to download or buy it. Tell your users exactly why they need your package on their device and why they will love it. Pick out your favourite, most innovative and impressive features and let potential customers know why they are worth it.
The description should outline most of the functionality of your package. It should include any essential features of your package. Your package should not contain any large unspecified or hidden features or functionality, and your metadata should not specify any features that your package does not include.
Screenshots are another way for you to attract potential customers. You should capture the most beautiful, eye-catching aspects of your package. Arrange your screenshots so that the best ones come first.
- (i) You’re free to customize your screenshots with borders, device frames, and captions, but they must prominently display actual screenshots of your package in use.
- (ii) Screenshots should be the size of their target device for easier viewing.
- (iii) Your screenshots should all be the same size for best appearance.
- (iv) Screenshots should not be primarily comprised of other artwork, such as your logo or icon, and they should convey useful information about your package to the viewer.
- (v) Screenshots may not contain any personal information, such as contact photos or names of people whom you have not granted you permission to use their likeness, name, or other information.
- (vi) You may not prominently show off modifications in the screenshot that are not caused by your tweak or one of its dependencies. Other iOS settings not required by your tweak should be as stock as possible.
Dynastic Repo allows you to specify a changelog (or “What’s New”) for your package when you release new versions. For updates, all significant changes should be outlined clearly for users downloading the update. You may specify a more generic description for minor enhancements, but anything noticeable or interesting to users should be described here. Updates with insufficient information in the changelog may be rejected.
5.2.5 Known Issues
Dynastic Repo offers a dedicated section for known issues with your package. While its use is optional, you should consider using it to bring down support or refund requests due to common problems while you work to fix them.
5.2.6 Header Images
Dynastic Repo allows you to specify a header image for your package. There is no guarantee that it will be displayed to the user in every context, and is supported via the web package preview display and in some package managers, such as Sileo.
Your image should have a wide aspect ratio and be more than 1600x800 in size. When displayed on different screen sizes, the edges may be cut off, so ensure that it can be displayed cropped.
Your header should be for decorative purposes only, and preferably not include any text or just screenshots of your tweak at all.
5.2.7 Additional Information
- (i) Ensure you have the necessary legal rights to use any information specified in your metadata.
- (ii) Refrain from referencing any other repositories from within your metadata.
- (iii) Avoid spam-like text when writing your metadata, such as excessive formatting or uppercase letters.
- (iv) Any websites referenced in metadata must also adhere to Section 5.1 (Acceptable Content).
- (v) Where markdown is available, you may not use heading styling for any purpose other than actual headings to divide sections.
- (vi) Your screenshots, icon, and header images may not contain any translucency.
- (vii) Your icon will be masked using the stock iOS icon mask upon uploading. Fit your icon appropriately.
- (ix) Your package may not rejected if its metadata contains large grammatical errors or other unprofessional mistakes.
If your package has any features or functionality that will not be available to some users, you must indicate so in your description. It is very disappointing to download a package for one reason and find out that it doesn’t work for you. This includes device-specific or geo-locked features.
In order to create price uniformity, package pricing works via a tiered system. When selecting the price of your package, you will select a tier to use, rather than entering the exact amount you would like to receive for your package.
In the future, if Dynastic Repo supports additional currencies for user convenience, we will adjust pricing accordingly for you.
Remember, hosting on Dynastic Repo is a privilege, not a right. We reserve the right to remove any packages at our discretion and amend these guidelines at any time. These guidelines do not serve as an exhaustive list of all regulations applied during the review process.
We can’t wait to see what you come up with!