Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.
Creating a good cross-platform
GUI framework is probably harder
than creating a good cross-platform
language.
SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tell you that the current "native" experience sucks green potatoes. There are like 9 or 12 different UI technologies I must interact with each month. All with different text sizes and massively inconsistent UI paradigms.
So I think there is an opportunity here.
But, I bet SwiftUI → Web will come first. And if that happens, SwiftUI on Windows, and desktop Linux, will be a no-brainer and will happen.
And if it doesn't happen, then probably SwiftUI won't matter outside of the Apple ecosystem, and that will mean Swift won't matter much in the end, either. (EDIT: I don't mean Apple need do this and I don't expect they will. But SwiftUI is just an API; anybody could port it to whatever environment they want, and there are already some nascent third-party efforts to implement it for HTML/web.)
Full disclosure disclaimer: former NewtonScript programmer
It looks like the bear is in keeping up with all the platform updates all the time though.
Unlike things like react native you wouldn't be actually using the native components necessarily unless you can implement the UI frameworks components in terms of them. Otherwise they would need to be written from scratch.
That being said, my experience with SwiftUI users is that they don't like it because it is so different from the standard Mac experience (props and re-renders and state...). And the documentation is poor (IMO has been Apple standard from MapkitJS to iOS Swift documentation to SwiftUI) which leads to a negative dev experience. Try finding what causes a component to re-render in SwiftUI vs React. If you find it great and please post it, but it's not easy to find in my simple research.
When flutter for desktop lands into beta I think it will pick up even more pace and would be very hard to ignore for a lot of companies.
But Swift doesn't run on Android, does it?
Not really. I'm sure there are plenty who will just stick with Qt based options or even Electron.
I've seen a lot of stuff built in PyQt by people who aren't strictly developers and who learned Python only because it fits with some other aspect of their job. There isn't a lot to incentivise them in learning a new language.
Maybe befause React native uses OS UI components while Flutter creates everything from scratch. https://microsoft.github.io/react-native-windows/
I don’t remember which video it was exactly, but one of the higher ups talked about future technologies within Microsoft and how they were doing more and more GUI-based thing with react. And if you look at it, they’ve done pretty amazing things within the JavaScript eco-system in general. Office 365 is amazing, Visual Studio Code is amazing and it just wouldn’t make sense for them to go from typescript to dart.
Especially when you consider how unfinished flutter is. We’re a C#/power shell with a little Python shop with a lot of Enterprise Microsoft techs. We still considered Flutter because Xamarin wasn’t working out for us and we’re not big on JS or big enough to do native, but flutter just doesn’t fill our needs either. That’s anecdotal, but the difference is that react and react native are proven techs and flutter still isn’t.
Like, isn’t VSCode all JavaScript? Surprisingly, this is probably what allowed Microsoft to build software that runs on both Window, Mac, and Linux! The JavaScript platform, ultimately became what Java dreamed of becoming back in the 1990s. And without the need to install a separate virtual machine layer, but at the expense of more inefficient code.
But VSCode is painfully slow, if you run it on an older PC.
And you’re not going to be running Windows 10 on a 15 year old PC anymore.
So could this mean, that software companies are going to force people to buy newer hardware, to run their programs? Most likely. Apple has programmed the consumer into spending unnecessarily for new hardware every year.
I wouldn't. I don't like Swift's syntax. The ecosystem would likely not be mature enough either.
But when I did use it, I loved it. I've written in quite a few languages, and it is my favorite, but not my go-to because of its limited environment.
Not to mention that developing C# in Visual Studio or Rider feels years ahead of what's considered good enough IDE assistance in other languages. Comparable with Java even.
And of course Electron, which is somehow even worse than Java.
wtf.
However for the desktop, a good real table, with columns, would be nice.
Where this isn't the case would be if performance mattered, some of Foundation system api implementations (at least, the Windows ones) can be a little inefficient since the Foundation api model and the Windows way of doing things doesn't always match and the Windows implementation has to do extra work to match the semantics.
Another would be UI wise, I haven't heard of plans for Apple to open source SwiftUI. Though since Swift can call into the native platform apis, it's quite possible to write a (perhaps not as slick) alternative.
As for the rest, it depends on what you consider "basic functionality". AppKit/UIKit is probably never going to be ported.
All this really means is you don’t get the iOS UI tools for your Windows and Linux projects.
Fun fact: Graydon Hoare, the original inventor of Rust, now works at Apple on Swift.
Disclaimer: I work at Google but not on TensorFlow.
Fortran, C++, Python and Julia drive the show and work with full tooling across UNIX flavours, Windows, macOS today.
Sure, there are people who want to tinker with it for fun, but outside of that what is the point in having Swift on Linux and Windows?
You can't use it to build mac or iOS apps on Linux because the important libraries aren't there. There is no cross platform UI and Apple isn't likely to port and support theirs from macOS. If you are into servers then you have plenty of better languages options with established ecosystems. Maybe there are some command line apps on macOS which can now be ported to Linux/Window, but beyond that, what is the point? Where is Apple trying to go with this?
Not a macOS or iOS app creation DSL.
It's also quite pleasant to use, and has already seen a few uses beyond macOS and iOS apps, including some backend development (Vapor, Kitura, SwiftNIO, probably others).
So you could use it to write command line tools. To write Linux or Windows apps. Or to write servers. Just like any other programming language.
I find it nice to work with, because it has a lot of the nice features Rust does, like affine types, 1st class optional handling, decent single-threaded safety guarantees, and it has a very nice, ergonomic interface. Generally the performance characteristics are not what you would get with Rust, but I am generally more productive in Swift because I don't have to worry about the low level details.
There's definitely some downsides - cross platform support being one of them - but if I'm just working on a tool for me myself to use, I will generally reach for Swift because it's pleasant to work with. I would be happy if I could use it for projects which need to be deployed across different platforms.
This is basic foundation building. It's true there aren't too many good use-cases for Swift on Windows or Linux now. But that can't really start to change until Swift has decent support for Windows and Linux.
Of course, it will take a lot more than this for Swift to catch on outside of its home territory. This is just one necessary step.
More broadly, I think we're still in the middle of the language wars, where the limitations of the historically dominant languages (like C, C++, Java, Javascript) have created openings for one or more newer languages. I think Apple and other Swift proponents would like Swift to become one of those newer established languages and take steps like these to at least keep it in the running.
And this is the Swift Open Source team, not Apple specifically. It’s not an Apple business decision (aside from lowering the learning hurdle for new iOS projects)
Not to mention there’s Swift for TensorFlow, would be nice if you could handle your code locally on a Windows machine: https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
Apple's behavior with open source is kind of "throw it over the wall" which isn't really good leadership.
The good stuff at apple is frameworks and apps, none of it released.
For examples of this, look at Darwin on https://opensource.apple.com
They provide some sources, but they are not complete and are more to look at than to use.
I figure this got through the approval process because it could plausibly get developers to pay attention to apple without letting others exit the apple ecosystem.
It seems pretty clear they have 0 plans on doing that. They could've open sourced it in the first place, along with Combine.
Not open sourcing Combine seems like a pretty short sighted decision to me.
There's nothing stoping anyone from implementing such a thing, just as someone wrote a SwiftUI for HTML. All the pieces are there, but it would be a huge amount of work unrelated to SwiftUI on Mac and iOS.
1. Create and introduce it as proprietary
2. Iterate fast, changing a lot of things to improve it quickly.
3. Stablize
4. Open source it (and continue iterating with an open process)
The advantage to starting proprietary is the initial iteration phase can move move quickly and stay focused on the goals of the people in the controlling group.
That would also means you would be able to deal with WinUI XAML and all.
while GetMessageW(&msg, nil, 0, 0) {
TranslateMessage(&msg)
DispatchMessageW(&msg)
}
If by some stretch that means Swift can then make complete Windows programs, that could be good for consumers but particularly good for enterprise developers.
It's not hard for me to think that. I've never been interested in .Net languages, and I write stuff for both Linux and Windows. If it was just Swift the language and compiler, and I had to wrap Win32 API calls by hand, I'd happily use it.
And just a minor nitpick, Apple’s development environment is called Xcode, where just the X is written uppercase.
I'm on a Mac already (Macbook with 10.14) - am I really going to have to run a VM because of a point release? (That goes for both the OS and Xcode so that's even more absurd)
The standard of their laptops is not good enough any more for me to justify the continued and continuous upgrades. Maybe access to their market would be but I'd need an existing set of customers to justify it, else Visual Studio et al look just as juicy.
So, direct ports are unlikely to be made that much easier, but it definitely opens the door to more code sharing.
Plus, Swift is a really nice language — great to see it getting more adoption.
Simple example.... the MacBook trackpad
Apple’s trackpads are even better now. How has nobody figured out Apple’s 2010s trackpad technology?
I was talking to someone also in lockdown and she's in the market for a new laptop or iPad/keyboard.
She also wants to play games with family and friends and that's when she realized multiplayer and games in general on iOS and Mac were not a strength at all.
IMO, Apple's above-average hardware (at times, not all keyboards) is severely hurt by the lack of real gaming options on Mac or iOS.
I think that is even more glaring now in our present circumstances.
RSI inducing tap to click barely works and you have to enable a horribly implemented accessibility options just to drag with a gesture to each their own though
the reflective screens they put on those things also cause eye damage
When I started working at my current client, there was a huge existing Objective-C code base to talk to an internal HTTP API. I just started coding. When I needed to add functions, I subclassed Objective-C classes in Swift.
For non-Apple platforms, you have to use a different implementation of Foundation — which has pretty good but not identical coverage to Apple's one.
As a side note, it's always seemed clear to me that when Apple provides a new technology, they provide a stop-gap solution, like Carbon, for developers who, for a variety of possible reasons, may not be able or willing to use the new tech, like Cocoa.
The bridge between Objective-C and Swift has always seemed like Carbon to me.
Fortunately, unlike when Carbon was canned and rewriting for Cocoa seemed like a real chore, I don't think Apple will can the Objective-C bridge any time soon — but for Swift code now targeting or intending to target non-Apple platforms, it may be best to start thinking about migrating away from relying on the bridge now — decarbonify your Swift code.
I could be wrong but I seriously doubt we will cross platform SwiftUI, UIKit, etc.
The documentation and error messages are a complete disaster though (https://nooverviewavailable.com/)
This project has a good list of SDL Swift libraries at the end of the page: https://github.com/ctreffs/SwiftSDL2 - but I don't know which one is the best one..
Then, we need to get Swift to compile for Android..
Out of interest I spend some evenings in swift (server-side) and it felt some kind of fresh air. Python feels so 'slugish' all the time. But I am worried, if swift will ever be 'useful' server-side.
As I've understood it, Foundation support is pretty good these days? But it would be cool if Apple ported even more frameworks that could be useful for server side applications. Recently I would have loved to have had AVFoundation available when doing some HLS parsing server side, for example.
Arguably people are already used to creating desktop apps using JS/Typescript using the Electron framework. React Native builds upon that.
2021 is going to be interesting
It’s pretty easy to take Apple’s HTTP implementation, add a router, integrate a template engine and have something working, but then the real issues start, because the ecosystem and community just aren’t there.
They would need to support customers who need that compatibility. So either they start being major contributors to WINE or something like it ... But then what about people who need a propriatary driver? Maybe a VM with hardware passthrough....
But they already have WSL for compatibility in the other direction. Not good enough?
WSL is there to sell Windows laptops to those that would rather buy Macs without any interest in Apple's eco-system, rather using them as pretty UNIX for GNU/Linux work.
They realised the mistake of not giving first class support to the POSIX subsystem and nowadays Linux compatibility is more relevant than POSIX.
That opens the door to seamless and full supported AWS Lambda functions in Swift.
Xcode Playgrounds (different from the iPad/macOS Playgrounds app) are really helpful for learning the language or testing things out.
For a complete course, see http://web.stanford.edu/class/cs193p/cgi-bin/drupal/.
Apple also has a series on creating iOS apps. It may be too beginner focused though. https://books.apple.com/book/id1118575552
I take it this isn't that?
[1] https://medium.com/incerto/the-most-intolerant-wins-the-dict...
Or perhaps they like the hardware or OS and have no intention to work on apps?
Guys, I hate to say this, just use Java. Its fully cross-platform with a complete UI toolkit that looks native and isn't slow. You're not going to find anything else thats as complete or performant. Java has been focused on this niche forever.
I bet you use Java GUI's all the time without even knowing it. Most of you every day. Tons of IDE's, database visualizers, and other dev tools are made with Java GUI's.
Every Jetbrains tool, DBeaver, DB Visualizer, MySQL Workbench, other stuff I'm too lazy to look up. If you have a tool thats not web with a big UI, its Electron or Java 90% of the time.
No.
> You're not going to find anything else thats as complete [...]
Qt. WxWidgets. Soon, React Native for Windows and macOS.
> [...] or performant
No.
> I bet you use Java GUI's all the time without even knowing it.
Oh, people know it. Even users of Windows and Linux, platforms where a consistent native look and feel for applications is now a veritable pipe dream, can tell.
Plenty of people specifically avoid apps written with a Java UI because they feel so non-native and slow.
(Disclaimer: I'm not saying Qt, WxWidgets, necessarily feel any more native than Swing or JavaFX; I only mentioned them as examples of complete cross-platform UI kits, not necessarily as ones with the best integration — although well-designed Qt and WxWidgets apps will still feel miles more integrated with both Windows and macOS, notoriously difficult to emulate, than Swing)
> Every Jetbrains tool, DBeaver, DB Visualizer, MySQL Workbench, other stuff I'm too lazy to look up. If you have a tool thats not web with a big UI, its Electron or Java 90% of the time
If you use apps from that specific set you listed, sure.