MantonReece
Latest
Tweet Marker Plus rebranded as Watermark, adds App.net support
Developer Manton Reece is the brain behind Tweet Marker Plus, a US$5 monthly service developed to index tweets and provide search and filtering tools. Now Reece is rebranding the service as Watermark in a move to distance it from Twitter and syncing. According to a post about the rebranding on Macstories.net, Reece is distancing Watermark from Twitter due to the controversy over the changes to that service's API and its strained relationship with third-party developers. While Watermark continues to use the same infrastructure and provide the same functions, it's now a "client and archive tool" that continues to work with Twitter apps that have been designed to support it and that can expand outside of simple Twitter support. Watermark has built-in support for Dalton Caldwell's App.net, a new real-time communication service currently in alpha and priced at $50 per year. Watermark includes an App.net option which pulls in posts from App.net friends and archives all of your posts. App.net is still lacking in many features, but Reece's support of the nascent platform is a good sign of what to expect as more developers embrace the API and as App.net evolves.
Does Gatekeeper point the way to an App Store-only OS X?
Apple's announcement of Mountain Lion included many promised new features, including a stronger focus on the Mac App Store than ever before. Two significant new features, iCloud document syncing and Notification Center, are only accessible to App Store apps, and the new Gatekeeper security tool will include a setting to lock a Mac down so it can only run software purchased from the App Store. All this has (probably inevitably) got people wondering if this is the first step towards a version of OS X that will only run programs from the App Store -- a world where indie developers who cannot or will not use the App Store as their distribution platform will be frozen out altogether. I think that's an unlikely end state (making my headline fully Betteridge compliant), and so do some prominent indie developers, but I also think the issue is worth examining. A brief recap of the App Store When Apple added the App Store to iOS in 2008, it was a revolution in more ways than one. For the first time, we had a major general-purpose computing platform where software developers could not freely distribute their work to a wide audience; a platform where users could only purchase and download approved programs from a central, controlling authority. This wasn't a new idea -- gaming consoles have been using this "walled garden" model since the earliest Atari and Mattel consoles -- but it's the first time it had been applied to a device that some might consider a successor to the personal computer. So powerful and successful was this idea that we had to invent neologisms -- "jailbreak", "sideload" -- to describe processes that we had taken utterly for granted for the first thirty-five years of personal computing. Now, I'm not suggesting that the App Store is bad. Although it undeniably introduces new restrictions on how we use our expensive devices, the upside is a frictionless user experience for discovering, installing, upgrading, and uninstalling apps that had never been seen before outside of console gaming. Coupled with Apple's economically viable micropayments infrastructure, this spawned a sprawling "appconomy." Hundreds of millions of users spending billions of dollars on apps from millions of developers; a fluid, dynamic software market the like of which the world has never seen the like of which. Back to the Mac In early 2011, Apple brought some of these principles to the Mac with the release of the Mac App Store. Like its iOS ancestor, this also promoted app discovery and management -- but with one key difference: it's not the only game in town. OS X on the Mac still has its traditional ability to download and install software from... well, anywhere. The Mac App Store also brought some restrictions to what an App Store-purchased app could do, but nothing too onerous. At the same time, it offered access to Apple's payment processing engine, meaning indie devs could spend less time looking after financial transactions and more time cranking out great code (at the cost of the familiar 30% "rake" of Apple fees). Everybody wins. Many developers found that their users quickly moved to accept and then prefer the Mac App Store. Reports of great success with their early releases were plentiful. For example, graphics manipulation program Pixelmator grossed $1 million in 20 days after announcing it would be an App Store exclusive. The authors of the Sparrow email client were very happy with the App Store. Other success stories abounded. Confined to the sandpit For the best part of a year, everything was happy in App Store land... but as of March this year, Apple was going to require all App Store apps to run in a "sandbox" (although this deadline was recently extended to June). This means, amongst other limitations, that each app's access to the underlying system is sharply curtailed, to the point where an app can only read and write to approved directories within the user's home folder -- and it requires explicit permission to do even that. An app has to specify which "entitlements" it needs (specific system permissions and capabilities) to get its work done; Ars Technica's book-length Lion review by John Siracusa has a great sandboxing section examining how this is managed. This set of restrictions affects many existing apps for the worse. Craig Hockenberry of the Iconfactory reported that the company successfully ported xScope (after having problems with a bug relating to symlinks in home directories). He noted, however, that some apps would never be effective in a sandbox; the example was Panic's Transmit, an FTP client, which requires wide filesystem access and probably couldn't be meaningfully ported to the App Store under the sandboxing rules. Hockenberry also told me that two other pieces of popular Iconfactory software, CandyBar and IconBuilder, could never work with sandboxing. The former modifies system files and the latter is a Photoshop plug-in. Some developers, seeing the sandbox writing on the wall, are being forced into difficult decisions regarding their App Store offerings. Manton Reece of Riverfold Software has announced that his ClipStart video library tool will be withdrawn from the App Store altogether because of incompatibility with sandboxing. This is particularly troublesome for users who have already bought the App Store version of his app; Reece cannot easily identify them to give them an upgrade to a non-App Store version, nor can he offer them new versions of the app within the App Store's framework. To his enormous credit, Reece is willing to "honor Mac App Store receipt files" -- presumably via a tiresome manual process -- and provide extra serial numbers for customers migrating to new computers. For similar reasons, and with similar problems for users, Atlassian Software's SourceTree is also leaving the App Store. Even apps that don't seem to require system-wide file access can fall foul of sandboxing. Any sandboxed app can open any file anywhere on the system via the File > Open menu, because the sandbox presents the standard OS X dialog window to the user with special elevated permissions. But Gus Mueller of Flying Meat, father of the image editor Acorn, tweeted "just discovered you can't use AppleScript to tell (sandboxed) Acorn to open an image it hasn't opened already." All this has provoked some understandable bad feelings. As Red Sweater Software's Daniel Jakult forcefully put it, "Shame on you, Apple. Your developers shed blood, sweat, and tears to succeed on the Mac App Store. Now you drop them with misguided policy." Jakult elaborated on his position in a blog post where he outlined the changes he'd like to see made to sandboxing to make it more workable for everyone. Mountain Lion Mountain Lion, the next version of OS X, will add further fuel to the fire. It adds a new security system, Gatekeeper. On its highest setting this will only allow programs downloaded from the App Store to run. This isn't the default, however; on the out-of-the-box medium setting, the Mac will run apps from the App Store and those digitally signed by a process carried out between the dev and Apple. This process doesn't cost the devs anything (beyond their existing $99 annual developer membership fee) and doesn't restrict what the app can do. It is designed to offer a halfway house solution between the locked down App Store and the anything-goes wild blue Internet. After all, Apple might not have a malware problem today, but that could change in the future. Finally, Gatekeeper's lowest setting allows all apps to run unfettered -- just like all previous versions of OS X. It's possible that Apple planned this split approach all along -- although if so, it was rather mean-spirited to not start off requiring sandboxing for all App Store apps. Yanking the rug out under existing apps isn't good for developers or users. It seems more likely to me that these changes are the result of a genuine strategy shift within Apple, or possibly the sandboxing/entitlements infrastructure was simply not fully baked enough in 10.7 Lion to permit most apps to work with it effectively (including those using Apple's own AppleScript interapplication framework). Still, after a somewhat winding road, we're arriving at a good place with Mountain Lion. Users who don't adjust the default setting will be able to run apps from the App Store and elsewhere with a degree of malware protection, and devs can distribute apps that fit the App Store's slightly simplistic model there whilst also distributing signed apps via other channels. Great, right? Well, I still see a few problems with this. Mixed feelings about the App Store Firstly, as it stands, every third-party app on your Mac today won't run on Mountain Lion, as they are not digitally signed. This means if you upgrade you're going to be plagued with "this app is not trusted" messages (you can enable Gatekeeper on OS X 10.7 to get a taste of how annoying this is). If you have a lot of apps -- particularly older apps that might not ever receive digitally signed updated versions -- this might become the Mac equivalent of Vista's hated User Account Control prompt. If so, many existing users might end up turning Gatekeeper off altogether, rather defeating the point. The second problem is the ongoing FUD being generated around the Mac App Store as a result of the ongoing painful process of enforcing sandboxing. Apple has twice extended the deadline to switch it on -- it was originally last November. In the mean time, I and other Mac users I've spoken to have found ourselves holding off on App Store purchases, or actively sought out non-App Store versions of apps, to avoid getting into a state where we have a licence for an app that is removed from the store. The third issue is commercial pressure. What if, in the future, users come to view programs not on the App Store with disdain for missing features or even outright suspicion at a perception of lower software quality? So far I don't think this has happened, but it's a possibility in the future. If sales outside the App Store begin to drop, devs will come under a covert pressure to move to distributing their wares via Apple. They might then face an unpalatable choice between dwindling sales or neutering their programs to comply with sandboxing. App Store only APIs With Gatekeeper and app signing, Apple seems to be proposing a three-tier system -- App Store apps in the first tier, digitally signed apps in the second, other apps in the third. In theory, apps in tier two and three are equal, but the ones in the App Store are limited by the sandboxing requirements. It's not that simple, however. A subtlety arises from the existence of features that are only accessible to the App Store apps. Two big new parts of Mountain Lion -- iCloud document syncing and Notification Center -- are described as being only useable to App Store programs. This widens the gap between the first and second tiers, particularly if the hunches of a few developers I spoke with are right and Apple continues to make marquee OS X features App Store-exclusive. Now to be fair to Apple, there is a big mitigating factor, because both of these services use server-side resources Apple has to maintain with no direct income. iCloud, for one, clearly relies on cloud storage to work and cloud storage doesn't come cheap. Notification Center is more puzzling. At first, I thought it worked primarily like Growl -- in other words, it was a way for an app already running on my Mac to bring something to my attention. Fellow TUAW writer Chris Rawson and Iconfactory's Craig Hockenberry told me I was wrong, so I dug deeper and talked to a few developers. Anand Lal Shimpi's investigation showed that, in the current developer beta, Mountain Lion has two types of notifications -- local ones, that can be sent by any app, and server-side push notifications, which can only be associated with App Store programs. Jonathan George, CEO of Boxcar, told me that for his company the push notifications are far preferable, even on OS X. On iOS, any app that wants to notify the user arbitrarily (except Apple's apps like Calendar and Mail, which can use private APIs) needs server-based push notifications as a workaround for the lack of always-on backgrounding. It initially seemed to me that this is less important for OS X. Consider my Twitter client, which is always running on my Mac. It's checking every few minutes for new messages and can send a ping to Notification Center without any external servers. This, however, can take a few minutes -- a server-side push is realtime, or at least, really really fast. This is clearly better for some types of apps than local-based notifications coming from a polling loop. So what about App Store-only? To come back to the question I opened this piece with: could/would Apple mandate, in a future release of OS X, that the App Store would be the only game in town for getting software onto the Mac? Well, perhaps "could" is the wrong word. Apple certainly could, but I think we're a long way away from a world where most users would approve -- and for those who are comfortable with it, they'll be able to switch Gatekeeper into full-on paranoia mode and achieve the same end. Furthermore, if Apple was planning it for the future, I don't think we'd have seen Gatekeeper's middle setting introduced at all. The mere existence of this feature underscores that Apple is serious about giving users some extra malware protection via code signing without mandating the App Store. Indeed, Panic's Cabel Sasser asked an Apple representative about this when he was briefed on Mountain Lion and he reported that "for what it's worth, they told me point blank that they value independent apps and do not want them gone." This code signing option is not only a technical solution, but also grants indie devs working outside the App Store a veneer of respectability that might help make some less experienced users more comfortable doing business with them. There's also the question of professional-level software. It seems rather unlikely that the Adobes, Avids and Microsofts of this world would be happy to hand 30% of the sales of high end programs like Creative Suite or Office to Apple, as would be required if these apps were put in the App Store. Do those companies need OS X more than Apple needs them? It's debatable, but it's a game of chicken Apple would perhaps be wiser to stay away from. It's not dissimilar to the row about in-app purchases under iOS and apps like Kindle, and Apple lost that one. A tale of two app stores I think Apple, in simultaneously watering down the existing App Store via sandboxing and giving a non-App Store mechanism for developers to bless apps, has created a segmented market. It seems to me we're going to end up with the App Store populated by smaller apps from smaller developers (who will find the support of Apple's payment processing infrastructure compelling) and larger but relatively simple apps for which sandboxing doesn't chafe too much. Meanwhile, we will hopefully still see a vibrant indie dev scene outside of the App Store. Indeed, by enforcing sandboxing, Apple might have just given the alternative channels a lifesaving boost... but by locking key OS X features up to only be accessible to App Store software, it's simultaneously making it harder for non-MAS indie devs to compete. It's too early to tell which of these factors will come to dominate over the others. This is assuming, of course, that Apple sticks by its guns. The slipping schedule for essential sandboxing suggests Apple is perhaps a bit uncertain or conflicted about the way forward here and maybe we will see sandboxing significantly relaxed or expanded before it becomes mandatory. I'll end with one piece of wild speculation, because I'm a blogger and because I'm under my House of Crackpot Theories quota for this month. If an existing sort-of-an-app-store service like MacUpdate took Apple's digital signing certificate and ran with it, it's not impossible we could see an Unofficial App Store emerge. One which requires digital signing of all the apps, and offers developers a payment processing and download hosting service, but does not require sandboxing or unpredictable app approval processes. I think Apple's sandboxing policy may create a gap in the market by wilfully narrowing the scope of the App Store. I don't know if that gap is big enough for someone to wedge an entire new product into, but I'd throw money at anyone who's willing to try. The author would like to thank everyone who helped compile the information in this article: Jonathan George, Craig Hockenberry, Chris Rawson, Erica Sadun, Anand Lal Shimpi, Fraser Speirs, Steve Troughton-Smith, and the other devs I spoke with off the record.
Tweet Library for iPad makes Twitter useful
I've long been fascinated by the idea of using Twitter as both a social platform and a means of archiving my life on the web. I've played with using favorites, searches, backup services, my own bots for archiving links and direct messages ... I know it goes against the grain of the original vision of Twitter, but it's grown to be something that really has the potential to be more than a flighty (excuse the pun) social network. I haven't, however, really found a solid way to make Twitter work for me the way I think it could. That seems to have changed today, with my discovery of Tweet Library for iPad. Tweet Library is a Twitter client, but its main feature set revolves around archiving and organizing your tweets. You can see your last few thousand tweets (3,000 tweets on import, which I believe is the limit of the API - Ed), and you can search and filter your timeline, lists, favorites and mentions, as well as search all of Twitter. When you run across words of wisdom, links of interest, general hilarity, or any tidbit you'd like to save, you can send them into custom Collections. Create as many collections as you need, and let them serve as a means of organizing the flurry of information you come across on a daily basis. You can archive and export your collections and timelines, too. I won't list every feature here (there are a lot of them), but I'll note that support for TextExpander and Instapaper is among a host of other niceties. Manton Reece (Riverfold Software), the developer of Tweet Library, is no stranger to TUAW, nor to polished and useful applications. There's obviously a good bit of his heart and soul in this latest endeavor. I've come across a couple of minor bugs in this initial version, but he's been very responsive and is already working on the next update with more features and fixes. The app is priced at US $9.99 ... a bit pricey for the timid, casual Twitter surfer, but a solid investment for anyone who spends more time there than they'd readily admit. If you fly with that flock, have a peek at Tweet Library on the App Store, and check out the website for screenshots and a short video.
