Manton Reece:
Maybe I could file bugs with Apple for exemptions, and reduce the functionality of my app to fit within the limits of the sandbox, but I’ve made the decision that it is just not worth it. I would much rather spend 100% of the time I have for Clipstart on new features only, not playing catch-up with Apple.
One problem is that you don’t know ahead of time what the costs will be. My apps required engineering work to comply with the original Mac App Store rules, then more work and some trickery to get around bugs in Apple’s verification tools that made them falsely think I was breaking the rules. There’s sandboxing in theory, with the promise of temporary entitlements to ease the transition. And then there’s the reality of the sandbox, which includes bugs in its implementation and guidance that even though the temporary exceptions exist you probably won’t be allowed to use them. At each step of the way, it looks like just a little more work to get into the Mac App Store, or to stay there. Until the next issue pops up. And then, if you’re successful, you’re sort of locked into it due to the reasonable expectations of your many customers.
Mac Sandboxing
The Wall Street Journal:
To get around Safari’s default blocking, Google exploited a loophole in the browser’s privacy settings. While Safari does block most tracking, it makes an exception for websites with which a person interacts in some way—for instance, by filling out a form. So Google added coding to some of its ads that made Safari think that a person was submitting an invisible form to Google. Safari would then let Google install a cookie on the phone or computer.
Dean Hachamovitch (via John Gruber):
When the IE team heard that Google had bypassed user privacy settings on Safari, we asked ourselves a simple question: is Google circumventing the privacy preferences of Internet Explorer users too? We’ve discovered the answer is yes: Google is employing similar methods to get around the default privacy protections in IE and track IE users with cookies.
Patrick Rhone:
Then, she explained, the iPhone came. There was no Office. People got things done. Then the iPad came. There was no Office. People got things done. Android came. People got things done. All of those things that they, just a couple of years ago, were convinced they needed Office to do. They got them done without it. And thus, the truth was revealed.
Tom Harrington:
You can’t override -dealloc in a category. But thanks to associated objects, you don’t have to. If have some object A, and you associate a secondary object B with it, then when A gets deallocated, B will too. If you have something you really need to happen when A gets deallocated, you can call that code from B’s dealloc method. Bingo, deallocation code for A that runs in a separate class.
Mountain Lion is said to arrive this summer, with Apple returning to a yearly update schedule. More frequent upgrades should help speed the adoption of new APIs and Objective-C language features, but I question whether Apple has the resources to pull this off. Some would say that it’s already stretched thin between Mac and iOS development and that quality has suffered. Indeed, the yearly schedule had already proved unsustainable before the iPhone was released.
A new release every year means that Apple will need to produce a continuous stream of new user-facing features that can appear in screenshots and on feature lists. But what I want most from OS upgrades (and the developer tools) are bug fixes, stability, and polish. Despite the Lion-derived name, Mountain Lion seems to be more of a “feature” release than Snow Leopard. Have we seen the end of super-stable releases like Mac OS X 10.5.8 and 10.6.8? Developers can provide plenty of exciting new features and apps if they have a solid foundation to build upon. By the same token, if there’s a constant churn and the ground is always shifting, we burn development and support time without having much to show for it. It also makes it harder to be ruthless. So I question the wisdom of having yearly updates to both OS X and iOS.
Some of the more egregious problems with Lion’s Address Book and iCal seem to be fixed. (The skeuomorphic chrome remains in place, though.) And there’s some cool new stuff in Mountain Lion for developers. More in-depth discussion will have to wait until the NDA is lifted.
The biggest news is, of course, Gatekeeper and the Developer ID—which are along the lines of the system that Wil Shipley proposed. The technology behind Gatekeeper is good and unsurprising. What’s important is how Apple will use it and what comes next.
Is Gatekeeper proof that Apple wants a vibrant Mac software market outside of the Mac App Store? Or is it just another click of the ratchet to a future where all software must be approved by Apple? I think it’s a Rorschach test; the facts can interpreted either way. On the one hand, it’s encouraging that Apple is providing for a level of security between zero and fully sandboxed. That’s a win for users, developers, and Apple. On the other hand, adding a Gatekeeper-like feature would also be a necessary transition step towards a more restricted world. We went from total freedom to a Security preferences pane that offers three radio buttons for which types of apps are allowed. The next step could be reducing it to two or to one.
The bottom line: are you more worried about Apple having a killswitch for your favorite apps than you are about a family member downloading and launching a malicious app that said killswitch would have protected against? Right now, with almost no Mac malware, it seems unnecessary to make any sort of tradeoff. But it’s prudent to be ready in case that changes.
Here are some areas to watch going forward:
- What language will Apple use to describe apps that don’t use Developer ID? How strong will the implication be that they’re unsafe or second-class?
- Will Apple only use Gatekeeper to block true malware? Originally we were told that the iTunes App Store review process was to protect users and the cell network. Apple would provide some common-sense guidelines that determined which apps would be improved and rejected. What actually happened was that app review was capricious. Apple rejected some apps for business and political reasons. It approved others that clearly violated the guidelines. Some types of safe apps were unwanted. Other apps had “too many” competitors in their genre.
- Will Gatekeeper eventually step in below the file quarantine level?
- What recourse is there for an application that’s mistakenly identified as malware?
- Will apps from identified developers have access to the same APIs as apps in the Mac App Store? Currently the answer is No, and Mountain Lion has added more such APIs, widening the gulf. Actions speak louder than words, and Apple has yet to even say that it desires parity. Thus, I’m skeptical of the feel-good rhetoric to Panic about not poisoning the well.
- What will happen on March 1? It’s now been more than eight months since the sandbox’s semi-secret debut at WWDC 2011. At the technical level, it still isn’t ready for primetime. At the policy level, it’s still unclear what the March deadline means. And communication from Apple has been almost entirely absent on these important issues. Originally it made a kind of sense that, if the sandbox implementation had been complete and solid, it should be adopted before the next major release of the OS. Now, with Mountain Lion scheduled for this summer, I don’t see how Apple can justify imposing the sandbox on Lion. There isn’t even a mechanism to prevent sandboxed apps from launching, and causing harm, on the earlier versions of Lion that had more bugs.
- Will Apple add support for Developer ID apps to iOS? This seems incredibly unlikely, but it sure would be effective at restoring goodwill. It’s becoming increasingly clear to people that the App Store doesn’t guarantee safety, and Gatekeeper shows that other options are possible.
See also the posts from Matt Alexander, Marco Arment, Rainer Brockerhoff, Jacqui Cheng, Andrew Cunningham and Anand Lal Shimpi, Dustin Curtis, Chris Foresman, Dan Frakes, Steven Frank, Jean-Louis Gassée, John Gruber, Pierre Igot, Daniel Jalkut, Jesper, Rich Mogull, Dan Moren, David Pogue, John Siracusa, Jason Snell, Sean Sullivan, The Talk Show, Marcel Weiher, and Dave Winer.
App Review Mac Mac OS X 10.8 Mountain Lion Sandboxing
Daniel Jalkut:
To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps. A good test for this is any app that is currently available in the Mac App Store. Having been approved by Apple’s own reviewers, and purchased by Apple’s own customers, the merit of these apps should be considered implicit. If a Mac App Store app’s reasonable behavior cannot be achieved in the confines of the sandbox, it should be considered a sandboxing bug, and a new entitlement should be added.
I would go even further and say that there should be entitlements to cover applications that are not currently allowed in the Mac App Store. For example, SuperDuper has won two Macworld Eddy awards. It needs full access to the filesystem, but the sandbox could prevent it from accessing the camera, acting as a network server, etc. With the behavior appropriately limited by entitlements, there should be a way for Apple to allow it in the Mac App Store. Likewise for my own SpamSieve, audio utilities from Rogue Amoeba, etc.
Brent Simmons:
I toss all my Mac app ideas that require more than the default sandboxing rules — no matter how cool the idea is.
The sandbox has a chilling effect on at least one developer. I’d be surprised if it were just me.
Mac Sandboxing
Martin Pilkington:
This does raise an interesting question: where are all the other developer tools? The most commonly used are included in Xcode. Instruments, File Merge, Application Loader, Icon Composer and Open GL ES Performance Detective can all be accessed from Xcode’s application menu. The rest of the developers tools are available via connect.apple.com in various packages. This should mean that the download for Xcode is lighter, though you won’t be guaranteed to get the most up-to-date versions of all the tools in one download.
This doesn’t make a whole lot of sense to me. Instead of a single download that installed a consistent version of everything, there are now multiple downloads from three separate places: the Mac App Store, the connect.apple.com Web site, and Xcode’s preferences window.
Stored inside the Xcode.app package, the auxiliary files and applications are now invisible to Spotlight.
Code completion now works within some macros. Unfortunately things have regressed with regards to the OCUnit macros.
This has been broken since Xcode 4.0. It really seems like Apple’s own developers don’t do unit testing. The text processing/scripting features that were present in Xcode 3 are still gone, too.
Mac Programming Xcode
Chris Forsythe:
OS X 10.8 Mountain Lion was revealed yesterday. A few people have noticed a new feature that is somewhat similar to Growl. Apple calls it Notification Center. We would like to clear a few things up about how we view Growl going forward due to this announcement[…]
Some people are asking whether this means that Growl is dead, but I think that’s far from the case. Apple limits Notification Center access to its own applications and those from the Mac App Store. Users will want to see all their notifications in one place, yet this is not possible. Apple’s applications don’t use Growl, and many third-party applications will be barred from Notification Center. Enter a hypothetical future version of Growl. Growl is in the Mac App Store, so it can post to Notification Center. It could act as a bridge, receiving notifications from third-party applications and re-broadcasting them through Notification Center. Assuming, of course, that the guidelines aren’t changed to prohibit this sort of thing.
