Posts tagged with "sandboxing"

Multiple Attachments Lets You Attach Multiple Files To Email Messages On iOS

One of iOS' biggest shortcomings is the inability to attach multiple files to an email message. Caused by Apple's resistance to bringing a visible filesystem to iOS or building inter-app communication features to access files outside of an app's own sandbox, the problem is epitomized by antiquated limitations such as the Open In menu and the aforementioned lack of multiple attachments in Mail. Interestingly, these two limitations are exactly what Multiple Attachments, developed by Jan Mazurczak, uses to send email messages containing attachments that aren't just photos or videos.

Read more


Droplr, Mac App Store, and Sandboxing

Droplr, Mac App Store, and Sandboxing

The developers of Droplr, a sharing utility for OS X, have announced that in order to release version 3.0 of their app on the Mac App Store, they will have to tweak the app's "upload from Finder" functionality to comply with Apple's rules.

The primary difference will be in the use of the global hotkey (opt+d by default) to share the currently selected item(s) in the Finder. The standalone version will continue to work as it always has, simply select something in the Finder, use the key combination, and that item will be uploaded to Droplr. For the Mac App Store version, when the key combination is triggered with the Finder active, instead of uploading the currently selected items, it will present you with an “open file” dialog where you’ll need to navigate to the item(s) you’d like to share and select them. We don’t believe this provides the best experience, but we do believe it’s an acceptable tradeoff to be able to remain in the Mac App Store, especially given many of our users don’t use the key combination as a primary method of sharing with Droplr.

This update from the Droplr team is particularly interesting as, back in May, speculation arose as to whether Apple would start rejecting any app with "global hotkey functionality" on June 1, when the company began enforcing its new Sandboxing policies for Mac App Store apps. As it turned out, the rumor didn't specify which kind of apps would fall under Apple's ban, but several third-party developers confirmed their applications carrying similar functionality went through Apple's approval process.

However, it appears the "issue" with Droplr 3.0 and the Mac App Store is simply related to standard Sandboxing practices, not strictly hotkeys. It is safe to assume that, per Apple's Sandboxing implementation, an app like Droplr can't benefit from unrestricted access to the Finder to automatically upload a file in the background. Several developers I have contacted about this issue confirmed that it's not a surprise Apple is requiring an Open dialog to access a file outside of the Sandbox, and that this would have been true even if Droplr wasn't combining the feature with a global hotkey. So while a calendar app can show itself with a hotkey, or a todo app can display a systemwide quick-entry panel, Sandboxing requires an app that accesses files directly (like Droplr does) to go through an Open dialog.

Read Droplr's blog post here, and our report from May on Mac App Store apps and global hotkey functionality here.

Permalink

Why Apple Is Making The Mac Harder To Use

Why Apple Is Making The Mac Harder To Use

Michael Schechter weighs in on today's news that TextExpander 4 couldn't be released through the Mac App Store due to Sandboxing restrictions:

I know I’m not the average Mac user, but I’m far from the geekiest. While there will always be things that need to exist outside of the Mac App Store for the geeky amongst us, the exclusion of something as useful and harmless as TextExpander shows the flaws in the current execution of App Sandboxing. The idea of protecting users from harm makes sense; the execution of protecting users from conveniently installing and maintaining useful software makes none.

This morning, Macdrifter brought a reasonable explanation as to why Apple's Sandboxing is, ultimately, benefitting the average Mac user who doesn't use apps like TextExpander, but wants a Mac to be secure and "safe":

New Mac owners lose the fear that Windows has instilled. I’ve seen it happen over and over. Ever so slowly, they begin to realize that installing software doesn’t have to be scary. Everything on the App Store is “safe” because Apple is moderating the content.

We actually saw this coming. Back in October 2011, when Sandboxing was still on track to become effective in November, I commented on two pieces by Andy Ihnatko and Jason Snell, noting how the concept of "app" -- software that "does one thing well" -- coupled with enhanced security for Mac users allowed Apple to position Sandboxing as a powerful technology for the new App Store market.

As a security measure, Sandboxing is a good thing for the user. It forces apps to access only the system resources they need, and, generally, it reinforces the belief that Apple-vetted apps are safer than software downloaded from the Internet. But like I said, the real problem -- and I guess the reason why people like Michael and I don't appreciate the consequences of this change -- is that developers of existing apps sold on the Store are being forced out of the door. I also wrote:

The problem with Sandboxing, I believe, is that it introduced a change that is forcing developers of existing apps to reconsider functionalities that are not compatible with the Mac App Store anymore. If this will lead to serious fragmentation of Mac software with a proliferation of deeply different Mac App Store and “website versions” of the same apps, we’ll see.

And we did see the first result with TextExpander 4. It's still too early to judge, but if these first signs are of any indication, then we should be thanking whoever thought of Gatekeeper at Apple, as it will bring some security to software downloaded outside of the Mac App Store. Similarly, we should appreciate the efforts of developers like ManyTricks and Smile, who are thinking of clever ways to offer upgrades without "officially" using the Mac App Store.

There is an argument to be made about Apple not particularly "liking" apps that change system behavior, like TextExpander. If that's the case, why approving them for Store sale in the first place? I understand that plans evolve and things can take unexpected turns; however, today's TextExpander update unarguably shows that this isn't the top notch user experience Apple typically shoots for.

Geeks will always know how to get around the Mac App Store's limitations; Sandboxing is showing its first trade-offs, including "harder" upgrades and fragmented applications, but we'll have to wait more to understand its long-term impact.

Permalink

TextExpander 4 First Casualty of Mac App Store Sandboxing

Today Smile Software released TextExpander 4, the latest version of its typing shortcut app for OS X. The new version contains several new types of fill-in snippets, including support for multi-line text fields, pop-up menus, expanding snippets while filling in text fields, and more. In addition, the UI has been slightly updated to match the monochromatic style of Lion and Mountain Lion, and snippet groups for French and German autocorrection are now part of TextExpander’s predefined group options. And in news that is sure to please anyone who has tried and failed to get their friends and family to understand the benefits of typing shortcuts, TextExpander 4 now includes a tutorial called the Snippet Creation Assistant, which will launch upon a fresh install of the app and guide new users through the process of making their own snippets.

TextExpander 4 also marks Smile’s break from the Mac App Store due to the sandboxing rules that went into effect on June 1st, making it the first major casualty of the new restrictions. Fortunately for Mac App Store customers, Smile has gone the extra step to ensure a smooth upgrade from the MAS version to their direct sale version. Once TextExpander 4 has been downloaded and launched, it will recognize existing MAS versions of TextExpander 3 and offer users the same discounted upgrade price as direct customers. As of this writing, TextExpander 3 is still on the Mac App Store and has not been updated with information about TE4 or the upgrade process.

TextExpander has been one of my most valuable apps for years and I highly recommend anyone who has yet to try it to download the demo from Smile’s website. TextExpander 4 costs $34.95 for a single license and $15 to upgrade from a previous version, with additional options for family packs and businesses. Any customer who purchased Text Expander 3 after January 15, 2012 can upgrade to TE4 for free.

TextExpander 4 is available for purchase from Smile Software’s website here. The company’s official press release, which includes the full list of new features and changes, can be found here.


Mac App Store vs Buying Direct

Mac App Store vs Buying Direct

Wolf Rentzsch has published a good piece outlining the pros and cons of buying software through Apple's Mac App Store, or directly from a developer's website.

Some developers are going out of their way to allow seamless cross-grading from Mac App Store versions of their apps to direct apps, which is commendable and helps alleviate somewhat the situation Apple has created. Sandboxing is just the latest App Store rule change, I’m sure there’s more to come. All things being equal, it’s safer to buy directly instead of being cut off from your own software based on an arbitrary Apple policy change.

Sandboxing may be the latest requirement to get apps on the Mac App Store, but the trade-off involved with selling software through Apple's channel has stayed the same since 2011: exposure vs. risk of change due to Apple's policy. Because the environment is controlled and actively promoted by Apple, a developer gets all the perks of a store pre-installed on every Mac: millions of potential customers whose buying decision is just a click away, and nicely designed sections to showcase new apps (though Apple has to do more). On the other hand, because Apple gets to decide which apps and which functionalities are safe for the App Store, changes happen, like Sandboxing.

For the user, the convenience of the Mac App Store is obvious. Purchases are tied to an Apple ID, updates are easy, and the ecosystem is integrated with an existing structure (iTunes). Unlike John Gruber, I don't think Sandboxing will be compelling for typical users, as I don't see Apple showcasing Sandboxing-enabled apps the way they did for iCloud-enabled apps or apps updated with Lion features. It's too technical, but Apple may figure out a way to market it (perhaps again the "Apps Enhanced for OS X Lion" section with new additions).

For developers, the Mac App Store means exposure to millions of eyeballs but also to Apple's ever-changing strategies and technologies. The problem with Sandboxing, I believe, is that it introduced a change that is forcing developers of existing apps to reconsider functionalities that are not compatible with the Mac App Store anymore. If this will lead to serious fragmentation of Mac software with a proliferation of deeply different Mac App Store and "website versions" of the same apps, we'll see.

Also worth reading: Lex Friedman's story at Macworld on the first day of Sandboxing in the Mac App Store.

Permalink


Apple Confirms Sandboxing Deadline For Mac App Store Apps on June 1

In an email sent to registered Mac developers earlier today, Apple has confirmed it will begin enforcing a deadline on Sandboxing for Mac App Store apps on June 1, 2012.

As a reminder, the deadline for sandboxing your apps on the Mac App Store is June 1. We’ve made the process easier with new sandboxing entitlements and APIs now available in OS X 10.7.3 or later and Xcode 4.3.2.

If you have an existing app on the Mac App Store that is not sandboxed, you may still submit bug fix updates after June 1. If you have technical issues that prevent you from sandboxing your app by June 1, let us know.

Previously pushed back from November 2011 to March 2012, and then again from March to June 1, 2012, sandboxing is a new technology aimed at limiting an application's access to certain areas of OS X through a system based on entitlements. As we wrote in February:

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra — utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) — couldn’t get past the sandboxing requirement for the Mac App Store.

With today's reminder, Apple has confirmed that new apps submitted to the Mac App Store after June 1 must adopt sandboxing, whilst existing apps that are not sandboxed will still be available to receive bug fix updates. Earlier this week, a report suggested that, in relation to the upcoming sandboxing deadline, Apple was also looking into "banning" new apps with "hotkey" functionality, though it appears that such policy won't take effect, according to several sources. Recently, several OS X developers expressed their wish for Apple to further delay the sandboxing deadline to the end of June in order to better explain the ramifications of the technology at the upcoming WWDC. Unfortunately for those developers who were hoping for a revised deadline for apps that have proven to be incompatible with sandboxing, WWDC kicks off on June 11 -- 10 days after the sandboxing deadline.

A number of Mac applications using Sandboxing are already available on the Mac App Store. Most notably, 1Password by AgileBits implemented the technology back in September 2011, and others like Edovia's Screens for Mac and, recently, Pixelmator were updated with support for sandboxing as well.


Apple To Reject Mac Apps With “Hotkey Functionality” Starting June 1? [Updated]

According to TUAW, Apple will start rejecting Mac apps with "hotkey functionality" starting June 1, when the deadline for Sandboxing will become active for Mac App Store developers.

Apparently, Apple will allow hotkey apps that are already in the Mac App Store before June to offer only bug fixes. New apps and any apps that add features (i.e. non-bugfix releases) will not be allowed to support hotkeys.

TUAW has been told that Apple will be rejecting all apps with hotkey functionality starting June 1, regardless of whether the new features are hotkey related or not. Basically, if you're developing one of those apps, an app that assumes you can still add hotkeys, don't bother submitting it to the Mac App Store.

While TUAW doesn't specifically mention any Mac app that would be subject to this new restriction, it is safe to assume that by "hotkey functionality" they mean desktop applications that allow users to set up keyboard shortcuts to activate other apps or system locations (such as Apptivate), or an app's specific functionality (such as Alfred's hotkey to show a search box, or OmniFocus' hotkey-based Quick Entry panel).

I spoke to various developers of Mac apps with system-wide hotkey functionality, and they were unaware of the changes that Apple may begin to enforce on June 1. Currently, there is no mention of such specific change in the Mac App Store Review Guidelines (or Sandboxing FAQs), and the APIs used by the developers I contacted aren't deprecated in the latest Mountain Lion Developer Preview, updated yesterday. Some developers told me Apple may have rejected some apps that registered hotkeys without a user's explicit consent, but according to TUAW the issue is different, and related to the kind of control and experience that Apple wants on the Mac App Store, rather than technical limitations or APIs.

Initially pushed back from November 2011 to March 2012, and then again to June 1, 2012, Sandboxing for Mac apps has found a considerable amount of skepticism in the Apple developer community, as it would pose a threat to existing Mac apps that would have to rework their functionalities around the limitations of sandboxing.

As I wrote in February:

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra — utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) — couldn’t get past the sandboxing requirement for the Mac App Store.

In the past months, a number of notable Mac developers have voiced their concerns in regards to sandboxing: Daniel Jalkut of Red Sweater Software wrote that "to increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps"; following his decision to stop selling Clipstart on the Mac App Store, Riverfold's Manton Reece noted how, rather than playing "catch-up" with Apple to work around the list of entitlements for sandboxed apps, he'd prefer to keep selling his apps on his own website -- something that the upcoming Mountain Lion will keep supporting thanks to GateKeeper.

Over at TUAW, Erica Sadun says we should say goodbye to "hotkeys, macro programs, end-user customization". While I can't confirm the kind of apps and "hotkey functionalities" that Apple has apparently already rejected or will start rejecting in two weeks (I've only seen some discussions about clipboard managers and keyboard shortcuts on the Mac Dev Forums), it would surely be unfortunate to lose software like Alfred, Apptivate, or Keyboard Maestro (just to name a few) to an updated Mac App Store policy. Erica Sadun refers to these hotkey-enabled apps as "all those great little hotkey shortcuts that used to let us bring an app to the forefront and do something".

That sandboxing would be a technical issue for apps based on AppleScript technologies is nothing new; however, Apple also specifically asked developers to get in touch with the company if technical issues were preventing them from sandboxing an app, suggesting that the company was actively working on getting developers of existing great Mac software on board with sandboxing, without limitations. This week, the Pixelmator team updated their application with support for sandboxing; other developers of "power-user" applications like Keyboard Maestro, however, still haven't found a proper way to work around sandboxing entitlements, going as far as writing "Keyboard Maestro requires access to other applications to perform your macros and so is not, and cannot, be sandboxed" on the app's Mac App Store page.

According to Apple's notice from February, developers of existing apps on the Mac App Store that are not sandboxed may still submit bug fix updates without sandboxing their apps. In theory, this should mean that apps like Alfred or Shortcuts (with hotkey functionality) or Keyboard Maestro (for general incompatibility) should stay on the Mac App Store as long as their developers don't include new features, but only bug fixes for existing customers. But what's going to happen when developers of hotkey-enabled apps or already-approved macro programs like KM will decide to update their apps with new features?

Just like in February, the future of sandboxing and Mac App Store apps is uncertain, but it's looking worse if Apple really has decided to ban hotkey functionality -- a common trait of keyboard-based software, such as Mac apps -- from the Mac App Store. With the WWDC '12 scheduled to kick off 10 days after the proposed sandboxing deadline, here's to hoping Apple will, once again, be more flexible, and offer third-party developers new ways to work around sandboxing -- the Mac App Store deserves all kinds of OS X software, from simple single-purpose utilities, to more complex, power user-oriented applications.

Update: Throughout the day, several developers I spoke to confirmed my earlier reports that the APIs to implement global hotkeys and keyboard shortcuts haven't been deprecated (not even in Mountain Lion), and aren't going away any time soon. Two developers I spoke to, in particular, confirmed that recent updates to their Mac apps with "hotkey functionality" were approved without issues by Apple.

Furthermore, developers confirmed they couldn't find any new mention of hotkey-related entitlements in today's updated documentation for Gatekeeper and Sandboxing. So while more "complex" utilities like Keyboard Maestro and TextExpander may still have to find a way to work around Sandboxing, other apps that incorporate hotkey functionality -- like OmniFocus, Alfred, or just about any app that offers a systemwide shortcut -- should still be fine for the Mac App Store.

Lex Friedman at Macworld confirmed with his own sources that a ban for general "hotkey functionality" isn't coming to the Mac App Store, writing that "so long as developers use Apple’s officially supported APIs to register systemwide global hotkeys, their apps will remain eligible for inclusion in the Mac App Store".


Apple Extends Mac App Store Sandboxing Deadline to June 1

With a notice posted on the Mac Dev Center's App Sandboxing webpage, Apple has informed developers that the sandboxing deadline, previously delayed to March 1, has been extended to June 1.

Starting June 1, all apps submitted to the Mac App Store must implement sandboxing. Take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3.

We have extended the deadline for sandboxing your apps on the Mac App Store from March 1st to June 1st to provide you with enough time to take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3.

Starting June 1, if you have an existing app on the Mac App Store that is not sandboxed, you may still submit bug fix updates without sandboxing your app. In addition, if you have technical issues that prevent you from sandboxing your app by June 1, let us know.

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of "entitlements" that cover various areas of the operating system an app can access, such as networking, printing, or a user's files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac's entire filesystem, which is required by some functionalities of certain applications that aren't necessary malicious or "compromised". Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra -- utilities that perform actions in the background without asking for user's interaction in some cases (user-initiated actions can override the sandbox) -- couldn't get past the sandboxing requirement for the Mac App Store.

Since the release of Lion last summer, Apple has been touting the advantages of sandboxing as a way to increase security on OS X, whilst third-party developers began asking for more clarity from Apple in regards to the list of entitlements made available to them. For instance, sandboxing has been heavily criticized in the past months as it would theoretically prevent apps that rely on system-level technologies such as AppleScript from working, as they would require an entitlement that Apple isn't providing. Similarly, apps that would require access to an entire user's filesystem would be problematic with sandboxing fully enforced (think backup utilities such as SuperDuper).

Sandboxing recently became a topic of discussion again as Apple announced the next version of OS X, Mountain Lion, featuring a new security measure called Gatekeeper, while claiming that sandboxing would still be enforced starting March 1. With Gatekeeper and Sandboxing seemingly aimed at fixing different problems with OS X security, a number of third-party developers asked Apple (again) to reconsider the list of entitlements for the sandbox and figure out a way to work with longtime Mac developers to keep their apps in the Mac App Store.

Notably, Daniel Jalkut of Red Sweater Software wrote:

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out. Given the current limitations of sandboxing, a significant number of developers will not adopt the technology, so its usefulness to users and to the security of the platform will be diminished. Apple can turn that around so that sandboxing is a worthy counterpart to Gatekeeper, and a technology that any developer in his or her right mind would feel foolish not to incorporate.

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps.

As a result of the uncertainty surrounding the sandboxing deadline prior to today's announcement, some developers have decided to stop supporting the Mac App Store, keeping their applications available for purchase on their website -- something that Mountain Lion will continue to support thanks to Gatekeeper. A notable example is Riverfold's Manton Reece, who wrote a blog post explaining the reasons behind his decision to remove Clipstart from the Mac App Store:

Clipstart also falls into the same "needs to access the whole file system" category as Transmit. It's not just one feature; the whole app is based on the fact that it can point to video files anywhere on the system, or manage your video library in a central location on any hard drive. These are things that are difficult to do in the sandbox, but even worse, I don't see a clear path forward for existing customers to move into such a restrictive environment.

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.

Following today's notice sent to developers, Reece told us: "The delay is great news for developers who have been scrambling to meet the deadline. With brand new sandboxing APIs in 10.7.3, it just wasn't realistic to expect developers to be ready. And for some apps, there are still areas where the current entitlements fall short." As for Clipstart, Reece says he's still planning to remove his app from Apple's storefront: "I still expect to transition away from the Mac App Store. These delays show that Apple is listening, but also that sandboxing isn't a stable environment yet. I want to focus my time on adding new features for users instead."

With Apple extending the Sandboxing deadline, the company will hopefully have time to come up with a broader selection of entitlements developers can use in their apps. As a side note, Apple is expected to hold its annual WWDC in June, and Mountain Lion is set to become available this summer on the Mac App Store. Apple seems to be very flexible with the new June 1 deadline, too, promising developers that they will be able to submit bug fixes without implementing sandboxing, and asking them to "get in touch" if technical issues are preventing them from implementing the new technology.


Apple Pushes Back Mac App Store Sandboxing Requirement To March 2012

In an email to developers today obtained by iClarified, Apple has informed them that all apps submitted to the Mac App Store must implement sandboxing by March 1st, 2012. Originally Apple had told developers that the sandboxing requirement would take place this month. It isn't entirely clear why Apple has delayed the introduction of this requirement but it does give developers a few more precious months to implement the restriction and resolve all issues that it might cause for their app.

In the email Apple notes; "Sandboxing your app is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users' systems". For those who aren't familiar with the technical 'feature', John Siracusa has a great (and in-depth) discussion of the feature in his Mac OS X 10.7 Lion review on Ars Technica. In short, sandboxing restricts the number of actions that an app can do so that if the software is compromised, the amount of damage it can do is greatly minimised.

In Lion, the sandbox security model has been greatly enhanced, and Apple is finally promoting it for use by third-party applications. A sandboxed application must now include a list of "entitlements" describing exactly what resources it needs in order to do its job. Lion supports about 30 different entitlements which range from basic things like the ability to create a network connection or to listen for incoming network connections (two separate entitlements) to sophisticated tasks like capturing video or still images from a built-in camera.

In its email to developers, Apple also notes that if an app requires access to "sandboxed system resources", the developer must also include justification for why it needs those entitlements when submitting the app to the Mac App Store. Finally, Apple notes that it is willing to offer developers additional, temporary, entitlements if the app is being re-engineered for sandboxing - but only on a short-term basis.

[Via iClarified, Image via Apple]