Hi there 👋

Running into a little bit of an issue with using Xcode where it can't seem to find the Swift Bundler executable.

I installed the tool using mint (mint install stackotter/swift-bundler), created a new project following the commands on the README, and generated the Xcode support files.

If I run swift bundler run in Terminal it works as expected, and just for sanity, so does swift-bundler run.

However, if I build my project in Xcode, it compiles correctly ("Build Succeeded") but then throws an error.

Could not launch “HelloWorld” The executable is missing. Please check your project settings and ensure that they produce a valid product.

If I check the logs, then it's clear the it's failing to run Swift Bundler:

/var/folders/54/7cl_0jq16sl8bg5xvn20skwm0000gn/T/SchemeScriptAction-SR1x7H.sh: line 2: swift-bundler: command not found

I've tried the standard lark of restarting Xcode and all that jazz to no avail.

Using Xcode 13.3.1 (latest non-beta), and bundler version 2.0.2 (latest).

Looking forward to giving this tool a try out. Thanks 🙂

This shouldn't be too difficult. Just need to target the build for iOS and then create an ipa instead of a .app (the structure seems pretty similar in some ways.

Using the init command uses the directory naming for its content. I initialized under a directory "bundler-testing" which created a compile error with the character -. This exception can be handled with a character substitute such as _ or the init command could include a name and create the associated directory which seems more consistent with existing cli's.

As discussed, this

• removes the extra package manifest in Documentation
• flattens the directory structure in Documentation
• adds the SwiftBundler documentation target to the main manifest
• updates update-docs.yml to the new directory structure

I don't think there's a way to test update-docs.yml prior to merging into main, is there?

Currently all Swift Bundler apps are non-sandboxed and aren't code signed. As Swift Bundler gets more users it would be useful to support such distribution features because code signing and sandboxing are important parts of shipping production-grade applications.

It seems like when Swift Bundler runs swift build, swift doesn't get given access to the interactive terminal, and its interactive output gets printed as separate lines and sometimes the lines get joined together for some reason.

The error enums themselves are quite descriptive, but it would improve developer experience if those errors could be converted into more human readable strings. This would also involve ensuring that ArgumentParser displays the string descriptions of errors.

Developers migrating from Xcode will want Asset Catalogs to behave as they would expect when using Xcode, this is currently not the case. I don't actually know how Asset Catalogs work so I don't know what is involved in implementing this.

I would like to use swift-bundler to create an app that includes an XPC Service. For that the resulting .app directory needs to contain a directory Contents/XPXServices which in turn contains .xpc bundles.

A first step to make this possible would be to support dictionaries dictionaries as additional plist entries:

[apps.ServiceProvider]
product = "ServiceProvider"
version = "0.0.1" # The apps can specify separate versions
[apps.ServiceProvider.extra_plist_entries]
CFBundleIdentifier = "com.my.ServiceProviderXPC"
CFBundlePackageType = "XPC!"
XPCService = { ServiceType = "Application" }

results in

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleIdentifier</key>
    <string>com.my.ServiceProviderXPC</string>
    <key>CFBundlePackageType</key>
    <string>XPC!</string>
    <key>XPCService</key>
    <dict>
        <key>ServiceType</key>
        <string>Application</string>
    </dict>
</dict>
</plist>

Given this I could already add a manual step that adds my ServiceProvider to the already created bundle.

Discussed this very briefly on Discord, but I think it would be really handy if we could provide a JSON schema document detailing every value supported in the configuration TOML file.

This would allow it to be used with plugins such as this one for VS Code which would provide code completion and validation of configurations improving the developer experience and hopefully reducing the number of issues developers face.

Taplo have stated they're happy for new schemas to be provided for native support, once the API is stabilised some, but even without pushing it upstream users can still utilise it if we host it on the documentation website 🙂

Currently the debug description of the deserialisation is just included in the error message for ConfigurationError.failedToDeserializeConfiguration. This is ok for now, but it takes quite a bit of reading to figure out what is wrong with your configuration. Configuration errors are common and they should be as easy to diagnose as possible.

It would be preferable to have some sort of custom error message for each command codable error. This could probably be done by adding LocalizedError conformance to whichever Codable related errors can be thrown. It could also be improved by adding nice error descriptions to all of the errors in TOMLKit.

TOMLKit also doesn't seem to provide a correct coding path (it's always empty from what I've seen).

Xcode is notorious for having a lot of unnecessary log noise which isn't at all useful. To fix this, OS_ACTIVITY_MODE=disable can be added to the Xcode scheme's environment variables. Given that Swift Bundler can generate Xcode schemes, it would be useful to be able to automatically add this environment variable.