10 Things you must do before Creating the iOS Application

10 Things you must do before creating the iOS application.

As a developer, creating iOS application from scratch, developer may stuck with questions like how to implement design, how to do code and integrate custom libraries. So here is a list which explain each and every point with clarity.

1.  Source control: First, Everyone needs to take the back up of the application. Each project needs source control. The most common source control is GIT and, there are so many other available source control in the market, but I’ll explain GIT.

    GIT : It relies on a distributed system for version management. You will have a local repository on which you can work, with a network connection only required to synchronize. Its access authorization is for the entire directory, tracks changes by registering content and both the repository and working copies have the complete change history.

2.  Architecture patterns: If you are starting the project from scratch, you have to implement the architecture patterns. There are some patterns used in iOS Development. It uses MVC architecture patterns.

    MVC : MVC means Model View Controller.The controller creates the bridge between the Model and the View. I understood this diagram in a very simple way: UIView, UIScrollView or UITableView is the view of that diagram. I arrange them on a scene in the Interface Builder, bind them with my source code — outlets and actions defined in my view-controller. The last one is exactly the controller from the MVC diagram. My application stores a user data, for example, in a text or, in a more complicated case, with Core Data. Classes allowing access to this data is the model from the diagram.

No business logic code in the model, the model does not communicate with the view. The view-controller is responsible to create all the views and the model and perform the communication between them. If the user action requires a change in the model, the view-controller calls the model to change. If the model changes, the view-controller is notified of this change. And the view-controller is the one, updating the view.

View-controller creates the model and calls it if a change happens and it is shown as an arrow on the diagram. An arrow goes from the view-controller to the view — the view-controller create all views and updates them if its state or the model changes. The model knows nothing about the view-controller and if a change happens in the model it posts a notification about it or, more often, the view-controller observes the model changes. It happens in the run-time and I’d prefer to use a dashed line to draw this arrow from the model to the view-controller.

3. Objective-C vs. Swift: As Developer starts the new application at that time the developer has two options 1) Objective C and 2) Swift. If given the options, I personally suggest using the Swift. Why I suggest swift? Because Objective C has very few advantages over Swift. Here, I have written some reasons why the future favors Swift.

    3.1. Swift is easier to read : Swift drops legacy conventions. Thus, you no longer need semicolons to end lines or parenthesis to surround conditional expressions inside if/else statements. Another large change is that method calls do not nest inside each other resulting in bracket hell—bye-bye, [[[ ]]]. Method and function calls in Swift use the industry-standard comma-separated list of parameters within parentheses. The result is a cleaner, more expressive language with a simplified syntax and grammar.

    3.2 Swift is easier to maintain : Objective C requires programmers to maintain two code files in order to improve the build time and efficiency of the executable app creation. The repetitive task of separating the table of contents (header file) from the body (implementation file) is a thing of the past. Swift combines the Objective-C header (.h) and implementation files (.m) into a single code file (.swift).

    3.3 Swift is safer : In Objective-C, if a value was returned from a method, it was the programmer’s responsibility to document the behavior of the pointer variable returned using comments and method-naming conventions. In Swift, the optional types and value types make it explicitly clear in the method definition if the value exists or if it has the potential to be optional that is, the value may exist or it may be nil.

    3.4 Swift is unified with memory management : In Objective-C, ARC is supported within the Cocoa APIs and object-oriented code; it isn’t available, however, for procedural C code and APIs like Core Graphics. This means it becomes the programmer’s responsibility to handle memory management when working with the Core Graphics APIs and other low-level APIs available on iOS. The huge memory leaks that a programmer can have in Objective-C are impossible in Swift.

    3.5 Swift requires less code : Objective-C requires programmers to memorize special string tokens (%s, %d, %@) and provide a comma-separated list of variables to replace each token. Swift supports string interpolation, which eliminates the need to memorize tokens and allows programmers to insert variables directly inline to a user-facing string, such as a label or button title. The type inferencing system and string interpolation mitigate a common source of crashes that are common in Objective-C.

    3.6 Swift is faster : Swift code performance continue to point to Apple’s dedication for improving the speed at which Swift can run app logic.

4. Dependency Manager : CocoaPods and Carthage are the most common dependency managers for Swift and Objective-C Cocoa projects. They simplify the process of implementing a library and keeping it updated.

CocoaPods has a truck load of libraries, is built with Ruby and can be installed using the following command:
$ sudo gem install cocoapods

After installing it, you will want to create a Podfile for your project.You can run below command.
$ pod init

Create custom Podfile with below structure
platform :ios, '8.0'
use_frameworks!
target ‘Application Name’ do
     pod ‘Podfilename’
end

Once cerated the Podfile than install you pods
$ pod install

Now you can open your project’s .xcworkspace and also import your dependencies.

Carthage is a decentralised dependency manager, in opposition to CocoaPods. Downside to this is it becomes more difficult for users to find the existing libraries.

5. Storing Information : In iOS Development so many used storing the data. Here I am write the available functions :

    5.1 NSUserDefaults : Generally it is used to save the user’s data, that is put in when the app loaded. For this reason it’s made to simple and easy to use. Objects can be saved to NSUserDefaults in the following manner.

Swift Example :
Set the data in NSUserDefaults :
let keyConstant = "objectKey"
let defaults = NSUserDefaults.standardsUserDefaults()
defaults.setObject("Object to save", objectKey: keyConstant)

Read the data from NSUserDefaults :
let name = defaults.stringForKey(keyConstant)

Objective C Example :
Set the data in NSUserDefaults :
[[NSUserDefaults standardUserDefaults]setObject:@"Object to save" forKey:@"objectKey"];

Read the data from NSUserDefaults :
NSString *name = [[NSUserDefaultsstandardUserDefaults]objectForKey:@"objectKey"];

    5.2 CoreData : It is a framework designed by apple, for your application to communicate with it’s database in an object oriented manner. It simplifies the process, reducing the code and removing the need to test that section of code.

You should use it if your app requires persistent data, it simplifies the process of persisting data quite a bit and means you don’t have to build your own way of communicating with a DB or testing it either.

    6. Storyboards vs. Xibs vs. Programmatic UI :

    Storyboards : It’s allow a broader view of the project, which designers love, because they can see the app flow and all of the screens. The downside is that as more screens are added, the connections become more confusing and storyboard load time is increased. Merge conflict issues happen a lot more often, because the whole UI belongs to one file. They are also a lot more difficult to resolve.

    Xibs : It’s provide a visual view of screens or portions of a screen. Their advantages are ease of reuse, less merge conflicts than the storyboard approach and an easy way to see what’s on each screen.

    Programming UI : Your UI gives you a lot of control over it, less merge conflicts and, if they do occur, are easy to solve. Downside is the lack of visual aid and extra time it will take to program.

    7. Protocols : A protocol defines a draft of the methods, properties and other requirements for given functionalities. It can be adopted by a class, a structure or an enumeration, that will then have an actual implementation of those requirements.

Protocols are also used in Delegation. It enables Classes or Structs to delegate certain functions to an instance of another type. A protocol is created with the responsibilities to be delegated, so as to guarantee the conforming type provides functionality for them.

Example :
class Fireman: RespondEmergencyProtocol, FireStationDelegate {
      func putOutFire(with material: ExtinguisherType) {
        print("Fire was put out using \(material.rawValue).")
      }
      func handleEmergency() {
         putOutFire(with: .water)
      }
}

8. Closures : Closures can capture and store references to any constants or variables from the context in which they are defined. This is know as closing over those variables, hence the name closures. Closures are use intensively in the Cocoa frameworks.Closures are first-class objects, so that they can be nested and passed around.

9. Schemes : Schemes are any easy way of switching between configurations. Let’s give you some background. A workspace contains various related projects. A project can have various targets  specify a product to build and how to build it. A project can also have various configurations. An Xcode scheme defines a collection of targets to build, a configuration to use when building, and a collection of tests to execute.

10. Tests : You are allocate the time to testing your app. It’s known the red bullet.
Cons :   1. Development time increased.
               2. Amount of code increased.
Pros :     1. To make testing easier.
                2. Easier to maintain.

You will have all the tools to make sure your app is bug free and crash free.