116

With the introduction of Swift I've been trying to get my head round the new language

I'm an iOS developer and would use types such as NSString, NSInteger, NSDictionary in an application. I've noticed that in the "The Swift Programming Language" ebook by Apple, they use the Swift types String, Int, Dictionary

I've noticed the Swift types don't have (or are differently named) some of the functions that the Foundation types do. For example NSString has a length property. But I've not been able to find a similar one for the Swift String.

I'm wondering, for an iOS application should I still be using the Foundation types?

Cezar
  • 55,636
  • 19
  • 86
  • 87
Alec
  • 1,247
  • 2
  • 9
  • 9
  • 3
    Prefer `String`. However, `String` functionality is still a bit limited in the alpha release, so `NSString` will be more used for now. We hope they will fix the API until GA. – Sulthan Jun 04 '14 at 13:27
  • 1
    Also, you can call `countElements(str)`, to answer that specific part of your question. – Nate Cook Jun 04 '14 at 13:44
  • Better, you can call `"foo".length" directly in Swift. An implicit cast to `NSString` is added for you by the compiler! – Gabriele Petronella Jun 05 '14 at 00:49
  • 1
    @GabrielePetronella .length may not work correctly for special characters. Such as Emoji or Chinese characters that take up 2 or 3 unicode chars. countElements is the correct method to use. – Fogmeister Jun 09 '14 at 11:33

9 Answers9

106

You should use the Swift native types whenever possible. The language is optimized to use them, and most of the functionality is bridged between the native types and the Foundation types.

While String and NSString are mostly interchangeable, i.e, you can pass String variables into methods that take NSString parameters and vice versa, some methods seem to not be automatically bridged as of this moment. See this answer for a discussion on how to get the a String's length and this answer for a discussion on using containsString() to check for substrings. (Disclaimer: I'm the author for both of these answers)

I haven't fully explored other data types, but I assume some version of what was stated above will also hold true for Array/NSArray, Dictionary/NSDictionary, and the various number types in Swift and NSNumber

Whenever you need to use one of the Foundation types, you can either use them to type variables/constants explicitly, as in var str: NSString = "An NSString" or use bridgeToObjectiveC() on an existing variable/constant of a Swift type, as in str.bridgeToObjectiveC().length for example. You can also cast a String to an NSString by using str as NSString.

However, the necessity for these techniques to explicitly use the Foundation types, or at least some of them, may be obsolete in the future, since from what is stated in the language reference, the String/NSString bridge, for example, should be completely seamless.

For a thorough discussion on the subject, refer to Using Swift with Cocoa and Objective-C: Working with Cocoa Data Types

Community
  • 1
  • 1
Cezar
  • 55,636
  • 19
  • 86
  • 87
  • 6
    +1 for the reference to `bridgeToObjectiveC()` and explaining the connection between NSString and Swift's String. – Chris Jun 15 '14 at 02:45
  • 2
    hey cezar, I think bridgeToObjectiveC is deprecated if you care to update your answer. – Dan Beaulieu Nov 05 '15 at 05:55
  • I notice in the Swift 3 manual that the Foundation types are passed by reference, while the native types are passed by value (or something like that I don't fully understand at this point). It would be great if you could update your answer discussing the implications of that. –  Nov 18 '16 at 00:23
36

NSString : Creates objects that resides in heap and always passed by reference.

String: Its a value type whenever we pass it , its passed by value. like Struct and Enum, String itself a Struct in Swift.

public struct String {
 // string implementation 
}

But copy is not created when you pass. It creates copy when you first mutate it.

String is automatically bridged to Objective-C as NSString. If the Swift Standard Library does not have, you need import the Foundation framework to get access to methods defined by NSString.

Swift String is very powerful it has plethora of inbuilt functions.

Initialisation on String:

var emptyString = ""             // Empty (Mutable)
let anotherString = String()     // empty String immutable    
let a = String(false)           // from boolean: "false"
let d = String(5.999)           //  "    Double "5.99"
let e = String(555)             //  "     Int "555"
// New in Swift 4.2 
let hexString = String(278, radix: 18, uppercase: true) // "F8"

create String from repeating values:

 let repeatingString = String(repeating:"123", count:2) // "123123"

In Swift 4 -> Strings Are Collection Of Characters:

Now String is capable of performing all operations which anyone can perform on Collection type.

For more information please refer apple documents.

Sandy Rawat
  • 685
  • 7
  • 12
  • 2
    This answer should get more up-votes. This is the fundamental difference between String and NSString. Everywhere else they are almost interchangeable – Max Feb 02 '17 at 04:18
  • 1
    Great answer. value v.s. ref type note especially. – spnkr Apr 29 '20 at 21:43
12

Your best bet is to use Swift native types and classes, as some others have noted NSString has toll free translation to String, however, they're not the same a 100%, take for example the following

var nsstring: NSString = "\U0001F496"
var string: String = "\U0001F496"

nsstring.length
count(string)

you need to use the method count() to count the characters in string, also note that nsstring.length returns 2, because it counts its length based on UTF16.

Similar, YES The same, NO

Emanuel
  • 1,981
  • 1
  • 20
  • 28
7

String and NSString are interchangeable, so it doesn't really matter which one you use. You can always cast between the two, using

let s = "hello" as NSString

or even

let s: NSString  = "hello"

NSInteger is just an alias for an int or a long (depending on the architecture), so I'd just use Int.

NSDictionary is a different matter, since Dictionary is a completely separate implementation.

In general I'd stick to swift types whenever possibile and you can always convert between the two at need, using the bridgeToObjectiveC() method provided by swift classes.

Gabriele Petronella
  • 106,943
  • 21
  • 217
  • 235
  • Swift's `Int` data type is stated, in the book, to be the same as the architecture's word size. `NSInteger` is also the same size as the word size of the architecture. – MaddTheSane Jun 05 '14 at 05:35
7

Swift 4 update

String gets revisions in swift 4. Now you can directly call count on it and it consider grapheme clusters as 1 piece, like an emoji. NSString is not updated and is counting it in another way.

var nsstring: NSString = "‍‍‍"
var string: String = "‍‍‍"

print(nsstring.length) // 11
print(string.count)    // 1
Community
  • 1
  • 1
Fangming
  • 24,551
  • 6
  • 100
  • 90
  • 1
    `NSString`s probably won't be updated to deal with grapheme clusters: It would break too many apps that rely on the old behavior. Also, `NSString.length` counts the UTF16 characters. – MaddTheSane Jul 05 '18 at 23:32
6

Since the objective C types are still dynamically dispatched they're probably going to be slower. I'd say you're best served using the Swift native types unless you need to interact with objective-c APIs

Jiaaro
  • 74,485
  • 42
  • 169
  • 190
  • Yes thats exactly the answer. And the avoidance of dynamically dispatched methods and object variable access is all that makes this speed improvements they talked about at WWDC. In the past everyone worried about performance used C++ string and containers to get static dispatching. – Lothar Jun 04 '14 at 13:38
5

Use the Swift native types whenever you can. In the case of String, however, you have "seamless" access to all the NSString methods like this:

var greeting = "Hello!"
var len = (greeting as NSString).length
Nate Cook
  • 92,417
  • 32
  • 217
  • 178
1

Swift Strings are quite elegant and easy to use, unless you need to parse them. The whole concept of indexing into Swift strings is just plain crazy. Whenever I need to parse through a typical unicode string, I convert it to NSString. Swift makes this a bit tricky though in that the common "character" integer expressions like ' ' or 'A' or '0' don't work in Swift. You have to use 32, 65, 48. Unfortunately, I'm not kidding! Because of this, I've put most of my string parsing code into an NSString extension written in Objective-C.

Yes I do know WHY Swift's designers made String indexing so crazy: They wanted to be able to express many-byte characters like emoji as single "Characters". My choice would have been to let this rare use case be expressed as multiple UTF16 characters, but what the heck.

0

String is a struct

// in Swift Module

public struct String

{

}

NSString is a class

// in Foundation Module

open class NSString : NSObject

{

}

kashish makkar
  • 161
  • 2
  • 5