> Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC,
Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Most of Apple's CVEs come from code written in C or C++, not Objective-C.
If you look at the original review videos (or even the keynote), you may notice that the first iPhone lags quite a bit. Of course, it's not Objective-C that causes it, but rather the limited hardware of the time.
Their failure was due to management failures, stupid decisions like the "burning platforms" memo, or introducing new WP versions without backwards compatibility.
Nothing to do with the greatness of iOS that has created revisionists of the mobile computing platforms history.
For the same reason python is fast for machine learning: because the performant parts were written in C.
Ignoring slick animations (which were written in C, if not in hand-tuned assembly) typical UIs of apps on the original iPhone could have run (a bit slowly and in monochrome) on an original Mac, that is in 128kB RAM on a 8MHz CPU.
Yep -- and more than that, I’d say that animation orchestration worked well because of the very elegant design that leaned on Objective-C’s strengths (like dynamic key-value observation to track animatable properties).
And using reference-counting rather than garbage collection helped to minimise jankiness even on low-memory systems.
I think Android in particular had a very hard time matching iOS here because Java just didn’t lend itself to that dynamic programming style, and because the GC was just inherently janky. (It’s a lot better now that hardware is vastly faster.)
Because the original iPhone was so stripped down that it could run on that thinly little slow cpu. It took Apple years and years to add features back into iOS frameworks. Every one very considered and every attempt to not destroy the battery of the iPhone. Multi tasking only around in iOS 4 right? Like on iPhoneOS 1 every app was closed when you hit that home button.
That it worked so smoothly was the result of extremely focused UX.
> Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part.
Ehhhh. If you write Swift the same way you write Obj-C, it will generally be as fast or faster. You only fall off the happy performance path when you use Swift features that don't even exist in Obj-C. That's not Swift being slower, that's Swift letting you use abstractions that aren't possible in Obj-C. But you don't _have_ to use them.
And given that Obj-C is a superset of C, you can't reasonably claim both that "most CVEs come from code written in C or C++" and also that Obj-C is as memory safe as Swift.
You can use the existing Obj-C libraries instead, which by definition do not use them.
I find it hilarious that Obj-C devotees object to this, since it precisely mirrors their argument for decades in the face of bogus performance complaints: “you can just use normal C functions”. They were right then, and you can just use Obj-C libraries today.
I think it’s a fair comparison to look at the idiomatic way to do something in a language and use that as the reference. Doing things on arrays in Swift often means people will call filter and reduce and map a bunch, while an Objective-C programmer might write a loop. It just so happens that LLVM can sometimes optimize the latter better. I mean, I could make the exact same argument you’re making about Objective-C being “as fast as C”: it literally is C. But when people use it they write methods and create objects, which are not things they can do in C. So I think it’s fair to call it “slower” if it needs to go through dynamic dispatch to enable the code that a normal developer would write.
This shouldn’t be true, ObjC’s only innate advantage is compile time, because the compiler is simply doing less and is capable of producing far worse (unsafe) code.
At runtime Swift can utilize static dispatch, where objective C is mostly dynamic. Good swift code should generally be faster.
Performance isn't about what you believe should be true, but about what actually is true. Kinda like science. (versus religion)
> ObjC’s only innate advantage is compile time
Objective-C has a bunch of advantages. Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile.
And there are languages with very comparable feature sets to Swift that are way faster to compile.
> At runtime Swift can utilize static dispatch
"can"
> where objective C is mostly dynamic.
Not true. The C part of Objective-C (it is most of the actual language) is very static.
Also, Swift has some pretty amazing dynamic performance pitfalls. For example protocols. You see, protocols in Swift can be adopted by both structs and classes. Meaning that when you call a function via a protocol, the compiler doesn't even know the size of the arguments or how to access them or copy them into the function's scope. So even that has to be handled by a small vtable, and you haven't actually done anything with that argument yet!
As this is one of the many places where Swift can lose a cool few orders of magnitude of performance, you obviously need the optimiser to specialise the function for specific callers. Which it can do, sometimes, at some cost, as long as it can actually see the caller and callee at the same time, in the same compilation unit.
IIRC, Uber had an OOPSLA paper describing the extra compiler pass they had to write to get their app's performance to at least somewhat acceptable levels, because the existing optimiser wasn't good enough.
And when you want to do separate compilation, you're sort of hosed, because you don't have access to the caller when you compile the callee.
Agree with most of your comment, but Uber’s thing was probably just as likely to be a team unable to say “no” to new code rather than one that “needed” people to anneal compiler passes
Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Most of Apple's CVEs come from code written in C or C++, not Objective-C.