The point is that an NSArray can only hold classes (an Objective-C limitation), so if the element type is not a class, it can't be an NSArray.

> Why would elements being classes change this?

It's more the other way around: having non-objects allows things to change.

Being able to transparently bridge between Objective-C and Swift is very valuable, particularly because the vast majority of library/framework code is written in Objective-C.

So Swift Arrays are designed to be bridgeable to NSArray whenever possible, for example by simply pointing to an NSArray as their backing store. NSArrays can be non-contiguous, largely due to them not really being arrays in the strict sense, but more like Smalltalk OrderedCollections, meaning you can, for example, add and remove elements from the front.

However, non-object Swift types cannot be stored in an NSArray and would thus never be expected in Objective-C code. Therefore, there is no need to bridge those, meaning that you can use different kinds of backing store.

It's very valuable...to working with the existing Apple ecosystem. These are the issues that keep sinking Swift as a general purpose language: it is hamstrung by its requirement to bridge to Objective-C.

Thought that was strange too, but if you read further it talks about having to use NSArray which isn’t always contiguous for class types to have free bridging with obj-c.

I think that because a Swift array of objects must be bridgeable from Objective-C, and Objective-C arrays might be non-contiguous, Swift arrays of objects must be permitted to be non-contiguous. This isn’t a concern with arrays of structs because they don’t exist in Objective-C. In practice, I’d imagine that Swift arrays of objects that are never bridges to/from Objective-C are almost always contiguous.

not sure why this is apparently being downvoted - this is a perfectly reasonable question for someone who isn't familiar with objective-c