Swift 5 ABI Stability why matters?

Swift is fast, safe and expressive language to code with great full stack potential and community support. According to Apple, it‚Äôs 2.6 times faster than Objective C (As a Swift Developer I agree on this too ūüôĆ). It‚Äôs 6th most loved language on StackOverflow.

ABI Background
As a developer, I hope sometimes you also felt that Swift is not mature enough as every year major changes are being introduced. One of the key problems articulated by a lot of developers is ‚ÄúLack of backward compatibility‚ÄĚ and you have to choose one Swift version for your Xcode projects (Version lock). Resulting in with a new Swift release you have to make changes in your existing code.

What is ABI?
ABI stands for Application Binary Interface. During runtime, Swift program interacts with other libraries through ABI (low-level set of protocols for memory representation, function calls, and access).
So when I say ABI not stable it means that each binary is building its own version of Swift Dynamic Library inside it. Now the Swift 5 is ABI Stable which means if I build two apps, one using Swift 5.0 and another using Swift 5.2, both will use Swift ABI embedded in the iOS Operating System.

Why ABI Stability matters a lot?

  1. Compatibility: which means new compilers can compile your old Swift code which means no more migration pain.
  2. Bundle Size: It will reduce the build size because of no Swift standard Library in your Framework folder.
  3. Binary framework and runtime compatibility which enables the framework distribution as a binary which will work across multiple Swift versions.

Conclusion: Swift is the future for Apple ecosystem and now it’s ABI stable which means, in other words, it is like write once and use everywhere.

Reference:
https://swift.org/about/
https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Swift | Open source projects for learning and developers to follow on twitter

Screen Shot 2018-10-05 at 10.26.35 AM

Announced in 2014, the Swift programming language has quickly become one of the fastest growing languages in history. Swift makes it easy to write software that is incredibly fast and safe by design.

Blog for developers to highlight, top 10 trending open source to learn.

  1. MessageViewController A SlackViewController replacement written in Swift, compatible with iPhone X, iOS12. Created by Ryan Nystrom
  2. Swift interpreter for Pascal language (Inspired from Ruslan’s Blog). Created by¬†Igor Kulman
  3. CollectionViewSlantedLayout subclass of the UICollectionViewLayout allowing the display of slanted cells in a UICollectionView.Created by Yassir Barchi
  4. Mint Package manager that installs and runs Swift command line tools, created by Yonas Kolb
  5. CryptoSwift Collection of standard and secure cryptographic algorithms implemented in Swift. Created by Marcin Krzyzanowski
  6. CocoaDebug Debugger tools for iOS supports Swift and Objective C, created by CocoaDebug
  7. iOS-Depth-Sampler Examples of Depth APIs in iOS, created by Shuichi Tsutsumi
  8. Universal Link Testing  It fetches and parses apple-app-site-association file for you to quickly check whether Universal Links are working. created by Ethan Huang
  9. Swift Syntax Set of Swift bindings for the libSyntax library. It allows for Swift tools to parse, inspect, generate, and transform Swift source code. Created by Apple
  10. WhatsNewKit Showcase your awesome new app features, Created by Sven Tiigi

 

Thanks for reading!

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.

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.

POV | Difference between ! and ? | In-Shorts Story

Whenever we write code in Swift we use optional because it beautiful way for handling null values as in Objective C its little different and difficult as well, one of the reason is, Objective C based on C, so there are legacy issues as well, but in Swift there is not legacy at all so for handling null value we have separate feature from the language itself that is called Optional (Optional chaining is a process for querying and calling properties, methods, and subscripts on an optional that might currently be nil).

Now the second question comes up in mind is, how does it work?

The idea is whenever you feel any value could be nil in future just make it as Optional simply and before using it first see, is it contains anything? if Yes than use it otherwise make the nessarary decision. In other words, we can say its something like you has a box and it may or may not contains something so before using it first unwrap and check.

How to create Optionals?

? and ! here is the answer. I also googled what is the correct difference and where to use what but only a few links were useful. Small answer is.

Use ? if the value can become nil in the future so that you test for this before using always (we have to use if let or guard statement).

Use ! if it really shouldn’t become nil in the future, but it needs to be nil initially like we do with IBOutlets always (Benefit is before using no need to unwrap using if let or guard statement). But it we use ! and the value is nil ready for the crash.

Thank you for reading.
Please share your comment it will help me to improve.

Happy Learning.

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.