App Distribution Sites

I have found these services that support mobile app distribution. I have only used TestFlight so far because it is the only free service.

I am looking for another free service like TestFlight that supports other platforms besides iOS and Android. I would also like to distribute private Tizen apps but have not found a free distribution site yet.

I will continue to list more app distribution sites here. If you have any suggestions, please let me know.

The iOS Developer Handbook

Getting a new developer up to speed on an existing team is an important job and must be done quickly and effectively. Doing that on an iOS team is even more time critical, due to the shortened nature of typical iOS projects. This process can be very time consuming and can be frustrating to the new developer if not done carefully.

After going through this process over and over for the past few years, I decided to create this iOS Developer Handbook as a more formal guide to use by other teams who struggle with this initiation period. This guide will help new iOS developers get started on a new team. The ideas in this handbook have been collected over the past few years from lists I created while on-boarding new developers on my teams.

iOS 7

This handbook is even useful to those who are not that familiar with iOS

development. Often times managers who are on-boarding new iOS developers have no experience with iOS development, or are not that familiar with all of the needs of an iOS developer. This handbook will guide you through all of those needs, step by step, with a little explanation of each step to help you better understand the environment in which they work.

I will try to keep this list in the order in which you should address them. However, as you get further down the list you may find the order is not as important as just getting these things done.


I always like to get started with email. Each new developer on a team will need an email account on the team’s email system. We normally use Gmail corporate accounts, but you are welcome to use any email that is available. This email account will be used often for team communication and notifications from some of the development tools used by the team. Make sure they have an email address that is functional before they start. Get your email administrator to setup the mail account well before their start date.

As younger people enter the workforce we find them less likely to have used email in the past. Due to the adoption of social Gmailnetworking with their own internal communications systems, the use of email outside of the workforce has diminished greatly. You should keep this in mind when introducing email to your new developers. Some of them may have never used email before, and many of them will often forget to check it.

Even before your new developer starts, you can include them in group emails and calendar events. When they first login to their email account they will have some interesting email to read, and possibly a few calendar events to accept.


Everyone needs a place to sit and developers are no exception. Make sure they have a desk nearby other developers who can help them get started.


There are a few things that should be noted about your new iOS developer before they start. You can send these details to the team so they are informed properly of the new member’s arrival.

Title: the title for their role on the team
Manager: the name of their manager
Location: the office location and address
Start date: the actual date the employee plans to start


Apple MaxBook Pro 13"Most likely your new iOS developer will be using a MacBook Pro laptop. All iOS development is done on a Mac. Even though you can use any Mac for development, the most common one will be the MacBook Pro. It offers the most convenience and power of all of the Mac line of computers by Apple. Get one that is no more than one (1) year old with at least 8 GB of RAM and a 13 or 15 inch display. If you skimp on this laptop you will notice a degradation in performance of your new developer, and a lot of frustration. The Xcode IDE application that is used for most of the iOS development work is memory intensive and consumes a lot of system resources. You want to make sure this tool runs as smoothly and efficient as possible.

Ask your IT department to have this laptop ready a few days before arrival of your new developer so you can check it out. You need to verify that it has the correct specifications for an iOS developer.

Apple ID

Each iOS developer needs to be part of the iOS Developer Program at Apple. They must have an Apple ID to register with the program. More than likely they already have an Apple ID because of their use of iTunes. Have them create a new Apple ID if they don’t already have one, or if they prefer to have a separate one for work.

The Apple ID will also be used to access the Mac App Store where they can download Mac applications like Xcode and Evernote.


Xcode 4.6.3 About windowAfter your new iOS developer has their beautiful new MacBook Pro in their hands sitting at their new desk, get them to download Xcode from the Mac App Store. This is a free download that is over 1 GB in size and will take a while on most networks. After downloading and installing Xcode, they will be ready to start coding. They can use the iOS simulator for most of their testing and it works very well.

iOS Device

Even though most of iOS development is tested on the iOS simulator, it is still important for developers to have their own iPhone or iPad. You should get your iOS developer either an iPod Touch, iPhone, or iPad for their full time use. Make sure it is not any older than 1 year.

Developers will use these devices for testing the apps they build, and also to learn about other apps. There is a lot of valuable information gained by using other well-built apps, and understanding how apps are used is essential in becoming a good iOS developer.

It is not good for a developer to be without a primary iOS device. This will slow down the learning of iOS and building good apps. Sharing is welcomed for secondary devices when they are rarely needed. Talented iOS developers will always have an iPhone in their possession. You should encourage that if they are new to iOS.

Online Conferencing

Most development teams will be involved in meetings with people outside of the office. The meetings are usually hosted online using web conferencing software like Google+ HangoutsGoToMeeting, Skype, or WebEx. Create an account for your new developer so they will be able to get online to your next meeting before the meeting starts. These conference tools often require significant setup time and should be completed well before the meeting starts.


All developers will need a headset so that the sound from audio chat and conferencing does not get blasted across the office and disturb others. If your new developer has an iPhone they can use the headset that came with the iPhone. If they don’t have their own headset, consider getting them one.

Project Management Tool

All iOS software development teams use some kind of project management software like JIRA, Pivotal Tracker, or Basecamp. These tools are available online and provide developers with a list of stories and tasks to be performed. You need to create an account for your new developer on your project management tool. Please use their new team email for their account.

Give each new developer a hands-on tutorial with this tool. They need to feel comfortable finding their way around so they will eventually be able to utilize it. They should be added to any existing projects in the tool that they are working on.


Most iOS development teams have an online wiki used for the documentation on iOS projects. If your team uses a wiki like Confluence or MediaWiki, make sure you create an account for your new developer. If you are not using a wiki, make sure you give your new developer access to the documentation they will need for their projects.

Online Chat

To keep the developers on iOS development teams in constant contact with each other throughout the day, they will need some kind of real-time instant messaging app. This tool is usually Skype, AIM, HipChat, Google Talk, or Google+ Hangouts. Make sure the developer has an account with the team’s designated chat tool, or have them create a personal one. Send an email to the entire team with the username of the developer’s chat account so everyone will have it.

Desk Phone

The old corporate desk phone is mostly on the way out for iOS development teams. They are now using various other tools for voice communication like chat or conferencing. In the unlikely event that your company still uses the old telephone, make sure your new developer has an assigned number.


Your company is most likely keeping track of time with some kind of online time tracking tool. If so, make sure you create an account for your new developer. Also, give them a hands-on tutorial so that they will track their time accurately. Their is a good time tracking tool by TM Software called Tempo that is a JIRA plugin. We have used this successfully on our projects.

Dropbox and Google Drive

The fastest way to share large files on the Internet is by using an online cloud storage tool like Dropbox. This tool, and others like it including Google Drive, will automatically sync files from your MacBook Pro to the cloud. Most teams use a tool like this. Have your new developer create an account for this tool, and then you can add their account to your shared folders.

Google Docs

I like using Google Docs to create presentations, slide shows, charts, and diagrams. Since most developers have a Gmail account, they have access to Google Docs in their Google Drive. Show your new developer how to use Google Docs and add them to any shared folders they will be needing.

Email Groups

If your team is using email groups, or email distribution groups, your new iOS developer should be added to the relevant groups. Send a welcome message to the team so everyone knows the new developer has been added to the group.


Most if not all iOS development teams are using some kind of online cloud storage tool for source code. Many of them use GitHub to host their Git repositories. If your team is using GitHub you need to add your new iOS developer to the team repositories. Your new developer may already have an existing GitHub account, and if so, that personal account should be used. If they don’t already have a GitHub account they should create a personal one and have you add it to your Github team. Another good free online source code repository is BitBucket.

If your team has internal source code repositories for Git or SVN, make sure you add your new iOS developer to those systems.


When iOS development teams are producing builds of their iOS apps they often use TestFlight for easy installation of those apps. This makes it easy to distribute those apps so they are quickly installed and tested. Invite your new iOS developer to the project team on TestFlight and also add them to any existing distribution lists.


Many iOS development teams are using continuous integration (CI) to prevent integration problems and have opted to use Jenkins as their integration server. If your team is using Jenkins, Hudson, or any other integration server, create an account for your new iOS developer on your server.

Gimp and Pixie

PixieHave your new iOS developer download Gimp and Pixie to use when fine tuning the iOS UI. The Gimp Mac application is a great image manipulation tool like Photoshop except that it is free.

We use the free Pixie tool from Apple which is part of the Graphics Tools for Xcode. We use this tool to inspect high fidelity mockups of the app UI to determine precise pixel layout of the UI. You quickly and easily zoom in on text and graphics to determine precisely how they are built and laid out.

The First Meeting

On the first day for your new iOS developer you should have a short private meeting to discuss the team and other details of the organization. Here are some of the details that I go over with my new iOS developers:

  • core working hours: the time to normally expect your new developer to be working
  • mobile number: their mobile phone number
  • personal mobile devices: gather a list of their mobile devices, types, and OS versions
  • currently scheduled vacation: note their days off that have already been planned
  • describe first project: share details about the first project or assignment

iOS Developer Program

Each iOS Developer must be part of the iOS Developer Program to be able to install development builds onto an iOS device. I am not planning to provide details about the iOS Developer Program in this article. Just make sure your iOS developer creates an account on on the iOS Dev Center and you add them to your Member Center team.

Your iOS developer will not need to be part of the iOS Developer Program to build and run apps in the iOS Simulator.

My Checklist

Here is the on-boarding checklist I am using for new developers. Feel free to copy this list and use on your projects.

  • Email
  • Desk
  • Title
  • Manager
  • Location
  • Start date
  • Laptop
  • Apple ID
  • Xcode
  • iOS Device
  • Online Conferencing
  • Headset
  • Project Management Tool
  • Wiki
  • Online Chat
  • Desk Phone
  • Timesheets
  • Dropbox and Google Drive
  • Google Docs
  • Email Groups
  • GitHub
  • TestFlight
  • Jenkins
  • Gimp and Pixie
  • The First Meeting
  • iOS Developer Program


I wanted to create this iOS Developer Handbook to record the notes I had been keeping in Evernote for a long time. I have been sharing these notes with others to help them onboard new iOS developers, and have been incrementally improving this list over time. I love using Evernote because it’s seamless across my iPhone, iPad, MacBook Pro, and the web. However, I felt that this list needed to be located in a more reachable location for everyone, like in this blog post.

Notice that I did not mention team calendars in this article. I have never had any checklist items for calendars. I am not sure why but I guess its not really that useful to iOS developers. You can make your own decisions about calendars for yourself and your team.

I will continue to update and refine this list as time goes on. It will need to keep up-to-date with iOS as it continues to change. With the upcoming new releases of iOS and the hope of new iOS SDKs for iWatch and iTV, I am sure there will be more and more useful tools that need to be rolled into the day to day life of an iOS developer. So look for updates to this list and check back often to read the wonderful comments of those who join you in this great group of developers.

I welcome all comments regarding this developer checklist and handbook. Please feel free to add a comment to this blog post if you have questions or comments.

-Larry Aasen

iMessage Does Not Support Screen Sharing

With the Messages app on Mac OS X you can easily start screen sharing with another Mac. This is very helpful when you need to assist someone else with a problem on their Mac. You can see their entire screen and can also move their mouse and type on the keyboard.

One thing I find disturbing is that iMessage on the Mac does not support screen sharing. I had been using iMessage for a while now, but was also using Bonjour and Jabber. I had no idea that screen sharing was not using iMessage. So, when using the Messages app on the Mac, you are required to use Bonjour or Jabber.

From the Messages help file:

“You can share screens using AIM (including and, Jabber, Google Talk, and Bonjour. You can’t share screens using iMessage or Yahoo!.”

Someday soon I hope that new users of Macs will be able to quickly start using the screen sharing feature with iMessages. Maybe Mavericks will support this soon.

Git diffs that are nothing

I was looking at this Git check-in today and notice many changes that showed up in the diff that were not really changes. I am not sure why diff identified them as changes, but maybe some tabs were converted to spaces or something like that. When lines of code are identified by diff as changed, but there are really no changes cause clutter in the commit. It is hard to determine exactly what has changed and others who review the code will have to spend extra time analyzing diffs that turn out to be nothing.

A good thing to remember to do before committing code to Git is to remove changes from your files that show up in diff, but are not really changes. Using the SourceTree app this can be done easily. It lets you discard parts of the file that show up in diff that really did not change. Check all of the changes in all of the files you plan to commit first, and then commit.

This will help others in the project and keep the commit logs clean.

LAWalkthrough – a view controller class for iOS

Yesterday I published my first CocoaPod for the LAWalkthrough class, a view controller class for iOS designed to simplify the creation of the walkthrough design pattern.

This class was inspired by the screenshots displayed at by Mari Sheibley. It is simple to use and requires very little code to implement a nice looking walkthrough. It uses UIPageControl and UIScrollView and is easy to subclass for customization.

See the documentation on GitHub for more details.

5 Features Your App Does Not Need

There are so many features added to mobile apps these day that just are not needed. They cost a lot of time and money to build, and take away from wonderful new features that user’s could enjoy. I have listed my top five (5) favorite features that are not needed in your mobile apps. When you create a new app you will not need these features until after your app finds a user base.

#5 About

The About feature is found in every app and serves no purpose to the user. This usually includes the Privacy Policy that nobody reads, and other legal messages that are meaningless to anyone but lawyers. I think we should stop wasting time building these meaningless features and spend that time and money on something functional.

#4 Ads

The only reason users put up with ads in mobile apps is because they are using the apps for free. Those ads serve no purpose to the user and clutter the screen. Ofter ads are not at all relevant to the user. I don’t mind interstitial ads once in a while because they usually look nicer than banner ads and do not clutter the normal app user interface. I think banner ads in mobile apps should be eliminated as a revenue source and other revenue streams explored.

#3 Walkthrough / Tutorial

Those beautifully designed walkthrough experiences that you see in apps like Evernote and 500px are not really that helpful. If your users don’t understand your app, or don’t understand how to use it without the tutorial, you should reconsider the user experience of the app. Time for a redesign based on user feedback.

#2 Tell a Friend

It is nice to have an app explode on the scene with lots of viral networking and without advertising. Think Instagram. However, the Tell a Friend feature in the app does not really contribute to that networking affect. If the app resonates with users it will be a hit. A lot of expensive UI design will not guarantee success. Beautiful does not sell. What sells is usefulness. Make sure your app resonates with user and entertains them or solves their problems.

#1 Rate This App

It is important to have lots of good ratings for your app because those stars can play a big part of a user’s decision when downloading an app. However, nudging the user to rate the app is annoying and may be counter productive. Don’t count on this feature to boost your high ratings. It may, possibly, boost your mediocre ratings.

The Mobile Six Pack

I have often been asked these two questions about building mobile apps:

  1. What size mobile team is needed to build a specific app?
  2. How long will it take to build this app?

After answering these same questions over and over for the past three years, I have come to the conclusion that most mobile app projects need to be completed quickly, and most can be first launched with an MVP, or minimal viable product.

I usually conclude that it will take about 3 months to complete a mobile MVP and most product companies like that time frame. Its not too long and not to quick. Its just about right.

I also usually conclude that the team should consist of three software engineers (SE), one quality assurance engineer (QA), one designer (UX/UI), and one technical manager (TM). The team is usually about six people and looks like this:

  • TM (1)
  • UX/UI (1)
  • SE (3)
  • QA (1)

After creating this same team structure over and over for mobile apps I realized there was a pattern growing here. There was always around six people involved in the team. Some of those six are not allows 100% allocated to the project, but for most members of the team, they are allocated 100% of their time.

A few months ago I coined the phrase “The Mobile Six Pack” to describe the default team size and configuration of a mobile development project. Since I usually concluded that the team size would be six people, I started using the term Six Pack. After a while I realized that this team configuration was only being used on mobile projects, so I tossed in the word mobile. Then I realized I had a memorable name for a mobile team: The Mobile Six Pack. After a while of using The Mobile Six Pack it started catching on with other colleagues because it was easy to remember, and it sounded pretty cool.

Not all mobile projects end up with the same resource configuration, but a good rule of thumb is a nice place to start. I am sure many of you would agree that this is consistent with many of the team proposals you have created.

#MobileSixPack @larryaasen