4 ms·

If you ever look under the covers at how Apple products are programmed you will know why. I'm not a big fan of Microsoft but if you compare, for example, the p

If you ever look under the covers at how Apple products are programmed you will know why. I'm not a big fan of Microsoft but if you compare, for example, the programming documentation on MSDN to Apple, it's night and day. Microsoft has clearly documented 95% of their APIs and for the most part, they are stable. Apple's APIs change constantly and are poorly documented. The documentation they do have is incomplete and full of dead links. How can you write good software on top of this?

millstone 9y ago
I agree that Microsoft's documentation is stellar for their Windows APIs. Apple's is noticeably worse. However Microsoft's APIs are not "more stable" than Apple's - in fact the Microsoft APIs change constantly. See Win32 -> MFC -> WinForms -> Silverlight -> WPF -> UWP -> WinRT... Or for languages, maybe you want to use or C++/CLI or C++/WinRT or C# or VB.NET or F# or JavaScript or the language they'll introduce next week. The treadmill is real and exhausting; what is a modern Windows app anyways? For comparison Apple wants you to write Mac or iOS apps in Swift, or in Objective-C if you can't use Swift.
- jcoffland 9y ago
  Microsoft's APIs are added to constantly. Apple continually breaks backwards compatibility.
  - steeleduncan 9y ago
    Microsoft abandon the entire API, and replace it with something new every couple of years (the grandparent comment has a good list). This has the benefit that once software does work it should continue working more or less indefinitely. Apple have mutated the same API over many years, however Xcode's default settings drift, deprecations are frequent, and the new macOS is rarely backward compatible with a large application. This means that each summer when the new Xcode/macOS combination is released you have to spend some time getting up and running again. I doubt that the ideal situation of a continually developed API with perfect backwards compatibility exists. In that case the getting your code building and running with the new Xcode/macOS each summer is likely less time consuming than rewriting against a new API every 5/10 years. If you are maintaining well established code, then the opposite is true.
    - pas 9y ago
      You can still install .NET 1.1 and run shit. I recently installed something that was probably first targeted Windows 98. The APIs listed by GP are deprecated and the platforms are not shipped/enabled by default, but that's worlds apart from intentionally breaking them (with almost no communication). Of course, I still prefer a good package manager and direct access to the source on GitHub/GitSomewhere, but MSDN is very well maintained.
  - blub 9y ago
    MS has backwards compatibility for existing software, but it's a gamble to start a new project using MS tech, you don't know what they will cancel, rename or invent next year. Apple doesn't have backwards compatibility for existing software and stuff breaks regularly from version to version. However, one can count on Objective-C to pretty much work (although Swift is still work in progress). So both suck, basically.
  - mrweasel 9y ago
    Microsoft is a little weird. The safe bet for a desktop application is to do it in WinForms. I'm pretty convinced that Winforms will outlive any of the newer frameworks from Microsoft. The XAML developers will jump to whatever the next thing is when it comes around, but the conservative WinForm developers won't go anywhere anytime soon, forcing Microsoft to continue supporting and developing Winforms. Throwing together a quick WinForm application is still much faster than building something using XAML, in my opinion. Especially if you don't know what you're doing, and that still how many in-house business applications seem to be built.
- pjc50 9y ago
  I've found that C++/MFC and C#/WinForms are the one that are stable and actually work over the long term. Our >20 year old app runs a lot of MFC code that is unmodified from that era.
- pjmlp 9y ago
  You mean like Quickdraw, Java Bridge, WebObjects, Quicktime Java Bindings, Carbon, Objective-C GC, Objective-C++ docs .... I can also pick up Objective-C class specific methods and classes that were dropped.
  - blub 9y ago
    No, he means Swift and Objective-C. That's what was, is and will be supported. On the other hand, Microsoft's API screw-ups are legendary at this point... not even they know what developers should use for Windows apps. I think Windows Phone was recently canceled, so that simplifies things a bit. And even if there was such a blessed SDK/language combination, they'd probably drop it or rename it next year ;-)
    - pjmlp 9y ago
      Many of those APIs listed by me were written in Objective-C. Which affected the way Objective-C was being used on Apple platforms.
- ac29 9y ago
  > However Microsoft's APIs are not "more stable" than Apple's You can pretty much always run apps for Windows XP (released 2001) on Windows 10. You can't run any apps from OS X 10.0 (released the same year) on modern macOS. Yes, there was a processor architechture change in there (and a subsequently dropped compatibility layer), but the APIs have changed enough that that isnt the main issue.
- SmellyGeekBoy 9y ago
  WinForms is 15 years old now and apps still run fine in Windows 10. Is that not stable?
- sli 9y ago
  I generally like MSDN's documentation, despite Google always sending me to an old version every single time (get on top of your SEO, Microsoft). That said... Fairly recently, I was looking in to controlling a service using C# and while the docs claimed that System.Management was deprecated, I could not find code samples anywhere that did what I needed without using System.Management. It doesn't seem like it's actually deprecated, and I couldn't find any corroborating claims that System.Management was deprecated, the mention only seems to exist on a single MSDN page. This one, in fact: https://msdn.microsoft.com/en-us/library/windows/desktop/aa393964(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... > Classes in the Microsoft.Management.Infrastructure namespace. (The System.Management namespace is no longer supported). For more information, see WMI .NET Overview. What exactly does "no longer supported" mean if not deprecated? Why is it still in use if it's not supported? Why don't the System.Management docs mention this at all? Full disclosure, I'm saying this as a very non-C# guy, so my relative inexperience with that ecosystem is absolutely a factor. But my thinking is that, if you're already a decently skilled programmer, you should at least be able to interpret documentation so long as it's not astoundingly terrible. In this case, there isn't a clear answer to my question, so I'm just left feeling like I'm writing doomed code. Sorry for the rant. It's a relatively minor gripe, to be sure, but it needs fixing.
danieldk 9y ago
When it comes to macOS, it seems that it simply stoped caring. Especially when it comes to features for their traditional UNIXy user base. Some examples: - It took them years to bring back features to Pages (e.g. linked text boxes). - Keynote now crashes on presentations that worked with older versions of Keynote (e.g. presentations converted with PDFToKeyNote). - XQuartz still doesn't permit native resolution in windows (meaning HiDPI-capable Gtk3+ are scaled up and blurry). - Location services steals focus from XQuartz, making X11 applications unusable. - macOS regularly crashes on my MacBook Pro with two external displays when the display configuration changes (e.g. one display is turned off)). - I regularly run into a bug where my MacBook Pro does not charge when the adapter is plugged in (even though the status icon shows the charging status). Plugging out and in again fixes this. - Many basic UNIX utilities are buggy and never updated or fixed. E.g. take grep: $ echo "1234 1234 1234" | egrep -o '^....' 1234 123 4 12 - macOS provides no trivial way to semi-automatically install drivers for Bonjour printers anymore if they support Postscript. Pretty annoying if you need scanner functionality. - Preview.app/PDF kit have become pretty much useless. E.g. form filling for a lot of work forms does not work correctly any more (it used to work find pre-10.12 or 10.11). And since 10.13 Preview.app crashes all the time while regenerating a PDF document using LaTeX (a use-case that worked fine before), sometimes when zooming. Moreover, going through a slide deck with the arrow keys often makes weird jumps through the slides. ...and I could go on for a while. macOS used to be so far ahead of the curve on the UNIX desktop (and perhaps the desktop in general) that even with all the current deficiencies, macOS is still a reasonable desktop. But it is clear that macOS is now beyond its high point. And if Apple does not lose their 'iOS is the future of the desktop'-blinders, things will only go further downhill. What makes this even more sour is that Mac prices have gone up a quite a bit. A reasonable MacBook (and not the near-EOL Air) with more than one port and a 256GB SSD starts at 1749 Euro. When I started using a Mac as a student ten years ago, an up-to-date Mac Mini was 500 Euro and a reasonable specced (and upgradable) MacBook was ~1000 Euro. I think the last Mac Pro and the iMac Pro show the disconnect with their traditional user base. People do not want overpriced works of art. They want a stable macOS. They want an upgradable tower Mac Pro, they want a memory-accessible Mac Mini, they want a MacBook Pro that stops optimizing for thinness but has a larger battery, MagSafe, and perhaps one or two USB 3.0 ports during the transition period.
- 9y ago
kalleboo 9y ago
I could go on and on about how bad Apple's developer documentation is. So much stuff is missing an overview document or sample project, so you have documentation on the 10 classes but not how they fit together. Sample code that does exist won't compile on the latest Xcode 1/4 times, especially if it's Swift. I've found code that won't compile even in the Swift language documentation. There's almost never any documentation what can go wrong and why. These days I prefer Stack Overflow answers to Apple's own documentation since it's more up-to-date

millstone 9y ago

I agree that Microsoft's documentation is stellar for their Windows APIs. Apple's is noticeably worse. However Microsoft's APIs are not "more stable" than Apple's - in fact the Microsoft APIs change constantly. See Win32 -> MFC -> WinForms -> Silverlight -> WPF -> UWP -> WinRT... Or for languages, maybe you want to use or C++/CLI or C++/WinRT or C# or VB.NET or F# or JavaScript or the language they'll introduce next week. The treadmill is real and exhausting; what is a modern Windows app anyways? For comparison Apple wants you to write Mac or iOS apps in Swift, or in Objective-C if you can't use Swift.

jcoffland 9y ago
Microsoft's APIs are added to constantly. Apple continually breaks backwards compatibility.
- steeleduncan 9y ago
  Microsoft abandon the entire API, and replace it with something new every couple of years (the grandparent comment has a good list). This has the benefit that once software does work it should continue working more or less indefinitely. Apple have mutated the same API over many years, however Xcode's default settings drift, deprecations are frequent, and the new macOS is rarely backward compatible with a large application. This means that each summer when the new Xcode/macOS combination is released you have to spend some time getting up and running again. I doubt that the ideal situation of a continually developed API with perfect backwards compatibility exists. In that case the getting your code building and running with the new Xcode/macOS each summer is likely less time consuming than rewriting against a new API every 5/10 years. If you are maintaining well established code, then the opposite is true.
  - pas 9y ago
    You can still install .NET 1.1 and run shit. I recently installed something that was probably first targeted Windows 98. The APIs listed by GP are deprecated and the platforms are not shipped/enabled by default, but that's worlds apart from intentionally breaking them (with almost no communication). Of course, I still prefer a good package manager and direct access to the source on GitHub/GitSomewhere, but MSDN is very well maintained.
- blub 9y ago
  MS has backwards compatibility for existing software, but it's a gamble to start a new project using MS tech, you don't know what they will cancel, rename or invent next year. Apple doesn't have backwards compatibility for existing software and stuff breaks regularly from version to version. However, one can count on Objective-C to pretty much work (although Swift is still work in progress). So both suck, basically.
- mrweasel 9y ago
  Microsoft is a little weird. The safe bet for a desktop application is to do it in WinForms. I'm pretty convinced that Winforms will outlive any of the newer frameworks from Microsoft. The XAML developers will jump to whatever the next thing is when it comes around, but the conservative WinForm developers won't go anywhere anytime soon, forcing Microsoft to continue supporting and developing Winforms. Throwing together a quick WinForm application is still much faster than building something using XAML, in my opinion. Especially if you don't know what you're doing, and that still how many in-house business applications seem to be built.
pjc50 9y ago
I've found that C++/MFC and C#/WinForms are the one that are stable and actually work over the long term. Our >20 year old app runs a lot of MFC code that is unmodified from that era.
pjmlp 9y ago
You mean like Quickdraw, Java Bridge, WebObjects, Quicktime Java Bindings, Carbon, Objective-C GC, Objective-C++ docs .... I can also pick up Objective-C class specific methods and classes that were dropped.
- blub 9y ago
  No, he means Swift and Objective-C. That's what was, is and will be supported. On the other hand, Microsoft's API screw-ups are legendary at this point... not even they know what developers should use for Windows apps. I think Windows Phone was recently canceled, so that simplifies things a bit. And even if there was such a blessed SDK/language combination, they'd probably drop it or rename it next year ;-)
  - pjmlp 9y ago
    Many of those APIs listed by me were written in Objective-C. Which affected the way Objective-C was being used on Apple platforms.
ac29 9y ago
> However Microsoft's APIs are not "more stable" than Apple's You can pretty much always run apps for Windows XP (released 2001) on Windows 10. You can't run any apps from OS X 10.0 (released the same year) on modern macOS. Yes, there was a processor architechture change in there (and a subsequently dropped compatibility layer), but the APIs have changed enough that that isnt the main issue.
SmellyGeekBoy 9y ago
WinForms is 15 years old now and apps still run fine in Windows 10. Is that not stable?
sli 9y ago
I generally like MSDN's documentation, despite Google always sending me to an old version every single time (get on top of your SEO, Microsoft). That said... Fairly recently, I was looking in to controlling a service using C# and while the docs claimed that System.Management was deprecated, I could not find code samples anywhere that did what I needed without using System.Management. It doesn't seem like it's actually deprecated, and I couldn't find any corroborating claims that System.Management was deprecated, the mention only seems to exist on a single MSDN page. This one, in fact: https://msdn.microsoft.com/en-us/library/windows/desktop/aa393964(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... > Classes in the Microsoft.Management.Infrastructure namespace. (The System.Management namespace is no longer supported). For more information, see WMI .NET Overview. What exactly does "no longer supported" mean if not deprecated? Why is it still in use if it's not supported? Why don't the System.Management docs mention this at all? Full disclosure, I'm saying this as a very non-C# guy, so my relative inexperience with that ecosystem is absolutely a factor. But my thinking is that, if you're already a decently skilled programmer, you should at least be able to interpret documentation so long as it's not astoundingly terrible. In this case, there isn't a clear answer to my question, so I'm just left feeling like I'm writing doomed code. Sorry for the rant. It's a relatively minor gripe, to be sure, but it needs fixing.

danieldk 9y ago

When it comes to macOS, it seems that it simply stoped caring. Especially when it comes to features for their traditional UNIXy user base. Some examples: - It took them years to bring back features to Pages (e.g. linked text boxes). - Keynote now crashes on presentations that worked with older versions of Keynote (e.g. presentations converted with PDFToKeyNote). - XQuartz still doesn't permit native resolution in windows (meaning HiDPI-capable Gtk3+ are scaled up and blurry). - Location services steals focus from XQuartz, making X11 applications unusable. - macOS regularly crashes on my MacBook Pro with two external displays when the display configuration changes (e.g. one display is turned off)). - I regularly run into a bug where my MacBook Pro does not charge when the adapter is plugged in (even though the status icon shows the charging status). Plugging out and in again fixes this. - Many basic UNIX utilities are buggy and never updated or fixed. E.g. take grep: $ echo "1234 1234 1234" | egrep -o '^....' 1234 123 4 12 - macOS provides no trivial way to semi-automatically install drivers for Bonjour printers anymore if they support Postscript. Pretty annoying if you need scanner functionality. - Preview.app/PDF kit have become pretty much useless. E.g. form filling for a lot of work forms does not work correctly any more (it used to work find pre-10.12 or 10.11). And since 10.13 Preview.app crashes all the time while regenerating a PDF document using LaTeX (a use-case that worked fine before), sometimes when zooming. Moreover, going through a slide deck with the arrow keys often makes weird jumps through the slides. ...and I could go on for a while. macOS used to be so far ahead of the curve on the UNIX desktop (and perhaps the desktop in general) that even with all the current deficiencies, macOS is still a reasonable desktop. But it is clear that macOS is now beyond its high point. And if Apple does not lose their 'iOS is the future of the desktop'-blinders, things will only go further downhill. What makes this even more sour is that Mac prices have gone up a quite a bit. A reasonable MacBook (and not the near-EOL Air) with more than one port and a 256GB SSD starts at 1749 Euro. When I started using a Mac as a student ten years ago, an up-to-date Mac Mini was 500 Euro and a reasonable specced (and upgradable) MacBook was ~1000 Euro. I think the last Mac Pro and the iMac Pro show the disconnect with their traditional user base. People do not want overpriced works of art. They want a stable macOS. They want an upgradable tower Mac Pro, they want a memory-accessible Mac Mini, they want a MacBook Pro that stops optimizing for thinness but has a larger battery, MagSafe, and perhaps one or two USB 3.0 ports during the transition period.

9y ago

kalleboo 9y ago

I could go on and on about how bad Apple's developer documentation is. So much stuff is missing an overview document or sample project, so you have documentation on the 10 classes but not how they fit together. Sample code that does exist won't compile on the latest Xcode 1/4 times, especially if it's Swift. I've found code that won't compile even in the Swift language documentation. There's almost never any documentation what can go wrong and why. These days I prefer Stack Overflow answers to Apple's own documentation since it's more up-to-date