Earlier quoted context omitted.
While half of the things you checked in that copy-paste are wrong, let me take the bait and say why it will work: - it's not just an arbitrary language, it's the new officially sanctioned programming interface for Apple's gigantic, wildly profitable ecosystem - it's much more concise than Objective-C - it's faster than Objective-C - it's safer than Objective-C - it has more features than Objective-C - ...yet it's ful…
How is Swift safer than Obj-C? I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.
ObjC was exceptionally type-unsafe. Any object type could be implicitly converted to and from the `id` type:
NSString* foo = @"hello world!";
id bar = foo; // no warning
NSDictionary* baz = foo; // no warning
The Foundation collections all used `id` for the values and keys when they had keys. `NSDictionary` will accept any object as a key, even though it will only work if the key is copiable and hashable, and it does mean that you could have keys of fundamentally different types in the same collection. Values can be heterogeneous too.As far as type safety goes, Swift is on par with modern languages.
ObjC also inherited several security issues of the C language, like unchecked arrays and unchecked arithmetic. Swift performs bounds checking by default (you can manipulate raw arrays with `UnsafePointer`) and has checked arithmetic by default (you can allow overflows by prefixing the operator with `&`, so `&*`, `&+`, etc). It also never requires you to allocate and deallocate buffers yourself.
So Swift is more secure because it has no buffer overflows, no integer overflows (though they're more an issue when you have buffer overflows) and no unsafe memory management. These are by far the three most commonly exploited vulnerabilities in software.