End of the project

From Iphone
Jump to: navigation, search


One of the hardest parts about finishing an iPhone app is to FINISH it! As the project draws to a close, there seems to be a constant stream of ideas to make it better.

You gotta ship, sometime.

  • The whole point of undertaking this development project is to ship an app. During development, you are likely to think of dozens (maybe hundreds!) of ideas for how to make it better

. It's important to set a limit to the v1.0 of the product and eventually finish it. This is not to imply that v1.0 should not be the most polished, spectacular app you can make it, only that it needs to ship, at some point, or all the work is for naught. It helps to group your ideas into 3 categories:

    • Items which are critical to the success of a v1.0 product.
    • Items which will greatly improve the original, and which should come soon after in a dot-release update.
    • Items which need more consideration, or which take the product to the next level, and which should be considered for a more distant future update.

Testing is critical.

  • In order to save the client money, we typically do basic feature testing during development, and a full feature run-through near the end, but ask the client to do the bulk of the testing.
  • While we are capable of doing in-depth testing, we typically divide the workload this way in order to reduce both calendar time to deliver and project cost.
  • Most issues found are cosmetic or flow related, and so simply described.
  • If a bug (program problem) is found, the most important information to give your developer are:
    • What did you do?
      • In particular, what steps would I have to follow in order to see the same thing on my device that you're seeing on yours?
    • What did you expect to happen?
    • What happened, instead?
    • If the app crashed (rare), please include a crash log with your report.


  • In addition to testing that the app does everything it should, it's very important to make sure that the app doesn't do anything that it should not!
  • It's also important to make sure that the app works under all circumstances, not just "if everything is going just-so." For example, your app should be tested under the following circumstances:
    • With the phone turned off.
    • With no network (in "airplane" mode.)
    • During a phone-call or calendar alarm interrupt.
    • If your app uses a server, it should be tested with a simulated server outage.
    • Etc.
  • In all cases, the app should respond in some reasonable and helpful to the user way, regardless of the exceptional circumstances.
  • Beyond "normal" exceptions, one should make sure the app is "bullet proof." That is, one should view the app from the perspective of "if I wanted to make this app crash or otherwise misbehave, how could I do that?", and then test how it does under those circumstances.

Preparing to ship