Quick Tips To Support Dark Mode In Your iOS App | iOS 13

All you need to know about Dark Mode on iOS 13

Overview? With iOS 13 and above people can adopt a dark appearance where Apple docs says user can use settings to make their devices automatically switch to dark mode when ambient is low and this will help you to put focus on your content.

Development Environment? As as iOS developer you’ve to use Xcode 11 with iOS 13 SDK and above, iOS will automatically update system controls such as switches, collection-views etc. If you are migrating your existing app to dark in that case you will have to adapt the colours. 

How to define colours for each mode?

System Colours? iOS 13 SDK includes new system colours so if you adapt these system colours your app will automatically support dark and light mode, You can use it via Storyboard as well as programmatically (Some example below)

Custom Colors? Yes it’s strongly recommended by Apple that use system colours to provide better UX and also to make sure the consistency across apps but using the asset you can define you colour choices. Once you define iOS will take care everything for you.

How to define Image for each mode?

Using the Assets you can specify which image you want to use for dark VS any other mode and just define the image and let iOS take care for you. 

How to detect dark mode programmatically?

On Load Detection? We can use overrideUserInterfaceStyle to check which mode is currently running on user device (Just make sure, this property only available on iOS 13 and above)

Runtime Detection? Can use traitCollectionDidChange to observe the changes, It is important to remember that trait-collection may be called for other trait changes (such as device rotation)

Set Dark Mode for Specific Screen? Yes you can, this property overrideUserInterfaceStyle is available for you to use (only iOS 13 and above)

How to support WKWebView?
Just need to create variable for the color and need to handle this in CSS.

:root {
    color-scheme: light dark;
        --h1-color: #333;
        --header-bg-clr: #FFF1FF;
        --header-txt-clr: white;
    }
    @media (prefers-color-scheme: dark) {
    :root {
        color-scheme: light dark;
        --h1-color: #333;
        --header-bg-clr: #FFF1FF;
        --header-txt-clr: white;
        }
    }

body { }
h1 { color: var(--h1-color); }
.header {
    background-color: var (--header-bg-clr);
    color: var(--header-txt-clr);
}

After Integrating this change you can use Safari to test (First you need to enable the developer menu option in Sarafi, Preferences, Advanced). Open wen inspector (using Command + Options + I) and you will see this screen with the option to toggle light/dark mode.

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

Benefits of Storyboards | iOS

Lots of developers consulted with me regarding on how to use storyboard with too many team members like when you have 20 developers on your team? So I have collected my thoughts on that today. I have used Storyboard as well as XIB so here are my thoughts on both.

  • Storyboards are the really nice way to see complete application flow without running into Simulator, you can see the screen flow and the navigation between them, it’s one of key thing that makes your application architecture better.
  • For a larger team of multiple developers it’s really difficult to use the same storyboard because at the end it’s XML file so really very hard to merge and you will end up with a lot of conflicts, So I have noted, a lot of developers suggest XIB here but I don’t see any reason why they choose XIB and I think the best idea is the divide the complete application in different storyboard according to their use-case, that is the first activity I always do, divide complete app into as much as possible storyboard you can (but it’s not like 1 storyboard for 1 ViewController) and use storyboard reference to connect them.
  • I worked in rapid prototype development (deliver the complete application in 15-20 days, developed POC in 7 days) so the biggest benefit that I earned from storyboard is Mock-up, I can create complete app mock-up without writing a single line of code and really easy to manage the transition between views.
  • Few issues that I feel with the storyboard is, it fails at runtime means if you made a mistake with segue name, the class doesn’t exist etc. Yes, it gives issue at compile as well only if you didn’t merge it properly (merge conflicts with XML tags).
  • Using Storyboard, no need to run your app on the different simulator to verify the UI, it gives you fantastic feature called preview (Click on the Assistant editor, select your storyboard, choose automation to preview).
  • Developers say it’s harder to reuse the code in storyboard but my opinion is, first think and implement, try to use mix approach with the storyboard, XIB (wherever requires use XIB to make it reusable on different storyboards).
  • Yes, storyboard creates an issue when you create one in Xcode 8 and try to open it in Xcode 7 but lots of developers already raised this concern with Apple so hopefully, we will hear something from Apple soon.

Thank you for reading! Please do share your thoughts if any.

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.

Clean Code | TDD | Swift | iOS | Quick Notes

TDD is a way of writing software, where we write as little code as possible to make the test pass and then late refactor the code.

Golden laws from Uncle Bob

  • You may not write production code until you have written a failing unit test.
  • You may not write more of a unit test that is sufficient to fail and not comping is failing.
  • You may not write more production code that is sufficient to pass the currently failing test.

Whenever we create a new iOS app, we start with UI/ViewController/Business Login directly but Idea here is to start with the Test-cases. How? Let’s say you want to add the functionality to find out the divisible or not as below mentioned the code. Write down the test-case first.

func testIsDivisibleByThree() {
let brain = Brain()  
let result = brain.isDivisibleByFive(number: 5)
XCTAssertEqual(result, true)
}

But we don’t have the class Brain till now!!! So create a class adds the function, don’t forget the aim is to write as minimum code as you can.

class Brain {
    func isDivisibleByThree(number: Int) -> Bool {
        return true
    }
}

Because as of now, we are returning static boolean value, test-case will be a pass for sure. Same pattern we need to follow for each and every code we are going to write.

Simple words I can say there are 4 stages in TDD.

RED – Write down the test case
GREEN – Write just enough code to make the test-case pass
REFACTOR – Clean up existing code
REPEAT – repeat the cycle

In above codebase we have done RED and GREEN, let consider the stage 3rd, REFACTOR.

Let’s say now we have to write a function where we need to check whether a number is divisible by given number or not, like this

func isDivisibleBy(divisor: Int, number: Int) -> Bool {
  return number % divisor == 0
}

So we have refactored the code, Utilizing it like.

func isDivisibleByThree(number: Int) -> Bool {
    return isDivisibleBy(divisor:3, number:number)
 }

the idea is to repeat these steps so we can make sure when we are making any new changes, is it breaking some existing functionality.

I have tried to create short notes on how to follow TDD but also Idea is here is to decouple your code from UIViewController as much as possible so that it will give you more testability scope (for implementing this I have tried MVVM design pattern in few my recent projects, will share one quick notes on that as well).

Thanks for reading.

Clean Code | Quick Notes

51bPR2V9fBL._SX258_BO1,204,203,200_

A handbook of agile software craftsmanship by Robert C.Martin.

Two reasons for reading this book, you’re a programmer or you want to be. So by the end of this, we’ll know how to write good code because we are going to look code in each and every direction.

There will be a code, some peoples say we are at the end of the code and we don’t need the programmers because business people will generate the program from the specification.  That’s not true because at some level details can’t be ignored so we have to be specified.

It is bad code that brings the company down.

Why do we write the bad code? go fast, in a rush, don’t have to time to think before writing the line of code. One thing we’ve all said we’d go back and clean it up later. But we didn’t know LeBlanc’s Law: Later Equals Never.

The Total Cost of Owning a Mess, we all see teams that were moving fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two, three other parts of the code. As the mess builds, the productivity of the team continues to decrease. Now management adds new developer to increase it but it creates the new mess because the new developers are not aware of current architecture and then together they create more mess.

The Grand Redesign in the Sky, eventually team rebels and they inform management that they cannot continue with the codebase and they demand redesign, Management doesn’t want to expend the resources but they can’t deny because productivity is 0. A new tiger team is selected and everyone wants to be on that team, now they have to develop same what old app is doing also the new changes that are coming in. It takes time but after some time, the developers of tiger team is gone and current developers demand new because it’s mess.

Attitude, Why does this happen to code? we complain that the change in requirements, schedules that were too tight, we blame stupid managers, intolerant customers etc. but the fault is in ourselves we are unprofessional.

The only way to make the deadline, the only way to go fast is to make your code clean as much as possible.

What is Clean Code? there are lots of definition given by different deep experience programmers, here I have mentioned one that I like most.

Bjarne Stroustrup, Inventor of C++. I like my code to be elegant and efficient. The logic should be straightforward to make it harder bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimisations. clean code does one thing well.

Thanks for reading this, here I am also including my point what I like most and I must recommend this book to each and every person who is responsible for writing/reviewing code. For more just buy the book.

Clean Code | Introduction | Quick Notes

51bPR2V9fBL._SX258_BO1,204,203,200_.jpg

A handbook of agile software craftsmanship by Robert C.Martin.

Writing clean code is what you must do in order to call yourself a professional, there is no excuse to do anything less than your best.

In this series of quick notes, I am going to share the quick notes from this book with you, So welcome aboard, let’s start with the introduction.

So think 2 mins, what is the valid measurement of code quality for you? The answer according to the book is funny but its WTFs/minute. haha 🙂 Now you can easily measure the quality of your code.

Next question will be, How to handle bad code? the answer is Craftsmanship. There are two parts of learning Craftsmanship: Knowledge and Work. It means you must gain the knowledge of principles, patterns and best practices and you must also grind the knowledge into your finders, eyes by working hard.

Yes, that’s why this book is divided into three parts.

  1. First will teach you principles, patterns, and best practices.
  2. Second, Case studies of ever-increasing complexity. Here you have to think and give the reason for making each change.
  3. Third, a list of heuristics and smells gathered while creating the case studies.

Thanks for reading this, I am also including what I like most and I must recommend this book to each and every person who is responsible for writing/reviewing code. For more just buy the book.