Long Live Cocoa (or is sandboxing killing carbon?)

Real Software posted an article on changes to the Mac App Store.  Starting in November apps submitted to the Mac App Store must be sandboxed.  This is a huge change and currently, according to Real Software, the carbon implementations to accomplish sandboxing are broken.

More information the Apple sandboxing can be found at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/ApplicationSandboxing/ApplicationSandboxing.html and I highly recommend you read it.

At the very bottom is a caveats section: apps can’t send AppleEvents from the sandboxed app (though they can receive them).  This seems rather extreme.  If your Mac app can’t send AppleEvents does this mean that Apple is killing AppleScript?  I doubt it, but it does seem to limit the usefulness of the service and I suspect that there will be a workaround.

Apps cannot work with non-bundled projects that reference other files.  Does this mean that services like Kagi and eSellerate will no longer work?

So what does this mean for a vast majority of Real Studio developers?  Not much really – unless you happen to be selling your apps in the Mac App Store.  For you, the changes are important and you’ll need to start compiling for Cocoa.  Cocoa is much improved in Real Studio 2011 R2 than any previous Real Studio release but unfortunately it still not complete.

So the bottom-line is that if you are developing Mac apps and hope to put it in the Mac App Store then you’d better start testing your builds in Cocoa.  While your app may not ship using Cocoa yet, Real Software needs the feedback on what’s not perfect so they can fix it.

It’s a good idea to start using Cocoa now because in November you’ll need it.  Long Live Cocoa!

5 thoughts on “Long Live Cocoa (or is sandboxing killing carbon?)

  1. Guess I’m going to have to port my RS apps to Xcode. It’s not just new apps, Apple will be booting existing apps from the MAS. I’ve been contemplating doing the conversion but was hoping R3 would be ready so I could renew my license. Oh well. Time marches on.

  2. Apple is not killing AppleScript and they are still encouraging applications to be scriptable. It’s just that applications aren’t allowed to control other applications in this brave new world.

    If your applications depend on sending AppleEvents, you should file a radar with Apple explaining what your situation is. If they don’t know you need something, it’ll never change. Also, for the short term, you can get a temporary entitlement that allows you to send AppleEvents to arbitrary processes. How temporary a temporary entitlement is has not been announced.

  3. That sandboxed apps can’t send AppleEvent is great news. My application depends on sending AppleEvents. Without this I don’t even have an application.

    @Christian:
    How should porting apps to XCode help you? The problem with sandboxing will stay the same.

  4. Where do you see it stated that “Apple will be booting existing apps from the MAS”? The last communication from Apple only stated that in order to UPDATE or place a new app on the app store after November, sandboxing would be required.

    @Christian Miller

  5. hmm… Seems like it’s just killed one app I’m working on! And my other apps have just lost a bunch of functionality. I tried to log bug in Radar, but encountered a Radar error…

Comments are closed.