Entries Tagged 'Apple' ↓

South Park Comes to the iPhone

Streaming episodes of South Parkare coming to the iPhone through a new application by South Park Studios. Personally, this is one of the most exciting applications I’ve seen.

Spotlight Turns to Notebooks

Apple has sent out -invitations for a town hall event next Tuesday. The invitation shows an aluminum notebook that could simply be a Macbook Pro — but looks more like a Macbook to me.

Can’t wait to see what they have for the holiday season.

The iPhone Platform

I wrote in June:

I think what this means is Apple not only still believes in software-hardware integration, and selling devices with high-profit margins, but that Apple’s long-term strategy is to dominate the post-PC market. The “post-PC” is a mobile device that, in Apple’s vision, complements a desktop PC, and is specific in function. It is the iPhone.

Apple is taking this pricing risk with the iPhone because they want to build the preeminent mobile platform, and the only way to do that is to sell a shitload of them.

Apple wants to establish the iPhone platform, the post-PC’s Mac, before Android, the post-PC’s Windows, has a chance to take off.

Gruber wrote last week:

The problem is that the apps that are the most interesting, the most important, are the ones that take the most work to create. And the apps that take the most work to create are the ones that are most likely not even to be made in this environment, because the risk is greater. The more work it takes to create an app, the more you lose if Apple rejects it. Going back to the ladder analogy, the higher you’re trying to climb, the more you need to trust the ladder before you start.

It’s not about a handful of developers who’ve had their apps rejected. It’s about all the other developers who are now spooked, and that the ones who are the most spooked are the ones who harbor the grandest, boldest, most innovative ideas.

I still believe Apple is positioning the iPhone to do what the Mac never did — dominate a nascent market with incredible growth potential. Their goal is to make the iPhone the only platform worth developing for.

The iPhone as a platform has incredible advantages over its competitors. It is connected with perhaps the most successful consumer product ever, the iPod, and enjoys the recognition and respect from consumers that connection entails. It is the only phone in the market that is as good a media player as an actual iPod, syncs with iTunes, and can download and play media from the iTunes Store. It is the most well-thought out, comprehensive, and intuitive device on the market. It is built by a company that really loves good design.

That is a lot of positives, which its competitors, for the foreseeable future, cannot match. It should be the dominant platform.

Notice the word there. It should be the dominant platform, not the dominant phone. But no matter how many advantages the iPhone has over its competitors, without developers, it will fail.

Gruber is exactly right. The problem isn’t that we lost Podcaster, MailWrangler and a fart-simulating application. The problem is that by refusing or removing these applications based on nothing more than Apple’s whim, the trust between developer and Apple is violated. Developers are unlikely to invest months into designing and developing a really great application if, even when they follow every single rule, their application may not even make it on the store. They will either not develop it at all, or will develop for Android.

If the iPhone is going to succeed as a platform, it must foster a positive developer community like the Mac has. One where good ideas and good design are encouraged. Apple must understands this, but what is scary is they are acting like they do not. Their actions suggest that developers will continue to build applications no matter what conditions they set — like they think that the developer community is incidental to the main show, what Apple itself develops for the iPhone.

Apple cannot be ambivalent toward the iPhone developer community. It must actively foster its growth as much as it can so the iPhone developer community can be the same asset the Mac developer community is for the Mac. If they do not, the iPhone may very well fall to Android.

Not because Android is better than iPhone OS X, but because its design is good enough, and if developers switch to Android rather than the iPhone, because it has a larger and better selection of applications. It may end up that innovative development happens on Android. If this happens, it does not matter what incredible work Apple does.

Apple has everything it needs to have the best mobile platform in the market. Great product, great customers, and a loyal developer base who wants Apple to succeed. Developers’ response to Apple’s lifting of the iPhone NDA showed just how much they want the iPhone to be the platform. News spread across the Mac community and received universal praise. Even better, people began doing things to encourage better design and code. Brent Simmons immediately set up a temporary iPhone developer mailing list. Craig Hockenberry published an article on making iPhone applications work together. These people want the iPhone to do well, and they want its third-party applications to be great. They have been waiting for months to help other developers, but have been waiting for the green light from Apple.

That is all Apple needs to do — give everyone the green light. And we already know how they can do that. Gruber, as usual, succinctly explains:

  1. State the rules.
  2. Follow the rules.

That, at least, eliminates the chill effect Gruber describes. Developers know what is and is not allowed, and thus can develop without fear their application will be rejected.

The rules, though, could be excessively strict. Essentially, Apple should stick to the rules they set forth in March 2008 when they announced the SDK. They will not allow applications which:

  • Are illegal
  • Are malicious
  • Are porn
  • Violate privacy
  • Hog bandwith

Those are Apple’s own rules, and that should be it. Everything else should be allowed, if Apple’s goal is to build a dominant platform. If that is not their goal, fine — but I think it is, and the only way it is going to really succeed is if developers are reasonably free to build whatever they want. We would never accept Apple banning applications on the Mac for “duplicating” existing functionality, because it would diminish the developer community, and we should not accept it on the iPhone for the same reason. Unless Apple allows a reasonable amount of freedom, the platform will never be dominant.

Obama’s iPhone App

It’s rare that I get to discuss my two great passions, politics and technology, within the same context, but the day has come. The Obama campaign has released an iPhone application that, I think, is a sign of what we’re going to see in politics in the coming years: campaigning at your fingertips.

Besides its excellent integration of media (video clips of Obama speaking or being interviewed), this application does two incredible things. First, this application sorts your contacts by battleground state. So, if your sister-in-law lives in Wisconsin, her name will show up in the “Call Friends” area so you can call them and convince them to vote for Obama.

There is a lot of potential here. Calling up potential voters in your area to convince them to vote for your candidate is mostly done at campaign headquarters using phone banks. Rather than using phone banks, though, which are limited in number and thus in the amount of people who can be calling at a given time, how about this application connects to a computer via Bonjour and accesses local numbers to call. This would allow a potentially-unlimited number of people to do phone banking without violating potential voter’s privacy (giving their numbers away).

Second, by using CoreLocation, the application lists local campaign events that are close to the user. This allows Obama supporters to get involved immediately with the campaign, and to connect with other supporters.

But think of what this feature could develop into. If a location-based social network is built into this application, supporters can begin to campaign on an unprecedented scale and in an unprecedented way. Supporters could opt in on a website component of this social network so their location is shown to other supporters within a certain radius of them. Then, supporters could post campaign events (whatever they are — fundraisers, sign-waving, meetings, et cetera) which would show up in the “events” area for supporters in the area. They could then confirm they will attend. This would take the power of meetup groups to an entirely new level.

But think about this a little more, too. The application already lists video clips of Obama and other campaign officials. Consider this: when doing precinct walks, campaign supporters are now beginning to bring along video clips on PocketPCs to show potential voters. This application could distribute these kinds of videos right in the application — no need to search YouTube, find them and save them to your PocketPC. Just open the campaign application and go to the media section.

Same with campaign literature. it’s can all be in the application, on your phone. This stuff is game-changing.

(Via Faruk Ates.)

A Touch of Cocoa

Ars Technica published a great overview of the iPhone SDK. What I found most interesting was their discussion of unexposed APIs and features that could/should pop up in future versions of the SDK.

Is Open Really Better?

Michael Mistretta just published a thoughtful article on his misgivings with Android, and he makes two excellent points.

First:

An open platform may have worked had there only been a single device. But Android is a multi-year project that will encompass a wide scope of devices with hundreds of varying user interfaces. Touchscreens to trackballs to keyboards to accelerometers. How can 50+ different phones made by different companies with different interfaces possibly function with apps in the Android Market?

Mark my word, three years from now, the Android Market will be a mess. Users will download—or even worse, purchase—an app, only to find that they have no way to interact with it because their phone lacks a touchscreen. Think there are a lot of flashlights and tip calculators in the AppStore now? Wait till you see the Android Market in 3 months.”

This illustrates a central problem with Android as a platform in the sense an iPhone is a platform: the “Android Market” is tacked on. Android’s intent is to be flexible enough to run on a multitude of devices with widely varying hardware. But this diversity of user interfaces, as Michael points out, is why an application store on Android phones doesn’t work that well: how do you account for applications with specific hardware requirements (e.g., “this app only works on phones with a touch screen,” or “…only works on phones with an accelerometer”) in the application store while still retaining a simple store design? I don’t want to wade through long lists of applications which aren’t even compatible with my phone — I only want to see applications that work with it.

One solution is for the application developer to specify certain criteria phones must meet, and if the phone doesn’t, its store will not display the application, but think about the upkeep involved in maintaining this system. The developer must specify explicitly what their application requires, and the Market must keep and update profiles for each phone of what it is and isn’t capable of. It’s begging for a poor user experience.

An OS which is designed to be run on a variety of devices with different configurations simply doesn’t work that well with a unified application store. That’s a trade off being made, and a rather large one on a handheld device, where ease of use is ultimately more important than features.

Second:

The iPhone was marketed as an iPod, a smartphone, and an internet communicator. Now, third-party applications can also be seen as a major selling point. With the lack of a 3.5mm headphone jack, dedicated video player, and desktop syncing, the G1 is hardly a media-centric device. It barely compares to the iPod. Surprising for Google, the G1 has a significantly laggy web-browser with a clumsy UI that leads to a lackluster mobile internet experience. That leaves the phone side of things, which I haven’t seen a single screenshot published to date.

The G1 — and any Android phone, really — is not a media-centric device. Period. As Michael points out, the G1 lacks a 3.5mm headphone jack, a built-in video player, and desktop syncing.

Google is betting on developers to make up for Android’s inadequacies, but the experience will be poor, because it isn’t integrated. It isn’t just that the audio application is poor and it has no video application. The issue is media wasn’t a focus in developing Android, so its support is a half-hearted attempt.

In contrast, the iPhone is a very simple concept: a phone, an iPod, and an Internet communication device. It has three functions, and it does the last two really, really well, and the first good enough. Just consider the music experience on the iPhone. The user can buy music, TV shows and movies, and subscribe to podcasts on their computer, and buy music on the iPhone, too. All of this media stays in sync effortlessly. All the user does is sync it whenever they have new media, and iTunes transfers new media to the iPhone and vice versa.

Once the media is on the iPhone, it is all accessible through one application, the iPod. Users can listen to music and podcasts, and watch movies and TV shows, all through this one application. And because this application is one of the device’s main focus, it’s very well-designed. It’s a joy to use.

To put media on the G1, however, users must enable mass-storage in the phone’s options, then hook the phone up and manually load media onto the micro-SD card. After they’re finished, they must disable mass-storage — because if they don’t, the G1 will not be able to access the card. Then they have to hook up a USB-to-3.5mm adapter and use separate applications for audio and video, all in a subpar user interface.

With the iPhone, you drop it in its dock and let it sync. It’s as close to seamless as anyone has ever gotten.

And with an Android phone, we’re back to the pre-iPod and iTunes days for managing our music collections. If there is one single reason I will not own an Android phone, this is it.

Iterating Things for iPhone

Cultured Code has published their iterations for Things for iPhone. Things for iPhone’s UI looks rather simple, so it’s interesting to see the initial sketches and iterations that went into its design.

(Via Via Daring Fireball..)

Shipley’s App Store Plan

Wil Shipley wrote today probably the definitive article on Apple’s App Store censorship, but I found this part particularly interesting:

The App Store needs to think of itself as two different parts - it already implements these parts, but the people who run the store need to understand that these two parts are fundamentally separate:

• Part one is a giant warehouse, where every piece of software that is not actively harmful is kept in case someone wants to buy it (remember, users can always get a refund). This warehouse can be searched with titles and keywords or an item can be directly linked.

• Part two is like a traditional storefront, with limited real estate, so only the best or coolest applications are highlighted. It’s a recommendation engine, that highlights popular, highly-rated, or innovative applications.”

(Via the Ranchero.)

This is an issue that has bothered me, too — how does the App Store scale? — and this is the first solution I’ve heard. I like the idea of having a “back room” where the majority of software titles are housed, and the storefront, where Apple displays the applications which deserve exposure.

Oddly, part of the reason I like this is it brings company website marketing back into the game. If your application depends upon traditional marketing, like word of mouth and advertising, you must build and maintain a well-designed website for your company and application.

This hasn’t been true thus far — with a few notable exceptions, like Tap Tap Tap and Cultured Code, companies have relied on their application’s iTunes store page to market the application, and that’s disappointing. Part of the Mac community’s magic, at least for me, is the excellent websites independent developers build for their applications. Panic’s website, Shipley’s Delicious Monster, Checkout’s website, and Cultured Code’s website all provide great inspiration for web designers. And, frankly, I love finding a new Mac application in part to see its website — the company’s website design is an important part of the application for me.

If Apple models the App Store around Shipley’s model (and even if it doesn’t, as the App Store is developing in a similar way, anyway — paging through certain categories is impossible), then application developers will have no choice but to create these websites again, and I will be a happy man.

Apple Denies MailWrangler

Apple has denied another iPhone app, MailWrangler, because it duplicates functionality of the built in Mail app without adding “sufficient” new features.

MailWrangler uses WebKit to access Gmail’s iPhone web interface, which users can do through Safari. MailWrangler’s added functionality is that users would not have to log in each time to access separate Gmail accounts like they do when using the web interface.

Granted, its added utility is not that great, and MailWrangler being denied is less egregious than Podcaster, but what is Apple’s criteria for what is and is not sufficient added functionality for duplicate applications? Apple needs to make these guidelines more clear, and I have a sneaking suspicion that they are, so they can avoid this mess every time they deny an application because of duplicated functionality.

App Store: I’m Out.

Fraser Speirs, creator of the great Exposure iPhone app, explains why Apple is making a huge mistake in rejecting applications for “duplicating functionality”:

Writing software is a serious investment of time and energy. It also carries the opportunity cost of the other things you could have built. We live in a capitalist economy. Under capitalism, profit is the reward for economic risk. Without a reasonable expectation of profit, the sensible business-person will not invest. Without investment and risk-taking, there is no innovation.”

I, and the rest of the Mac community, was enamored with the iPhone’s potential as a platform in the run-up to July 11th. I wrote in June that the iPhone is becoming Apple’s Mac for the 21st century, their central stool leg if you use Jobs’s analogy. I think this is still true — but how Apple is handling the App Store could give Android a large competitive advantage.

The iPhone is now, whether Apple intended it to be or not, a platform, and will succeed or fail on that basis. That means the iPhone’s success now depends as much on Apple as it does its developers, and Apple is, unfortunately, giving developers good reasons not to develop for the iPhone.

The NDA issue is still not resolved (and now we are stuck with the chock-lock as a result), it takes too much time for app updates to go live on the App Store, and most damaging, Apple has no clear guidelines for rejecting applications.

Why would a developer spend weeks or months of their time developing an application that Apple may reject because it “duplicates” functionality, or if it may be rejected in the future if Apple builds new functionality into the iPhone? Why would a developer take the time to develop a great application when it may not even make it onto the store?

Ironically, if Apple continues down this path of rejecting apps that duplicate functionality or have limited utility, that’s all the app store will be, because very few developers will take the requisite risk involved in developing a well-thought out, well-designed application. All the App Store will be is a list of games and koi ponds, and if that is what happens, the iPhone will fail.

If Apple wants the iPhone to succeed as a platform, they must, as Speirs calls for, develop clear, unambiguous guidelines for what is and is not acceptable in the App Store, and they must follow them religiously. A platform is about trust — developers need to know that the ground rules are followed, and that Apple is looking out for their interests.

Unfortunately, right now, that is just not the case.

(Via Shaun Inman.)