This Week's Sponsor:

PowerPhotos

The Ultimate Toolbox for Photos on the Mac

Posts tagged with "developers"

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.

Greed and Entitlements

Nate Boateng has published a very good explanation of why App Store users aren’t entitled to free, universal upgrades of iOS apps:

The thought that a small development team is expected to do months work for free is insane to me. Yes, there are tons of successful apps that are universal (see Instapaper, Due, and Twitteriffic), but the perception that we are entitled to that is not only selfish, it’s just plain wrong. Universal app updates that come for free should be considered a bonus, not a right. A while back Iconfactory developer Craig Hockenberry gave a ballpark on Twitteriffic’s development. He estimated that it cost around $250,000 to develop Twitterrific. Think about that for a second. Still think you’re entitled to free universal updates for the lifetime of an app? I sure don’t.

Today’s Tweetbot releases are just another example of a subset of users that think developers should keep on updating their apps, even adding completely new iPad versions, for free, forever. This kind of controversy seems to take place every time a major iPhone app is released as standalone on the iPad, or vice versa. So I’d like to formulate a quick thought on the subject.

I understand those who say “I would have preferred it to be universal”. Sure, sounds reasonable. I would have preferred my iPhone 4S to come for free in the mail, too, but it didn’t. Stuff isn’t free in this world (even when they give you the illusion of free, you’re the one being sold). What I can’t accept is people getting angry and offensive at third-party developers that decide, you know, to make people pay three bucks for an app that’s been in the works for months. Unfortunately, the App Store doesn’t allow for paid upgrades, so if these people’s rhetoric is that it’s not about the price, it’s about the convenience of a universal binary, well, there isn’t much developers can do about it. Ask Apple.

More importantly, I’m baffled when I see people really getting angry because of a standalone app that was always meant to be that way. So here’s a tip for these people: next time you’re about to send a tweet to a developer, claiming that he promised a free and universal update and he’s now “stealing your money”, do your homework. Because if I can’t argue on economics, I sure think I’m pretty good at Google Search, which brought me to this page (screenshot). From the old Tweetbot FAQ, when the iPhone app was first released in 2011:

Will there be an iPad/Mac version?

It’s a possibility, but we have no plans for it at this time. We are focusing on the iPhone version for now. If we do an iPad version, it will not be universal.

Don’t be greedy. Support indie developers and great software.

Quick Review: RankIt Checks On iOS & Mac App Store Charts

Developed by Steve Reynolds (Analytix, Clicky Touch), RankIt is a new iPhone app that allows you to check on iOS and Mac App Store charts for any app that’s currently available for sale. Whilst some iPhone apps have tried to bring the complexity of web-based App Store analytic tools to iOS in the past, RankIt focuses on simplicity in that it allows you to quickly enter as many apps to “monitor” as you want, and refresh at any time to see real-time rankings.

As you fire up RankIt for the first time, you’re asked to add an app from the App Store you’d like to check rankings for. You can choose between iPhone, iPad, Universal and Mac apps, and change from United States to 9 other markets with available charts. In Settings.app, you can further tweak RankIt to adjust the number of maximum ranks returned (from 50 up to 400), set a default country, and refresh on launch. Once you’ve entered an app to monitor, RankIt will quickly refresh its ranking to check on freshly updated charts. RankIt will display an app’s position in the Top Paid/Free charts, as well as its ranking in the category’s charts. Universal apps will show iPhone and iPad icons next to them; with one tap, you can open a single app view that displays rankings in multiple countries. You can refresh at any time, with RankIt taking only a few seconds to get updated charts from the App Store.

In spite of its simplicity, I believe RankIt can be a worthy addition to any iOS or Mac developer’s workflow. In fact, the app’s focus on “quick stats” might just be its biggest selling point when compared to more in-depth tools that can’t just be refreshed every 10 minutes, whereas RankIt seems to be meant exactly for this – quickly checking on the App Store’s charts. I’ll make sure to test RankIt again during one of the big app launches next week, and see how it handles updates in real-life usage scenarios.

RankIt is $1.99 on the App Store.

The State Of iCloud-enabled Apps

Three months after the public launch of iCloud, I thought it’d be interesting to check upon the App Store and see how many developers have decided to enable iCloud integration for documents & data storage in their apps.

iCloud went live alongside iOS 5 and OS X 10.7.2 on October 12th, two days ahead of the iPhone 4S’ launch. In retrospect, iCloud’s public debut wasn’t without its issues and hiccups, but it was relatively smooth in the following days and Apple acted promptly to restore interrupted services for its users. Looking back, it’s just weird how many times iCloud Mail has been down, and continues to be unstable, whereas iCloud sync (for apps and data) has been fairly responsive and, at least on my side, always up. This says a lot about priorities, I guess.

In 107 days since iCloud went live, and 235 since Apple’s announcement at WWDC ‘11, it appears the majority of third-party developers are still considering whether or not iCloud is something worth investing their time – and customers’ money – or not. Those who have successfully implemented iCloud have done so in ways that require minimal user interaction, most of the times enabling sync capabilities through a single setting switch. Others have tried more complex solutions, often having to come up with separate tools to enable iCloud. Especially on the Mac, the fact that only apps sold through the Mac App Store can be directly integrated with iCloud isn’t helping developers who are still selling apps both on Apple’s App Store and their own website. Overall, there seems to be a shared trend among developers choosing to wait for Apple to clarify specific aspects of iCloud sync, improve the platform and fix some bugs that may prevent certain applications from being iCloud-enabled without requiring a major restructuring of the codebase on their end. Turning an iOS or Mac app into an iCloud-enabled app hasn’t turned out to be the 1-click process many, including me, wrongfully assumed when iCloud was previewed at WWDC last year.

Every app has its own way of storing local documents and user data. Some apps prefer keeping the original source of a document intact, say a .txt file, whilst others may apply their own file format to store documents and data internally in a proprietary database or multiple files, such as Evernote’s take on XML. There are pros and cons: keeping a universal file format such as plain text gets you more benefits in data portability; writing your own database structure allows you, as a developer, to do things exactly the way you want. What does this mean for iCloud?

Without getting too technical (also because my knowledge on the subject can only get you so far before I suggest you go read the developer documentation), the developers I’ve talked to explained that in the way iCloud syncs file, there may be some incompatibilities with apps that are based on complex databases and libraries. Apps that simply want to sync .txt files across multiple devices might be easier to port to iCloud, but then again there are always some aspects to consider such as conflicts, renaming a file, or getting a timestamp for the modification date when multiple devices are accessing iCloud. That’s not to say implementing iCloud is technically impossible for apps that are based on libraries, and not easily exportable files: below, I’ve collected some examples of apps that do just that, and quite cleverly too. However, getting to enable iCloud and make it reliable enough so that all kinds of apps can work with it without frustrating the user (who, in theory, never has access to the inner workings of iCloud) while at the same time providing the functionalities he or she expects. Read more

Apple’s Results and Developers→

Apple’s Results and Developers

David Smith looks at yesterday’s Q1 2012 numbers from an indie developer’s perspective:

If you add up the combined resolutions of all iOS devices sold in this quarter you get 40,747,941,888,000 pixels. It takes 17 viewings of entire Star Wars Saga on Blu Ray to see that many pixels. (805 minutes x 24 fps x 1080p).

On a more serious note:

Apple paid out $700M to developers during this quarter. That is equivalent to 125 $0.99 apps being sold every second.

Hardware brings in the real money for Apple. But I think it’s safe to say that, at this point, it’s the software ecosystem and the developers that are convincing people to switch to iOS. I’d like to know: how much of those $700 comes from games?

Permalink

New Twitter Clients

Justin Williams writes about the current state of Twitter clients for iOS:

What iOS needs is the Twitter equivalent to Adium: a well maintained, open source Twitter client that is targeted at the most hardcore and passionate users of both Twitter and the iOS platform.

That, of course, is easier typed than done. Many open source projects fail because of lack of vision or direction. Others fail because they are just badly engineered software that aims to shove every pet feature into a unified product. Projects like Adium succeed because there is an established hierarchy of managers, developers and contributors. Each release has a focus and direction much like a commercially produced project.

My first Twitter client was Twittelator Pro by Andrew Stone, which I installed soon after I got my first iPhone in 2008. After that, I switched to Twitterrific, which I kept until Tweetie came out. For a few months I bounced back and forth between Tweetie, Twitterrific and Birdfeed but, eventually, I settled with Tweetie 2. I loved Tweetie 2. It was the perfect Twitter client for my needs, it was fast and Loren was (is) a great guy. But then Twitter bought the app, started doing all kinds of crazy things to it, and the excitement wore off. I went back to Twitterrific, but it wasn’t the same – I had become very accustomed to Tweetie (now Twitter for iPhone) and the simplicity of Twitterrific was disorienting. Like Justin, I’ve always had a problem with inline DMs in Twitterrific.

Throughout 2010 and 2011 there’s also been a period when I went back to trying every Twitter client out there, including Twittelator Pro (again), but also Echofon, Tweetings, HootSuite, Osfoora, TweetList and TweetLogix. I was addicted to trying Twitter clients until Tweetbot came out and, as I wrote in my review, proved to be a Twitter app for iPhone I could once again fall in love with. I’ve been using Tweetbot for iPhone ever since, and the app keeps getting better on each release. Personally, I don’t agree with Justin’s point that Tweetbot is “the best designed Android app available for iOS”, but this isn’t the main problem.

The real issue is that these days iOS Twitter nerds are left with Tweetbot and nothing else. Twitterrific clearly isn’t targeting power users – maybe a better expression would be “users that don’t just casually check on Twitter” – and Twitter for iPhone, well, let’s just say it’s not exactly focused on Twitter geeks anymore. How about the other clients? I see very few innovators around, and the only third-party app I’m excited about (again, except Tweetbot, which I use every day) is Twittelator Neue – Stone’s app has a good chance to reinvent a few things especially if it ever comes to the iPad. But looking at the whole Twitter software landscape today, it’s clear to me there isn’t the kind of verve and anticipation for new clients that we experienced three years ago, with developers constantly updating their clients, one-upping competitors in terms of features, and teasing new products that (sadly) never came to be.

In a scenario where the less popular Twitter clients are either a) maintained through bug fix releases or b) updated with minor features every once in a while, lacking major additions like iPad and Mac counterparts, I see a glimmer of hope in Tweetbot – Tapbots are always up to some great stuff – and services like Tweet Marker: available for free to developers to implement in their apps, Tweet Marker is the first step towards that kind of client-side unification whose lack made switching Twitter clients on a daily (or even hourly) basis so painful in 2009. Check out the apps that already support Tweet Marker, and note how they’re the same names that I’ve mentioned above.

Building an Adium-like model for the ultimate Twitter client might be a viable plan, albeit an elaborate one considering all the technical complexities and frequent changes behind the Twitter API. An ideal modern Twitter client for power users should have delightful and powerful iOS apps and an outstanding Mac client that makes it extremely easy to switch environments without user fatigue; you have to make sure the apps are always brought up to date with the latest Twitter features from Twitter itself and iOS 5 (I’m fairly sure the technologies and APIs behind AIM aren’t updated nearly as often as Apple releases new iOS betas), and when everything’s distributed for free you have to make sure you’ve got a dedicated, kick-ass team of contributors and leaders, or things start to get messy (and slow) because of updates, user support, feature request, and so forth.

So here’s another possible scenario. Let’s continue to diversify the offer of available Twitter clients, and settle with one app for power users. Justin doesn’t like Tweetbot, but perhaps one year from now Tweetbot will be available on more platforms with changes and tweaks that everyone will like and use on a daily basis, even Justin. Around that Twitter client for power users, I imagine a flourishing ecosystem of innovative Twitter apps that don’t simply focus on building an alternative to Tweetbot – a daunting task at this point – but provide a unique experience that can live alongside the main, full-featured client. I’m thinking Tweet Library, also by Tweet Marker’s Manton Reece: instead of just focusing on being the perfect regular client, Tweet Library’s built-in client is functional to the app’s real feature: curating tweets and archiving them. This is the path I believe developers should strongly consider for building Twitter-connected apps: focus on APIs, services and interactions with other software. Where’s the Twitter app that integrates with Evernote and lets you annotate tweets? Where is the app to run, manage and archive online polls exclusively via Twitter? Where’s the service that lets you use your custom vanity URL and get beautiful, real-time, reliable click analytics instead of the ugly mess that’s HootSuite?

You see where I’m getting at – I believe developers are (obviously) completely free of investing their time and resources into competing with Tweetbot, but on the other hand I don’t think focusing on other aspects of Twitter means admitting defeat. It’s easy to say “Tweetbot won” or “Twitterrific is the best” when, really, the story is much more complex than that and also goes back to a company that has shown a “peculiar” approach to guiding its own third-party developers.

Will we ever go back to the Birdfeed and Tweetie era? I don’t think so. Twitter is now integrated in iOS 5 and seeing massive growth because of it, thus justifying the prospect of creating an app “for power users” even less. Yet I can’t help but think about a time, not too distant from now, when the power users will finally settle on a single solution for their power-hungry needs, and let other developers innovate atop of the Twitter platform in disruptive new ways. The ideas, devices, APIs and users are waiting.

[Photo by Jorge Quinteros]

New Apps for 2012

With the new year, many people make up resolutions that often involve losing weight or spend less time checking email and Facebook. Whilst those are certainly noble resolutions, they don’t quite fit the goals that I have set for this year when I began thinking about 2012 and the things I’d like accomplish in the next 12 months. Instead of working more to make more money, I’d like to work less but work smarter, as Shawn recently mentioned in an episode of Shawn Today. I want to spend more time with my family and friends and use the “time for work” with better tools to get the same things done, but better. I’m working on a series of completely new projects, too, but I also would like to optimize my existing tasks to require less time yet yield better results.

Which means I have to get new tools and understand how to properly use the ones I already have.

So instead of making up new year’s resolution and give up on losing weight after three weeks as most people do (but won’t admit), I actually went ahead and got new tools. Which, in my case, means I bought new apps and gear to get work done.

I recently wrote about how I’ve switched from OmniFocus to Remember The Milk, Calendar and Todo.txt to effortlessly manage my tasks, events, and articles. I’d like to quote for the sake of context:

I don’t have access to my Mac 24/7 anymore. I work from different places, and 80% of the time I prefer to keep my iPad with me than a MacBook. Obviously, the tweaks and adjustments I had made on my Macs didn’t carry over to iOS devices.

Articles, app releases, website management and finances are all different kinds of tasks. I used to keep them in OmniFocus, and tweak the app and its view options to fit the way I worked. It turns out, having separate tools for different sets of tasks is helping me focus more and avoid distractions. Articles need research and are more text-oriented; app releases only need a quick ping or alert; finance and website management can go into a proper GTD app with lists, due dates, etc..

These are two key points: access and writing. I don’t have access to my Mac(s) 24/7 anymore and I have to give up on pretending my articles are tasks that need to be managed with tags and due dates. Writing is a creative process (even when I’m breaking news or analyzing a rumor, I try to offer a perspective for debate and analysis), and I don’t think creativity can be managed with strict rules and app badges.

So here’s a short list of new apps that are helping me rethink my workflow. Some of them will stick around, others will probably be deleted – I don’t know. What matters is that taking a step back and reconsidering your work habits is a healthy practice (clearly better than telling your friends you’re going to lose weight or quit smoking) that, I believe, can lead to better relationships, a new knowledge of your workflows, and, ultimately, better results. Read more

Camera+ Reaches 6 Million Downloads, Over $5 Million In Revenue

The developers of Camera+, the most popular alternative to Apple’s Camera.app on the iPhone, have posted updated statistics regarding the performances of Camera+ in the App Store, and the results are quite astonishing. To date, Camera+ has sold over 6 million copies and earned over $5 million after Apple’s cut. Camera+ was first released on June 7, 2010, and was later pulled from the App Store in late July, only to come back in December 2o10 with version 2.0. Since then, the app has been growing in popularity and receiving updates with various enhancements and bug fixes.

Over the past 6 months, Camera+ revenue has increased over 3x. Play along and fantasize for a second about that trend continuing over time… if it keeps going, by 2018 our daily sales would be twice the world population. Yeah, this growth might not be sustainable over time. Anyway…

The two most relevant things contributing to the large jumps on the right side of the above chart were the launch of the iPhone 4S in early October and the annual Christmas bump. Both were increases that were expected but what’s been surprising is how long each has lasted.

tap tap tap’s latest blog post is interesting not just because of app sales numbers alone: I think it provides good insight into the 4S “bump” from October and the typical sales increase in the holiday season, which is related to new users buying apps for their new devices. This year, however, sees a new iPhone model released against the holiday season for the first time. It’s been widely reported the iPhone 4S should be selling really well (we’ll know more on January 24), but tap tap tap’s numbers seems to suggest an impressive growth, not just a good one.

Camera+ is a rare example of a paid app maintaining a stable growth over time with only a few promotions and features by Apple. Read more about the app’s sales figures here.

“Developers, A Love Story”→

“Developers, A Love Story”

Gabe Weatherhead sums up the reason why I started MacStories in 2009, one that still holds true today:

While browsing my Application folder on my Mac, I noticed something. I have a fondness for some apps that I rarely use. I’m just glad that I own them. I may not use them all but I feel good about the money I’ve spent.

If I like a developer I buy their wares just to support their work. When I say “I like a developer” I don’t just mean I like their products. I mean that I like the people behind the products. I like the philosophy, the commitment, the personalities. Sure, I’ll buy software and services from people I think are ass-hats if they make polished high quality stuff. But I’m more likely to buy less awesome software from someone I like than I am to buy highly polished stuff from a jerk. This is especially true in the Indie Software scene. There are real people behind every pixel and algorithm.

We may talk about news and rumors occasionally, but ultimately the people that make the products we use are what really matters. Their stories, the choices they make in developing great software they use in the first place, the way they handle customer support and engage with the community only to make amazing apps that make us more productive every day. I could add a few names from my Applications and iTunes folders: all the app from Edovia. Hazel and MindNode Pro. Airfoil, Alfred, and iStat Menus. I’m serious when I say MacStories is here today also thanks to the Apple developer community. People I (and many others) trust. And great things still have to come.

What’s not to love about the iOS/Mac indie development scene, honestly? Go read Gabe’s post now.

Permalink