Mac App Store distribution question

[rivera-ernesto]

Probably a silly question. But what prevents an open source app like Vienna from being distributed on the Mac App Store?

• Apache license should be fine.
• An AppleID account. Probably the main problem is who's ID would it be? The license would allow anyone to do it but is there a image/policy problem?

Also an AppleID seems to be preferred for #49.

[mstroeck]

Yeah, we should probably do that. I'll look into this, as I need to work with the App Store in any case in the near future.

Am 11.04.2014 um 03:33 schrieb Ernesto Rivera notifications@github.com:

Probably a silly question. But what prevents an open source app like Vienna from being distributed on the Mac App Store?

Apache license should be fine.
An AppleID account. Probably the main problem is who's ID would it be? The license would allow anyone to do it but is there a image/policy problem?
Also an AppleID seems to be preferred for #49.

—
Reply to this email directly or view it on GitHub.

[dak180]

Code signing as it is currently done should work out of the box with the mac app store.
This still leaves the question of how well Vienna plays with the app sandbox.

[barijaona]

An App Store version would be the best answer to those numerous Vienna clones « publishers » who are blatantly profiting of our open source philosophy.
But I’d like to keep a non App Store version : it speeds development (open betas, faster publication). So, we would have to maintain two targets.

Some parts of Vienna would need to be removed in the App Store version : I think mainly of the Sparkle autoupdate mechanism.

[barijaona]

Related : legal actions suggested in #375

[josh64x2]

App Sandboxing is a good idea for security and will help prevent issues such as #736 in the future. It is very simple to do, we just need to implement the migration as per Apple's guide.

I have tested it without the migration and simple Vienna functionality seems to be fine. Not sure about Apple scripting or the plugins though.

[Eitot]

Sparkle seems to be almost ready to support sandboxing too. They have a ui-separation-and-xpc branch (“2.0”) that awaits merging.

[JanX2]

Thanks for mentioning the state of Sparkle Eitot. Great to know!

[Eitot]

(@josh64x2) Just for reference: Migrating an app to a sandbox.

[Eitot]

I believe scripting and plug-ins should still work even with a sandboxed environment. It is possible to define symlinks that point to directories outside of the sandbox and then regulate the access using entitlements, in particular the com.apple.security.temporary-exception.files.home-relative-path.read-write entitlement.

For reference: File Access Temporary Exceptions

One caveat is that I do not know whether Apple (still) accepts these entitlements for App Store apps.

[Eitot]

Sparkle’s XPC branch is still not the stable branch. I am not sure who maintains Sparkle now. Apparently, even their 2.x branch is based on deprecated APIs, so who knows if is worth waiting for this. There might be an alternative in the future.

[Eitot]

Now that Sparkle 2.0 is installed, it should now be possible to enable sandboxing. I did some of the legwork already by pushing #1468. I also have some reusable code in other private projects that I can repurpose.

What still needs to be done:

• The user can in some situations manually choose a path, also outside of the sandbox (e.g. the default download directory for downloads). For this, “security-scoped bookmarks” have to be used to store the access token that is given when the user chooses a location.
• Sandbox migration has to be taken care of, so that the transition runs smoothly. This means moving all of Vienna’s into the sandbox container. This happens automatically for the most part, bur decisions have to be made. I have a WIP branch for this.
• Think about whether plug-ins and styles should be stored in the sandbox too or whether an external location in the user library should be kept. This decision has to be made before the sandbox migration.

Things that probably will no longer work:

• User profiles (used by passing an argument to MachO binary). (removed by More sandboxing preparations #1574)
• Reading files in system directories, such as the hasOSScriptsMenu() function (resolved by More sandboxing preparations #1574)

References:

• App Sandbox Design Guide
• Entitlement Key Reference

I think the next major version of Vienna should use sandboxing, since it is a recommended security feature and should not stop Vienna from working normally.

[Eitot]

Given that Vienna uses private Apple APIs to make the browser work properly, I think Mac App Store distribution can be ruled out (s. 2.5.1 of the App Store Review Guidelines).

[TAKeanice]

I think we could still try and if Apple rejects it we could try replacing the calls with an alert saying "this feature is not available in the AppStore version of Vienna"

[github-actions]

This issue hasn't been updated in a while so we're going to mark it as stale. stale issues will automatically be closed after 60 days of inactivity. If this issue is still affecting you, please update us on how it affects you, and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. Thank you for your contributions.