iOS development tools checklist – Project work made easy

iOS development tools checklist. There is a lot of good tools and habits that will help you with development. In this post I’ll list the ones that have helped me the most. These tools and habits will help you to write better looking code, reduce the number of errors and simplify the release process of your iOS application. These tools will also make your application easier to maintain. I won’t be listing the best libraries that will help you develop better applications. This post only focuses on tools and habits that will make your project work more effective.

You don’t need to use all of these incase you are working for a short period of time to produce an MVP(Minimum Viable Product). But if your project last for  a longer period I highly recommend them for you. Also keep in mind what a colleague of mine said the other day “MVP does not mean you can write crabby code.”. So you might want use these in all of your projects.

The aim is to provide a tool and work habit checklist for every developer out there, regardless of the experience. So bare with me if you think some of these things feel obvious to you. If you think the iOS development tools checklist is missing something, please let me know! I really want to hear about your favourite tools, which would make my life easier :).

iOS development tools checklist

I’ll first list all the items on iOS development tools checklist, and then go through them one by one:

  1. README -file
  2. Version control
  3. Code review (Gerrit, PR)
  4. CI (Jenkins, BuddyBuild, CircleCI)
  5. Fastlane
  6. Scheme and launch argument configuration
  8. Swiftlint
  9. BartyCrouch

Version Control

First thing on the iOS development tools checklist is version control. There are a lot different tools available such as GIT, VNC, Mercurial and Subversion. I personally prefer GIT. It is faster compared to others, and I also like how easy it is create a new branch both locally and to push to GIT server. The biggest draw back on GIT is the learning curve. It takes a little bit effort to learn to use it, but after you’ve figured it out I think you won’t look back.

You can get a free GIT repository from sites like GitHub and BitBucket. Just create an account and then create a repository for you project. Atlassian, company behind Bitbucket, has also developed a terrific tool called SourceTree. It is a GUI for GIT and I have found it very usefull.

README -file

Second thing you should do when starting a project is to write a README -file. It should contain all the information needed for someone to start writing code for the project:

  1. What branches are used (for example development, release, QA)
  2. Short description how to compile the project. This is helpful incase you are using 3rd party components from Cocoapods etc.
  3. Short description about the project architecture. (MVVM, MVC…)
  4. Coding style guide. Incase you don’t have one (I don’t), Ray’s Swift style guide is pretty popular and very good.
  5. Description about the Scheme and build configurations.

I think these are the minimum requirements for a README file. But put anything you find important to it, that will help people to start working with the project. Remember also to keep the README file up to date.

Code review

Code review is one of the most important things in a software project. Please, please, please use it in your project. The main reason for code review is to catch errors and mistakes. But I think even more important thing is to teach and learn! There is no better way to learn about coding than code reviews. Incase you have the opportunity to work with developer who knows more about stuff than you, the insight that he provides to you is invaluable. The best way to learn is from someone that knows more than you. Incase you are the senior programmer, code review allows you to teach your fellow programmers and help them get better at their work. The overall benefits in code review are:

  1. Code is better.
  2. There are less errors.
  3. The knowledge in your organisation is spread.
  4. Everyone is getting better.

You can use code reviews even if you are working alone. It is usually helpful to go through your own code after you created a commit. Take a coffee break, lunch or check the code the next morning with fresh eyes and mind. At least I usually find somethings that are not quite the way I intended them to be.

You can use tools such as Gerrit to help you with code reviews. Or if you are using pull requests to get your commits to master branch, those are also easy to review.

Be kind when giving feedback

One final word of warning. Sometimes with a tight schedule and pressure it’s not so pleasant to hear that the code you have written needs to be refactored. Always comment with good intentions and never badmouth anyone in the project. Remember also to give good feedback, if a peace of code looks very good! And when you are reading comments about your code, remember that no one is blaming you. We are all friends here and we are supporting each other to get the best possible product out. And to become better developers while doing it.

Continuous integration build

Next item on the iOS development tools checklist is CI. Always set up a CI-build for your project. CI should compile and run tests every time a commit is pushed to a branch. With a solid set of unit tests CI becomes one the most important tools you can have. This specially comes in handy if you are making some changes to an existing piece of code. You might not remember all the requirements and decisions that was made when the code was originally written. When CI runs tests for the refactored code, if all tests are passed, you can safely assume that it is working as it should!

In our company we use Jenkins as the go to CI tool. It works with iOS, Android and Web applications and is highly configurable. Other useful tools are BuddyBuild and CircleCI which both works for iOS. BuddyBuild was acquired by Apple at the beginning of 2018 so it won’t be supporting Android builds anymore.  CircleCI works both with iOS and Android.


Next item on the iOS development tools checklist is Fastlane! With Fastlane you can automate your build and release process. It is the best time, money, headache saver you can have in your project. Imagine that you are building an application. The project is in the phase where you have already released the app and the development continues. You have 3 types of builds:

  1. Nightly builds for internal testers to test previous days features.
  2. Testflight builds for external testers to test the upcoming feature sets.
  3. Release builds to update new version to App store.

Each of these builds have their own provision profiles to sign the package. Every time you need to make a release you need to use the right one. You can achieve this by defining the schemes and selecting the correct one, but wouldn’t it be great if you wouldn’t have to worry about it at all?

With Fastlane you can define specific “lanes” for each one of these cases and you can integrate it with your CI. Every night Fastlane would run the lane “nightly build”, compile and sign your project and upload it automatically, for example to HockeyApp. Also the App Store and Test Flight releases can be automated. So instead of you choosing the correct provisioning profiles and targets, you could just say: “fastlane appstore_release” or something similar. Or even better, configure you CI build to run these lines. When commits are pushed to master branch, CI will test the codes and then automatically run Fastlane line to release the app to Apple Store!

Since we already mentioned it here few times, let’s next look at the scheme configuration for the project!

Scheme configuration

Set them ones, set them properly! Schemes can make your life so much easier. Imagine that you need to provide few different kind of releases depending on where you will send them. You have to make releases to Apple Store. You might want to provide AdHoc build for testers or client to test a new features. And you might also want to have one scheme for everyday development.

In the image below you can see 3 different schemes defined for Friends project:

  1. “Development” scheme –  used when deploying the app from Xcode to a simulator or to a device.
  2. “Development Release” scheme – used when AdHoc build is required.
  3. “AppStore Release” scheme – used when releasing the app to Apple Store.
iOS development tools checklist - schemes for a project

Friend projects schemes

You can define the correct provisioning profile for signing for all these schemes. Then you don’t need to scratch your head everytime you are making a release about which one to use. Incase you are working with multiple projects at the same time, this can become a burden. Now you only need to select the correct scheme and you are safe.

Add Launch arguments to Schemes

Another great thing with schemes is that you can define launch arguments and active them accordingly. If you are using a test server, you can define a launch argument which defines if test server should be used for that build. Incase it is a development build you set this argument active and check it in your network code when selecting the url to connect to.

iOS development tools checklist - define launch arguments to help selection between production and test server

Launch arguments defined for Friend projects Development scheme

In the code you can check the argument like this:

In the scheme that you want to use the default production server, just make sure the blue check mark is not checked on the left side of the argument.

Another terrific argument to know is -AppleLanguages. It is provided by Xcode so you only need to define a new argument for example -AppleLanguages (fi). Then, when you activate it and run your app, it will be run with the selected language (this case in finish). Remember that you also need to have all localization files in place for that language ;).

Schemes also work with Fastlane! So if you have automated your release process with Fastlane, schemes and lanes play well together. Just define which scheme you want to use, referring it by it’s name, and you are done.


Next item on the iOS development tools checklist is Changelog. Changelog really helps you you keep your project and releases organised. Always keep an Unreleased tag at top of the file and under it write down all the changes you’ve committed.  Your changes falls in to 6 categories:

  1. Added
  2. Changed
  3. Deprecated
  4. Removed
  5. Fixed
  6. Security

When you make a new release just write a new tag under the Unreleased -tag where you provide version number and date to the release. -file goes to your version control and you update it with every commit. When you use it correctly, you will always keep on track which version introduced which features and fixes. Read more about how to keep a Changelog here.


Next item in the iOS development tools checklist is SwiftLint! As I mentioned in the README-section, it is good to have coding style guide for your project. But sometimes it is not so easy to follow it. This might make your code hard to read. To the rescue comes SwiftLint! Swiftlint is a tool created by Realm. It has predefined set of rules which loosely follows the Swift Style Guide. For example: maximum line length, how to use spaces when creating a closure, max number of line breaks between code lines etc. Now this all might sound a bit overwhelming, but trust me it will make your code look a lot better.

You can activate and disable the rules as you see fit, and create your own. You can also define the alert level of the rule breaking. Xcode shows an error or a warning depending on which rule you break. You can also silent some error/warning incase you want to make an exception for some case. Follow the link to read more about SwiftLint.


BartyCrouch is a tool that will help you with your storyboard and xib file localizations. In case you only have one set of storyboards, (not one for every language), you definitely want to check it out. It incrementally checks the strings from your storyboard files to localisation files. Incrementally means that it won’t override the ones that you have already translated.

This tool has greatly helped me to keep my sanity with localisation process. I am not saying that it is perfect even now, but at least it is a lot better. Read more about how to use it here BartyCrouch.

iOS development tools checklist – Conclusion

There are a lot of tools and habits that will make your life easier as a software developer. The ones that you just read are the ones that have helped me the most. This list works best when you are setting up your project, but you can of course also add them to you project later on. As said, you don’t need to use them all, but pick the ones you think would helps you the most.

What do you think? Are you already using these tools and practises? Is this “iOS development tools checklist” already complete or is there something missing on the list? What is your favourite tool?

Thank you for reading and have a great day my friend!