Xamarin Component Review Guidelines
- PDF for offline use
Let us know how you feel about this
last updated: 2017-03
The Component Store was launched in March 2013, as part of the Xamarin 2.0 launch, with the aim of helping developers get their apps built faster and to add great features without a lot of work. The store has a catalog of stunning UI controls, charts and graphs, beautiful themes, cloud services, and other powerful features that you can add to your app in minutes. The Component Store is integrated into Visual Studio so that components can be added to your app with just a few clicks. This document provides the rules and requirements that your component should comply with to ensure it is reviewed and approved as quickly as possible..
We opened the Xamarin component store in March 2013 as part of our Xamarin 2.0 launch. The component store allows talented developers to package and publish their code for other developers to integrate into their own projects improving the entire Xamarin ecosystem and making it an even better place to develop your mobile apps.
We have published these component review guidelines so that you can see how we review your components and what we are looking for. By reading them you can improve the speed of review and increase your chances of getting approved first time.
1. Terms and Conditions
1. 1 Xamarin pays 70% of net component revenue to vendors within 30 days of the end of each calendar month.
1.2 Vendors must provide 30-day notice on price changes and must honor Xamarin's 30-day return policy.
1.3 Vendor licenses must allow library distribution as part of end-user apps without hidden fees or royalties.
1.4 You can read the full agreement for complete details.
2. Legal Requirements
2.1 Your code must comply with all laws that apply to you in your location. It is up to you to know what they are, and whether your code complies or not.
2.2 You must own, or have full rights to, all of the intellectual property that you include in your component package.
2.3 We trust that your component does NOT misrepresent itself, or mislead people as to its purpose or its origin.
2.4 We won’t approve components that induce or entice other people to commit crimes or endanger themselves or others.
2.5 Components with rude or offensive content or contain defamatory or libelous content will be rejected.
3. Metadata (name, descriptions, icons, websites)
3.1 Component name must be descriptive.
3.2 Component name must not include “Xamarin” or imply a connection with Xamarin
3.3 Publisher name must be provided and be relevant to the actual author
3.4 Component summary must be correct and concise.
3.5 If the submission updates an existing component, ensure that release notes are provided. The notes should indicate what has changed since the release. This information assists users in determining whether to update or not.
3.6 Make sure that the component is appropriately categorized and tagged. Icons should look good, appropriate, and professionally represent the component in our store.
3.7 Icon should not apply rounded corners or glossy highlights.
3.8 If you charge for your component make sure that the price is comparable to similar components.
3.9 The main website link must work and be either related to the component(such as the github repository) or the author.
3.10 If source link is provided it must work and be related to the component(such as the github repository)
3.11 The component ID must not include the name "Xamarin" and must be specific to your product. Component ID's that are catch all terms will be rejected
4. Screenshots and Videos
4.1 If a link to video is provided it must work and be appropriate for the component.
4.2 If screenshots are provided they must be appropriate for the component, be 740 wide by 400 high, and look clean and professional.
4.3 If the screenshots require attribution, such as with PlaceIt, this must be included on the details page.
5.1 Components must include a short description of what the component does and why someone would want to put it in their apps.
5.2 Code snippets included in the page must work and be compilable.
5.3 Ensure that the information provides accurate and useful content, with proper spelling and grammar.
*5.4 * All links included in the details page must work.
5.5 Any features listed as available must be functional in the component.
5.6 If the screenshots require attribution, such as with PlaceIt this must be included on the details page
5.7 If any portion of the details has been copied from elsewhere then attribution must be provided
5.8 The formatting of the details page must be render correctly
6 Getting Started
6.1 An extended description of the component must be provided
6.2 If a License Key or access token is required it must be stated clearly and illustrate the steps involved to get one.
6.3 If a particular Android API is being targeted, rather than being Automatic, this should be documented on the getting started page.
6.4 Must demonstrate initializing the library and perhaps some useful code that the user might use.
6.5 Must show library-specific using statements or fully qualified class names.
6.6 Code snippets included in the page must work and be compilable.
6.7 Ensure that the information provides accurate and useful content, with proper spelling and grammar.
6.8 All links included in the getting started page must work.
6.9 Any features listed as available must be functional in the component
6.10 If any portion of the details has been copied from elsewhere then attribution must be provided.
6.11 The formatting of the details page must be render correctly.
7.1 For open source components the license should be MIT X11, BSD, Apache2 or MS-PL.
7.2 The terms of the license should be included on the page.
7.3 For commercial or proprietary libraries it must include the appropriate licensing, copyright, and attribution information.
7.4 The formatting of the license page must be render correctly.
7.5 All links included in the license page must work.
8.3 Components will be reviewed in both simulators/emulators and real devices.
8.4 Any components that crash, or do not run as expected will be rejected.
8.6 Must not target a pre-release build of Xamarin.iOS or Xamarin.Android, such as an Alpha or Beta channel release.
8.6 Any dependencies that are not available from the component store must be included with the component.
8.7 Libraries must include a namespace.
8.8 Namespace should not include Xamarin.
8.9 If source code is provided within the component package then it should compile without modification by the user.
9. Samples - General
9.1 Component must includes at least one sample for every supported platform.
9.2 Each sample should be provided inside its own separate solution per platform, though multiple projects can be include in each solution.
9.3 Each sample must build using the latest Stable channel release in both Release and Debug mode
9.4 Each sample must build and compile without requiring modification by the user
9.5 Each sample must deploy successfully to both the simulator and real devices.
9.6 Each sample must runs successfully and not crash.
9.7 Each sample must behave as expected
9.8 Samples must target the same platform API / SDK version as the library in the component.
9,9 Samples should not reference components that must be paid for, to download and allow the sample to compile.
9.10 Comments in sample code must be clean, descriptive and concise and not contain foul or offensive language.
10. Samples - iOS
10.1 Project Options > Build > iOS Bundle Signing > Identity must be set to Developer (Automatic)
10.2 Project Options > Build > iOS Bundle Signing > Provisioning Profile must be set to Automatic.
10.3 Info.plist > Deployment Target must be set to 4.3 or above.
11. Samples - Android
1 1.1 Project Options > Android Build > Advanced > ABI Settings must all be ticked to ensure that the sample will deploy to any and all simulator and devices.
11.2 Project Options > General > Target framework must be API Level 10(Gingerbread) or above.
11.3 Project Options > Android Application > Target Android version should be set to Automatic.