Downloaded and installed the iFFmpeg update but found a bug, I did a screenshot then sent it off to the developer where the developer replied back within a couple of hours then a day later an update was released which fixed the problem. That is what I love about the Mac ecosystem – developers actually care about the products they put out there and taking care of their customers. Reminds me very much of MarsEdit and the asking questions to the developer along with reporting bus I found – fixed within hours and updates pushed out as soon as the Apple AppStore accepted the update. My experience with the Apple ecosystem is overwhelmingly positive – great developers focusing on making their product better, taking care of their customers and focusing on making sure that the over all experience, not just the ‘guts’ of the software, is pleasant.
All those glowing praise does have a much more serious point to make when it comes to user interface particularly when it comes to developers focusing on the small details that make all the difference. Take OS X, when it was first released it was a mixture of Carbon and Coca elements but eventually when the move to 64bit came it started mid way through the 10.6.x release cycle then formalised in 10.7 and because Apple made the tough decisions we’re reaping the rewards today with a gorgeously consistent look and feel without all the drama that Windows users are dealing with.
I noted in a post last night what Microsoft should have done was this:
Win32 was pushed over to the side and labelled as ‘legacy’ where the only purpose is to to provide backwards compatibility then when the WinRT stack is moved into the C:\Windows\WinRT (the kernel would sit in C:\Windows and drivers would sit in C:\Windows\Drivers) directory which is a new directory structure in which all the frameworks are put along with the bundled applications based on WinRT. Part of that would also include moving code around from the original dll’s to the new dll structures as noted in the linked document ( link ) then organise everything on top of that. Win32 would be relegated to an optional subsystem that one can uninstall with the Windows 10 installation being a pure WinRT that is hardware accelerated and HI-DPI compatible from day one rather than a ‘feature’ that is bolted on at the last minute. Then start moving everything from Win32 to WinRT from within Microsoft with a public ‘five year plan’ where all divisions were aiming to get all their code moved to WinRT within 5 years so that the only purpose at that stage for Win32 is to support third parties then in 5 years following complete conversion (10 years after Windows 10 has been released) it becomes an optional installation that is downloaded on demand. Developers need a long term path and so far with the mishmash combination mixture of win32, MFC, WinRT, WPF and more you’ll never get the sort of consistency be it in the matter of supporting Hi-DPI or basic support for consistent touchpad gesture behaviour.