[zainhoda]

Long overdue -- there's a very noticeable difference in runtime errors with Swift libraries vs the rest. This is especially true of AVFoundation, which is an absolute mess of hidden and undocumented state. Swift optionals and enums will go a long way to fixing that.

[saagarjha]

One of the interesting side effects of this is that those new libraries are going to have significantly worse introspection and hotpatching opportunities, so they better code them correctly, or things are going to really suck.

[ponyous]

Would you mind to elaborate why this is the case? I am not in Swift/Obj-c ecosystem so I'm just clueless.

[saagarjha]

Apple, like all software companies, ships bugs. People who write software for their platforms also ship bugs, but sometimes they have to deal with the bugs that are in the OS and system frameworks. Sometimes these get fixed in future updates, but sometimes they don't, and in any case until then something needs to get done for software to work correctly, not crash, etc.

Apple, like most companies, does not provide official mechanisms to patch bugs out of their software. They also keep most of their system frameworks closed-source. However, it just so happened that they write most of their software in programming languages are are highly dynamic and easy to reverse engineer, allowing third parties to dig into implementation details when they need to, understand how things work, and most importantly, change things as needed. It's risky and dangerous work, but every major app you've ever used on an Apple device ships with several fixes like these at any given time.

The Apple of today has very different goals from their frameworks. Shipping symbols that help people understand how the system frameworks function is "needless bloat" that "exposes implementation details". Indirection and patching functionality is seen as overhead that can be removed for improved performance. App review does not like it when people ship self-modifying code, and as a result patching system frameworks is also not permitted due to codesigning. Swift in particular removes a lot of dynamic dispatch functionality, gets stripped far more aggressively, and compiles to code that is far less readable that what we had before.

What this really means is that we are moving closer to a system where what Apple ships is what you get. Being able to make tradeoffs in this area is necessary, but the ones Apple have chosen mean that they have to be very confident that they don't ship bugs. If they aren't capable of doing this, well, it's not a good tradeoff.

[nicoburns]

Obj-c is basically a dynamic language on top of C, whereas in Swift most things are statically determined at compile time.

[KerrAvon]

This will not directly affect AVFoundation, or any other framework which is not Foundation itself.

[stephen_g]

Not as part of the work from this announcement, no, but it is surely an indication that Apple is moving in a direction where those other libraries will eventually be re-written in Swift too.

[stephen_g]

(Oops, I commented before looking at the link and thought it was pointing at something like this - https://www.swift.org/blog/future-of-foundation/ - not the git repository! But you know what I mean)