> Not everyone cares about cross-platform, some developers rather specialize in a given platform.

True.

> You can keep using sockets if that is your thing.

For the moment, yes. However, as you know, earlier this week, Apple has officially deprecated OpenGL and OpenCL, a few years after introducing a competing (and admittedly suprerior) API. It is my understanding that Apple has not attempted to get this replacement API standardized, nor to offer it on any other platform. While it's hard to deduce from such a small sample, this precedent does suggest that the days of sockets are numbered.

This would make the life of some of my colleagues quite more complicated, and it would, in time, simply get rid of the macOS version of a number of existing cross-platform applications whose authors have neither the time nor the energy to rewrite the network layer.

Every effort to get rid of plain unsafe C APIs is a plus on my book.

Apple has enough business with developers that care about macOS experience, not plain ports from other platforms.

When I buy a computer with a specific OS, I want the experience provided by the OS APIs.

I understand your point. I also dislike a lot these plain unsafe C APIs.

However, I am a developer. When I write an application, I only have so much time to spend on ports. Anything that requires me to have different designs for different platforms is bad for me. So, in the ideal case, we'll end up with a few high-level cross-platform abstractions (which may actually share Network.framework's API, for all I know) on top of networking, and everybody will remain happy. In the worst case, we'll end up with bits of duct tape, or simply with fewer macOS apps.

Also, even as a macOS user, most of the applications I use daily are cross-platform: Firefox, Thunderbird, VSCode, my various compilers & interpreters & debuggers, VLC, Gitter, Open Office, Terminal, games, etc. In fact, looking at my recent applications, the only single-platform applications I seem to be using are Keychain, SimpleComic, Instruments (the only one in the list to particularly integrate with the OS), Notes, Calendar. I sometimes use Pages and Keynote, both of which have nice UX, but the niceties don't strike me as particularly OS-integrated.

As I mentioned above, everything that makes it harder for developers to add macOS to their list of targets encourages them to not port their app to my current OS of choice. I'm thinking of, well, many in the list above, including games.

This is, I imagine, part of the reason why so many developers left single-platform development for web development. At least, that's my reaction.

> This is, I imagine, part of the reason why so many developers left single-platform development for web development. At least, that's my reaction.

Spot on. You even gave an example of this: VSCode. If Microsoft is doing it, you can bet loads of other people are.

> I sometimes use Pages and Keynote, both of which have nice UX, but the niceties don't strike me as particularly OS-integrated.

Well, what are the niceties you see? I'd generally say that Pages and Keynote's integration with macOS is one of their strengths.

Yes precisely. I’m sure this varies from person to person but the applications that have the most staying power in my tool belt by far are those that are well executed first class citizens of my platform of choice. Cross platform apps written by developers who are more concerned with an easy one size fits all solution nearly always fall to the wayside.

I chose the platform I use for a reason. Why should I be ok with apps that undermine that by taking the lowest common denominator approach to porting?

Interesting. As a counterpoint, if I look at the toolkit I'm using right now on my MacBook, it's:

Chrome

Firefox

Hipchat

Vim

Git

So, not one single-platform tool in the bunch. I'd even go so far to say that, aside from my terminal emulator and app install tool, I don't use any single-platform tools in my day to day job.

> Why should I be ok with apps that undermine that by taking the lowest common denominator approach to porting?

Because they're, in many cases, as good if not better than the native-only alternatives?

I guess it depends on what types of apps one tends to use and what work you do. While I make frequent use of the terminal, I live in UI apps all day, so bad ports tend to stick out more prominently. If I lived in vim or emacs I could see it not mattering as much.

Do you use iTerm for opening vim?

Clutching at straws.

Which of the apis provided by the socket layer do you find to be unsafe?

All that require manually keeping track of pointers, structure and buffer sizes.

That's why you have wrappers in the language of your choice that will handle this for you.

I agree. I extend same to other software like databases etc. I have seen so many project over abstract and that turns out useless when migrating or supporting additional backend with same abstracted solution.

The people who tend to care about high performance on a specific platform are game developers, and we all know Macs don't have that market. And with deprecating OpenGL, they probably aren't going to be getting it either. People on web are always saying performance of language doesn't matter, but then when these ultra-specific libraries come up it becomes different--- but I'd say server performance is _way_ more important than how fast my Notepad app runs...

Well, also web browser developers, authors of A/V software, etc.

Do you want Safari to be the only web browser on macOS, Quicktime to be the only video player, etc? Not saying that it will happen, but with the disappearance of OpenGL and if sockets eventually disappear, too, it will become more difficult for independent web browsers (e.g. Firefox, Servo), independent video players (e.g. VLC, MPlayer), etc. to create or maintain a macOS version.

While there’s truth to this, there’s no real discussion here about deprecating or removing BSD sockets. UNIX, POSIX and OpenGL are very, very different things to discuss, and Apple deprecating one doesn’t speak to any real expectation of deprecating anything else.

At some point it may happen, but there’s simply no writing on the wall for it right now.

Fair enough.

But I'll remain at least a bit worried, if you don't mind :)

OpenCL didn't seem to be succeeding, so that's not entirely surprising. It is disappointing that they've chosen to deprecate OpenGL and ignore Vulcan in favor of Metal, though. Although I don't know much about this particular area, and I couldn't tell you about the merits of Vulcan vs Metal. It's hard to tell whether there's any good technical reasons for their decisions or if it's purely just business in that they don't want to contribute their resources to something that will benefit Android.

Admittedly, I am also not well versed in this area. My guess is, because Metal is proprietary, they can include intimate details of their hardware platform to squeeze out the most performance. And they probably would not feel comfortable having that same level of detail in Vulcan.

They also started making/using (and deploying?) Metal before Vulkan was announced/available.

Doesn’t mean they couldn’t have changed course, but I’m sure it was a factor.

And they may still yet change course. At this point it’s hard to say.

> Not everyone cares about cross-platform, some developers rather specialize in a given platform.

Yeah. This is exactly what people thought in the early 2000s of IE6. It was the de facto 'standard' web browser. Whole enterprises were built on the assumption that no other browser matters.

But the world around changed. IE6 became obsolete. Then insecure. People kept running it to use the old apps that would not work on modern browsers. But eventually, IE6 had to be buried.

Thousands of apps containing billions of lines of code had to be re-written at an astronomical cost. Just because, for a short while, we once thought specializing on one platform was a sustainable long-term strategy.

You are claiming a false dichotomy. Specialization doesn't mean future-deprecation. Every single cross-platform app is written to an abstraction. There is no implicit assumption that all abstractions are good. Whenever I hear cross-platform code I think slow bloated web-apps or slow bloated java apps with a funky UI.

Websites written for IE6 can still be used today with minor changes. The problem is activex and other crappy plugin technologies. If people had just targeted Win32, those apps would still be working today - but probably still end up requiring a rewrite because of modern security requirements.

Which is why those devs now specialize in Chrome instead.

Sad but largely true.

On the other hand, it is easier to install Chrome on your machine, if you need a Chrome-locked webapp, than to install macOS on the same machine. In fact, the only platform on which you cannot install a Chromium-based Chrome is iOS, and that's a political choice by Apple.

edit Rephrased entirely.

Blocking all third party code (and most first party code) from creating executable pages is a pretty strong security decision, but yes it has political ramifications.

You can also code in a language with good cross platform network APIs like Go or use a wrapper library like boost::asio or libuv. The latter are likely to add support for this eventually if there is a strong benefit to doing so on MacOS.

I'm ambivalent about platform-specific solutions but I welcome any attempt to obsolete socket() and select()/poll() and friends. I absolutely loathe that API.

I couldn‘t care less about cross Platform honestly, and yeah the most of the mobile market use Andoird, well, the android user (average) don‘t download apps, do not spend money in apps, so... is out of my target.

Wot. Citation needed? I may not be an "android user (average)" but I download apps every day (paid and free) and have spent far more money than I'd like to admit on the Play Store.