Developers may ditch Mac App Store over sandboxing issues

Further to our story last week about concerns and frustrations relating to Apple’s insistence that applications distributed via the Mac App Store are sandboxed, today we are looking at what developers are doing to meet Apple’s sandboxing requirements.

Rather than update their apps some developers are considering removing them from the Mac App Store altogether. Others have decided to maintain more than one version of their app. And some have accepted that they will have to lose functionality. In some cases developers are refusing to do anything because Apple keeps changing the guidelines for sandboxing and they don’t want to waste development time on making changes that may become unnecessary. While other developers are concerned that making the changes required by Apple may break their apps.

Open Planet’s Karen MacLean told us: “We understand Apple’s desire to move to sandboxing and are generally very supportive of it, but we are being cautious. Our big concern at the moment is that sandboxing is a one-way process; once an App has been sandboxed it cannot be un-sandboxed. The worst thing that could happen from our point of view is that we release an update that breaks functionality, especially if we are powerless to fix it.”

She added: “At present sandboxing appears to be varying with each release of the OS and it has the feel of a technology still in Beta. If there is an issue, all the end-user sees is that your App no longer works and this could be very damaging to a small company like ours.”

Like Open Planet, developers at Literature & Latte are also concerned about addressing sandboxing before they feel Apple has ironed out exactly what the requirements are. “Because sandboxing has been evolving rapidly over the past few months, I’ve been biding my time to see what will happen. So many things have changed with each Lion update and developer preview that I didn’t want to have to rewrite my code every two weeks, especially given that sandboxing has been postponed twice before,” said Blout from Literature & Latte, although he admitted: “At the same time, I’m actively working on ensuring Scrivener works well under sandboxing – so that our Mac App Store users can rest assured that Scrivener is as secure as other apps they use – while striving to keep the same level of functionality for all our users.”

Other developers will work on implementation of changes in their own time, rather than being dictated to by Apple. Cognito’s Grant Cowie told us: “All of our software is available through distributors and from our own web store, and is updatable from our own update server. We intend that this will continue to be our primary sales channel on desktop platforms. We will incorporate sandboxing (on our schedule, not Apple’s) provided it can be done without removing critical functionality from the software.”

The fact that sandboxing can limit the applications is another reason why developers aren’t rushing to fulfil Apple’s requirements. “The biggest issue with sandboxing is that it severely limits integration with other applications,” said Cowie. “Accounting software that creates invoices in your email program, for example, won’t be able to do so without an entitlement exception, so the application functionality would need to be removed.”

Boinx Software’s Oliver Breindenbach also expects that there may be some challenges in meeting the requirements of Sandboxing: “Since a lot of data flows in and out of our apps, we might have to make some adjustments,” he noted.

Open Planet’s MacLean notes another challenge that could be caused by the implementation of sandboxing: “For example in educational institutions there are typically multiple students logging in to shared Macs so it makes sense to have shared licenses and other resources on these machines, but this is not possible in a sandboxed environment. I’m sure we will find a way to work around these issues,” she told us.

Is maintaining two versions the answer to sandboxing? 

For some developers who require sandboxing for their app maintaining two separate versions may be a solution. Sandboxing the app distributed via the Mac App Store, but keeping sharing features in a version available direct from the company site.

Frank Reiff from Public Space noted: “Sadly, my website will now become the only place where ‘full’ versions of my programs can be downloaded from.”

However, there may be issues with maintaining two versions of one app. As RealMac’s Fletcher notes: “When we sandbox any of our apps that are also available away from the Mac App Store, we’ll likely sandbox those releases too. With users able to use versions from our website in demo mode, we need to ensure that however they choose to purchase the app their data is available to them. If we weren’t to sandbox the version from our website, the sandboxed App Store version would look for user data in a different location to that of the non-App Store version.”

“Sandboxing entails some negatives – for instance, we’ve had to remove iBank’s ability to back-up remotely – but we feel it’s better to implement these changes for all versions and all users rather than offer a confusing array of products whose functionality is dependent on the point of purchase,” notes Becker, but “To the greatest extent possible, we have kept the downloadable version of iBank, the retail version, and the Mac App Store version identical.”

Boinx’s Breindenbach thinks that keeping both versions the same is important for the sake of user experience. “We want to keep App Store and non-App Store versions of our apps in sync as much as possible. If the App Store version is sandboxed, the non-App Store version will also be sandboxed so that the user experience is not significantly different between the two versions. Our plan is to have all apps properly sandboxed eventually, with the goal of maintaining all features.”

Despite the concerns about education users, Open Planet Software still plans to keep both the App Store and other versions the same. “Our free trial of Smoovie and a version for education have always been available outside the Mac App Store and we will continue to offer these.  Our preference would be to sandbox these versions.  After all, the point of the sandbox is improved security for our users.”

Other developers are less concerned about the need to make changes. Grant Cowie of Cognito told us: “The sandboxing requirements only apply to new apps. Since sandboxing may require functionality to be removed, we’ll likely only do it if absolutely compelled to,” however, he added: “It’s unclear whether non-sandboxed apps will still be available for sale, or merely for update – we have sought clarification from Apple on this.”

“Since sandboxing rules allow for bug fixed being made to non-sandboxed app, and we don’t have a major Mac update in the pipe, I can’t see any issues,” said Ilja A. Iwas from IWasCoding.

Apparent Software’s Kosta Rozen told us about his concerns for productivity app Blast, which gives a user access to recently used documents. “In order to do it, Blast monitors the entire file system and uses Spotlight – both of these functions will be restricted by Sandboxing. There are some partial workarounds, but if Sandboxing limitations will not be changed, Blast will be seriously crippled.”

To solve this issue Apparent Software is working on a new version of Blast, with a new name. “Trickster will be able to better cope with Sandboxing restrictions,” Rozen told us. However, Trickster doesn’t use Sandboxing, and “we plan to leave it that way for as long as we can,” Rozen said, noting that even Trickster could be crippled by Sandboxing. Should that happen: “We’ll move the application from the Mac App Store altogether,” Rozen told us, adding that there is a standalone version on the company’s website.

Some lucky developers developed their apps with Apple’s Sandboxing requirements in mind from the first instance. Open Planet Software’s MacLean told us: “We’re not going to lose any features. When we designed Smoovie we did so in accordance with Apple’s recommendations for locations for file storage, so our data transfers to the sandbox without issue. In terms of external resources we make use of cameras, the infrared Apple Remote and of course we share movies to a user’s iTunes library and upload movies to YouTube, and there are sandbox entitlements for all these resources.”

As Nik Fletcher of RealMac Software, the company behind RapidWeaver and LittleSnapper, noted: “As a result of Apple allowing bug-fix updates to existing Mac App Store apps, we’re in a pretty good position with regards to the sandboxing rules. We’re obviously looking to ensure that over time our apps are fully sandbox-ready, but in the immediate term there’s no affect on our apps.” He noted: “The ability to ship maintenance updates without implementing sandboxing certainly helps us with our shorter-term roadmap, whilst giving us good guidance on what we need to do in the longer term.”

Fletcher admits that RealMac does have some work to do however: “Our apps all access sandbox-ready resources – however, we do need to spend a little time correctly implementing some of the newer OS X additions for sandbox compatibility for updates that do get sandboxed.”

Iggsoftware’s Becker said: “It’s not always easy for an independent developer to keep up, and the effort diverts resources from other development priorities. But we’re in this for the long haul, and – especially as we are focused on financial apps – we think ongoing protection of the security of desktop and mobile customers is always going to be a primary consideration, as beneficial as any new feature.” 

Confusion and concerns And why isn’t Apple listening? What is sandboxing? And will it work?  Is there really a Mac security threat? And will Sandboxing remove it?  The case of the evolving sandbox guidelines And how Apple needs to get its act together