Ahmed edited this page Jan 14, 2015 · 5 revisions

#iOS Checklist

Naming Conventions

  1. Developer should consider the Objective-C coding guidelines. (https://developer.apple.com/library/ios/documentation/cocoa/conceptual/CodingGuidelines/CodingGuidelines.pdf).
  2. Developer should use code formatter to let his code be more readable. (https://github.com/octo-online/Xcode-formatter)

Memory Management

  1. Developer should decide to use manual memory management or ARC
  • If manual memory management

    1. Developer is the owner of all objects that he allocated, retained or copied.
    2. Developer should release the object he owned at the end of the lifetime of its pointer or when moving the pointer away from referencing it.
    3. Any local variable/pointer used inside an Objective-C block for a read-operation is captured as a copy and its lifetime is the lifetime of the block object. Developer should nullify it after the original ownership released.
    4. Any global variable used inside a block or a local variable/pointer used for write-operation. Developer should declare it by __block modifier.
  • If ARC

    1. __block, __weak, __strong, __unsafe_unretained are storage modifiers for variables/pointers. Developer should use them to express ownership.
    2. Any variable/pointer is strong by default. Developer should not weakify a variable/pointer in the same line of object allocation.
    3. If a variable/pointer is strong, its object is released at the end of its lifetime automatically or when moving its pointer away from referencing it. Developer should take care of this.
    4. Developer should obtain a strong (__strong, __block) reference to objects that he wants to own.
    5. Any local variable/pointer used inside an Objective-C block for a read-operation is captured as a copy by the same storage modifier and its lifetime is the lifetime of the block object. NO need for a developer to own them inside the block.
    6. Any global variable used inside a block or a local variable/pointer used for write-operation. Developer should own it by __block or __strong storage modifier.
  1. Developer should analyze his code by Xcode static analyzer.
  2. Developer should profile the app using instruments (allocation, leaks, CPU). If he observes a memory leak, he can use the details panel of leaks instrument.
  3. Developer should avoid retain cycles by not to let an object to have a strong reference direct or indirect to another object that already have one to it.
  4. Developer should override the memory warning method of UIViewController to free memory from any unneeded data.
  5. Some C-functions/methods return objects intended to be owned by caller. Developer should take care of this.
  6. Developer should make sure NSZombiesEnabled is NO in the environment variables when debugging.


  1. Developer should not use synchronous calls in main thread.
  2. Developer should not call UI tasks from background threads.
  3. Developer should not depend on extensive timers usage.
  4. Developer should remove unneeded or redundant method calls.
  5. Developer should not use UI events for subscription method calls.
  6. Developer should queue background tasks if possible.
  7. Developer should not call web services in loops or recurrences but make them correspond to user actions. (Wireshark, CocoaRestClient)
  8. Developer should cache most accessible data if possible.
  9. Developer should eliminate unused imports.
  10. Developer should release resources. (HTTP connections, DB connection, files, etc.)
  11. Developer should take care of thread safety and possible deadlocks.
  12. Developer should use GCD for Concurrency if possible.
  13. Developer should avoid new compiler warnings.
  14. Developer should optimize project resources like images if possible. (http://imageoptim.com, https://github.com/JamieMason/ImageOptim-CLI, https://github.com/JamieMason/grunt-imageoptim, http://jamiemason.github.io/ImageOptim-CLI/, https://www.macupdate.com/app/mac/28766/imageoptim)
  15. Developer should optimizing Core Data searches and sorts if possible. (http://www.artandlogic.com/blog/2013/01/optimizing-core-data-searches-and-sorts/)


  1. Developer should only expose the minimum necessary properties/methods in class interface.
  2. Developer should attribute methods with attribute if needed.
  3. Developer should consider proper use of exceptions and errors.
  4. Developer should avoid any hardcoded pieces.
  5. Developer should document any corner cases, workarounds or limitations of the frameworks.
  6. Developer should replace any code that can be done by calls to external reusable components or library functions.
  7. Developer should consider comments on code.
  8. Developer should generalize types where possible.
  9. Developer should factor out repeated code.
  10. Developer should design command classes to handle only one task.
  11. Developer should not import subclasses headers in its superclass header since it should not know any thing about them.
  12. Developer should ensure that the functionality fits the current design/architecture.
  13. Developer should document the design. (Gliffy Diagrams Google Chrome app)
  14. Developer should involve known design patterns in Cocoa (MVC, Delegation, Singleton, Class cluster, etc.).


  1. Developer should decide which security model to follow synchronous or asynchronous.
  2. Developer should avoid JSON injection and SQL injection.
  3. Developer should store small private data/credentials of the user in Keychain and any sensitive big data encrypted/protected on disk.
  4. Developer should avoid using HTTP GET if possible.
  5. Developer should take care of automatic keyboard caching and screen caching done by iOS.
  6. Developer should use vulnerability checker if possible. (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)
  7. Developer should encrypt/protect sensitive project resources.
  8. Developer should not depend on device identifier.
  9. Developer should involve authentication with a maximum number of login attempts if needed.


  1. Developer should involve build/test tool. (OS X Server with Xcode, BitNamiStackJenkins, http://www.raywenderlich.com/22590/beginning-automated-testing-with-xcode-part-12, http://www.raywenderlich.com/22816/beginning-automated-testing-with-xcode-part-22)
  2. Developer should involve deployment/distribution tool. (https://www.testflightapp.com)
  3. Developer should involve framework management tool if needed. (http://cocoapods.org, https://github.com/jspahrsummers/xcconfigs, https://code.google.com/p/google-toolbox-for-mac/source/browse/#svn%2Ftrunk%2FXcodeConfig%2FProject)
  4. Developer should use version control system. (SourceTree, http://github.com)
  5. Developer should use crash-reporting tool if needed. (https://crashlytics.com)
  6. Developer should use testing tool if possible. (https://github.com/kif-framework/KIF)
  7. Developer should use documentation tool if possible. (http://gentlebytes.com/appledoc)
  8. Developer should use code review tool if possible. (http://www.reviewboard.org)


  1. Developer should ensure the code is unit testable and unit tests are completed besides developer tests.

  2. Developer should enforce preconditions in functions unless he have a good reason not to.

  3. Developer should try to guarantee uniqueness of all identifiers.

  4. Developer should made appropriate use of logging.

  5. Developer should handle cases like

    • Incoming Call
    • Text message
    • Other app notifications
    • Storage low
    • Battery low
    • Battery dead
    • No storage
    • Airplane mode
    • Intermittent connectivity
    • Home screen jump
    • Sleep mode
  6. Developer should consider localization and time zone changes.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.