Category: Development

Hello App Store

The big day has come and passed. And you know what? We’re still in uncharted territory: for most of us Mac developers, the App Store is something new and strange.

Let’s start by looking at Apple’s cut in the deal. Is 30% reasonable?

My first impression was that it seemed a little high, but acceptable. You’re getting someone else to deal with the hassles of downloading, payment processing and, to some degree, promotion. There’s a lot of value in that. Look at what it costs to be on other plaforms, such as Xbox Live, and it seems fair.

But thinking through the situation a bit more, I realized that those things pale in comparison to the value of being associated with the Apple brand. Having their explicit stamp of approval and being included in the App Store will make any product more appealing to a customer. Buying directly from Apple means that your software won’t screw up their phone and that can be returned if it doesn’t live up to expectations. That, combined with the ease of a single click purchase, is going to drive a lot of sales. You’ll make up that 30% without even trying.

Update on March 13th, 2008: A reader, Philip Smith, wrote in with an interesting observation: how many developers have the ability to offer gift cards for their products? Traditionally, giving software as a gift has been a very hit or miss affair. But when friends and relatives can go down to the local grocery store and pick up a gift card for the App Store, that problem is solved. Yet another way to increase your sales with the help of Apple.

One thing that disappoints me about the iPhone SDK sign-up is that the entry fee of $99 is too low. I look at the entry fee as a way to filter out developers that aren’t fully committed to the platform. Unfortunately from what we’ve seen so far, including the load on developer.apple.com on the day of the SDK release, there’s a huge amount of interest. I fear that Apple is going to be overloaded with application reviews, issuing certificates, and other administrative tasks. A higher entry fee would lessen the chance of this becoming a bottleneck for getting my product into the system. Please charge me $499 and let move to the front of the line.

Now, let’s look at how this affects our current business and way of doing things. Even though writing applications for the iPhone is now incredibly easy, selling software is much more than just writing code. My primary concerns at this point are with the details of distribution.

Take a look at our Twitterrific product: we’d love to offer both free and paid-for versions. Will that be allowed in the App Store? There’s also the traditional “try before you buy” model that we’re used to having with our desktop applications. As a customer, I’d like to know what I’m getting before I put my money down. Will the App Store allow some kind of trial period?

As Apple builds out the App Store, I hope they take the approach that they have with the iTunes Store. Let me write an application “preview” that anyone can download freely. If they like it, the buy button makes us both happy. All I need to do in order to make this happen is provide two files to Apple: one is the software equivalent of the 30 second clip, the other is the real deal.

Anyone who’s been selling online for more than one major release knows how important upgrade fees are to the continued growth of a product. It drives new features and keeps the product life cycle moving along. Yet we’ve heard nothing about how this will be handled at the App Store. Will we be able to identify existing users and offer them discounts? Keeping existing customers happy is in my best interest and that of my new partner: Apple.

Update on March 10th, 2008: Another issue that occurred to me was how we’ll be able to offer the product at varying price points. For example, NFR licenses for reviewers, free licenses for contest prizes and discounted licenses for promotions like MacSanta. Again, I hope that Apple keeps our promotional needs in mind as they implement the App Store.

There has also been no indication on how we’ll be able to handle distribution during a beta test. There’s no way I’m going to release a major product without letting a significant number of users run a private version of the application. Can we get these pre-release versions of the product onto their phones without using the App Store? Will the App Store itself provide some special beta mechanism? Will we have to run our own App Store like large enterprises? Any guidance in this regard needs to happen soon, June will be here before we know it.

This is an exciting time to be an OS X developer. I feel confident that Apple will address some of the concerns mentioned above and we’ll all be happy campers by the time the App Store launches. Now, excuse me while I open up my new Xcode project…

Written on March 7th, 2008 for Development, Opinion

So you’re going to write an iPhone app…

Welcome! Many people arrive at this page while searching for information about developing iPhone applications. The ideas from this article are expanded upon in my book, iPhone App Development: The Missing Manual.

As we’re all waiting with bated breath for the release of the iPhone SDK later this month, now would be a good time to pass along some of things I learned while working on MobileTwitterrific. Read this now and you’ll save yourself some headaches when diving into the SDK.

Code reuse

Don’t expect to reuse much of your existing code. If you’re using a standard MVC design (which is pretty much inescapable if you’re using Cocoa) then about 2/3rds of the application will require major rework.

From my experience, your models and the infrastructure that support them can be reused without much effort. On the other hand, the multi-touch interface obviates the need for your existing views and controllers.

As an example, the code I use in Twitterrific to download the data from Twitter using NSURLConnection, parse the XML into an NSDictionary and store it in a sorted NSArray was largely copied without change from the desktop application. The controller and view code was all new.

Memory usage

There are some very tight limits on memory usage. You’re given approximately 64 MB of space to work with (about half of what’s available.) If you go beyond that, Springboard shuts you down unceremoniously. That combined with the fact that there isn’t any swap space where unused objects can go to rest, makes for some design decisions that you haven’t had to consider in the desktop environment.

For example, let’s explore how I manage the scrolling list of tweets in MobileTwitterrific. In the desktop version, each tweet in the list is an NSView, while on the phone each tweet is a UIView. The big difference is when these views are instantiated and freed.

On the desktop app, views are created whenever there’s a new tweet and they occupy space in memory until removed from the list. The views don’t have a very large footprint and the supporting infrastructure (NSTableView) works much more smoothly with real objects (rather than some sort of proxy.)

The iPhone, on the other hand, uses a UITableView. This subclass of UIView has delegate methods that ask for a view to display for each row in the table. Of course, you could instantiate a complete list of views and just use the row index to pull the view out of an NSArray. But think about this delegate design pattern a bit: it’s there so you have a chance to instantiate views when they are actually needed. If you have 2,000 names in your contact list, and are only displaying 8 at a time, why do you need to have 1992 views wasting memory?

Basically, you’ll find yourself being as lazy as possible when it comes to object allocation, and being as ruthless as possible when it comes to freeing those same objects.

NIB-less

Try to imagine developing a Cocoa application without Interface Builder. Try really hard. Really, really hard. Seems like a nightmare, huh?

Guess what? This nightmare will become a reality as soon as you start building your iPhone application. There are no NIBs. None.

I don’t think this is one of those “let’s skip it for version 1.0” design decisions. The process of unarchiving the objects in the NIB takes CPU cycles and memory: both things that are in limited supply on the phone. And, as I stated above, you’ll find yourself creating and destroying views much more frequently than you do in your desktop application. (And anyone who has tried to deallocate objects from a NIB knows that’s not so easy.)

Creating views, placing controls as subviews using NSRects, and then setting a bunch of properties isn’t the most glamorous coding in the world, but it’s the price you pay to run on a mobile device. Just be very happy you’re working in Objective-C and not some other crappy language, OK?

Another thing that us Cocoa developers have gotten spoiled with: bindings. You’ll find that all the normal KVC and KVO infrastructure is present, but it saves much less time when you have to establish all the bindings manually with code. If you’re like me, you’ll end up just targeting controls at methods and be done with it.

Complexity

The good news is that the user interface is much less complex. The bad news is that the user interface is much less complex.

If you have a rich desktop application with hundreds of features, you’ll find that it’s hard to pick what you absolutely need. Culling features isn’t easy, but it’s absolutely necessary.

One mental exercise that I’ve found useful is to ask myself “Will I need this feature while walking down the street or sitting in traffic?” Both are situations where there are significant distractions to the task at hand. Does the feature make it easier to interact?

Luckily, not having NIBs and bindings gives you some motivation to get rid of unnecessary complexity. When it’s not easy to add that view with hundreds of controls, you’ll think twice.

Look and feel

Don’t think that your desktop and mobile application will share any look and feel. There may be slight resemblances with regard to branding, but that’s about it. Does Safari look like MobileSafari? Sure it has the same icon, but…

While I was developing the look and feel of the MobileTwitterrific application, there were two areas which were problematic: display contrast and button placement.

Being able to read the display in all kinds of lighting conditions means you’re going to need high contrast. In your office environment, it may seem a bit garish to have a lot of dark elements on light backgrounds (or vice versa), but once you actually try to use these elements in the “real world” it makes complete sense.

This “real world” usage also makes you think about where to place controls. In one case, I placed two buttons too close to one another and found that when I used one hand to drive the UI, my thumb would often hit the wrong control by accident. When I was doing development in my office with the phone on my desk, I used two hands to control the UI and didn’t see this problem.

It’s likely that there will be a simulator in the iPhone SDK. Don’t believe for a second that you’ll be able to use this simulated device for all your development and testing. You have to literally live with the application.

That’s all for now. Let’s go back to waiting impatiently.

Written on February 11th, 2008 for Design, Development, Observation

Don’t feed the raccoons

Piracy is a fact of life for software developers. There are always douche-bags who think they should get your hard work for free. Sometimes this takes the form of distributing serial numbers, sometimes it’s kracking the application to eliminate the checks. I’ve come to accept this as part of running a software business.

Recently, however, a certain individual has made a claim that Twitterrific has a security vulnerability that allows it to be modified and not display ads. That is a very serious claim; not just for my application but for all Cocoa applications. And it puts my good name in a bad light.

I am not going to link to the individual in question since it’s likely that these claims are attempts to generate traffic (link baiting.) Instead, I’ll link to a salient tweet by my friend John Gruber.

Without getting too technical, the claim is that a tweet received by Twitterrific causes code to be executed. That code modifies the application and eliminates the ads. If true, this would mean that there is a security vulnerability in the Cocoa frameworks that process XML (NSXMLDocument) or text (NSString). A security vulnerability of this type would have broad implications: applications like Safari, NetNewsWire, and anything else that processes XML or text would be vulnerable to malicious payloads. A vulnerability of this magnitude should be reported directly to Apple, not just posted to some shitty little web log.

Fortunately, I have yet to see this exploit actually do anything. Nor has the person making this claim produced any source code showing how it’s done. (Why does a vulnerability have to be released under the GPL anyway?)

All I can assume at this point is that Marc Fiszman is not only a jackhole, but a very dangerous one: and not for the security exploit, but for the libel.

My partner, Dave Brasgalla, has a phrase for this kind of situation: “Don’t feed the raccoons.” Feeding these individuals only makes them want more food and leads to unnatural behavior, malnutrition and disease. So my best course of action at this point is to clear my name and ignore this jerk.

There is some good to come out of all of this: I’m reminded that for every idiot on the Internet, there are hundreds of individuals that are kind and supportive. The comments and registrations we’ve received in response to this incident are much appreciated. I thank you all.

Written on December 28th, 2007 for Advice, Development

Put your content in my pocket

Sometimes it takes awhile to fulfill a promise.

One such pledge was made last century to my good friend Jeffrey (he was only a prince at the time.) I said that I’d love to write something for his fledgling mailing list: A List Apart. This past month, I finally got around to writing that piece: Put Your Content in My Pocket.

If you’re visiting this site for the first time, you might be interested in the original article that prompted our collaboration. I’ve also written some articles that explore some of the problems, performance and less than obvious features on the iPhone. For the hard core geeks, there are also some explorations into the specifications.

So enjoy your visit and please make sure to join in the discussion forum at ALA if you have any questions or concerns about my article. Thanks!

Postscript: I mentioned some nonsense in the article: here it is, the Eric Meyer Memorial iPhone Blocker.

Written on August 27th, 2007 for Design, Development, Personal
Newer
Older