My initial takes on WWDC announcements… Continue reading
At work, we support a lot of platforms. We support iOS and Android, Windows, Linux, supermarket checkout scanners, Raspberry Pis, old Windows CE devices, and more. And all the devices run our same (large) core code, and all that code is written in C++. I’m not the biggest fan of C++. But there’s no doubt when we need to write something that works across a range of platforms, it’s a rich, commonly understood tool. It’s also been a massive blocker for Swift adoption for us.
For our mobile customers, we do provide both Java and Obj-C APIs. They’re both just wrappings around our C++ core, and they do the conversion from all the Obj-C or iOS native formats into the raw buffers we need to handle in our C++ core. Whenever I look at doing a Swift native SDK in the future, I’m still stuck on not having native C++ support from Swift code. In order to provide a pure native Swift API in the future, I’d have to wrap our ever growing C++ source base once in Obj-C, and then wrap it again in Swift. It just doesn’t make sense to wrap the same code twice over. Continue reading
As WWDC fast approaches, and rumors of the next OS X update focusing on polish persist, I thought I’d go over my wish list for what I’d like to see Apple address.
Vulkan/Enhanced Graphics Support
The graphics situation on OS X is bad. 3D graphics on OS X have been rocky from the beginning (the first ever public OpenGL demo on OS X, which sadly I cannot find video of), but Apple in the past was willing to participate in a benchmark war with DirectX. At WWDC 2006, I remember Apple was still rolling out new features to try and compete with DirectX’s performance. And with 10.6 Apple introduced OpenCL which went on to become an industry standard for GPU based computation.
But recently, while Linux and Windows have had continuous cycles of improvement for 3D graphics, OS X has been seeing improvements in fits and starts. Mavericks, which moved to OpenGL 4, looked like it might be a recommitment to improving 3D graphics on OS X. But Yosemite didn’t seem to bring any real improvement to OpenGL at a time when OpenGL on the platform is already seriously lagging.
There is some speculation that Apple will bring Metal to Mac OS X, which from what I’ve heard seems like a strong possibility. Metal on Mac OS X might provide a direct route to high performance 3D and 2D graphics, but Apple might have a long road ahead in convincing developers to adopt Metal, and GPU manufacturers to write drivers for it. The driver quality on OS X for OpenGL is already so hit and miss it’s hard to believe that Apple would be able to get AMD and Nvidia to write a good driver for Apple’s proprietary Metal platform, when the OpenGL driver quality is already not that great. I have no doubt that Apple would be able to get a few software vendors on stage to demo Metal support on the Mac (Epic seems like a good possibility), but there are several third party vendors (like Adobe or Valve) that I see not being eager to have to support another standard. I could see Adobe dragging their feet for a long time on supporting Metal, or possibly not supporting it ever.
Recently the next version of OpenGL called Vulkan was announced and I think this would be a great chance for Apple to really improve cross platform graphics on OS X. Vulkan already has strong support from Valve (which is huge for a developer that used to be strongly in the DirectX camp), and is more likely to draw support from Adobe. The word is Apple is still on the fence about supporting Vulkan on the Mac. Vulkan supports the same capabilities as Metal, which puts it in an awkward position on OS X. But there will be a lot of smaller developers that won’t be able to put forth the effort to port to Metal, especially in the professional software community, so it would be foolish not to support Vulkan. Vulkan also promises a simplified driver architecture, which could be a boon for the traditionally complex development of OpenGL drivers on Mac OS X. I’d even suggest that maybe Apple should be spinning down development of Metal and really focusing on Vulkan instead, but I think the politics of Apple wouldn’t really allow for that.
At the very least, seeing support for OpenGL 4.5 in Mac OS 10.11 would be ideal, but it would be great to see Vulkan support. Metal would be an improvement as well, but I worry it would further alienate some developers of both professional software and games if only Metal were present as a modern API.
A Modern Window Server
(I don’t have visibility into the OS X window server, so this section is based on speculation on how Apple has implemented some parts of Yosemite. Please let me know if there are any corrections to be made.)
OS X’s window server is another component that had a very impressive start, looked to have a very impressive future, and then suddenly seemed to have public facing development stop while competing platforms passed it by.
The very first version of the Mac OS X window server did every bit of it’s drawing on the CPU. That made sense at the time. Great dedicated GPUs were still not common on the hardware OS X supported, and the OpenGL support required may not have been present either. But as a result, basic things like dragging windows across the screen was choppy on the first versions of Mac OS X.
In 10.2, Apple added something called Quartz Extreme. While everything inside of a window was still drawn on the CPU under Quartz Extreme, the contents of the windows themselves were stored on the GPU, meaning operations like moving a window around on the screen became very quick. There was a further project called Quartz 2D Extreme (later QuartzGL) which would have drawn the contents of the windows themselves with the GPU. This project was comparable to Windows Vista’s Windows Presentation Foundation which promised similar features to unlock fancy effects such as windows with a glass like transparency. While WPF was the source of a lot of Vista’s early performance issues, high requirements, and consumer confusion (Microsoft had two tiers of Vista certification for hardware, and one was not compatible with WPF), Microsoft’s investment in a fully GPU accelerated window server eventually paid off with a fast and responsive user interface that is capable of rendering advanced effects with ease.
Apple’s QuartzGL project eventually fizzled out due to performance issues (some interesting benchmarks are still posted here). With 10.11, it might be time for Apple to take a second look at extending QuartzGL further. Microsoft has pushed through their performance issues, and many of the visual effects Apple is trying to do with Yosemite could be speed up by GPU acceleration.The “glass” vibrancy effect OS X is using doesn’t seem to be GPU accelerated, which might be leading to some performance issues (I sometimes see vibrancy backed views “lag” behind their window being drawn which leads me to believe the vibrancy effect isn’t drawn as part of window compositing on the GPU.) GPUs are really good at these sorts of effects, and it would be great to have a window server that could do things like flag a portion of a window to the GPU as transparent, and then attach a shader to that portion of the window. As with Windows, not every element on the display would have to be drawn on the GPU. Certain views could opt in to GPU backed drawing (such as the vibrancy view), which would help the performance of views that could benefit, without hurting the performance of other views.
My understanding is that QuartzGL is still present in some form in Yosemite, and that applications can opt in to it, but it would be great to see QuartzGL taken a few steps further to allow the advanced OS X vibrancy effects to be GPU backed.
Networking and WebKit Enhancements
Yosemites’ networking woes have been well documented at this point, but I’ve also noticed a decline in Safari’s quality. HTML5 web views in particular don’t perform right, the controls always seem to be in the wrong place, the video is scaled incorrectly, and sometimes they don’t play at all. I’m having to open Chrome more and more often these days and I really wish I wouldn’t have to.
As a follow up to my post about the Mac Pro, I had one more thing that I wouldn’t mind seeing at WWDC, but it’s really a long shot. If Apple doesn’t really care to continue maintaining their pro hardware, they should really think about licensing OS X. It doesn’t have to be a license free for all. Maybe they could only license to certain HP product lines. And Apple hasn’t been against licensing in the past. Apple’s failures in markets like the server market weren’t necessarily because OS X made a poor choice for servers, but because the company didn’t seem to be willing to provide the support services required for that market. Apple’s Pro hardware may be in a similar place.
If Apple really comes out supporting Pros over the next year in a big way, I’ll gladly eat my words. But I’m becoming more and more convinced that licensing OS X would allow Apple to keep users who are happily buying Apple software (and would be paying Apple licensing fees) as an alternative to having them leave the platform entirely would be the best course of action. If Apple isn’t willing to dirty themselves with towers that can be opened and customized, or 1U rack mount servers, they could let someone else serve those markets for them.
End of Sandboxing For the Mac App Store
The Mac App Store is slowly dying, and sandboxing is a big reason. Apple either needs to fix sandboxing, or remove it as a requirement. This is again a place where Windows 10 is pulling ahead of Apple.
Real Exchange Support on OS X
Microsoft Outlook, especially the new beta version, provides a good Exchange client on Mac OS X. But I’d love to see the built in support enhanced. Mail.app still doesn’t support push email. The Exchange client in iCal still sucks (better meeting availability assistant, please.)
A lot of the suggestions I’m making are not user facing, but are instead foundational. OS X hasn’t had many foundational enhancements in almost 10 years (not counting security orientated things like Gatekeeper.) Microsoft has put a lot of working into their foundations that cost a lot of time and money that Apple has so far been unwilling to commit. My worry is that if Apple doesn’t concentrate on the less glamorous aspects of OS X, like graphics performance, the user experience will continue to decline. Apple is simply stacking too many new features on an aging foundation. Beyond stabilizing the features they already have, Apple really needs to look at building a foundation for the next 10 years of the Mac.
I’ve been looking at replacing my 2008 Mac Pro, and as much as I’d like to replace it with a new Mac Pro, the Mac Pro just looks so odd when you compare it to both Windows products and other Macs.
The most visible missing feature that has been widely commented on is the lack of an Apple 5k display. I don’t really want to buy a Mac Pro at the present time because I’m pretty sure it’s going to get outdated by Thunderbolt 3, and I’m not sure what the 5k support picture will look like for the current Mac Pro in the future. Continue reading
On Twitter, I’ve been vocal that I don’t believe Obj-C is going away any time soon. For reference, Apple’s stance on the matter is:
“Objective-C is not going away, both Swift and Objective-C are first class citizens for doing Cocoa and Cocoa Touch development.”
It’s important to note that while there are a lot of community websites stating that Swift is the replacement for Obj-C, that has never been any sort of official position from Apple.
This “There can only be one language” phenomenon also seems entirely unique to the Apple developer community. The Windows .NET environment is up to approximately two dozen supported languages with a common API, and it’s made that community stronger, not weaker. Yet instead of taking advantage of a position where we have two languages, each with their own unique strengths, we’re asking which one should be sent to the chopping block.
But even if it’s just my opinion it’s a good thing to have two languages around, let’s review why realistically Apple probably isn’t going to stop development on either Swift or Obj-C. Continue reading
(There are Star Trek spoilers here.)
My girlfriend and I have been watching Star Trek: The Next Generation in order, from the beginning. This morning we just got to “All Good Things”, the final episode of The Next Generation. I’ve spent the rest of the day thinking about why Star Trek used to be so popular as a TV series, and why it feels like it’s lost it’s way. And then I had a weird thought. Star Trek had certainly had it’s up and downs after Next Generation went off the air in 1994, but after the 90s ended, things went really badly. Star Trek Enterprise, the last TV series, was prematurely canceled. Plans for a fifth Next Generation movie fell through after the fourth, Star Trek Nemesis, was a commercial failure. And it wasn’t just that people were over Star Trek. Star Trek, with the same writers, and the same producers, had seriously declined in quality. So what happened? And then I had a totally crazy thought. Could it have been 9/11? I know, crazy. But after 2001, something about Star Trek got weird. Star Trek got unnaturally… dark.
In the debate on Apple quality, OS X Snow Leopard is usually cited as the high mark in recent OS X quality. Whether or not you believe that Snow Leopard had less bugs than any other release (which I tend to), another thing has changed since Snow Leopard is how Apple distributes Mac OS X. Continue reading
My mom loved her iPad 2. She got it a little more than 3 years ago. It’s been with her and my dad all over Europe. She’s used it with her camera to import photos. She does shopping on it, looks up directions in maps, browses Craigslist.
In November I got a text from her. She was strongly thinking of getting rid of the iPad and buying an Android tablet. She’d made a mistake and had upgraded to iOS 8. Desperate, she asked if there was a way to undo the upgrade. Otherwise, the iPad had to go, and it’s replacement wouldn’t be an Apple product. She was furious at Apple, wondering why Apple did this to her iPad. Continue reading
The release of the iWatch SDK has given developers a head start in adding WatchKit to their applications, but with the release of the iWatch Simulator, they’ve also given developers a valuable insight into how the iWatch API stack is shaped. The WatchKit framework runs on the iOS device, but to power the simulator Apple has also added many of the device side frameworks. With a little elbow grease, we can learn a lot about the iWatch’s software stack.
This was my first “handheld” device.
It was a NEC MobilePro 200. My neighbor had bought it, but never found a use for it, so I got it in exchange for some web work I did for him. It had Mobile Word and Excel, Solitaire, and a 56k modem in the PC card slot I could use for dialing up and checking email. I couldn’t sync it with my Mac, but aside from that it worked great. I could do spreadsheets and documents in science class comfortably, and when I wanted to be a real nerd, find a phone line someplace to check my email. It was a really big device, but it was a great work companion.
But eventually, like everything else electronic, it died. I don’t remember why. I just remember being sad it wouldn’t boot anymore. So it was time to upgrade. And I upgraded to this…