Although we can't flat-out drop existing features anymore, we can certain evolve best practices, and introduce more robust features while deprecating and discouraging use of misfeatures over time. This isn't ideal, since getting from deprecation to actually dropping support takes a long time, and in the meantime the possibility of someone relying on features that negatively impact the usability of the language still lingers, but it can still steer the community forward. I for one would love to see a more Haskell- or Python-ish import model, along with the IDE support to automatically groom explicit import lists; @codafi had pitched this before on the old swift-evolution mailing list.
Just to mention that it's not the SSWG's mission to design software by committee. As per the SSWG charter everybody can pitch a library to the SSWG, existing, or new. Assuming it has been proposed, whether a piece of software is listed as 'SSWG approved' is determined by whether if fulfils the minimum requirements. The SSWG explicitly allows duplication and competition.
What the SSWG tries to achieve is to give you certain guarantees about liveliness (e.g. a project will get security fixes) and compatibility (it should work with the vast majority other Swift and for sure other SSWG packages) of a project.
The initial reason for the SSWG reboot was that we essentially had three larger ecosystems in the web frameworks (Vapor, Kitura, and Perfect) with very little sharing. The parties involved however all liked to have more sharing alongside to reduce duplication of efforts. But we also needed some reassurances that a certain packages has certain code quality, compatibility, and complies with other ecosystem standards.
Can Swift server side services use native Apple's native framework such as CoreData and CoreML?
I would imagine yes, but only if that server is running macOS. These frameworks are not available on Linux.
That depends on where you decide to host the "server side" services. If you run a macOS machine as a server, then yes. Those Apple frameworks will be available.
If you intend to host the service on Linux, then no.
Can Swift server side services use native Apple's native framework
such as CoreData and CoreML?
What the other folks have said plus…
If you want to run your server as a daemon, which is the normal way to do things, you have to make sure these frameworks are daemon safe. Apple doesn’t do a great job of documenting whether frameworks are daemon safe or not . Of the frameworks you mentioned:
I’d have no qualms about using CoreData from a daemon.
I’d be much more concerned about CoreML. It links with CoreVideo, and CoreVideo links with a lot of frameworks that I’d not consider daemon safe (like OpenGL).
If you absolutely need to use frameworks that aren’t daemon safe, you can run your server in a user context. This complicates things a bit:
You have to configure the machine to automatically log in as a specific user at boot.
That user better not log out.
This is nothing insurmountable, but it is something you need to plan for.
Anyway, this issue has nothing to do with Swift per se. If you have follow-up questions about it, please post them over on DevForums, and specifically the Core OS > Processes topic area.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
 Way back in the day we published a list, and some general guidelines, in Technote 2083 Daemons and Agents.
Yes only if you are running servers on macOS.
And please note that macOS is licensed only to Macs hardwares. Which means you gonna need physical Mac hardware to host your server. I'm not sure whether the license allows virtualization or not.