I want to mention that we greatly appreciate your control submissions. I am continually impressed by the resourcefulness, dedication to quality, and willingness to share demonstrated by our community. To that end, I wanted to mention a few things about the process behind the scenes, both so you can better understand how and when content is published to the site, and also to help us streamline the process.
The queue
Controls are published on what is typically a first-in first-out basis. Right now, there are seven controls in the queue. When we have a big backlog (>15), we’ll publish two controls a day. Otherwise, when the queue is getting smaller, we’ll publish one per day.
When a control’s turn for publishing comes up, I’ll take a look at the control and ensure that it meets our quality bar, add a screenshot if necessary, edit the control’s description for language and clarity, and then publish it. Sometimes, if I am pressed for time, I’ll skip over a control that lacks a screenshot, or has an ‘incorrect’ screenshot (‘incorrectness’ is described in more detail below).
If a control fails to meet a certain threshold for utility, novelty, or code quality, I’ll decline to publish it, and instead delete it from the system. I don’t do this very often, but I do try to ensure that the content we publish remains useful and/or highly novel for you.
Speeding your submission through the queue
The best way to ensure your control speedily makes its way through our queue is by following these guidelines:
- Make sure your control has an example project that demonstrates how to use it. I see quite a few controls come through that point to a GitHub repo that consists of nothing more than a .h/.m file pair and a README. Unless I am really intrigued by the control’s description, I’ll usually decline to publish these, since the alternative is for me to fork your repo, write an example project, and submit a pull request.
- Include a good-looking screenshot. A few months back, Apple added the ability to capture a properly-sized screenshot of your iOS app from the Simulator, simply by pressing ⌘S. Sometimes, submitted screenshots include the Simulator chrome, or errant black lines at the top or bottom.
- Include a good description. A simple two-to-three sentence description of your control is ideal. If you have a blog post that goes into more detail about the control, please include that in the ‘Found At’ field on the control submission page.
- Include a license. Technically, any control marked as having an unspecified license can’t safely be used in other people’s projects. A license should be included in your source repository, and selected on the control submission page. Additionally, it’s ideal if your repository’s README clearly spells out which license you’re using. In other words, the README should explicitly say ‘MIT License’, followed by the license text, instead of just including the license text. Otherwise, you’ll find that people actually have to copy and paste a snippet of the license into Google to ensure they know which one they’re looking at.
- Email us! If you have any questions that aren’t addressed here, let us know at [email protected]. We’ll be happy to help you out.