SwiftLint is a tool to enforce Swift style and conventions. It is developed by Realm.


In this page, we will install SwiftLint via Homebrew.

Open terminal and run

$ brew install swiftlint

Once installed, navigate to your project folder in terminal and create .swiftlint.yml file:

$ touch .swiftlint.yml

swiftlint.yml file is where we define how the linter configuration will be. In the configuration file, you can add, disable or update the linting rules.

You can see a sample of this file’s structure at here.

Rule inclusion in .swiftlint file:

  • disabled_rules: Disable rules from the default enabled set.
  • opt_in_rules: Enable rules not from the default set.
  • only_rules: Only the rules specified in this list will be enabled. Cannot be specified alongside disabled_rules or opt_in_rules.
  • analyzer_rules: This is an entirely separate list of rules that are only run by the analyze command. All analyzer rules are opt-in, so this is the only configurable rule list, there are no equivalents for disabled_rules only_rules.

Open the .swiftlint.yml file to edit:

$ open .swiftlint.yml

After you have configured the .swiftlint.yml file, save it and close.

Then navigate into your project – XCode Target > Build Phases > + icon > Create New Run Script Phase

Add below script:

if which swiftlint >/dev/null; then
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"

Place your build script in top of Build Phases, Then build your project.

In my example project below, SwiftLint’s script is the second one.

There is a built-in feature in SwiftLint by which can correct some type of violations automatically.
Run below command in the root directory of your iOS project to autocorrect:

$ swiftlint autocorrect

When you run above command files on disk are overwritten with a corrected version. So to be aware that you have backups of these files before running, swiftlint autocorrect in case some datas can be lost.

Now that you have configured your linter in XCode, you may want to check some common Swift Style guides as well.

Run swift lint in custom iOS file

  • add your file location in -included tag:
  - Source
  - Tests
  - ../

Here is my custom .swiftlint file.

Here you can find the source code and learn more about SwiftLint.


Closures in Swift

Closures are blocks of code that defines functionality in your code. Closures can capture and store references to any constants and variables from the context. Basically, swift handles all of the memory management of capturing. Yet, when building hierarchies of objects and closures you have to be very careful in considering which type that will act as the owner for each given instances. With a clear hierarchy, parent instances will be responsible in retaining their children in which, children instances will be “weak” references, and a lot of memory related problems will be avoided.

@Escaping: When the passing argument defined in outside of the closure and will be executed later this argument must be defined as @escaping. When the execution ends, the scope of the passed closure will exist in the memory till it gets executed. In such, asynchronous functions like waiting API response, or calling Grand Central Dispatch – like doing animation, will cause the @escaping argument to be stored in memory until the animation is done, or api delivers response. In those cases, we must explicitly  define self’s as “weak” properties to avoid memory issues.

@Non-Escaping: When the passing argument is already a in a function, closure executes the argument in the function itself and returns it to back the compiler. In those cases, once the execution ends, the passed closure goes out of scope and have no more existence in memory. (Default one)

Memory Management in Swift

Swift uses ARC memory management model.

Retain Cycles Problem: When two objects reference each other, or when capturing in closures may cause a retain cycles.

1. Referencing object increments object’s retain count: For example, lets say we have a Stationery.swift class and Notebook.swift class, and both these classes includes object of one another. Imagine that we have both instances of these classes, in that case retain cycles occur. For solution, we must break the retain cycle by making notebook’s instance to “weak”.

2. Closures: Another example could be about closures, just like how referencing an instance using a property increment its retain count, so does capturing instance in closure.
For example, if we are using a closure to observe a notebook instance whenever its being sold in stationery object, and using the same stationery object within that closure will again cause the retain cycles.

TDD In Practise

When it comes to Testing In Swift, there are 3 keys,

1 – Design your code for clear testability.

Unified Input & Output: In the functional programming world there is this talk about pure function which simply means that same input will always produce the same output no matter where it is called. You don’t have to become Haskell programmers and change all your code according to pure functionality, yet, you may want to inspire by them to make your code easier to test.

Keep Our State Local: In the Apple Community a lot of people are using singleton patters simply because they are used to. We have seen Apple do it like, UIScreen, UIDevice, Bundle, etc. So we as IOS Devs, tend to use it by default even when we really don’t need it. As singletons can be nice for sharing some apis they can also lead you a dangerous paths such as undefined state. So before using it we must think that whether we really need it or not. In summary, my humble suggestion would be try to keep states in local so that we are gonna end up with less bugs and also easier to test the code.

Dependency Injection: When you are testing a state or functionality, all the needs to create output must be declared as you call the testing function, so try not to put variables in the class itself but try to create them while calling the function via putting those variables in initializers. So that, all the needs will always generate the same output with the same input no matter when or where.

2 – Remember that you are going to write a test against all your public api. So keep caution on access modifiers.

Always keep going with framework oriented programming, so that your codes will be easy to test and easy to reuse them.

3 – We all need mocks when it comes to testing, yet be very careful while using them. Remember your only purpose is writing tests to check your real code. Mocks come with a cost and more complexity. And you can end up instead of testing your api, testing too much of your implementation.

Swift 4 Skeleton Project

Hey everyone!

Here is skeleton project for our swift projects with mvc, shared folders and some objective C libraries(for UI animations- ProgressHUD etc.)

This project is also base of angela yu’s project!



Alsoo, here is common auto layout issues both programmatically and Main Board Solutions:



IOS Design Patterns in Swift

Hey Guys! We all heard the term design patterns, and we know that this is very important for our project, yet when it comes to writing code we don’t pay attention too much for reusing codes.Why we care if there is more than one instance of the same class? Or copy paste the same methods in some classes over and over when code and memory is cheap. However, there are some cases  in which it makes sense to have exactly one instance of a class. For example, there is only one instance for your application and one main screen for every device. So you only want one instance for each. Actually Apple uses this approach a lot. So we will examine their patterns and see how to use them to make our codes more readable and increase its reusability. For example, NSFileManager.defaultManager(),UIApplication.SharedApplication(), UIScreen.MainScreen() are the example of the singleton pattern.

If you copy/paste some of your methods in classes over and over OR if you are rechanging the same function in other classes when you are adding a new functionality to the same method, I guess it is time to use Design patterns.

  • They are reusable in multiple projects.

  • Design patterns don’t guarantee an absolute solution to a problem. They provide clarity to the system architecture and the possibility of building a better system.

  • They also help you create loosely coupled code so that you can change or replace components in your code without too much of hassle. 🙂

    Don’t worry we are already using IOS design patterns thanks to the Cocoa! So lets dive into this patterns with simple examples!

    Most Common Design Pattern – MVC

    I am not going to write what MVC is, instead I will show with a simple example. Here is the Model – View – Controller, the king of the patterns 🙂

    The clean separation of the code based on the role.

    • A Model , which represents the underlying, logical structure of data in a software application and the high-level class associated with it. This object model does not contain any information about the user interface.(Basically,The object that holds the data and defines how to manipulate it. It has nothing to do with the UI)

    • A View , which is a collection of classes representing the elements in the user interface (all of the things the user can see and respond to on the screen, such as buttons, display boxes, and so forth)- basically all the UI – derived objects.

    • A Controller , which represents the classes connecting the model and the view, and is used to communicate between classes in the model and view.(The mediator that coordinates all the work between model and the view. It accesses the data from model and displays it with the views – listens the events and manipulates the data if necessary.)

    • A good implementation of this design should mean each object falls into one of these groups.


    This is how it works basically.
    Soo lets start our very simple project. First, Open Xcode then select the “Create a new Xcode Project”, Then choose “Page-Based Application”, give the name you want to your project in the “Product”and select the lang Swift and click Ok.Here is your project with 4 swift classes.

    1. AppDelegate.swift
    2. RootViewController.swift
    3. DataViewController.swift
    4. ModelController.swift

    AppDelegate might look like full of mostly empty functions but it is the main file of our swift project. There is a part written “@UIApplicationMain”, this means Xcode will assume this file as the main file.

    ModelViewController  is the place where the data is shown, variable pagedata holds the date to show in init().(Model)

    let dateFormatter = NSDateFormatter() 
    pageData = dateFormatter.monthSymbols

    DataViewController is the place where UIView is shown, displaying datalabel.(View)

    RootViewController updates the data from ModelViewController in the DataViewController. DataViewController can then notify the controller of user actions and the controller will either update the model if necessary.(Controller)

To Design Custom Icon for IOS App

Hey Guys! In android, we developers are really lucky to copy/paste the icons to our app. In IOS However, Apple makes you add very specific sizes. We need different sizes, because devices are different. Ipad, different versions of Iphone… They all display different resolution of icons. Of course, newer models have high resolutions. But we have to think all devices.:)

Sooo, Lets Begin!

When we take a look at image.xassests for our AppIcon there will be Iphone — Iphone Spotlight — Iphone App and so on… The important thing is below this pictures there is “pt”(points). Also, there will be 2x or 3x or whatever for each different size. So All we gotta do is to multiply points with this sizes. For example, In the first picture there is an iphone with 29 pt and 2x size so we must have icon with (29 x 2 = 58) 58 pxs. For other devices you should also have 58pxs, 80pxs, 87pxs, 120pxs, 180pxs…
Also, As you might noticed all icons should be SQUARE. But you can change the image with insets to rectangle or whatever you want.:)