-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Ahmed edited this page Aug 5, 2021
·
7 revisions
#iOS Checklist
- Developer should consider the Objective-C coding guidelines. (https://developer.apple.com/library/ios/documentation/cocoa/conceptual/CodingGuidelines/CodingGuidelines.pdf).
- Developer should use a code formatter to let his code be more readable. (https://github.com/octo-online/Xcode-formatter)
- Developer should decide to use manual memory management or ARC
-
If manual memory management
- Developer is the owner of all objects that he allocated, retained, or copied.
- 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.
- 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. The developer should nullify it after the original ownership is released.
- Any global variable used inside a block or a local variable/pointer used for write-operation. The developer should declare it by __block modifier.
-
If ARC
- __block, __weak, __strong, __unsafe_unretained are storage modifiers for variables/pointers. Developers should use them to express ownership.
- Any variable/pointer is strong by default. The developer should not weakify a variable/pointer in the same line of object allocation.
- 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. The developer should take care of this.
- Developer should obtain a strong (__strong, __block) reference to objects that he wants to own.
- 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.
- 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.
- Developer should analyze his code by Xcode static analyzer.
- Developer should profile the app using instruments (allocation, leaks, CPU). If he observes a memory leak, he can use the details panel of the leaks instrument.
- Developer should avoid retain cycles by not letting an object have a strong reference direct or indirect to another object that already has one to it.
- Developer should override the memory warning method of UIViewController to free memory from any unneeded data.
- Some C-functions/methods return objects intended to be owned by the caller. The developer should take care of this.
- Developer should make sure NSZombiesEnabled is NO in the environment variables when debugging.
- Developer should not use synchronous calls in the main thread.
- Developer should not call UI tasks from background threads.
- Developer should not depend on extensive timers usage.
- Developer should remove unneeded or redundant method calls.
- Developer should not use UI events for subscription method calls.
- Developer should queue background tasks if possible.
- Developers should not call web services in loops or recurrences but make them correspond to user actions. (Wireshark, CocoaRestClient)
- Developer should cache the most accessible data if possible.
- Developer should eliminate unused imports.
- Developer should release resources. (HTTP connections, DB connection, files, etc.)
- Developer should take care of thread safety and possible deadlocks.
- Developer should use GCD for Concurrency if possible.
- Developer should avoid new compiler warnings.
- 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)
- Developer should optimize Core Data searches and sorts if possible. (http://www.artandlogic.com/blog/2013/01/optimizing-core-data-searches-and-sorts/)
- Developer should only expose the minimum necessary properties/methods in the class interface.
- Developer should attribute methods with attribute if needed.
- Developers should consider the proper use of exceptions and errors.
- Developer should avoid any hardcoded pieces.
- Developer should document any corner cases, workarounds, or limitations of the frameworks.
- Developer should replace any code that can be done by calls to external reusable components or library functions.
- Developer should consider comments on code.
- Developer should generalize types where possible.
- Developer should factor out repeated code.
- Developer should design command classes to handle only one task.
- Developer should not import subclasses headers in its superclass header since it should not know anything about them.
- Developer should ensure that the functionality fits the current design/architecture.
- Developer should document the design. (Gliffy Diagrams Google Chrome app)
- Developer should involve known design patterns in Cocoa (MVC, Delegation, Singleton, Class cluster, etc.).
- Developer should decide which security model to follow symmetric or asymmetric.
- Developers should avoid JSON injection and SQL injection.
- Developer should store small private data/credentials of the user in Keychain and any sensitive big data encrypted/protected on disk.
- Developer should avoid using HTTP GET if possible.
- Developer should take care of automatic keyboard caching and screen caching done by iOS.
- Developer should use a vulnerability checker if possible. (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)
- Developer should encrypt/protect sensitive project resources.
- Developer should not depend on the device identifier.
- Developer should involve authentication with a maximum number of login attempts if needed.
- 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)
- Developer should involve deployment/distribution tool. (https://www.testflightapp.com)
- Developer should involve a 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)
- Developer should use version control system. (SourceTree, http://github.com)
- Developer should use a crash-reporting tool if needed. (https://crashlytics.com)
- Developer should use a testing tool if possible. (https://github.com/kif-framework/KIF)
- Developer should use a documentation tool if possible. (http://gentlebytes.com/appledoc)
- Developer should use a code review tool if possible. (http://www.reviewboard.org)
-
Developer should ensure the code is unit-testable and unit tests are completed besides developer tests.
-
Developer should enforce preconditions in functions unless he has a good reason not to.
-
Developer should try to guarantee the uniqueness of all identifiers.
-
Developers should make appropriate use of logging.
-
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
-
Developer should consider localization and time zone changes.