CommentComment

When Hursh Agrawal published this video six months ago, he made a bold claim. He said they planned to create the Windows version of their Arc Web Browser using Swift, and it would have a native look and feel in terms of Windows UI and controls.

It was an ambitious plan, but it also made me want to watch what they were doing. It all made more sense when I learned that Saleem Abdulrasool had joined their company, presumably to lead this effort.

In case you’re not aware, Saleem is a Swift core team member and the driving force behind Swift on Windows and other efforts like SwiftWinRT and SwiftWin32.

I was happy (and just slightly surprised 😅) to see this update from Hursh at the end of last week. They seem to be making progress and even mention open-sourcing the cross-platform UI framework they are creating. If they are working on something that allows developers to share UI code across platforms and they follow through with platform fit being important, that framework could be a big deal.

Today, cross-platform Mac and Windows (and Linux) development is likely to mean using either Electron or Flutter. Both are fully cross-platform, but neither creates a great native-feeling UI.

Swift faces an incredibly challenging journey to be relevant as a language used for Windows development, but a Mac and Windows (and Linux?) UI framework that cares about platform fit would be unique in the industry and give it a nice boost. I’m looking forward to seeing what gets announced when Arc showcases it.


Note: I also considered including Xamarin.Mac and React Native for macOS above, but I had reasons not to include them. Xamarin.Mac creates AppKit apps and while it could help with a partially cross-platform codebase, you’d still need a separate UI layer for Windows. React Native for macOS doesn’t seem to have gained any traction since launching, and even the official desktop showcase has broken links and very few mentions of apps that work on macOS.


Update: Hursh dropped me a quick email with a slight correction on my assumptions above. He clarified that they are not working on a cross-platform UI toolkit, and instead are a declarative UI toolkit for WinUI in Swift. This will mean you need to build your UI layer twice, but that you will, of course, be able to share business logic and non-UI code between platforms. Apologies for the mistake in my assumptions!

Dave Verwer  

News

Code




Design


Jobs

Senior iOS Developer @ Shareup – Want to build something new? Join our small, design-led team at @shareupapp to build the fastest, easiest, and most secure way to share anything with anyone. We use Apple’s best tech, including Swift Concurrency, Combine, Catalyst, UIKit, and SwiftUI, and you’ll work closely with our talented team. – Remote (within European timezones)

Apple Platforms Developer @ Cascable AB – Cascable is a small "indie" company based in Stockholm, Sweden. This is the job for you if you love working with and learning about multiple technologies. We have UIKit, AppKit, SwiftUI, and Swift-on-the-Server (Vapor) across our suite of products, and you'll be working with all of them! – On-site (Sweden) with some remote work (within European timezones)

Senior iOS Engineer @ Reveri – We’re looking for an experienced, adaptable, and engaged Senior iOS Engineer looking to make a genuine positive difference in our member’s lives through self-hypnosis. 100% SwiftUI codebase, iOS 15+, Combine, and Concurrency. Small team, 3 iOS, 2 Android Engineers, every role has impact. – Remote (within European timezones)

 

Is your company hiring? Don’t forget that you can post any iOS/macOS/Swift job for free over on iOS Dev Jobs. What are you waiting for?

 

And finally...

Maybe there’s an upside to being replaced?