Avoiding dangling pointers requires a bit of discipline in pre-ARC Objective-C and C++, but now that we have ARC, isn't ObjC pretty much as safe as Swift? (Unless you explicitly use "assign" properties, of course.)
Objective-C's solution had its downsides, though. The classic `[firstName stringByAppendingString:lastName];` being fine when `firstName` is nil, but not if `lastName` is (though it doesn't always crash if `lastName` is nil – it's fine if `firstName is also nil!). Or how `[myObject isEqualTo:myObject]` returns false if `myObject` is nil. Or how adding a nil object to an NSArray doesn't crash (but is likely a bug!) when calling `arrayWithObjects:`, but does crash when it's an array literal.
These aren't world-ending problems, and you learn the rules easily enough, but it's like Objective-C only solved 1/2 of the problem.
Then there's the really strange corner cases, like how sending a message to nil was undefined behavior:
- when expecting a returned struct, before Apple switched to LLVM 3.0 (would vary depending on the platform's ABI, as well as the size of the struct)
- when expecting a returned floating-point value on PPC <= 10.4,
- when expecting a returned `long long` on PPC (it happened to return `(long)selector`)
For the record, I always loved how Objective-C handles this – I definitely preferred it to Java, Ruby, etc. where you're constantly checking for null or catching NPEs. But I like Swift's solution even more. I no longer have to remember about which parameters are nullable, or sanitize my inputs with `NSParameterAssert`s, etc.
No because there is the whole C part of Objective-C, including UB.
So unless there is some validation of 100% of the code writen by the team and third party libraries, it is impossible to ensure there aren't C style coding tricks being used.
Also ARC only applies to Cocoa like classes, there is no bounds checking, implicit casts are like in C, C style strings are still used in many APIs, and this are just a few examples of unsafety.