One more week to go before the start of WWDC 2020 and the rumour mill is starting to kick into high gear with discussions of an extra session, rumours that this will be the time that Apple will announce the transition from x86 to their own ARM based SoC designs that’ll form the foundation of Mac’s future. It’ll be interesting to see whether they do what they did when they moved from PowerPC to x86 by giving developers a developer kit then eventually then release a final products later on or will they do something smart like having a ARM based macOS farm where developers can remotely take advantage of ARM based hardware without Apple needing to hand out hardware and then get the developers to send it all back to them again.

As noted in a prior post I made, the migration is different to what took place in the PowerPC to x86 transition – not only was it a transition between platform it also required companies to move from non-Xcode IDE’s such as CodeWarrior to Xcode, move from one set of compilers with a code base tuned to dealing with the compilers quirks, limitations, work arounds etc. and moving to a new compiler that had its owns set of quirks, limitations etc. In the case of the move from x86 to ARM there is a vibrant ecosystem of third party libraries, open source projects that are working to not only support but optimising their code for ARM,

There was an essay put out by Steven Sinofsky (link) regarding the move by Apple over to ARM. Where do I start because it is one thing to comment about a possible future direct or directions of Apple but it is another thing when one doesn’t even acknowledge where things went wrong at ones old employer. I’ll put some points out there, not in any particular order but rather what came to me when I was reading through the article.

1. The problem with Microsoft’s attempt to create a platform that could go beyond win32 on the desktop into a broader operating system with a unifying API is the lack of any real vision communicated with the developer community. They first started off with Windows Phone 7 with a Windows CE base and utilising Silverlight for the development platform, that was then reset with Windows 8 and the future then was WinRT which was then reset once again with Windows 10 with the future now being UWP. As a developer are you really going to dedicate limited resources (time and money) in moving beyond win32 when there is no clear indication that the parent company even knows what it wants.
2. The lack of a clear vision manifested itself in the form of Microsoft failing to articulate where they want to take the platform – where does win32 fit into this? if UWP is to replace win32 then why keep adding new features to win32 or making new features access to win32 developers when you want developers to move over to the new platform? by making those new features accessible to both then aren’t you sending a mixed message, “UWP is the future but we’ll make all new features available for win32” thus sending the message that they’re not completely committed to the new platform.
3. The new platform that was developed (UWP) was developed by sitting on top of win32 resulting in all the dumb decisions that were made 30 years ago being inherited – MAX_PATH limitation rearing its ugly head as one example of that. It is one thing to keep win32 around for backwards compatibility – it would be business suicide killing off backwards compatibility but UWP should have been an opportunity to make a clean break and deal with the limitations and design flaws of the win32 API with a clear indication to developers that it was the way forward by pushing forward a gradual deprecation of parts of win32 along with deep restructuring of the system by removing large parts of the win32 out of kernel space to avoid a repeat of a fiasco which earned its ugly head not too long ago (link).
4. Microsoft demonstrated no confidence in their own platform when they failed to move the whole UI (shell) and bundled applications over to the new framework nor was there any announcement of Microsoft migrating their own products over to the new platform The net result? what developers saw was a new platform and its operating system vendor that was happy to encourage others to ‘dog food’ but not themselves. If you want third party vendors to use your platform then you need to be willing to use it yourself – “yes, you can use this platform for serious work”.
5. There is no reason for Apple to abandon AppKit and there is a tonne of developers already utilising AppKit already – for Apple not to provide AppKit on their ARM based Macs would be the same business suicide that removing win32 backwards compatibility would be. When it comes to the practical side, there is no technical reasons – it isn’t as though it is an assembly code riddled monstrosity that cannot be recompiled – they bought it from PowerPC to x86 and I’m sure they’ll bring it from x85 to ARM, and after all Catalyst relies on AppKit.
6. I see Catalyst as a short term stop gap measure because long term their eventual goal is to replace UIKit, Catalyst and AppKit with SwiftUI – a unified UI which has certain UI elements exposed based on the platform(s) targeted by the developer with a shared set of UI elements that are shared by both platforms. Over the years parts of the AppKit have been gradually been replaced with seperate frameworks resulting in movement away from having one big giant framework that does it all in favour of specialised frameworks instead. Btw when I am talking about ‘long term goal’ I’m thinking 3-5 years time frame.
7. The interesting part will be the parts that will be jettisoned – OpenCL is an obvious one they’ll get rid of given that almost no one takes avantadale of it and it has since been replaced with Metal Performance Shaders. OpenGl will be interesting given that everything from OpenGL 3.2 forward it is based on a modem LLVM based code where as everything prior used an old way of delivering OpenGL that I could see Apple dropping even that I’m sure those who do rely on OpenGL have already moved over to OpenGL 3.2 (or higher) or maybe have migrated to Metal.
8. Stop allowing or expecting third party developers to control parts of the application Ui that quite frankly they should have nothing to od with – the window management should be part of the system itself and it shouldn’t be an opt in situation where developers have to make their application compatible rather than the application automatically inheriting the change. Just take a look in house built modern applications that still need to be hand coded to take advantage of new features. At some point the operating system, not the developer, should be dealing with many functions that Microsoft have expected their parties to deal with resulting in the mess that exists today.