Advice for new developers

From iPhone Development Wiki

So you're working on your first tweak, and you're getting ready to release it on a default repository - or you've released a few tweaks already, and you want to improve what you're doing. Exciting! Here's some help for the next steps, especially if this is your first experience in building a small business or not-for-profit public project.

You're invited to edit this page and add more, especially if you're a developer who has released a few things already and has advice for people starting out.

Before you release your tweak

Advice for improving your marketing and installs/sales

You can encourage many more people to download or buy your tweak if you put some effort into marketing it.

This section includes a lot of advice based on Sebastien Page's great talk from JailbreakCon 2014 - you can watch it for more explanation. He's the main editor of iDownloadBlog.

How to name your tweak

There are a couple of popular ways to name a tweak:

  • A descriptive name, like MailUnlimitedPhotos - these are great for simple tweaks.
  • A brandable name, like Zephyr - these are great for big tweaks that are here to stay.

When naming a tweak, make sure the name is easy to spell so people can find it when searching Cydia.

Before you release it, search Cydia to make sure a similarly named tweak doesn't exist yet. This is related to another important pre-publishing step: also search to find out if a tweak with a similar function is already available on the default repositories! If your tweak is very similar to something that exists already, potential users might not be very excited about it, so it can make sense for you to pause and add something new before releasing it.

Also, avoid using other people's trademarks or brand names in the name of your product, to avoid making those companies annoyed at you. For the Cydia Store, saurik does not accept products with names with potential trademark problems, and you should also avoid that kind of name for free products. So for example, if you're making a tweak for CoolApp, don't call it CoolAppPlus or anything else that could potentially confuse anyone into thinking it's an official product by that company - instead, call it something original that doesn't include the name "CoolApp", like FreezeToolbar. Making up a unique original name reduces the likelihood that the company will come after you for trademark infringement, and it's also stronger for your tweak's branding - for example, it means that people can more easily find information about your product via Google, instead of being buried in the results for CoolApp.

Related: avoid using other people's logos, icons, or other visual trademarks in your product icon or graphics. If you make a tweak that modifies an app, don't use that app's icon as your tweak's icon. You might borrow an element of that app's icon (such as a similar color), but your icon needs to be mostly original - it needs to avoid confusing anyone into thinking that it's an official product.

How to write a short description

Two examples of short descriptions (in grey).

This short description displays on Cydia's "Changes" tab, under the name of your tweak. You have to make a good impression in approximately 39 characters or less! You should use this field to accurately and simply describe the tweak. Use important keywords because these words are used in Cydia's search feature.

Be clear and concise. Saying your tweak is the "best" or "greatest" in your short description is usually a waste of your precious few characters, since everyone thinks their tweak is the best - instead, it's helpful to use this space to provide a summary of what the tweak does, so people know whether they should tap to find out more. You also don't need to repeat the name of your tweak in the short description.

How to write a long description (depiction)

Error creating thumbnail: File missing
Instead of only a dry list of features, iFile also gives you a way to understand it and a reason to buy it: a comparison to Finder in OS X and an explanation that it's useful for advanced customization.

A great tweak description page (called a "depiction" inside Cydia - see saurik's explanation of it) should include:

  • An accurate and clear description of the tweak and what it does.
  • An explanation for why people might need it. This is a great place to make your tweak stand out - explain to people that it'll make their life easier, or impress their friends, or make their phone look really cool, or whatever it does.
  • Instructions for how to use it.
  • Information about its iOS version and device compatibility.
  • Screenshots.
  • A YouTube video if possible, demonstrating the tweak.
  • A changelog, updated when you release updates. People appreciate knowing what's new.

It's also great to link to reviews of your tweak on blogs. Remember that you can email your repository manager to update the description without necessarily having an updated package as well.

Good examples: Auxo 2 and Pluck 2.

How to price your tweak

See #Advice for choosing whether to make your tweak free or paid (or to include ads) for details about the pros and cons of free tweaks and tweaks with ads.

If this is a paid tweak, the Cydia Store is flexible when it comes to pricing - ask your repository manager for help if you want to set up temporary discounts or a different kind of pricing scheme. You can use discounts as a marketing tool ("if you bought my previous tweak, get my new one at a discount").

If you haven't sold software much before, there's a lot of existing great advice about pricing that you can adapt for your Cydia Store product. For example, here's a long article about how to price software: Don't Just Roll The Dice, by Neil Davidson - it's helpful for thinking about pricing psychology.

If you want to provide a free trial of some kind, you can do that with the Cydia Store as well - for example, MyWi has a time-limited trial, and iFile has a limited-features trial. See Cydia Store Integration for information about the API. This does mean you have to build DRM to manage your trial system; see Advice for dealing with piracy for more about DRM.

How to get the word out

Reaching out to blogs is great!

Make a list of jailbreak bloggers and learn about their tweak preferences. Connect with them and explain why you think they will like your tweak. Send pre-release versions of the tweak so bloggers can have a look at it first. Gift the tweak to the blogger (there's an option for this in Cydia Connect) if it's not free. If the reviewer liked your tweak, keep them posted about future updates - they might want to post again if you do a major update.

Monitor the comment section to collect feedback and answer questions.

How not to reach out to blogs: don't be a stalker, and don't send 47 emails or tweets. Be open to criticism, and don't be sour if a blog doesn't cover your tweak.

How to get your tweak localized (translated) into more languages

Many jailbreakers are multilingual! They may be fine with reading English but prefer to use their device in their native language, so providing localizations is a great way to make more users happier. Ideally a localization includes more than just translated strings - for example, different languages have different punctuation for dates and numbers - but starting with translated strings is reasonable.

Often developers ask their fans to contribute volunteer translations. You can also try asking people on this list of /r/jailbreak members willing to be translators. It's best to offer volunteers a free copy (if it's a paid product), credit them in your tweak or depiction somewhere, and thank them a lot. For a couple examples of ways people have asked for volunteer translations, see this GitHub repository for IfFound² or this one for rpetrich's projects, or this custom system for AnyAttach. You can also use a tool like Transifex.

If you'd like to hire professional translators to work on your project, Tethras is one service flexible enough to work with people developing for jailbroken iOS as well as normal iOS; you can email them if you have questions about this.

Advice about submitting paid products

Products sold via the Cydia Store (or via PayPal with your own payment system) must comply with PayPal's Acceptable Use Policy. PayPal's policy includes that you may not sell products that:

  • "violate any law, statute, ordinance or regulation"
  • "infringe or violate any copyright, trademark, right of publicity or privacy or any other proprietary right under the laws of any jurisdiction"
  • "are considered obscene"

If you submit a product to be sold via the Cydia Store, saurik can also decline it for other reasons. The reasons may include the following, although he makes decisions on a case-by-case basis and this isn't a comprehensive list. These reasons can usually be summarized as: the product has too much risk of causing unhappy customers who will request refunds, and/or the product has too much risk of causing problems with PayPal or the law. Cydia Store products shouldn't:

  • Have faulty or malicious DRM - see Tweak DRM for guidance. Bad DRM makes customers angry.
  • Have marketing that promotes copyright infringement. For example, the product's description and screenshots should not show pirating apps, music, movies, or games.
  • Be likely to stop working right away or frequently. For example, a tweak may be likely to break right away or frequently if it targets a specific App Store app that gets updated often, especially an app that tries to prevent being modified. Even if the tweak developer tries to update the tweak frequently, there is too much risk of customers having a product that isn't working for them and getting angry.
  • Be a game emulator. Unfortunately the Cydia Store can't sell these, since PayPal considers emulators to be supporting copyright infringement.
  • Have major moral/ethical problems, especially ones that PayPal and the law are not going to like. Products marketed as "break your friend's device with this tweak" or "spy on your partner's device with this tweak" are not likely to get approved for the Cydia Store.

The Cydia Store payment system is not required for distributing paid products via Cydia. You can sell a product on a default repository using your own payment system, as long as the repository manager approves. You can also sell a product on your own repository using your own payment system.

Set up an official revenue split for collaborative products

For Cydia Store products, if you've worked on a product with somebody else and the revenue is supposed to be split between the contributors, you should ask your repository manager to set up the product with an official revenue split going to the individual PayPal accounts of the contributors. You and your collaborators can choose the percentages of the revenue that will go to your PayPal accounts. Setting up an official Cydia Store revenue split (before release) means that everyone gets their fair share of the money, avoiding potential disputes with your collaborators and simplifying your accounting (such as for your income tax).

Advice for choosing whether to make your tweak free or paid (or to include ads)

There are obvious benefits to making a paid tweak (money), and there are less obvious but also very important benefits to making a free tweak. You have to choose which is right for you - it's great to get paid for your work, and it's also great to release things for free.

See also: #How to price your tweak.

Some good things about releasing free tweaks

  • It builds your reputation: Especially if you're new to releasing tweaks, people don't really know who you are yet, and they sometimes prefer to install and buy products from developers they trust - the jailbreaking community is small enough that people do recognize names. Releasing some things for free means that tons of people can try your work and start building trust in you as a developer. Gathering an audience of fans means that your later products will be more successful!
  • It gives you a feeling of satisfaction: A free tweak is accessible to all jailbreakers, which is potentially millions of people. It can be very fun to see that many thousands of people are using and enjoying your work.
  • It causes less obligation and less worry: If you know you don't want to do a lot of maintenance work for your tweak (such as updating it for upcoming iOS versions), releasing a paid tweak could make people annoyed at you. People have lower expectations for free tweaks in terms of updates and support (although not zero expectations - people will still expect the tweak to work properly as described).
  • It contributes to the community: Cydia having good free tweaks available (along with paid tweaks) makes the jailbreaking community healthier and more fun. For example, newcomers to jailbreaking usually start with installing free tweaks, and if they install great stuff that they really like, that means they're more likely to stick around and be enthusiastic about jailbreaking in general.

Factors to consider if you're thinking about putting ads in your tweak

  • Will it annoy people? Releasing a tweak with ads is less common than releasing a non-commercial free tweak or a paid tweak. Non-commercial free tweaks have a lot of advantages (as described above) and paid tweaks have advantages as well (money), but ads can be a little bit annoying to your users without making a lot of money.
  • Is it worth it? Related to the first factor, will ads make you enough money to be worthwhile? Mobile ads often don't make much money unless you have a large audience frequently looking at the ads. Do some research (or ask fellow developers) to find out some numbers.
  • Will it confuse your users? Put the ads in a place that is obviously associated with your tweak - for example, on the tweak's settings page. If you put ads in some part of iOS or an app that your tweak modifies, your users may be very confused about where those new ads came from (they may have installed your tweak as part of a large queue of tweaks, for example). If they're surprised by the ads, they may be concerned that malware has infected their phone. In general for free ad-supported products, you should note on your package description in Cydia that the tweak has ads and that the ads will show up in x place. It can also be appropriate to explain the ads on your settings page, saying something like "To support our development of [name of product] as a free product, we've set it up to display ads in [describe place]."
  • Will it confuse pirates? Do you have a paid product and you're putting in ads only for pirate users and not for paid users? Consider that people who "try before they buy" may be confused - they may think the real product will have ads as well. You might consider putting a friendly note on your settings page saying something like "This is a 'trial' version with ads on this settings page. Please purchase this product for $x from the [BigBoss/ModMyi/whatever] repository to help support development; the legitimate version doesn't have ads."
  • Will people ask to remove ads for a fee? If you want to have an "in app purchase" that removes ads from your product for a small fee, the Cydia Store can support that if you'd like to use it. Your licensing system can verify devices against the Cydia Store payment service via the Cydia Store API (see Cydia Store Integration).
  • Will it cause clickfraud? Remember not to put ads in places where people are very likely to accidentally click those ads. Tricking people into clicking ads is considered "click fraud" by ad networks, which is against their terms of service, and they may ban you from their ad network for doing that. Asking or encouraging people to click ads is also considered clickfraud. Make sure to read your ad network's policies - for example, here are the Google AdSense policies.
  • Will it make people very angry? People don't consider it appropriate for paid products to also include ads. They will complain a lot if you try that.

Advice for choosing open vs. closed source

You might also consider releasing your tweak's code as an Open Source Project, typically published on GitHub. The main benefit is that your code can help other developers learn how to do new things, especially beginner developers who are interested in reading sample code. You may also be able to find other people who want to collaboratively contribute to your open source project.

If you want to publish your code, remember to pick a license for your code to specify what other people are allowed to do with it. The top of the Open Source Projects page also explains this, but here's more detail. By default, if you don't pick a license, your code will remain fully copyrighted by you, and other people will only legally be allowed to read it and learn from it (they won't be able to reuse any portion of it or redistribute it) - if that is what you want, you should make a clear note of this copyright status in your README to avoid people getting confused into thinking they're allowed to republish your code because the code is available to view. If you want people to be able to fully reuse and redistribute your code (including allowing commercial/paid redistribution of your code), you need to specify that by adding a "free software" license to your code (in your README and/or in a LICENSE file), such as the MIT or GPL licenses - see How to choose a license for your own work and Choose A License for advice on which license to choose. GitHub also explains how to add a license to your repository.

Note though that people can ignore licenses - if you publish your code and say in the README something like "this is copyrighted code; please don't redistribute this, especially not for money", people can ignore your wishes and try to submit your work to a default repository as a free or paid package. This happens occasionally; if you notice that a default repository has accepted a package because they didn't realize it's made of code copied without permission, please send the repository manager a report of the problem.

Often people publish open source code for their free tweaks, but you can also publish the code for a paid tweak. That probably won't even reduce your sales much, since most people don't know how to compile projects (or don't want to bother), or know it's better support the developer, so they'll still buy it via Cydia.

After you release your tweak (but read before releasing it)

Advice for testing and releasing updates

You know you need to test your initial version thoroughly, but it's also very important to test your updates thoroughly before pushing them. This is true for free packages as well as paid products. Small changes can have unexpected side effects, and problems with updates can be very frustrating for users and reduce their trust in your work (even if you publish a fixed update quickly). You can ask friends to try test versions on different devices with different tweak setups to check for problems.

(What does "small changes can have unexpected side effects" mean? Changing one part of your code to fix or add something can break seemingly unrelated things in your tweak. A good practice is to make a checklist of all the major features of your tweak, including common actions that users might do, including changing settings. After you make a set of improvements to your tweak, take a moment to go through the checklist and test that list of common actions. This checklist step might feel a little repetitive but probably won't take very long. It's a simple form of regression testing. After you do the checklist, ask other people to try the product on their own devices, since jailbroken device setups can vary widely.)

If you don't know anyone to help you test, you can try asking on the developer IRC channels, where you can find fellow developers and help each other. This is also an interesting reason to maintain a Twitter account as a developer - fans who like your work will follow you for updates, and you can ask a few of them to be beta testers for updates. A lot of people are happy to volunteer to test packages that they enjoy using. Be extremely cautious if you're distributing a beta version of a paid tweak - you will want to stick to close friends and fellow developers, because untrustworthy people may leak the beta to their friends and to pirate repositories. (That kind of leak has happened more than once and can be a big headache.)

You can use Theos to make a .deb package for distribution (see Packaging for more advice), and your testers can use iFile or dpkg (or similar) to install the .deb file. If you'd like to maintain a beta repository to help you distribute beta versions to testers, see Repository Management for advice.

Advice for handling criticism and improving support

If your tweak is rejected from the repository you submitted it to, that's not the end of the world. It happens. The important thing is to listen carefully to any feedback that you got from the repository manager (they have a lot of experience and expertise) and to continue improving your work and learning new things. That way, you will learn to accept failure and learn from your mistakes, as well as gain even more determination to develop for the jailbreak community.

Also, don't fear criticism. It comes along with with success and having lots of real people use your work. Learn to ignore the bad, and if possible, learn from the mistakes that cause the criticism. Try to look for the deeper problems and patterns that cause complaints, so that you can fix the core problems. Hate emails also happen. Reply politely or simply ignore the hate, do not let it gnaw away at you. If you find yourself getting angry about something legitimate but critical that a person has said about your work, take a breath, step away from the computer, and take a break before responding so that it's easier to respond calmly.

Improving the experience of using your product

You can help yourself minimize support problems and angry users by providing helpful explanations for your product, especially if your product is complex, contains numerous features or is not very intuitive. If you keep getting questions about the same thing, consider whether you can improve your explanations so that you don't get that question.

  • Make sure your package description in Cydia includes a complete description of the product. Videos are really helpful here too. Ask a friend or beta tester to look at your package description and give you advice for improving it, since it's easy to forget to include something that seems obvious to you (as the person who made the product) but is not obvious to other people. See also: #How to write a long description (depiction).
  • In your preference pane, take some care to explain the details. Maybe add a demonstration video linked from the preference pane (hosted online to not waste the precious space in our devices). If you can't fit the objective of an option in the cell, set it up as a single group with a footer text explaining what the option does.

Improving your support

This is a nice article about the basics of improving your email support, including: manage expectations (such as being clear upfront in the tweak description about the level of support you can provide), use annotated screenshots to help explain things, put some documentation and FAQs online so that people can read it and you can link to it, don't take things personally, tell a customer when you have fixed their bug, and never send an email in anger.

If you're working on a paid tweak that has a lot of users, consider using a professional support ticketing system for email support instead of just using your personal email account. A service like Zendesk can help you stay organized, including setting up auto responses based on email keywords for frequently asked questions. Other options similar to Zendesk include Freshdesk and Helpscout.

There are some examples of developers maintaining public support forums to assist in helping their users:

Some developers have created subreddits for discussion of their tweaks. These include /r/Convergance, /r/cylinder, /r/DynamicText, /r/FlexTweak, /r/nintype, /r/LockHTML3, /r/ProWidgets, /r/Springtomize, and /r/XPasscode.

It can be helpful to write some public documentation on the web and link to it from both the package description in Cydia and from your tweak's settings. Here are some examples:

Advice for dealing with piracy

If you build a way to check whether your tweak is pirated, you may be surprised to see a high piracy rate compared to purchase rate, and this can feel pretty disappointing - it feels disrespectful, and it feels like you're losing a lot of money. But for a variety of reasons, many pirates aren't actually able to buy tweaks - in other words, these are not sales you would have been able to make. It's best to try not to spend a lot of effort worrying about this and to instead focus on your paid users and the fun parts, like improving your tweak and spreading the word about it. (See the marketing section above for advice about increasing sales!)

If you're considering building systems to prevent piracy, see Tweak DRM for lots of advice (philosophical, practical, and technical).

Even though piracy can be really frustrating and discouraging, we have to treat all users and their devices with at least a basic amount of respect - it is not OK to harm devices in revenge for piracy, and writing nasty email replies isn't a great idea either. Writing malicious DRM, or even joking about it, unfortunately, can be incredibly damaging to your brand and users' trust in you. There are many pirates who decide to start buying tweaks after getting to know developers better (such as via Twitter or /r/jailbreak) and starting to see them as fellow humans who do hard work that is worth supporting. There are also pirates and even tweak crackers who get to know the community better and decide to switch to development and selling tweaks, or other forms of contributing to jailbreaking in helpful ways.

Understanding reasons for piracy that aren't lost sales

Context that may be helpful:

  • Some jailbreakers are too young to have a credit/debit card or bank account, or too young to legitimately register a PayPal or Amazon Payments account. Their parents may not be willing to purchase tweaks for them. Sometimes young people in the United States can use cash to go to a store and buy pre-paid debit cards like Vanilla Visa, but not everyone has access to doing that. Also, not every young person has the opportunity to make money (limited opportunities in their area, parent requirements, etc.).
  • Some jailbreakers don't realize that they're pirating tweaks. This can easily happen if their friend jailbroke their device and installed pirate repositories for them, or if they trusted YouTube instructions without paying attention to Cydia's piracy warning for repositories.
  • Some jailbreakers use piracy to "try before they buy" because they want to be really sure that the tweak works for their setup in the way that they want, even though this strategy has its own problems. (Pirate repositories often have outdated versions, incorrectly configured conflicts/depends, poorly-cracked DRM, and other problems.) They may use a pirated version for a while and then buy the package if they decide it works well for them. To give potential customers more confidence to purchase without pirating, it helps to include a great demo video and lots of detail in your package description. With some extra work it's also possible to use the Cydia Store API to allow users to trial the full package for a limited time, or to require payment for particular features (similar to an in-app purchase).
  • Some jailbreakers don't have the money to afford tweaks. This might seem counterintuitive - that they have an expensive device and perhaps an expensive service contract but can't afford a tweak. But there are many situations where this makes sense: they may have received their iOS device as a gift, or they may have purchased it a long time ago when they had more money available, or they may have purchased a used older device. They may have an inexpensive pay-as-you-go service plan instead of a fancy service contract. They may also live in countries with lower salaries and lower cost of living, where the equivalent of a few US dollars represents hours of work for them instead of less than an hour.