And Swift is mostly or mainly used for iOS. Most developers out there think iOS development must use Swift. Even a complete and comprehensive Swift tutorial for MacOS is quite rare.
4 Likes
To be precise… Swift marketshare is not mobile development, but iOS development. 
I can't even write fancy console program using Swift without calling C libraries. While I can do the same thing with Object Pascal using the classic CRT unit. That's one of the reasons I made ANSITerminal library for Swift.
3 Likes
Why is it embarrassing for the primary marketshare of a language to be in one of the 2 most popular software platforms that have ever existed? If Swift could never be used outside of iOS development it would still be one of the most popular languages around. See Objective-C
There's a difference between a language and an app-platform. Dart and JavaScript are ~useless on mobile by themselves. React Native and Flutter are app-platforms with tens of thousands of development hours on the books that make those languages relevant on Mobile. If a company wants to poor that amount of resources into a similar effort for Swift on Android or Web, I would love it. Without that it's irrelevant to the vast majority of use cases.
2 Likes
My point is it's the exception for a language to have multiple major use cases. Most languages only have one, and that's hardly "embarrassing" or not worth investment. Especially given it's still brand new in terms of programming languages.
1 Like
I respectfully disagree. It's common that a programming language has multiple major use cases, not exception. The most obvious example is C/C++. The others are Python, Basic, (Object) Pascal, C#, Java, etc. Although those languages don't cover all use cases but they do cover multiple major use cases.
Although it's unnecessarily embarrassing, it's still worthy investment. Swift since went open source was declared as general purpose programming language that will able to target many platforms. Linux was the first operating system supported outside of Apple platforms, though some people thought the support for Linux development seemed to have lower priority and quality.
What I think the most problem in Swift development is different focus between Apple and the Swift community. Apple seems to care only about its own platforms. SwiftUI, Combine, and ABI stability showed that. On the other hand, Swift community want Swift to support non-Apple platforms with the same priority as Apple ones.
So, if Swift has UIKit/AppKit for Apple, the community want Swift should have similar solution for other platforms as well. At least, the foundation to build UIKit/AppKit for other platforms are there for community to work upon. This thread by Mr Kremenek showing that Apple is listening and seems trying to fix this particular problem. We should support the team.
6 Likes
Regardless of the merits of that claim (which may be true for all I know), it is a stated goal for Swift not to be in that camp of languages. From Swift.org - About Swift (my emphasis):
Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.
The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services.
4 Likes
Aren't those the exceptions? (most of which I pointed out) On the other side there's (off the top of my head) Objective-C, Dart, Ruby, Kotlin (that may change), PHP, Go, Rust, Matlab, Visual Basic. Then there's the numerous application-specific languages that have been created.
To be extra clear, I'm talking about what a language is used for, not what's technically possible.
Right, and I'm really hopeful that will happen! I'm not saying it won't or shouldn't, I'm responding to (IMO) unfair criticism that a 5 year old language having (very) widespread adoption on "only" one platform is somehow a failure and "embarrassing".
I wouldn't call it embarrassing and Swift certainly isn't a failure as a language.
But it still has some distance to go in order to achieve its stated goal, methinks. Hence this roadmap.
5 Likes
Can we shift this discussion on to a more constructive course? The original post already notes that this is an area we want to improve:
More platforms, more easily deployed-to, with better (and cross-platform) tooling, and a richer ecosystem. If you have ideas about how we can reach those goals, we would be happy to hear them. Complaining that we haven't reached them yet without suggesting improvements isn't very helpful.
34 Likes
Exactly! Now that one use case is established (with another being actively cultivated) it's time to build out the things necessary for world domination! 
With the recent evolution of SPM, platform-agnostic Swift is becoming much more viable (for me) to develop. The more that part of the eco-system develops, the more compelling Swift is for developers/companies to use for new libraries. Jump ahead to having memory-mangement and C++ integration and Swift may soon be in a league of it's own!
Side-note:
Where do Swift Playgrounds fit into the ecosystem? Is that a Swift thing or an Apple thing? It's a really nice way to play with the language and test things out, but it feels like it's kind of gotten lost in the shuffle the last couple years.
With good SPM integration (and some performance/UX improvements) it would be a perfect way to test out new libraries!
2 Likes
Yeah, it seems like we could avoid fragmenting the language by making it so that Swift is an "umbrella module" that transitively imports modules for multiple levels of support, like a Swift.Standalone module that defines just the basic runtime-independent machine types and operations, a middle-tier module Swift.Basic that adds runtime-supported features and types like the collections and maybe String without full Unicode support, and finally the complete Swift.Full standard library as it exists today. That seems like it could let embedded and other limited ports get off the ground without splintering the language base, since code written against one of the subset modules would still be valid "real" Swift code. One remaining concern, though, would be that the package ecosystem would probably by and large target the full standard library.
16 Likes
Yes, I have a pretty good high-level view of how this will unfold, which I wrote about here tracked in this top-level bug. I'm not currently working towards this but I can help provide guidance or mentorship for anyone who is interested.
There are details and engineering tradeoffs to be discovered from actually doing the work. We need to get Unicode data (specifically UCD, not CLDR) into the standard library binary. If the size of that data is acceptable, then this is pretty straight forward. Otherwise there is more engineering required to subset and compact the data, balancing tradeoffs between load time, speed of access, and binary size.
Grapheme breaking algorithm and normalization algorithms should be straight-forward to write, as they're mostly data-driven. Grapheme breaking will need some release-to-release updating, but hopefully not much. The Swift optimizer is much better now (and is improving), so making one that's very fast will hopefully not require undue hackery.
Note that these data files will exist in stdlib binary (and accesses to ICU are not inlined), so outside of statically-linked contexts, when we solve the data size problem above we should be good as far as the client is concerned. For statically linked contexts, we'll want to explore how to divide up the data such that it can be more-easily stripped.
For example, we could add a flag to trigger a warning/error on certain Unicode.Scalar.Properties which may pull in a lot of the data.
Isolating ASCII-ness might not be necessary if we get an important subset of the data nice and compact. Equatable and Collection conformance semantics rely on that important subset, which is much smaller than all of the UCD. Otherwise, we can have a mode that will insert a trap if they need to be consulted (e.g. non-trivial graphemes or non-trivially-NFC string contents).
12 Likes
I've moved to using notebooks for tasks I would have used playgrounds for. It's platform agnostic, and even more powerful than a playground without a lot of the quirks and pain points.
6 Likes
Of everything here, Generalized Existentials could have the biggest positive impact to the enjoyment and ease of using Swift. I think every developer has run into it when trying to make some advanced use of Swift generics.
It's listed in the Generics Manifesto and I'm also surprised it isn't more a bigger priority given how impactful it would be.
6 Likes
I think your tone is inappropriate right now. Please feel free to share your thoughts, but it would be fair to everyone not to shout and claiming something is 'fake' or someone is 'close minded' just because you personally have a different opinion. 
3 Likes
In my efforts to use Swift on non-Apple platforms, the one thing I’d say needs to be done to grow adoption is to improve the C-interoperability. API Notes documentation and support, and SwiftPM support for building and integrating with existing C libraries is critical. I found it very hard to write Swift code against some existing libraries like SDL2.
In addition to making C libraries look swifty (much in the same way Apple does for its own C libraries like Core Graphics), basic C interop could stand to be improved. It's really hard to work with C memory, and fixed-length arrays in structs, and so on.
2 Likes
Oh dear, it can be really depressing how unconstructive many discussions turn out... could we simply (and silently) agree on "it would be really nice if cross platform support is improved" instead of arguing about "excuses" and relativizations for the current situation?
I'm also concerned about the number of flagged or deleted messages: As you can (could...) see, flagging itself is also some sort of aggression, and it can be worse than the actual content that got flagged.
Imho it's way better to write a short personal message with a full explanation (when you do so in the thread, this not only adds noise - it's also a much more competitive context).
9 Likes
Please don't forget to add macOS High Sierra to the list of supported platforms. I can understand that Apple doesn't want to support old SDKs, but I can not understand why not to make the compiler and the language available there. That is weird. If Apple doesn't want to make the language available on their own not so old macOS version, will it ever has willing to support it on the other, "alien" platforms?
3 Likes
Extending on the commentary above on the C interoperability improvements I'm so much looking forward to Swift supporting C++ interoperability at all - it's not only a present pain point for most of our daily work on iOS/macOS development but also something that would enable Swift adoption by a much bigger use base share in Windows and Linux.
It is not until you need it that you realize how many common libraries and whole ecosystems (e.g. games) rely on C++ components.
1 Like
Something else that would be great: Swift support on tiny MCUs. Today we can use C/C++ and Python on Arduinos with ease, and it gets a lot of people thinking Python is the be-all, end-all language. The ability to strip down Swift to work on tiny architectures would be great, but there are some substantial MCUs with lots of RAM but no formal OS that I think would benefit greatly from Swift. Being able to build a Swift back-end the excludes certain features (Dispatch, for example), would be cool.
And who knows? Maybe it's possible to build out parts of an OS to support all of Swift on these little platforms.
5 Likes