Swift Best Practices and Development Tips - Part 1

When it comes to iOS Application Development, Performance of the App and Readability of your code must be your priority to maintain throughout the Development Life cycle. Keeping this in mind, I have prepared a list of iOS development tips which I have learned so far from our development environment at Time Based Software, LLC. It will surely help you out to improve the quality of development.

• Generics come in handy for providing reusable pieces of code and avoiding duplication.
• Replace Magic Numbers with Symbolic Constants to improve the readability of your code.
• Use variadic parameters because it’s powerful and very easier to implement.
• If an extension contains a lot of code, consider separating that extension into a separate .swift file.
• Protocols that describe a capability should be named using the suffixes: able, ible, or ing.
• Code separation and organization are very easy to do using Extensions.
• Use storyboard for a complete story not for a complete project.
• Use optional binding instead of force unwrapping to save your application from unusual crashes.
• When it comes to switching statements, enums can be a life saver.
• Always prefer switch statements over if else statements where possible.
• Reduce Duplicate Code with Protocol Extensions.
• Make the Delegates weak in order to avoid reference cycles.
• Careful day by day commit and Consistent pull will definitely resolve merge conflicts.
• Try to stick to let where possible because mutable var require more memory than immutable let.
• Having a list that breaks up a design in to several smaller steps is a great way to deal with complexity of a project.
• Variable name should be greater than 3 characters, you should always keep your names descriptive, it helps to improve readability and create self-documenting code.
• Your function body length should be less than 40 lines, a larger method could prompt you to think 'should I split this', better make it short!
• The trailing closure syntax can make code clearer by reducing boilerplate code, but make sure it should not be used when there are more than one closure arguments.
• Your commit message should describe why you have changed a certain thing. Remember, your diff tells you what changed, but your commit message tells you why.
• Always fix every single warning, there is a reason that warnings exists, but you should never leave any of them in your production code.
• Classes should be final by default because you generally don’t design them to be extendible to get slightly better compile times.
• In the list of Optional Binding for “if let statements” which are separated by the commas, starting from the second let, all the following let should be on their separate line for better readability.
• Always prefer Higher Order Functions because of its compactness, simplicity and style.
• Avoid AppDelegate overuse, it is not a place to keep your PersistentStoreCoordinator, global objects, helper functions, managers, etc. It’s just like any class which implements a protocol. Always try to create separate classes (and files) to manage different kind of responsibilities.
• We should always be using the appropriate access control modifier to encapsulate code. Good encapsulation helps us understand how pieces of code interact without having to remember our thought process or ask the developer who wrote it.
• Avoid extensive logging, stop printing every little error or response you get. It’s equivalent to not printing at all. Because at some point, you will see your log window flowing with unnecessary information.
• It’s perfectly valid and better to define a type whose sole purpose is to be a table view’s data source. This keeps your view controller clean, and separates logic and responsibilities into their respective objects