Year: 2009

Open sesame

Here’s a simple little script that saves me a lot of time:

#!/bin/sh 

if [ -z "$1" ]; then
  echo "usage: $0  [ Preferences |  ]"
else
  base=~/Library/Application\ Support/iPhone\ Simulator/
  apps=Applications
  app=`ls -1td "$base/"*"/$apps/"*"/$1.app" | head -1`
  if [ -n "$app" ]; then
    dir=`dirname "$app"`
    if [ "$2" = "Preferences" ]; then
      open "$dir/Library/Preferences"
    else
      open "$dir/Documents/$2"
    fi
  fi
fi

Put this script somewhere on your PATH and name it opensim. Use it to find the most recent application loaded in the simulator and open the Preferences, Documents or a named document in the Finder.

For example, to open the current Documents folder for an application in the iPhone Simulator, just do this:

$ opensim Thunderbird

To open a document within that folder, you can do this:

$ opensim Thunderbird chockenberry.db
$ opensim Thunderbird accounts.plist

You can easily get to your preferences folder with:

$ opensim Thunderbird Preferences

Notice how I haven’t mentioned a GUID in this essay? That’s the feature…

Written on March 3rd, 2009 for Development, Miscellaneous

Trendy

If you’re reading my essays, it’s likely that you’re selling some kind of software on the Internet. (Or soon will be.)

To be successful at this endeavor, you need to monitor your sales and plan development around the revenue. Ask anyone who’s had success with a software product, and I can guarantee you that they have some kind of metric that tells them how well they are doing.

What I’d like to do today is share one of my favorite methods. But before I do, let me share some advice that will help you understand why this tracking scheme is so effective.

If you’ve released a product, you no doubt have witnessed the “first day spike.” It’s one of the great things about doing a release: you find that people really do love your work.

But there can be a problem. Typically, that initial spike is followed by an exponential curve: every month you’re making half as much money. And even though your income is less and less each month, the support load from existing and new customers stays fairly constant. You’re working just as hard, but earning less.

So how do you work around this? As you would in any other business: by planning ahead.

As software developers we often fall into the “just one more feature” trap. We want a 1.0 release to be awesome, and that one more thing will only take a day or two, and people will love it, so why not?

Because that awesome feature could be a very good thing to generate buzz and sales for a 1.1 or a 1.2 release. And by not “doing it all” in the first release, you get your product to market faster. You’ll be making money while you implement that cool new feature.

And holding back can have another advantage: you might find that your users want something different than what you had planned. Their input can often change your idea, so don’t waste time doing something without feedback.

So when do you know that it’s a good time to do a 1.1 release? A general rule of thumb is 30-90 days after your 1.0 release. On the day you release your 1.0, you should have some code already in the works for the 1.1 release. Give yourself a head start on the next release, because you’ll find those first 30-90 days are consumed by customer support and go by very quickly.

(I can also guarantee that you’ll have a 1.0.1 release because of some stupid little bug you overlooked. So make sure you plan ahead for that, too.)

With all this in mind, I present a simple way to visualize your release cycles by graphing trends of averaged daily sales:

The graph shows four hypothetical products and their sales. The Y axis shows how much the product earned. The X axis shows increasingly short time intervals. To plot each Y value, you just take the total amount sold in that period and divide it by the number of days. The intervals were chosen because they’re nice approximations of monthly, bi-monthly, quarterly, bi-yearly and yearly cycles.

Let’s say the Y grid lines are at $10, $20, $30 and $40 earned per day. The red product has sold about $2.50 per day over the past month, and about $10 per day over the past year. It’s a product that’s definitely in need of a version bump. An update should push it over $10 per day in the 30 day interval.

The gray product shows how a new release looks. Instead of seeing a spike, you’ll see the averages for all intervals go up (with the most change at the most recent intervals, of course.) You’ll also see the most recent averages go up as a result of ads, reviews and other good PR. As time goes on, the 30 day average will eventually drop. When it gets below the 60 or 90 day average, that’s a good time to do a release.

The goal is to end up with a product like the green one. For the most part, it trends upwards. You’re doing things right.

Finally, this graph also shows products that you shouldn’t spend time on. The lavender product isn’t performing as well as the others. Your time is better spent on things that are going to generate more revenue.

In case you’re wondering how I generated these graphs, it’s proprietary Ruby on Rails code that reads our financials and feeds them to XML/SWF Charts. The information in these graphs will change frequently: you’ll want to find a way to automate the collection and processing of your own sales data.

I’ve been talking with Dylan Bruzenak about incorporating this trend graph into AppViz. Hopefully we’ll see it in a future release—make sure to let him know if you’d find it helpful. (And if you’re not already using AppViz to track your iTunes sales, pull your fricken’ head out and start using the trial version.)

Who knew that accounting could be so trendy?

Written on March 2nd, 2009 for Advice, Business, Observation

Sharing iPhone projects

The latest version of Xcode has a “feature” that prevents you from specifying a wildcard name for the Code Signing Identity. (This feature does make it easier for new developers or people working alone, so I’m not going to write a Radar for this behavior.)

When you have multiple people working on an iPhone project, this behavior is very annoying because every developer has to change the Code Signing Identity before they can run the latest version on the device. Here’s a typical scenario:

  1. I set the Code Signing Identity to “iPhone Developer: Craig Hockenberry” and do my device build. Everything is wonderful and I check in a new SekretApp.xcodeproj/project.pbxproj.
  2. I add some cool new features to SekretApp and I want Anthony Piraino to try them out. Anthony updates his working copy to the latest version.
  3. Anthony has to change the Code Signing Identity to “iPhone Developer: Anthony Piraino” so that he can do the device build. He does, and everything is wonderful.
  4. Anthony then adds some new files to the project. He checks in a new SekretApp.xcodeproj/project.pbxproj as a result of this change.
  5. I need these new files, so I get the latest version of the project. Unfortunately, this latest version has Anthony’s Code Signing Identity in it. Everything is not wonderful.
  6. Lather, rinse, repeat.
It gets even more fun when you have merge conflicts. The solution to this problem is to get rid of the individual developer names in the project.pbxproj file.

Before you begin, make sure that you’ve closed the Xcode project you’re going to be updating. You are going to be modifying files used directly by Xcode, so things can get screwed up if you make changes while the project is alive.

The first step is to locate SekretApp.xcodeproj in the Finder and right click on the file. Select “Show Package Contents” to reveal the project.pbxproj file.

Now, open project.pbxproj with your favorite text editor and look for the Code Signing Identity. It will look something like this:

CODE_SIGN_IDENTITY = "iPhone Developer: Craig Hockenberry";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: Craig Hockenberry";

Change the identity to look like this:

CODE_SIGN_IDENTITY = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer";

You also need to delete the embedded provisioning profiles. These are normally located a few lines below the CODE_SIGNING_IDENTITY:

PROVISIONING_PROFILE = "DEADBEEF-1337-FACE-F00D-EA7A7BADCAFE";
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "DEADBEEF-1337-FACE-F00D-EA7A7BADCAFE";

(And, yes, I felt very lucky the day I was assigned that GUID.)

Note that there will probably be more than one CODE_SIGNING_IDENTITY (depending on your Project and Target settings.) Make sure to search through the whole file.

After making these changes, re-open the project in Xcode, clean it, and do a device build. If you make it through the CodeSign build phase, you’re good to go. Now all you have to do is check in the new version of project.pbxproj.

This trick works because the underlying codesign utility searches your keychain for a match. From the SIGNING IDENTITIES section of the manual page:

To be used for code signing, a digital identity must be stored in a key-chain that is on the calling user’s keychain search list. The identity is located by searching all such keychains for a certificate whose subject contains the identity string given. If there are multiple matches, the invocation fails and no signing is performed.

Since you and everyone else on your team has only one certificate with the pattern “iPhone Developer”, this search works correctly and no one will need to update the project settings after they check out the latest version of project.pbxproj.

And everything will stay fricken’ wonderful.

Written on February 26th, 2009 for Advice, Development

Bootstrap

A lot of people stumble upon this website because they’re looking for information about developing applications for the iPhone. If this is your first time here, welcome!

I have been developing applications for the iPhone since it was released (using both the Jailbreak and official SDK.) My company is currently selling several applications in iTunes. I also have many years of experience with the underlying technologies on the device (Cocoa, the predecessor to Cocoa Touch.) I’d like to share some of my experiences and give you some pointers that will help get you started.

The first thing you need to know is that learning how to develop applications for a mobile device isn’t easy. But it’s worth the effort, ask any seasoned iPhone developer about seeing their work run on the device for the first time: it’s fricken’ amazing.

Get a Feel for the Device

Some of you may want to target the web with your application. If this is the case, you’ll want to start looking at a series of articles I wrote for A List Apart: Put Your Content in My Pocket (Part 1 and Part 2.)

Even if you’re going to be writing a native application, knowing how to develop web pages for Mobile Safari will be helpful. A product information website and other ancillary information about your app will work best when your new customers can view it on their device.

Working with the web is also a good way to start understanding how a mobile device is so much different than a desktop. Using HTML and CSS can be an excellent way to begin thinking about your application design and doing prototypes—we’ve used this technique in many of our own products.

After getting a feel for the web capabilities of the iPhone and iPod touch, you’ll want to look around the Apple Developer Connection (ADC) site for more in-depth technical documentation for developing web applications.

Which leads to our next topic…

Buy a Mac

There’s no two ways about it. If you’re going to develop iPhone applications, you’re going to do it on a Mac. The whole toolchain is Mac-only: you can’t do it in Visual Studio or Eclipse or anything else that runs on Windows.

Don’t think that this is some evil plan by Apple to make you use a Mac. It’s no more nefarious than Microsoft requiring Mac developers to purchase Visual Studio in order to develop Windows versions of our products.

Buying a Mac can be an expensive proposition: if you’re just getting started and on a shoestring budget, here’s some advice on doing it on the cheap:

  1. Buy a used machine. A lot of perfectly good hardware can be found on Ebay. New models of the Mac Book Pro were recently introduced, so many people are selling hardware after they upgrade. This older hardware is perfectly fine for doing iPhone development: the apps you’re going to develop are small and compact and don’t need a lot of processor power to build and test.
  2. Buy a Mac mini. Even though you’re buying new hardware, you’ll save money because you’re supplying your own display, keyboard and other peripherals. If you’re like me, you have plenty of this stuff lying around.

If you’re having a hard time justifying the hardware expenditure, remember that you can run Windows or any other x86 based OS on this machine.

The only thing to keep in mind as you’re buying hardware: make sure that the Mac has an Intel processor. The development tools won’t run on the older PowerPC processors.

The good news is that once you buy the Mac, all the development tools are free. Think about all the money you spent buying Visual Studio and MSDN and you’ll feel much better about spending a thousand bucks for the hardware :-)

So how do you get all these free development tools? Read on…

Join Up and Download

There are two things you’ll need to do before you can start writing applications: sign up for ADC and register to become an iPhone developer.

Neither of these things costs money. Everything is free until you want to put your code onto the device. At that point, you’ll need to pay $99 to get a certificate that allows you to sign the binary and put it on the device.

The first step is to create an Apple ID; it’s an email address that you’ll use to access the developer site. You may already have one for your iTunes account. These pages guide you through the sign-up process.

Once you have an application that you want to test on a device and distribute on the App Store, you need to apply to the iPhone Developer Program.

After you have the keys to the ADC kingdom, there is a wealth of additional information available…

Sit Back and Watch Some Movies

Before you start diving into coding, I highly recommend spending a few hours watching the “Getting Started Videos” in the iPhone Dev Center.

(Note: if the links on that page are grayed out, it’s because you’re not logged in yet. Sign in using the Apple ID that you obtained above.)

As I said earlier, I came into iPhone development with a fairly extensive background in the technologies used on the device: even so, I learned a lot from these videos. Make sure you take advantage of this valuable resource.

And make sure you do it before rushing off and hacking on code…

Start Playing

If you’re like me, you’ll want to start playing around with code as soon as possible. The best way to do this is with the excellent sample code that Apple provides on its developer site.

(Note: Again, that link is behind a login, so you’ll need an Apple ID before you can download the samples.)

Since you’re new to iPhone development, it’s likely that you’ll have some problems going beyond a simple build and run of the projects you download. (If you’re having problems running the sample projects, make sure that you have “Simulator” selected in the drop-down menu at the top of the project window.)

When you start to get confused by Xcode or the syntax of Objective-C, you’ll want to move onto the next step…

(Note: I said “when”, not “if”. Trust me on this.)

Crack a Book or Two or Three

You’re lucky that there are a lot of great books about iPhone development available now. It’s a luxury that those of us who worked on iPhone apps during the NDA are very jealous of :-)

If you’re just starting out, I’d highly recommend Beginning iPhone Development: Exploring the iPhone SDK by Dave Mark and Jeff LaMarche. The best thing about this book is the step-by-step approach it takes to working with Xcode, Objective-C and the iPhone APIs. They’ll lead you through the basics and you’ll be building your own apps in no time at all.

As you get more comfortable with the tools and AppKit/UIKit frameworks, I’d recommend you take a look at Erica Sadun’s iPhone Developer’s Cookbook: Building Applications with the iPhone SDK. This book presumes a bit more knowledge about the SDK, but is a very handy reference both to the official and unofficial APIs. (Go ahead and play with the undocumented features, but do not use them in an application that you want to put on the App Store.) You may want to read my in-depth review of this book.

Since you’re going to be working with Cocoa Touch on the iPhone, you’ll also want to start thinking like a Cocoa programmer. Every great iPhone and Mac developer has nothing but wonderful things to say about Cocoa Programming for Mac OS X by Aaron Hillegass. Don’t be misled by the “for Mac OS X”—you’re going to be working with classes and design patterns that are identical on both platforms. You’ll also have a Mac that you’re using for development, so building the samples and test code isn’t a problem.

If you have previous development experience with C, C++ or Java, you’ll want to read this mailing list post by Erik Buck that enumerates some of the difficulties that you’ll have coming up to speed with Objective-C and Cocoa. Make sure to take some time and read the replies to that post: many of the people commenting on that post are fellow developers whose work I hold in high regard.

And while we’re talking about Erik’s writing: there are a lot of experienced Cocoa developers waiting for this book. You won’t need it for awhile, but you will need it.

As you’ve probably figured out by now, this whole learning process is going to take awhile. I’d also be remiss if I didn’t mention that there is a pretty steep learning curve. I’ve built products in assembly code, BASIC, C/C++ on Unix, X11, Win32, Java and a whole bunch of other technologies. Objective-C and Cocoa weren’t the easiest to pick up, but they’re definitely the ones that I plan on sticking with. Try not to get discouraged: once you “get it” developing with this language and framework is a joyous experience.

Other Resources

I’ve been coding long enough to remember a time when we didn’t have the Internet as a source of information. Thank God those days are behind us: here are some online resources that I use often:

  • cocoabuilder.com There are two mailing lists where other Cocoa developers and Apple engineers hang out: Cocoa-dev and MacOSX-dev. The archives for both of these lists can be searched using CocoaBuilder: extremely handy when you come up against a problem that someone else has already solved.
  • cocoadev.com A wiki that is maintained by the Cocoa developer community. This is the first place I look when I need to learn some new part of the framework. As an example, check out this entry about the string class.
  • cocoadevcentral.com A beautiful site maintained by Scott Stevenson. So many great tutorials and links to other sites and blogs that focus on Cocoa development. Spend some time exploring those links and you’ll learn a lot about our developer community.

Apple recently launched another great resource: Developer Forums. It’s currently in beta, but is still an excellent place to ask fellow developers questions about iPhone SDK topics.

But wait, there’s more!

You’ll find a lot of iPhone content on this site. Here’s proof.

To save you some time, here are some quick links to some of the more popular essays on this site:

Memory management issues (part 1.)

Memory management issues (part 2.)

How to run a beta test.

Extracting information from crash reports.

Final release testing.

What to expect on release day.

Debugging with customer backups.

How to deal with expired certificates.

And, of course, source code for you to use in your own projects:

[REDACTED]

Fancy UILabels

Or just have fun with:

Lights Off

And if you aren’t already completely bored with me crapping on about the iPhone, there are videos.

Conclusion

I hope this information has been helpful and gotten you started in the wonderful world of iPhone development. Don’t forget to subscribe to this site’s RSS feed since I have a lot more I’d like to write about :-)

Good luck!

Written on February 19th, 2009 for Development, Miscellaneous, Observation, Opinion

Raising prices

Many of you are starting to realize that a ringtone price point does not sustain a business. I’m with you.

Lately, I’ve been thinking about ways to make higher prices more palatable to customers. Several discussions at Macworld kicked off these thoughts, and a recent tweet by Justin Williams made me realize that a lot of you could benefit from these ideas. Hopefully, this short essay will help us all make it through the App Store gold rush.

The first thing to do is think about a “Lite” or ad-supported version of your application. Let customers find out how great your work is by giving them a free copy.

Based on our dealings with Apple Developer Relations, there are two basic rules you need to follow when making a Lite version of your product:

  1. The product must be fully functional. The application must stand on its own and be useful.
  2. The user should not be inundated with “up-sell” reminders. Showing BUY NOW every 5 minutes is the quickest way I know to get rejected by the App Store.

The hard part, of course, is how to limit functionality. For many games, it’s pretty easy: you just limit the number of levels the user gets to play for free. A similar technique can be used for applications that track data by limiting the number of records that can be added.

But there are many applications that don’t fall into these neat categories. One such application is our own Frenzic. Due to the game’s open-ended nature, there’s not much we can do to set “levels.” Until there is some kind of demo mechanism on the App Store, we’re stuck with advertising, good reviews and word-of-mouth.

One interesting case is James Thomson’s PCalc application. I love this calculator, and found his analysis of what to keep and what to remove very interesting. You should note that this effort paid off: his sales doubled as a result of the Lite version.

Free applications that are supported by ads are also a viable alternative. We’ve seen a steady stream of sales with Twitterrific because customers that use the free version know exactly what they are going to get for their $10. The main consideration with this approach is thoughtful integration of the ads into the user’s activities. Annoying a user with ads is a good way to get deleted from the home screen.

Using this model, some people will never buy your application. And that’s OK, and maybe even better, because you’ll make your money back over the long term. I was not surprised when Shazam started showing ads. They spent a lot of time and money developing their application and back-end infrastructure. When millions of people are using your product and seeing ads every day, that revenue can be substantial and easily pay for development costs.

Another thing I’ve noticed is that iPhone applications that have a tie-in to a Mac desktop product can command a higher price. If you have group of users who already love what you do on the desktop, selling those users mobile functionality is easy. Take a look at Things and OmniFocus as examples: the desktop versions of these apps sell for $50 and $80, respectively.

The iPhone version of these products sell for $10 and $20. From a customer’s point-of-view, that’s not 10 times more expensive than the typical ringtone app. Instead, it’s a small price to pay for mobile access to their desktop data. Conceptually, the 20-25% fee is just another upgrade cost.

Finally, you should take a look at vertical markets. I love the prices for Medical applications in the App Store. There are a lot of apps with price tags over $10 (some are even over $100.) Again, the customer for these apps is not thinking so much about cost, but rather of the value provided.

When businesses start to see the capabilities that an iPhone applications gives a distributed workforce, vertical markets could become quite lucrative. You may only have hundreds or thousands of customers, but if you’re earning hundreds of dollars from each of them, that’s a viable business.

In closing, I’ll pass on a small reminder that an Apple employee gave me during Macworld: the App Store has only been live for a little over six months. Last month’s 25 year anniversary of the Mac should also remind us that this new market for our products is still in its infancy. Yes, it’s a wild ride at the moment, but if you think about your costs, customers and revenue streams, I think you’ll enjoy a very long journey.

Written on February 16th, 2009 for Observation, Opinion
Newer
Older