Swift Keynotes: classes & structs

Structs are the value type.

Screen Shot 2018-07-16 at 4.52.45 PM.png

Classes are the reference type.

Screen Shot 2018-07-16 at 4.51.19 PM.png

Properties of a constant instance of the struct are immutable because struct’s instance own the whole object and by declaring it as a constant means the whole object itself will be immutable.

Screen Shot 2018-07-16 at 4.59.08 PM.png

Properties of a constant instance of the class are mutable as class’s instance owns the object’s reference thus by declaring it as a constant only means that the further reference assignment can’t be done.

Screen Shot 2018-07-16 at 5.01.29 PM.png

Structs are blessed with default member-wise initializer but classes are not.

Screen Shot 2018-07-16 at 4.02.52 PM.png

Structs are preferable when they are small and copyable.
With Structs, there is much less need to worry about memory leaks or multiple threads racing to access/modify a single instance of a variable.
Since struct instances are allocated on the stack, and class instances are allocated on the heap, structs can sometimes be drastically faster (but it still depends on how many values you’re storing and the size/structure.)
In a multi-threaded environment, for instance, with a database connection that’s opened in a different thread, structs are safer. They can be copied from one thread to another thread, without running the risk of a race condition or deadlock. Classes do not have this inherent safety unless they’re deliberately made thread-safe.

Thanks a lot for reading it.

Quick Notes | Swift classes into Objective-C Code when you have multiple targets.

How to use Swift classes into Objective Code when you have multiple targets.

For using Swift classes in Objective-C Code when you have one target in your app. We generally need to andimport TargetName-Swift.h next to add support in your Swift file you need to inherit if from NSObject or use @objc flag.

What if you have multiple targets in your codebase? As you cannot import, TargetNameA-Swift.h TargetNameB-Swift.h etc. In that case, you can tell the compiler that not to create Swift module specific to target change it to project name because the project will be same and unique.

For achieving this select your every target, Build Settings and change the build configuration.

Objective-C Generated Interface Header Name —> replace $(SWIFT_MODULE_NAME)-Swift.h that is specific to the each target, with $(PROJECT_NAME)-Swift.h

Screen Shot 2018-04-19 at 11.02.20 AM.png

Screen Shot 2018-04-19 at 11.02.38 AM.png

Later import PROJECT_NAME-Swift.h in your Objective C code to make use of your Swift code.

Creating and Distributing iOS Frameworks | Swift | Tips & Tricks

Why do we need to create frameworks? because it has three major purposes mentioned below and also you can share your code with your team, other developer or iOS community.

Code encapsulation
Code modularity
Code reuse

Let’s create the iOS framework.

Screen Shot 2018-02-05 at 8.24.50 PM

Now just give some meta-data about your framework like name, organization, identifier etc (I hope you’re already aware of it).

Screen Shot 2018-02-05 at 8.26.54 PM.png

We’re good to go till now. Just add the files that you want to keep within your framework.

add

Build the framework project to make sure that you get build succeeded with no build warnings or errors.

Things that you need to take care.

Make sure to check Copy items if needed, so that the files actually copy into the new project instead of just adding a reference. Frameworks need their own code, not references, to be independent.
Double-check that each of the files has Target Membership in ThreeRingControl to make sure they appear in the final framework. You can see this in the File Inspector for each file.
Double-check the access modifiers, while creating framework access modifiers plays very important roles.
if you’re creating Swift framework make sure you’re extending classes from NSObject otherwise it won’t reflect once you will import the framework.

Thanks for reading.

SOLID principle with Swift | STUPID

SOLID principle is an acronym created by Robert C Martin also unknown as Uncle Bob. It represents five principles for OOPS.

Single responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

Now the first thought that came to my mind is Why do we need this? Here is the answer, using these principles we can solve the problems of a bad architecture.

Fragility where A small change may break complete module it’s really very difficult to find this if you don’t have good test cases.

Immobility where A component is very hard to reuse in another project or we can say multiple places in the same project because of too many dependencies.

Rigidity where Single change requires lots of developer efforts because it affects several parts of the project.

Here I want to add principles will not turn a bad programmer into a good programmer you need a better judgment there. Principles have to apply with judgment and you must be smart enough to understand when to apply what.

I have also written one blog where they have mentioned one more acronym like SOLID and it’s STUPID. This may hurt your feeling but yes if you are following this you are writing stupid code.

Singleton
Tight Coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

Thank you for reading the quick introduction, In next blogs, I will try to define all principles with Swift Code.

Signs of wrong architecture? | Quick Notes

Recently I have got one iOS Application codebase to review and it always gives a thought, where to start?

Here are the 3 important first steps for me that I always do.

find . -type f -exec wc -l {} + | sort -n

Execute the terminal command in your project location, it will give you count of number of lines, like mentioned below

3000 ./ViewControllers/DashboardVC.swift
5655 ./AppDelegate.swift

where 3000/5655 is the lines of code.

Second, I track are we using Appdelete directly?

grep -rnw . -e "UIApplication.shared"

Last, but not the least. Swift/Objective-C dependency visualizer. It creates object dependency graphs and gives you the clear picture.

Screen Shot 2017-11-22 at 5.33.12 PM

Thanks for reading. I hope it was quick and informative for you.

App Secure | URLSession | Authentication Challenge | NTLM | Security | Credentails

Yesterday, I have posted about How to response Authentication Challange but thoughts came in mind that if you are going with the first options Provide authentication credentials is it really secure and safe? how is client sharing the credentials with the server?

After lots of Google, I have found, how’s NTLM works and it’s pretty interesting to see that client don’t share the password with the server. here are the steps as follow.

Screen Shot 2017-10-12 at 1.06.51 PM.png

The client makes the request to the server.
The server needs to validate the user because there is no identity so server generates 16 bytes random number called as the challenge and sends it to the client.
Client hash this challenge with the user’s password and return it back to the server that is called the response it also includes username as plain text and challenge sent to the client.
The server sends everything to the domain controller and it uses the username to retrieve the hash of the user’s password from security account manager database and hash the challenge.
Domain controller shares the response back to the server if they are identical then authentication is successful otherwise a failure.

So the interesting part is here that Network API doesn’t share the password with the server it means it very secure.

Thank you for reading.

Share your thoughts and feeback.

How to Respond to an Authentication Challenge | iOS

How to Respond to an Authentication Challenge

If a session requires authentication it creates authentication challenge

 URLSession:task:didReceiveChallenge:completionHandler:

in order for the connection to continue, the delegate has three options.

Provide authentication credentials
Attempt to continue without credentails
Cancel the authentication request.

NSURLProtectionSpace will give all information about the authentication type and failure if any attempts failed earlier.

Providing Credentials

To attempt to authenticate, the application should create an NSURLCredential object with authentication information of the form expected by the server. You can determine the server’s authentication method by calling authenticationMethod on the protection space.

HTTP basic authentication (NSURLAuthenticationMethodHTTPBasic) requires a user name and password. P
HTTP digest authentication (NSURLAuthenticationMethodHTTPDigest), like basic authentication, requires a user name and password.withcredentialWithUser:password:persistence:.
Client certificate authentication (NSURLAuthenticationMethodClientCertificate) requires the system identity and all certificates needed to authenticate with the server. Create an NSURLCredential object.
Server trust authentication (NSURLAuthenticationMethodServerTrust) requires a trust provided by the protection space of the authentication challenge.

Continuing Without Credentials

If the delegate chooses not to provide a credential for the authentication challenge, it can attempt to continue without one.

• NSURLSessionAuthChallengePerformDefaultHandling processes the request as though the delegate did not provide a delegate method to handle the challenge.

NSURLSessionAuthChallengeRejectProtectionSpace rejects the challenge. Depending on the authentication types allowed by the server’s response, the URL loading class may call this delegate method more than once, for additional protection spaces.

Canceling the Connection

The delegate may also choose to cancel the authentication challenge, by passing NSURLSessionAuthChallengeCancelAuthenticationChallenge to the provided completion handler block.

Dependency Injection | Swift | Quick Note

A short answer is, it’s scary terms for a very simple idea!!! See this lines of code.

class Engine {

}

class Car {
    let engine: Engine? = nil
    init() {
        self.engine = Engine()
    }
}

we are creating dependency internally but the object can be also received from outside with lots of benefits like the object become instantly testable, Testing becomes possible without any frameworks, No runtime effects, This makes the whole system more loosely coupled.

class Car {
    let engine: Engine? = nil
    init(engine: Engine) {
        self.engine = engine
    }
}

There are three common types of dependency injections.

Setter, Interface, Constructor based.

In iOS Constructor based is preferable one, it’s when dependency passed to the client in the initializer and don’t change during the whole client life and the biggest advantage of this type could be that it makes the violation of the single responsibility programming principle, if an object takes all dependencies in the initializer and if it has more than three parameters so it means refactoring is needed.

Thanks for reading!!!

Swift | iOS 10 | Orientation | Quick Notes

When it comes to handling Orientation in iOS App Development, creates little confusion because with every release their minor changes. so let’s see who does it works with iOS 10.

First thing if you want to support all Orientations just enable it from here.

Screen Shot 2017-08-02 at 3.40.51 PM.png

Second, if the requirement is something like, need Orientation support only for few Controllers. make sure you have followed the first case and just this code snippet for enabling/disable it for each view.

override var shouldAutorotate: Bool {
    return true
}

its simple as its looking just return `true` if you want to support orientation for controller else return `false`. Next concern is if you are returning true then you have an option to specify the orientations as well just implement this code snippet.

override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
    return UIInterfaceOrientationMask.all
}

Click `UIInterfaceOrientationMask` to see the options so just return whatever you want to use. Sounds good?

public struct UIInterfaceOrientationMask : OptionSet {
    public init(rawValue: UInt)
    public static var portrait: UIInterfaceOrientationMask { get }
    public static var landscapeLeft: UIInterfaceOrientationMask { get }
    public static var landscapeRight: UIInterfaceOrientationMask { get }
    public static var portraitUpsideDown: UIInterfaceOrientationMask { get }
    public static var landscape: UIInterfaceOrientationMask { get }
    public static var all: UIInterfaceOrientationMask { get }
    public static var allButUpsideDown: UIInterfaceOrientationMask { get }
}

Thank you for reading.

Make your iOS apps more secure with SSL pinning

SSL/Certificate pinning plays a very critical role in building highly secure mobile apps which users will be able to use even in countless insecure wireless network connections.

At a glance, Idea is the SSL(Secure Socket Layer) ensures the encrypted client-server communication over HTTPS. The encryption is based on PKI (Public Key Infrastructure) and a session key. The session key was introduced because encrypting and decrypting a public/private key uses a lot of processing time/power/space for sure it will slow down the process.

MIMT, Yes SSL Communication is very secure but the man-in-the-middle attack still poses an exact threat using ARP cache poisoning and DNS spoofing.

SSL/Certificate Pinning, ensure that the app communicates only with the designated server only and the prerequisites for SSL pinning is saving the target’s server SSL certificate within the app bundle.

SSL pinning is implemented within the

func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void)

and here are the steps we need to follow.

First read the server trust and server certificate.

let serverTrust = challenge.protectionSpace.serverTrust
let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0)

Now set the policies for server validation, previous failure count etc.

SecTrustSetPolicies(serverTrust, SecPolicyCreateSSL(true, (challenge.protectionSpace.host as CFString)))

Start policies validation, convert server certificate in Data and get the local certificate from bundle.

let remoteCertificateData = SecCertificateCopyData(certificate)
let pathToCert = Bundle.main.path(forResource: “certificate”, ofType: “cer”)

At last compare your policies result and local certificate data with your server certificate data, if everything goes well complete the challange with credentail.

completionHandler(.UseCredential, credential)

Otherwise cancel the authentication and pass nil as credentails.

completionHandler(.CancelAuthenticationChallenge, nil)

Thank you reading, you can download the source code from GIT and also learn contribute about iOS Security.