Meet Plain Swift

Here's my take on developing Windows apps in Swift: Plain Swift.

Plain Swift on the Web:
Plain Swift in Microsoft Store: Plain Swift - Official app in the Microsoft Store
The Microsoft Store link is recommended for seamless installation experience.

It is a project manager, code editor and build and deployment system. A simple IDE.


  • It can install Swift compiler for you, along with its dependencies (Build Tools and Windows SDK).
  • It will organize your source files into a project: Console App (.exe file), Dynamic Library (.dll file for use in projects written in languages other than Swift), or Importable Module (.dll file specifically for your Swift projects).
  • It will allow you to specify an icon and versioninfo resource details for your resulting executable.
  • It will allow you to edit source files with syntax and error highlighting and code suggestions, and build the resulting .exe or .dll file.
  • It will allow you to zip the resulting executable along with all its dependencies, making it easier to deploy it to another PC that doesn't have Swift installed.

For better or worse, it does not use the Swift Package Manager. It provides a build system alternative to SPM, sparing you from studying all the SPM quirks, but on the other hand not allowing you to use all the power of SPM.


  • No debugging. This is planned for the future.
  • No GUI apps. This is planned for the future.

I made this thing (and continue to develop it) for myself. But along the way, I decided to monetize it a bit. It is not free (there is a fully functional free trial period). Don't shoot me for that :)


Woah - very cool, thanks for sharing @dima_kozhinov!

What's the thinking behind no SPM? How could I integrate 3rd party frameworks?

1 Like
  • The development of Plain Swift began at a time when the Swift Package Manager was buggy and limited on Windows platform, if worked at all.
  • Swift Package Manager adds unnecessary complexity, while Plain Swift is designed with the KISS principle in mind.
  • Swift Package Manager relies heavily on online git repositories. These are moving targets. Just because they are compatible with your project today (and if they are available at all), doesn't mean they will be the same tomorrow. This IMHO is absolutely unacceptable if you want a reliable build system with predictable build results.
  • Using Swift Compiler (swiftc.exe) as opposed to Package Manager allows more fine grained tuning for the resulting executable, e.g. linking resource files (app icon, version info, and other resources), or creating a Windows GUI app (and not a console app), etc. Maybe SPM allows all that, but for me it's hard to figure out how.

How could I integrate 3rd party frameworks?

This is a tricky part :(

If a 3rd party library is available as a compiled .dll already, e.g. fooBar.dll, I guess you can just
import fooBar
in your source code.

However if you want to integrate it at the source code level, I see no other way other than copy all 3rd party .swift files into your project source folder. Plain Swift will recognize them as part of your project when you (re)open the project. Of course this will create a mess, that may not compile :(

This is how Importable Modules work in Plain Swift :wink:

You will also need fooBar.lib, fooBar.swiftdoc, and fooBar.swiftmodule files.

Very cool. It's great to see more devtools support for Swift on non-Apple platforms (especially Windows).

I wonder if there'd be any interest or collaboration to be had with the Arc folks, that are (somewhat famously) building native Windows apps with Swift (about the only example I can point to off the top of my head, sadly).

The established project forms not specific to Apple‘s platforms are SPM and cmake, an IDE that wants to be more than a tool for just trying out the programming language should respect that and at least allow the use of SPM projects, considering the free Visual Studio Code extension for Swift from the Swift Server Workgroup can handle this quite well. You will have a hard time with a commercial product that offers less in this respect.

Well, things are changing, and you can always reference SPM packages by system paths.

Swift/WinRT (also see the samples) uses both SPM and cmake (cf. the articles by The Browser Company, just choose “No thanks” when first opening this website).

The Arc folks (The Browser Company) use Visual Studio Code, and e.g. for debugging the view tree of a GUI they use Visual Studio (which is needed for Swift on Windows anyway).


Plain Swift is an easy-to-use build system. You need a .dll? You have it. Not the case with SPM.

1 Like

As of Plain Swift version 1.10, you can use the Modules -> Install Swift Modules... menu command. It supports 3rd party modules built with Swift Package Manager or any other build tool. The only requirement is that it must be compiled as a dynamic library with .swiftmodule, .swiftdoc, .lib and .dll files.

1 Like