How to be better iOS Developer using this tips!

canva.com

When you first start writing code, it’s exciting to be able to solve problems with code. You may have also felt the satisfaction of creating an app that meets your expectations.

But when you’re new to coding, it’s easy to miss things. That’s because most of us learn by ourselves, without a guide book.

I’ve been learning iOS development for a year now, and I’ve learned a lot about the technical aspects of the platform. In this article, I’ll share some of the things I’ve learned that I think are interesting and important.

So without further ado, let’s get started!

What benefit

After studying and researching for a long time, I’ve learned some things that can help you improve your iOS development skills. I’ll share three of them with you today:

1. Writing code that’s shorter and easier to read.
2. Writing code that’s more secure.
3. Writing code that’s more challenging.

I’ll try to explain each of these benefits in as simple a way as possible. Let’s start with the first one.

Empty variable

In some GitHub repositories and my projects, I’ve found that the general use of empty variables is still as shown below.

//Declare Variable
var name: String = ""
var age: Int = 0
var cities: [String] = []

Is that wrong? Of course not, my friend. However, I have an alternative that you can write to make it easier to read, as follows.

//Declare Variable Alternative
var name: String = String()
var age: Int = Int()
var cities: [String] = [String]()

//You can add default data too
var number = Int(0)

So, what’s the difference? It’s more of a matter of personal preference or writing style. I personally prefer to write the alternative version. On the one hand, it eliminates the extra parentheses and quotation marks. But ultimately, it’s up to you to choose which way you find easiest to read and understand.

Boolean and String Interpolation

Next, we’ll cover some of the more fundamental concepts in Swift. We’ll be talking about how to write Boolean and String code, so for more details, let’s take a look at the code below.

//declare variable
var isAuthenticated: Bool = false
let firstName: String = "John"
let lastName: String = "Doe"

//common write change boolean
isAuthenticated = true
//common write string
let fullName: String = firstName + " " + lastName

You’re right, there are still a lot of people who write Boolean changes and String concatenation like the example above. But did you know that Swift has a cool and simple way to do this? Let’s take a look at an example.

//alternative change boolean
isAuthenticated.toggle()

//alternative string with string interpolation
let fullName: String = "\(firstName) \(lastName)"

Congratulations, you’ve made great progress in becoming a better Swift coder. Let’s keep going and try something even more interesting.

Function Parameter Label

In Swift, we’re all familiar with the syntax func name(name: "John"). In my experience, we can also write parameters for both internal and external usage in Swift. Let's take a look at a comparison of these two approaches.

func setAge(name: String, value: Int){
    print("\(name) is now \(value) years old")
}
//call function
setAge(name: "Paul", value: 20)

The function call seems to be working as expected. However, we should never stop learning. We can use some options to make our code easier to read for other developers, as follows.

//using external parameter label
func setAge(for name: String, to value: Int){
    print("\(name) is now \(value) years old")
}
//call function
setAge(for: "Paul", to: 20)

See, you can even read the function call as if it were natural language, right? Using external parameter labels makes the code more readable, but what if we don’t want to use parameter labels at all? It’s actually possible with Swift Omit Function. Let’s take a look at a code example to see how it works.

//using omit parameter label
func setAgeFor(_ name: String, to value: Int){
    print("\(name) is now \(value) years old")
}
//call function
setAgeFor("Paul", to: 20)

See how much easier it is when we can customize the way we write parameters in functions. I suggest that you always consider the context of the function when doing so. After all, a well-written function should accurately describe the code that is executed.

I hope you’re not feeling overwhelmed yet. Let’s continue our discussion of guard statements. What is a guard statement and how do you use it? Let’s find out together.

Guard Statement

Have you ever written a function to help ensure that your data is not nil or invalid? Maybe you’ve been writing code like this for a while.

func isValidNameCommon(name: String) -> Bool {
    if name.isEmpty {  
        return false
    }
    
    if !name.allSatisfy({ character in
        character.isLetter || character.isNumber
    }) {
        return false
    }
    
    return true
}

The code above works as expected, but the author still finds it a bit hard to understand, especially the use of negation in the check. The author then thought, if we can write the code like above, is there another way to make it easier to understand? Yes, we can use guard statements. Let’s look at an example of how to use guard statements to improve the readability of our code.

func isValidName(name: String) -> Bool {
    guard name.count > 0 else {
        return false
    }
    guard name.allSatisfy({ character in character.isLetter || character.isNumber }) else {
        return false
    }
    return true
}

Great, we’ve made the code easier to read and maintain. When should we use guard statements in our code? I’ll quote from SwiftLee.

Guard statements are used to early return from a function if a condition is not met. They are a great way to improve the readability and maintainability of your code by making it clear what conditions must be met for a function to continue executing.

As explained above, guard statements are not only more readable, but they can also help us to clarify the requirements for our functions. This is because guard statements will return early from a function if the condition is not met. This can help us to prevent errors caused by invalid data or other unexpected conditions.

The examples of code writing above show how guard statements can be used to improve the readability, maintainability, and safety of your Swift applications.

Additional

I have one additional case, which is related to writing arrays with default values. I found a great way to make the code shorter and more concise using default values. Let’s take a look at an example.

//Unique Case for default array
var scoresForUser: [User: Array<Int>] = [:]

func addScore(_ score: Int, for user: User) {
//check user existing in array
  if let existingArray = scoresForUser[user] {
    //update new score for user
    var newArray = existingArray
    newArray.append(score)
    scoresForUser[user] = newArray
  } else {
    //add new user to array
    scoresForUser[user] = [score]
  }
}

As we saw above, there is a function to add a score. Here, I will show you how to use default arrays to make this function even more powerful.

//you can handle that by using default if user not exist like this!
func addScoreNew(_ score: Int, for user: User){
    scoresForUser[user, default: []].append(score)
}

the case up is if you want a modify a value from var, if you just read only you can use anything!

Isn’t that amazing? I’m sure you agree with me. Using the right fundamentals can help us write more efficient and easier-to-read code that will be more sustainable in the future.

Reference

The 100 Days of SwiftUI

A weekly Swift Blog on Xcode and iOS Development

I would like to thank all the websites above for helping me find Swift fundamental patterns more easily.

To Conclude

I may not have a lot of experience to share, but I hope that the explanations and code examples I’ve provided will help you become a better developer who pays more attention to the fundamentals of code.

If you find that these tips have helped you improve your Swift code, I’d be grateful for any feedback you have. So please, don’t hesitate to reach out and let me know what you think.

Thanks!