Building App Store apps on top of container... a possible solution

[jacques-n]

The Challenge

We're exploring the creation of an application built on of both containerization and container. One of the challenges is that all the XPC routes in container are hardcoded. Because of this, if you want to build on top of an installed instance of container, one would need to have the following entitlement.

<key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
<array>
    <string>com.apple.container.apiserver</string>
</array>

My understanding is that the App Store review team would be unlikely to approve an application with that entitlement. That means it is currently near impossible to release a on-top-of-container app in the App Store.

Options

It seems like there are multiple ways to solve this:

1. Have the entitlement of accessing com.apple.container.apiserver concrete rather than using the temporary exception backdoor.
2. Expose a TCP protocol to access the API server (and support that in ContainerClient, etc)
3. Allow configurability of the XPC routes so the container code can be embedded and signed by another organization than Apple.
4. Hard fork the project and replace the problematic routes.

Are there other options that people think would be good?

My Subjective Triage of Options

1. Would likely take a long time to happen (if ever).
2. Involves a large additional amount of code: either emulating another protocol like dockerd or creating something all new to expose the intricacies and strengths of container
3. Relatively simple and not that invasive to the project.
4. Ugly but works today.

I am most attractive to trying to move forward with item 3. It's local to the project, non-invasive and enables people to start embedding the container code today.

What might (3) look like

Right now, there are a lot of places where routes are hard coded "com.apple.container.xxx". A simple solution might be to introduce the ability to override the default route prefixes. While there are probably a million ways to do this, we could start with something very simple such as:

public struct Route {
  nonisolated(unsafe) public static var prefix = "com.apple.container."

  // Returns the full route for a given suffix.
  private static func QualifyRoute(_ suffix: String) -> String {
    return "\(self.prefix)/\(suffix)"
  }
}

We'd then go to all the places where the prefix is hardcoded and replace with QualifyRoute invocations. I'm the first to admit that I'm not a huge fan of public global variable. I also hate that there is a need to guarantee initialization order. On the flip side, this seems far less invasive than trying to figure out how to pass the property through all the different initialization code for the client and server sides of the container project.

Thoughts on the overall need? Other ideas for a solution?

Thanks!

[jacques-n]

One thing I forgot to mention above is that there is another way to build an app on top of container and ship to App Store: execute container commands directly through Process(). We weren't a fan of this pattern as it feels especially brittle.

[crosbymichael]

Have you considered building the app targeting Containerization instead of the container tooling?

[jacques-n]

Have you considered building the app targeting Containerization instead of the container tooling?

That's where we started. Unfortunately, if you want to build something fully featured you find yourself building the majority of what is in apple/container. (Container is almost as much swift code (15.5k) as containerization (19.6k))

[crosbymichael]

What is the scope of application do you want to build? Building a client/server model and dealing with multiple containers does introduce a lot of complexity and code to carry that UX.

If you were targeting a smaller scope, I recently added a ContainerManage type in Containerization that has allowed me to build a few SwiftUI apps that spawn containers in 100 lines of code or less.

[Typ0genius]

@jacques-n I'm in a similar situation. I want to publish an app on the App Store that accesses containers running on the Mac. However, the temporary exceptions were rejected by the App Store review team, and after speaking with DTS, it's clear they will never be approved.

It's not only the com.apple.container.apiserver service that is required. There are several others, including one separate service for each container that gets spawned. Additionally, the system writes blobs to /Library/Application Support/com.apple.container/, which are blocked by the Sandbox by default. It's possible that additional requirements or limitations exist that I haven’t uncovered so far.

Because of this, using containerization in an app intended for the App Store only seems possible if you spawn a fully encapsulated containerization instance inside your app's Sandbox. This instance must be completely detached from any containerization system that may already be running on the Mac.

I haven’t looked too deeply into what modifications would be needed to support spawning such a sandboxed containerization instance, but a good first step might be to provide an easy way to define a custom prefix.