@Apr 02, 2019
Apple's biggest Swift mistake
Microsoft has been shipping .NET Framework runtime as part of Windows for over a decade.
It seemed like a good idea at the time.
For many reasons, it's still a good idea.
For example a small GUI program could be 100 kB in size because Windows included many megabytes of code that many programs could share.
With time, things got worse.
All code has bugs. The more code, the more bugs. .NET Framework has a lot of code so it has many bugs.
When you have tens of thousands of applications, some of them start depending on those bugs.
If Microsoft fixes a bug in .NET Framework, some applications will break because they depended on buggy behavior.
The more .NET applications there were, the more likely Microsoft was to break some application by making changes to .NET.
As a result, Microsoft mostly froze .NET Framework. While web platform was quickly improving, Microsoft's main UI technologies (WinForms, WPF) were frozen because they could not make improvements without breaking existing apps.
Microsoft changed the course recently and is now planning to provide WinForms and WPF as part of .NET Core 3. You're now expected to build stand-alone apps which include all the code you need.
What does that have to do with Swift and Apple?
Apple is going to repeat Microsoft's mistake. Their plan is to include Swift as part of iOS and OS X.
It seems like a good idea today.
10 years from now they'll wish they didn't.
They'll encounter the same problem as Microsoft had with .NET Framework: they'll be unable to evolve Swift because too many apps depend on the most subtle implementation details of whatever they shipped in the past.
The OS libraries will be frozen, unable to evolve and adapt to new trends.
Apple should follow Microsoft's lead: open-source as much of OS code as possible and evolve it independently of OS releases. This is what Microsoft started doing with Winforms and many other libraries that used to be shipped as part of the OS.
Go to index of articles.