Announcing the Build and Packaging Workgroup

Announcements
,
1

The Ecosystem Steering Group is excited to announce the formation of a new Build and Packaging Workgroup for Swift! The main goal of this group is to deliver a great build and packaging experience for the Swift community.

This new workgroup is composed of several contributors to Swift Package Manager and Swift Build as well as advocates of build and packaging tools in the community. For more details about this new group, including its charter, members, and how you can participate, see the new Build and Packaging Workgroup page at Build and Packaging Workgroup | Swift.org

41 Likes
2

It seems the term Packaging is generally being used to refer to SPM and the much proposed swift package install command aimed at CLI tools.

Would packaging include the work I’ve been doing with Swift Bundler to support cross platform packaging of Swift apps (SPM executable products with additional metadata) into,

  • .app for Darwin platforms
  • .rpm, .AppImage or loose bundle directory for Linux, and
  • .msi or loose bundle directory for Windows

?

It feels at least somewhat related to the working group, and if it’s something that the working group is interested in then I’d be happy to get involved in some capacity.

13 Likes
3

I think this sort of tooling which needs to post-process build artifacts for deployment is certainly the kind of thing the workgroup would be interested in discussing and helping enable. One of the goals in the linked charter is:

  • Encourage development of build tooling for cross-platform installation and deployment of packages

Various folks have also mentioned interest in improving building containers as well for deploying services.

I think this would be a great topic to continue discussing here on the forums or bring to an upcoming workgroup meeting. For those who haven't seen it yet I think it's worth calling out this info from the charter:

Community Participation

Everyone is invited to help improve Swift’s build and packaging experience and participate in the Workgroup’s initiatives. Here are some ways to consider participating:

  • Discuss ideas on the Swift forums.
  • Open GitHub issues to track enhancements or report bugs in the projects governed by the workgroup, such as SwiftPM, Swift Build, and llbuild
  • Contribute bug fixes or enhancements to SwiftPM, Swift Build, and llbuild
  • Provide feedback directly to the members of the workgroup directly by sending a message to @build-and-packaging-workgroup on the Forums. The workgroup chair brings outstanding issues and topics to the workgroup to discuss during regular meetings.
  • Join the Workgroup’s regular video meetings. Send a message to @build-and-packaging-workgroup to request access, since calls must be kept to a relatively small number of participants. Meetings open to the community will be announced on the Swift forums in advance.
6 Likes
4

Feature request for this new exciting work group:

i would love it to be able to replace current justfile/makefile commands like such

build-app:
  xcodebuild -quiet \
      -scheme Counter \
      -configuration Debug \
      -destination 'platform=macOS,arch=arm64' \
      -derivedDataPath ../.build \
    build

run-app:
  open ../.build/Build/Products/Debug/Counter.app

With simply:

swift run

Which would, use some simple heuristics to find a non test target scheme, understand if it is macOS only, iOS only or both and start on suitable destination accordingly (and controllable with —destination mac/iOSSim/iOSDevice), with built in support for booting an iOS sim.

The discrepancy between SPM and Xcode building is being bridged thanks to Swift Build being used by both. But I still find it annoying it is so cumbersome to have to use xcodebuild and awaiting start of iOS sim (complexity ommited in my example above) and then launch the app.

Would this feature request - if reasonable and wanted by the community at large (Im pretty sure it is) - be something which would fall under this new working group? Or does it count as non Swift project responsibility to launch non-CLI apps? We note though that these might be non-SwiftUI/UIKit/AppKit apps, eg UI built with QT or similar.

1 Like
5

You may enjoy Swift Bundler.

You can replace your makefile with a SwiftPM package and the following Bundler.toml configuration file. Swift Bundler will build the specified SwiftPM product and then bundle it up as needed;

format_version = 2

[apps.Counter]
identifier = 'com.example.Counter'
product = 'Counter'
version = '0.1.0'

You can run your app like so;

# Run on host machine (app gets built at .build/bundler/Counter.app)
swift bundler run

# Run on iOS device (this does basic matching so '--device Alex' would likely suffice)
swift bundler run --device "Alex's iPhone"

# Run on iOS simulator (boots the simulator if needed)
swift bundler run --simulator "iPhone 16"

# Run on the host machine using Mac Catalyst
swift bundler run --platform macCatalyst

For all of those commands, the final built app will get put at .build/bundler/Counter.app.

As a bonus you can also target Windows and Linux using Swift Bundler, but it sounds like you don’t need that.

The Bundler.toml configuration format lets you specify app icons, custom URL schemes, Info.plist entries etc. You can specify different configuration values per platform as well using overlays.

Unfortunately producing .isa bundles for iOS isn’t supported yet. I’ve got a lot on my todos.

3 Likes
6

I would love to see this being done: Provide official image that includes the Static Linux SDK · Issue #480 · swiftlang/swift-docker · GitHub

2 Likes