My initial takes on WWDC announcements…
I’m still waiting for more announcements, but I haven’t seen anything so far that pushes me any closer to Swift exclusivity. C++ is still unsupported, which is still a major blocker for cross platform projects. No word yet on the Swift standard library being preinstalled on devices (which I expect might be mentioned in a later session.) And my pet issue of not being able to iterate over enums still seems to be present in Swift 2.0. Apple seems to be trying to push Swift heavily with new Xcode features, but I didn’t really come out of today more convinced that I should be using Swift for application (I am pretty well convinced to use it for unit tests, but more on that later.)
The new try/catch way of handling errors also seems a little gross, and isn’t really what anyone was asking for. It’s also a strange reversal from last year where exceptions where purposely left out of Swift.
On the other hand, Obj-C got a few nice enhancements. The nullibility features that had been added previously were noted again, and there are now Obj-C generics. For those of us that still have code that cannot be ported to Swift, these features should make interop much easier. Apple also seems to be adding these features to allow them to continue maintaining Cocoa in Obj-C instead of doing a bulk port to Swift, like I previously suggested. There still doesn’t seem to be a move-all-the-APIs to Swift event coming, but as the lines blur between Obj-C and Swift, such a move doesn’t sound like it would sunset Obj-C anyway.
Graphics on OS X
In my WWDC Wish List I mentioned that I had hoped Apple would address the awful state of graphics on OS X. And they did. Kind of.
Metal’s performance seems promising, and a CoreGraphics and CoreAnimation layer on Metal is also intriguing. CoreAnimation on Metal could see a good performance improvement over what we have now, but CoreGraphics has traditionally done all it’s drawing on the CPU. Apple seems to be implying that CoreGraphics might finally be drawing on the GPU, which would be a huge advancement. I look forward to finding out more.
Apple’s whole hearted endorsement of Metal does seem to mean the end of the dream of a unified graphics API. Valve and the console manufacturers are strongly backing OpenGL, Microsoft is still backing DirectX, and now Apple is backing Metal. I didn’t expect a commitment from Adobe to support Metal, but I have a feeling getting third parties on board will be difficult. Valve’s logo was noticeably absent from the companies supporting Metal. There also seems to have been no movement on OpenGL in El Capitan. Long term, this could harm the availability of games and other software on Mac OS X.
Metal’s requirements are also fairly high. An initial driver take apart has found that a GeForce GTX 400, Intel HD4000, or AMD 7000 series GPU is required. Unless it was a higher end configuration, a lot of Macs that will support El Capitan won’t support Metal. This is especially a problem if the only way apps are going to function on those machines is a poorly maintained OpenGL path. I also worry about how well the Metal drivers will be maintained. At least Metal may eliminate a lot of the layers of software causing issues with OpenGL on OS X.
I still hope that Apple will implement OpenGL Vulkan on OS X. It would clear up a lot of these issues.
It was a really great day for unit testing tools. I got cut off from the last bit of the State of the Union session, and I’m super excited to see the new tools in action. Code coverage for Obj-C is something that has been really valuable to my workflow, and I’m very happy to see more official support.
UI Testing is also a huge step forward. Before, developers had Apple’s unstable UIAutomation tool as part of instruments, or third party tools that all complicated the build process. If you’re still on those tools, it’s time to switch. I’m especially excited that the tests seem to integrate cleanly into existing workflows, and hopefully into code coverage as well. Super great announcement.
There was something Apple introduced today that was absolutely huge that hasn’t gotten the attention it deserves, and might hint at some huge hardware changes…
iOS applications will now default to generating LLVM bitcode instead of code for a specific platform. Instead of generating ARM64 and ARMv7 code, LLVM intermediate code will be output, and then recompiled for the destination platform. Apple’s reasoning is that the code can be updated and optimized on the fly for current platforms with new compiler advancements, or new platforms.
The new platforms part is very interesting. I don’t buy the optimization update angle Apple is selling as much. Or the “application sizes will be smaller with less architectures” angle either. Apple could always strip out unneeded architectures. After all, they showed off they can strip out unneeded resources for a device as well.
If Apple planned on making a more catastrophic change, say changing from ARM to another architecture, such as a more custom architecture or even x86, they’d want to avoid having to run applications in emulation like they did on the Mac on such a low power device. By keeping applications in LLVM bitcode, they have the option of distributing applications not only for future ARM architectures, but for architectures that don’t even use the ARM instruction set. Hmmmm.
(At work we write a lot of NEON assembly, and this has certainly given us something to think about.)