Swift
Objective-C
isEqualToString
string comparison
programming languages

What is the Swift equivalent of isEqualToString in Objective-C?

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

In Objective-C, string equality is commonly written with isEqualToString:. In Swift, the direct equivalent for most code is simply the == operator, which compares two String values by content rather than by object identity.

Using == for exact string equality

Swift strings are value types, so equality is expressed in a natural way:

swift
1let first = "Hello"
2let second = "Hello"
3let third = "hello"
4
5print(first == second) // true
6print(first == third)  // false

That is the ordinary replacement for Objective-C code like this:

objective-c
1NSString *first = @"Hello";
2NSString *second = @"Hello";
3
4BOOL same = [first isEqualToString:second];

If your only question is "do these two strings contain the same characters in the same order?", == is the right Swift answer.

Comparing optional strings safely

A common source of confusion during migration is optional handling. In Swift, String? values can still be compared directly:

swift
1let a: String? = "admin"
2let b: String? = "admin"
3let c: String? = nil
4
5print(a == b) // true
6print(a == c) // false

This is convenient because Swift handles the optional comparison rules for you. If one side is nil and the other is not, the result is false. If both are nil, the result is true.

When you need to compare a non-optional string with an optional one, unwrap intentionally:

swift
1let expected = "admin"
2let actual: String? = "admin"
3
4if let actual, actual == expected {
5    print("Match")
6}

That keeps the intent clear and avoids accidental force-unwrapping.

Case-insensitive and localized comparisons

== is an exact, case-sensitive comparison. If you need more flexible behavior, use the comparison APIs provided by Swift and Foundation.

For a case-insensitive comparison:

swift
1let first = "swift"
2let second = "Swift"
3
4let sameIgnoringCase = first.caseInsensitiveCompare(second) == .orderedSame
5print(sameIgnoringCase) // true

For user-facing text, a localized comparison is often better:

swift
1import Foundation
2
3let first = "straße"
4let second = "Strasse"
5
6let sameLocalized = first.compare(
7    second,
8    options: [.caseInsensitive, .diacriticInsensitive],
9    range: nil,
10    locale: Locale.current
11) == .orderedSame
12
13print(sameLocalized)

This distinction matters because exact string equality and locale-aware user comparison solve different problems.

Bridging with NSString when needed

Most Swift code should stay with String, but you may still encounter legacy APIs or Cocoa code that expects NSString. Bridging is straightforward:

swift
1import Foundation
2
3let swiftValue = "Hello"
4let cocoaValue: NSString = "Hello"
5
6print(swiftValue == cocoaValue as String) // true

You can call isEqualToString: on NSString, but in mixed Swift code it is usually cleaner to convert to String and continue with Swift-native equality.

Common Pitfalls

The most common mistake is assuming == performs a case-insensitive comparison. It does not. "Admin" and "admin" are different unless you choose a case-insensitive API explicitly.

Another issue is mixing up equality of string content with identity of an object instance. Objective-C developers sometimes think in terms of objects and selectors, but Swift String equality is about value equality, which is exactly what you want most of the time.

Be careful with optionals as well. Force-unwrapping a String? just to compare it is unnecessary and can crash. Swift can compare optionals directly or you can unwrap safely with if let.

Finally, use locale-aware comparison only when the problem is truly user-facing text comparison. For keys, identifiers, tokens, or protocol values, exact equality is usually the correct rule.

Summary

  • The ordinary Swift equivalent of isEqualToString: is ==.
  • '== compares string content exactly and is case-sensitive.'
  • Optional strings can be compared directly, but explicit unwrapping often reads better.
  • Use comparison APIs such as caseInsensitiveCompare or compare(..., locale: ...) when the match should ignore case or follow locale rules.
  • In mixed Cocoa code, bridge NSString to String and keep the comparison Swift-native.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.