My second reaction being: "Oh, well, I'll just make it a web app instead of a native app."
edit Rephrased the last sentence.
2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp.
On the API itself. I think it is a really good idea to make a new generic tcp/udp library. With everything we use today included, and as a first class citizen from the first minute of the design. The particular API they present looks good and it is very well thought out. Mostly integrates async tcp/upd/tls seemless and supports changing interfaces on the fly. This alone is a big improvement. Does this while still providing raw access to the out/input net queues. You can even access the lowlevel details and parameters if you want or need to.
However this is not the first modern network API. QT (qt network) has a good network layer for one. There are simpler alternatives: libuv, libevent etc. This are more speciallized and dont handle all that Network.framework offers.
I agree that removing sockets would break large chunks of the ecosystem. On the other hand, after OpenGL's removal, it's not clear to me that Apple cares anymore about anything outside of Cocoa.
> 2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp.
Of course. Nearly 100% of my code is not webapp/http. Which is why I'm annoyed when I see (or in this case, fear) cross-platform APIs disappear.
> On the API itself. I think it is a really good idea to make a new generic tcp/udp library. [...]
I have no problem with a new, better, API. But I would certainly be more enthusiastic if any effort was presented to make it cross-platform and, hopefully, open-source and/or standardized.
Implementing this (similar functionality) API on Linux on top of libuv/libevent and gnutls + multipath tcp shouldnt be much work. Well, maybe multipath tcp is problematic, I dont know details there.
[0] "Supposed to" is my opinion on OpenGL. At the time it was the only cross-platform graphics API, and with Valve pushing a DirectX to OpenGL converter and building all their games with OpenGL support, we were finally going to get to a standard interface to graphics hardware. I guess that ship has sailed now. At least there will be abstractions that compile to the various platforms.
They opensourced libdispatch[1] and ported it to linux, so there's hope they might do the same with Network.framework. It would be time consuming, but it shouldn't be hard for someone in the opensource community to write a linux / BSD implementation of this stuff on top of posix sockets & libdispatch.
I suspect the reason they didn't opensource it is that it looks like it was designed mostly with phone apps in mind, not servers. And thats a shame - it looks like it would be a great addition to the swift server story, especially given it does user-space networking out of the box. I still prefer swift's ergonomics over rust for application development, and this would help immensely. (Rust is steadily closing that gap though, what with native wasm support and async/await on their way.)
You can keep using sockets if that is your thing.
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.
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 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?
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?
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.
Well, what are the niceties you see? I'd generally say that Pages and Keynote's integration with macOS is one of their strengths.
Spot on. You even gave an example of this: VSCode. If Microsoft is doing it, you can bet loads of other people are.
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.
At some point it may happen, but there’s simply no writing on the wall for it right now.
But I'll remain at least a bit worried, if you don't mind :)
Doesn’t mean they couldn’t have changed course, but I’m sure it was a factor.
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.
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.
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.
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 skimmed the video and it really looks like sockets++: once you have the connection the rest is up to you. It doesn't seem to break anything on the wire. Unless you're referring to compilation - but we can assume that Libuv will soon abstract this platform away (just like it does with Windows IOCP).
So, while Apple is not going anywhere, whichever technologies you're using to build your iOS apps might.
If it's deprecated on macOS, it's going to be around for a lot longer. They can certainly make things hellish for users trying to install your kext, but the APIs will still be there.