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