Welcome to 2012! If you're a consumer, you're likely getting ready for another year full of new products, drama, and intrigue from the tech world. If you're a journalist, you're cowering in fear of the upcoming CES trade show. And if you're a Mac or iOS developer—well, as always, you're wishing for bigger and better things out of Apple and its community.

While the iOS and Mac App Stores exploded in popularity in 2011, there's still plenty of room for improvement on the developer side. When we spoke with a number of iOS and Mac developers about their wish list for 2012, they didn't hesitate to let us know about changes they would like to see.






Read the comments on this post

Many newspapers and other traditional media entities still think of themselves as delivering their content in a specific package, although most are trying hard to build an online readership as well, or experiment with iPad and Facebook apps (not to mention paywalls). But few are thinking about their businesses in radically different ways — as content-generating engines with multiple delivery methods, or as platforms for data, around which other things can be built. USA Today  appears to be moving in this direction, by opening up its data for others to use and even commercialize, following in the footsteps of The Guardian and its ground-breaking “open platform.”

USA Today has had an API (an “application programming interface,” which allows outside developers and services to access its content) for some time now, as many other newspapers such as the New York Times  do. But like most of those other media outlets, the terms of the USA Today content API said it could only be used for personal or non-commercial uses, which meant the range of applications that could make use of the paper’s content was extremely limited. Now, the Nieman Journalism Lab notes that the newspaper has changed the terms of its API, and will allow commercial licensing of its data, with no rate limits or data caps for these “premium” licenses.

Opening up a relationship with outside developers
The paper’s APIs include one for all of its news articles, one for reviews of books, movies and other entertainment, and one for its census data — which is made up of public data, but has been collected by USA Today and made available in a more usable format than the original government version (although most of its APIs require non-commercial use, the New York Times allows commercial use of its government-info API, which is also made up of public data). Stephen Kurtz, VP of digital development at USA Today, told the Nieman Lab that most of the developers interested in using the paper’s APIs for commercial use are “mom-and-pop” shops, or a couple of guys in a garage, mashing up the content they get with other sources — such as combining USA Today movie reviews with data from Netflix. Said Kurtz:

We encourage that, and they give us good feedback of what they’d like to see and how they would like the API to grow. So for us, it’s very symbiotic.

This is a smart way to think of what an open API accomplishes. It’s not so much that it’s going to generate huge sums of money for a newspaper that offers it, but it allows for experimentation outside the traditional confines of the publication itself — and that can generate valuable ideas and feedback. For The Guardian, which launched its “open platform” approach last year, the opening up of its API was very much an extension of editor-in-chief Alan Rusbridger’s belief in what he calls a “mutualized newspaper,” one in which readers and those outside the publication help on both the journalistic side and the development side.

Those outside the paper have good ideas too

As Chris Thorpe, then the Guardian‘s developer advocate, described in an interview with me last year when the open platform launched, the paper’s API allows for access on several levels. One is the original free level, which allows anyone to use the data for personal or non-commercial purposes; the second is a commercial license, which allows developers to make use of the API provided they agree to accept advertising within the content; and the third is a “bespoke” arrangement, in which developers can request specific data and work with the paper to build a service or app — and then share in the revenue generated from it.

The British paper has been inviting outside developers to make use of its APIs through a series of “hack days,” and they have come up with some interesting ideas. For example, Thorpe has a prototype of a site he calls the “Later Today” Guardian: the site takes the newslists that the newspaper recently made public, which detail which stories it is working on for a particular day, and then maps them against the stories that the paper actually produces. Not only that, but it also notes which ones are in the process of being updated, so readers with useful information can contact the author via Twitter or email.

It’s great that newspapers like the New York Times have “labs” like Beta620, where their staff can experiment with different formats and services based around their content. But one of the driving forces behind the Guardian open platform was the idea that the paper itself couldn’t possibly think of or develop every interesting or worthwhile project involving its content — so why not “crowdsource” that effort via the API? That’s a worthwhile attitude that more traditional media outlets could benefit from. Embedded below is the video interview I did with Thorpe when the open platform launched.



Watch this video for free on GigaOM



Post and thumbnail photos courtesy of Flickr users Arvind Grover and George Kelly

Related research and analysis from GigaOM Pro:Subscriber content. Sign up for a free trial.
Content Farms: The Players, The Benefits, The RisksFacebook and the future of our online livesNewNet Q1: Content Farms and Niche Networks on the Rise

Fans of Red Sweater Software's blog publishing tool MarsEdit got a surprise Tuesday morning with the release of MarsEdit 3. The most significant update to the software is the addition of a rich text editor, though those who fiddle with the HTML for their blog posts got an updated syntax highlighter. A new media manager rounds out this solid update, one that the company hopes will attract new users and get old ones writing again. 

According to Red Sweater founder and developer Daniel Jalkut, some of the features in MarsEdit 3 have been in the works for roughly 2.5 years—basically since MarsEdit 2 was released. Many of the enhancements in the new version respond to long-standing requests from users, Jalkut told Ars, particularly rich text editing. "Most of the [blog] Web interfaces and desktop competitors have a rich mode but, until now, MarsEdit has focused exclusively on HTML/markdown source," Jalkut said.





Read the comments on this post

Dan Grigsby, founder of Mobile Orchard, is abandoning iPhone development. The reason? Apple's "ask permission" environment doesn't work for him anymore. He explained his decision in a recent blog post:

Ask permission environments crush creativity and innovation. In healthy environments, when would-be innovators/creators identify opportunities, the only thing that stands between the idea and its realization is work. In the iPhone OS environment when you see an opportunity, you put in work first, ask Apple's permission and then, only after gaining their approval, your idea can be realized. I've always worked at the edge; it's where the interesting opportunities live. None of the startup[s] I've created would have been possible in an ask permission environment.

What's interesting here -- from an industry perspective -- is that if you get past the Apple vs. Adobe vs. OS 4.0 vs. what-have-you stuff, there's two legitimate viewpoints floating around. You've got developers like Grigsby who find Apple's model too limiting. So they get out. And then you've got devs who think the App Store opportunity outweighs the obstacles (for now). Dan Pilone, co-author of "Head First iPhone Development" and founder of Element 84, is in that second group.

After corresponding with Grigsby and Pilone, I was struck by how much they have in common. There aren't any vast philosophical differences at play here. Both dislike aspects of Apple's model and both also see lots of opportunity in the App Store. Yet one is in and one is out.

The concerns

To help me understand his fundamental problems with Apple's model, Grigsby began by outlining the series of events that led to his departure from iPhone development.

Grigsby: Very often, you would have a group of developers in some kind of social setting and one would say, "I want to give you a free copy of my app." And in one case, a guy handed me a business card that had a URL for the iTunes store. And then he gave me a dollar and said, "Just go buy my app." That's crazy. I don't want your dollar. I want you to be able to whip out your iPhone and give me a promo code.

So, I wrote a single-site browser that would interact with iTunes Connect and let iPhone developers generate a promo code. Now I knew, because I've read the terms and conditions, that would never be allowed into the App Store. There's language in there that says you can't scrape the store. I was going to distribute the source instead. But I talked to some attorneys and they said Apple could decide that bothers them and kick me out of the program.

From what I perceived as maybe a $10,000 or $20,000 opportunity, I had to make a decision as to whether I should stay in this business. That's such an uncomfortable place to be. And so that most recent experience, the "you live or you die at Apple's discretion," made me start to look at all of the other examples of places where they're treating the App Store as an extension of their brand as opposed to just a marketplace. I lost all of my enthusiasm. I made a decision that I was going to change to something else.

Pilone has his concerns as well. He's a pragmatist, not an evangelist. He noted, for example, that recent app snubs should raise red flags for all developers.

Pilone: I think there's a potentially significant risk lurking out there. That's the approval process. Not from an "Are you using undocumented APIs?" perspective. That's an easy one to avoid. But from a "No thanks, you're competing with something we've already done," or "We don't want that kind of application on our phone," perspective.

Google Voice is the poster child for this issue, and there was a lot of rumor and speculation over whether the Opera browser was going to make it into the store (it ultimately did). This now begs the question, if Google Voice was delayed (Apple never officially rejected it as far as I know) because the voice, voicemail and SMS features duplicated functionality already on the phone, on what grounds could the Opera browser possibly be accepted? The point being, there's a real business risk of investing in a product only to have it completely rejected without any real avenues to rectify the situation. I don't want to make a bigger deal out of it than it is. Obviously 180,000+ other applications have managed to get into the store. But it's a risk.

A secondary marketplace

One proposed solution to developers' concerns is for Apple to allow a secondary market to take root. This would be an open space where developers who don't want to go through Apple's process can sell their apps legitimately. I posed this alternative to both Grigsby and Pilone.

Grigsby said a secondary marketplace would be a fine addition, but he's interested in a different change: he believes markets will naturally form if users can install software on Apple devices in much the same way developers can.

Grigsby: When you give someone the fundamental ability to install software on their phone, entrepreneurs will build marketplaces and create discoverability. Obviously, that's a threat to Apple. And so I can see Apple's point in all of this. This is why when you talk to me, I'm sad. I'm not mad. But it runs against my principles.

Pilone responded with a host of big questions:

Pilone: How many "secondary" marketplaces are we talking about? One? Two? Who decides? As a consumer, do I need to worry about all of them? What's my purchasing, downloading and installation experience like? Do I get enough value in the apps in that "store" to justify the time and complexity of having to figure it out? Sure, there will be power users who would use it, and as a developer I don't want to ignore that crowd, but really, in the grand scheme of things, what apps do you want or need that aren't in the App Store now? I go back to the philosophy that if a secondary market is valuable to you (as a developer or a consumer), go with a device that has it.

In or out?

I asked Grisby what Apple would have to do to get him back. He laughed, claiming he has no say in the matter. But in the off chance Apple asked, there's only one thing he wants:

Grigsby: I'm not standing outside saying, "Apple, you will do this or else." I recognize that my voice doesn't command that kind of authority with them. But I'd be happy if they gave people the ability to distribute apps outside of the store. I love marketing. I'm a marketing hacks kind of guy. So I can get people to find the applications. Just give me the ability to freely create works and find a market for them and I'll be happy.

It's a simple enough request. Just one tweak to the model, right? But in the course of my exchange with Pilone, he hit on the fundamental problem developers face: Apple is, above all else, focused on the consumer. Anything that runs counter to that isn't debatable.

Pilone: I take a very pragmatic approach to this. I think it's important for people (read: developers) to realize that Apple is a consumer products company. At the end of the day, they're about consumers, not developers. Apple philosophically believes that by delivering a closed system they can deliver a better consumer product. The success of the iPod and iPhone strongly supports that argument.

Apple's iPhone, iPod Touch, and iPad are "closed" devices that are 100-percent targeted at the end users. Developers are welcome, but you're going to support Apple's vision of the end-user experience whether you want to or not. Ultimately, it's a gamble for Apple. They're taking a risk that if they alienate too many developers, some other platform may draw them in. But Apple's wagering that if they make the best consumer product out there, it will have the largest user base. Developers will code for it because that's where they can be paid for their work and reach the broadest audience.

On Friday, we wrote about the changes Apple is making to the terms and conditions that it requires from iPhone, iPod Touch, and iPad developers before they can write software for these platforms. The new terms include a clause that prohibits a wide range of third-party toolkits and frameworks that offer developers benefits such as quicker, more robust application development and instant access to complex functionality like 3D game engines.

We believe the targets of this change to be, in particular, Adobe and Google's Android. Adobe is imminently releasing a new version of Flash that will, among other things, be able to produce iPhone applications. The new terms prohibit the use of such tools. Android is hurt because many of these frameworks facilitate cross-platform software development. As the smaller platform, Android benefits from the use of toolkits that allow developers to target the iPhone and then rapidly, and at low cost, migrate to Android.

Over the weekend, it appears that Steve Jobs weighed in on the issue. Jobs referenced John Gruber's rationale for the changes. He then, if the e-mails are authentic, clarified Apple's position, claiming that intermediate layers between developers and the platform have two results: they result in "sub-standard apps" and they hinder the "progress of the platform."
Let's take a look at each claim.





Read the comments on this post

One day has passed since Apple gave developers a sneak preview of iPhone OS 4.0, and already there's new (NDA-breaking) information floating around about the other 90-some features that Steve Jobs didn't discuss at Apple's media event. 
In addition to renewed evidence that Apple may add a front-facing camera and other camera-related features, developers with access to the beta have told Ars about even more tidbits buried within, essentially making OS 4.0 a piñata of API goodies for devs to beat on.

Thursday's announcement immediately turned up evidence that Apple might be adding a flash to the iPhone's camera, thanks to functions named VCaptureDevice.hasFlash, AVCaptureDevice.flashMode, and AVCaptureDevice.hasTorch. Apple is allegedly investigating LED flash options, which would make such a feature very BlackBerry-like. Additionally, the latest iPhone SDK continues to contain hints about a front-facing camera as well as iChat support.





Read the comments on this post