This Week's Sponsor:

Textastic

The Powerful Code Editor for iPad and iPhone — Now Free to Try

Clear Sells 350,000 Copies In 9 Days→

Clear Sells 350,000 Copies In 9 Days

The Guardian reports “buttonless” todo list app Clear has sold over 350,000 copies in nine days of App Store availability:

We’ve sold just over 350,000 copies,” says product manager Nik Fletcher. “The launch day was massive, and by Wednesday last week it was number one on App Stores around the world. It’s been an incredible response.”

Clear costs 69p on the App Store, meaning that the app has generated net revenues of just over £169,000 so far, after Apple’s 30% cut. The revenues are being shared between Realmac, software studio Impending and co-creator Milen Dzhumerov, as Clear was a collaborative project.

Clear is another example of the App Store’s uniqueness as a platform for independent developers. A simple idea such as a todo list application for iPhone, coupled with a great UI and the right marketing strategy can be a sustainable business model for smaller development shops and individuals. It’s also another example of how buzz and social networks such as Twitter can build an incredible amount of hype around software these days (just take a look at the visualizations on Clear’s Vimeo teaser).

Make sure to check out our review of Clear if you missed it, and our interview with developer Phill Ryu.

Permalink

Tip: Handle iMessage Notification Overload with Contact Settings

Since Apple released a public beta of Messages for Mac, we’ve been having a bit of a notification overload here at MacStories HQ. See, ever since iMessage was released with iOS 5, we’ve had our own group message with everyone on the MacStories team – it was a portable water cooler, where we could chat about random things, share silly pictures and even co-ordinate things for the site, even when we were out and about. We used it quite frequently, but things turned for the worse last week when we all got that Messages for Mac beta. What might have been 10 messages in a given time period, suddenly morphed into 50 messages because of the convenience of having iMessage just a click way on our Macs. Things were becoming chaotic and quite distracting, Don had even turned off vibrations — meaning he got no notification for any message, from anyone.

We didn’t want to give up on using Messages for Mac, and it was probably going to be a hard task to change our messaging behaviours to limit the number of messages sent, but it was clear this week that we had to do something.

Fortunately, we think we have found a solution. In iOS, Apple includes the ability to change the text tone and ringtone on a per-contact basis. What we did for everyone in the MacStories team, was to change the text tone to “None”. You can do this by going into the Contacts app, selecting a contact and tapping the ‘Edit’ button and scrolling to “text tone”.

This now means regardless of whether your phone is on Silent or not, you will not get any noise or vibration to alert you to the new message. There are two downsides to this ‘workaround’: the first is that you will still get the notification bar flipping down from the top of your screen. The second problem, which could be a deal breaker for some, is that any messages from that person will not cause a vibration or text tone – important to remember if they are a participant in a few of your group message threads.

There should be another way…

Whilst the ability to change the text tone (and ringtone) on a per-contact basis is really cool (and can be used for a number of other purposes), perhaps there should be another way to control message notifications differently – especially now that iMessage is bundled in iChat, and may lead to an increased number of messages sent to iOS devices. Specifically I’m talking about muting specific message conversations. This would allow me to mute the message thread that has all of the MacStories members, but still receive notifications from Federico, in case he urgently wanted me to cover something.

Apple could easily implement the option inside the Messages app, simply displaying a mute icon next to each message thread when in the ‘Edit’ mode. Just like changing the text tone on a per-contact basis, this power-user option wouldn’t make the UI messy, because it would only appear in the ‘Edit’ screen. That way, users could choose between completely muting on a per-contact basis or on a per-message thread basis – all whilst still receiving notifications for your other messages.

iPad + Office + Apple + Microsoft: Why It All Makes Sense→

iPad + Office + Apple + Microsoft: Why It All Makes Sense

Rumors of Office for the iPad flared up again this week after The Daily posted an alleged photo of it, after apparently getting some hands on with a near-complete build. Some of you may recall me tweeting that day, what I thought was a crazy thought: Apple inviting Microsoft on stage next month at the iPad 3 keynote to demo Office for iPad. Apparently it wasn’t as crazy as I originally thought, because others are thinking it might just happen.

Office for the iPad makes total sense, though. And I wouldn’t be surprised if Apple did give Microsoft some stage time to unveil it at the new-iPad event in a few weeks.

Those are the words of Dan Frommer of SplatF, someone who (in my mind) has always made strong, rational cases for his arguments, never sensationalising or using hyperbole for the sake of it. In an article published a few hours ago, he lays out why “iPad + Office + Apple + Microsoft” actually makes sense. In it he lists out all the big arguments for such a Microsoft appearance at Apple’s iPad 3 keynote.

This isn’t like when Microsoft had to scratch and think before making Office for the Mac in the ’90s, when it would be lucky to sell a couple million copies per year. The iPad is way different: It should easily pass 50 million unit sales this year alone, and that’s potentially tens of millions of Office buyers for Microsoft. (Office, by the way, represented significantly more of Microsoft’s sales and profits last quarter than Windows.)

I strongly encourage you to read the full list of arguments in his article, I don’t think anyone could have laid out the argument for such a proposition any stronger than Dan did. On the flip side though, Daring Fireball’s John Gruber doesn’t think it’ll happen.

But what would be in it for Apple to offer such a spot to Microsoft? You can argue that the iPad with Office available is an even more attractive platform/device than the iPad as it stands today, sans Office. But why share the spotlight with Microsoft? Apple doesn’t need to.

Permalink

Buzz: My New Phone App Replacement and Contact Hub

I’m not typically one that likes to replace Apple’s core iOS apps with third-party alternatives, but Savvy Apps’ latest iPhone app, Buzz, allows me to access my contacts faster than Apple’s own Phone software, and I had to leave a spot for it in my Dock.

For the past two weeks, I’ve been testing Buzz, the latest production by iOS design and development firm Savvy Apps by Ken Yarmosh. Similarly to Agenda, also by Savvy Apps, Buzz comes with its own clean, custom UI focused on presenting text against a light background that contributes to increasing readability and finding things in seconds. Whilst I believe Agenda benefits more from this design aesthetic because of how it handles information density (a calendar app can get pretty busy), the same focus on clarity and simplicity works equally well for Buzz, which is a quick dialer/contact management app that emulates many of Apple’s Phone functionalities in a completely new interface.

Think of Buzz as a minimalist take on Apple’s Phone app, aimed at enhancing a few important functionalities, leaving out many others that are (at least in my workflow) rarely used. Whilst Phone.app obviously offers control over recently missed phone calls, the voicemail, and your system favorites, Buzz takes the “quick shortcut” aspect of apps like Launch Center and Matt Gemmell’s Favorites, combines it with group management and native integration with the Address Book, and comes up with a rather unique implementation that allows for a very lightweight usage, or deeper full-blown contact interaction. I believe many out there will find it hard to completely give up on the native Phone app – especially for the Recents view – but I found Buzz to be enough for me and, if anything, a better solution for my daily Address Book needs. Read more

Apple Purchases Land In Oregon For Another Large Data Center

An Apple spokeswoman has confirmed to news agency KTVZ.com that it has purchased land in Prineville, Oregon and plans to build a data center. The land, purchased from Crook County covers 160-acres and was purchased for a reported $5.6 million. Apple confirmed the purchase after they were named as the purchaser in a February 15th filing in Crook County.

Apple spokeswoman Kristin Huguet confirmed Tuesday that “we purchased the land and it’s for a data center,” but could not speak to details beyond that, other than to say it will be a “green” facility.

Rumors of Apple scouting out land in Prineville for another large data center emerged in December last year when it was reported that Apple was in discussions over purchasing the land. The land Apple purchased is nearby Facebook’s data center in Prinneville, which is pictured above.

[KTVZ.com via MacRumors]

Storify for iPad Review

Since its release in April 2010, the iPad has been widely regarded as a “consumption device” not really suited for “content creation”. Whilst we have already examined the issue with dismissing the iPad as a device that’s not capable of doing the same things a computer can – and my friend Shawn has a good take on why “content” generally is an awful marketing umbrella – the Storify iPad app, coming today for free on the App Store, is yet another example of how the iPad is changing the way we create through unique interfaces built around touch and the strengths of iOS.

Storify is an interesting service. Per se, Storify isn’t strictly focused on allowing you to create original content (images, text, or a combination of both) that you can share with your friends; rather, Storify is a curation tool that, among other services, leverages Twitter and the openness of the web to let you create “social stories” based off elements shared by people you follow, or just about anyone else on the Internet. Storify wants to tell stories by “curating social media”. I have covered the topic of curation – especially Twitter curation – several times on MacStories, and I recently mentioned Storify in my review of Tweet Library, an iOS app by Manton Reece that enables you to create collections of tweets for future reference. As I detailed in the article, Storify integration in Tweet Library means you can easily collect tweets from a variety of sources (people you follow, Twitter lists, favorite tweets – Tweet Library does a great job at breaking up Twitter sections in neatly organized “sources” panels) and publish them online as a bundle on Storify. The first official Storify iPad app, however, brings the full feature set of Storify (or at least the majority of its online functionalities) to the tablet, mirroring the web counterpart available at storify.com to allow you to create visually rich social stories that go beyond collecting data from Twitter.

I have been able to test Storify for iPad in the past weeks, using it to create and edit stories that I’ve embedded on MacStories such as this one, or this one. When I first talked to Storify CEO Xavier Damman about their upcoming iPad client, I wondered how well the team had managed to port the desktop user interface and experience of Storify, which is largely based on drag & drop, to the iPad. Furthermore, the Storify web app benefits from the desktop nature of the web browser, which makes it easy to switch between dozens of tabs, collect links, snippets of text, and images, or simply open links from other applications without having to worry about “switching back” using a multitasking tray, such as the one we have on iOS. These are all problems a native iPad app should somehow address, I thought, as it’s not just as easy and quick to switch between the browser and multiple sources on an iPad, and I wouldn’t want the Storify creation process to become slow or, worse, cumbersome. It turns out, the Storify team solved the problem with converting mouse interaction to multitouch, and quite beautifully. Read more

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.