#MARSEDIT MAC OS 11 ARCHIVE#
#MARSEDIT MAC OS 11 UPGRADE#
#MARSEDIT MAC OS 11 CODE#

The new behavior in Xcode 9 strongly suggests that Apple expects most developers to use archives, and joining the crowd is usually a good idea when it comes to avoiding trouble with Apple’s developer tools. But as a long term solution, this is probably the safest bet. It strikes me as a little obnoxious to have to use Xcode archives when they don’t offer any added benefits for my dibstrution workflow. It frankly sounds like a pain in the neck to recursively re-sign every binary in the app bundle, ensuring that the suitable entitlements (minus the unwanted one) are preserved, but I’m sure it can be done.

#MARSEDIT MAC OS 11 CODE#

Code signing is code signing, and you’re free to sign anything you like to suit your needs, using the “codesign” command line tool.

The downside to sticking with Xcode 8 is you won’t enjoy any of the new features of Xcode 9, you’ll have to work to support either Swift 4, macOS 10.13, or iOS 11 SDK features in your app. Xcode 8’s signing process does not impose the unintended entitlement, so there is no risk of shipping a product that has it, unless you add it yourself.

#MARSEDIT MAC OS 11 UPGRADE#

The simplest solution is to not upgrade to Xcode 9 unless and until you need to. So, if you’re a developer who doesn’t use archives, what are your options? I’ve come up with four workarounds, and I present them here, roughly sorted by advisability and level of tedium:

Unknown consequences of shipping with an unintended entitlement.Inability to launch sandboxed child processes.Most developers, and particularly iOS developers, use Xcode archives.įor folks who don’t, side effects of this additional entitlement include, but may not be limited to:

#MARSEDIT MAC OS 11 ARCHIVE#

For the majority of developers, this is probably not an issue, because the entitlement is removed when an Xcode archive is exported for distribution. Although the gist of that post involved sandboxed Mac applications that launch sandboxed child processes, the fundamental issue is a bit broader: Xcode 9 adds a “-task-allow” entitlement to any binary it signs. I wrote on Monday about issues with Xcode 9 relating to code signing. I filed Radar #34757710: “NSColorPanel swatches don’t work on apps linked against 10.9 or earlier.” I don’t know of a workaround yet, other than compiling against a later SDK. Using a totally straightforward demo app, consisting only of an NSTextView and a button to bring up the color panel, I was able to confirm that the bug affects an app that links against the macOS 10.9 SDK, but does not affect an app that links against the 10.10 SDK. Sometimes, the variations in behavior lead to bugs like this one. The idea is usually to preserve the old behaviors of frameworks, so that any changes do not defy the expectations of a developer who has not been able to build and test their app against a later SDK. It’s not unusual for the behavior of Apple’s frameworks to vary based on the version of SDK an application was built against. The MarsEdit 4 Beta, which is built against the 10.12 SDK, does not exhibit the problem. I was able to reproduce the problem in the shipping 3.7.11 version of MarsEdit, which for various reasons is still built using an older version of Xcode, against the 10.6 SDK. Shortly after macOS 10.13 was released, I received an oddly specific bug report from a customer, who observed that the little square “swatches” in the standard Mac color panel no longer had any effect on MarsEdit’s rich text editor.

Marsedit mac os 11