Category: Observation

Bugging

It’s pretty clear that the App Store is a huge hit. We’re all loving the ability to customize our iPhones and iPod touches with cool new software!

But with any big new release, there are problems that didn’t pop up while beta testing. As iPhone developers, we’re finding ourselves in a position where we can’t help customers who are encountering these issues.

Let’s take a couple of examples with our app Twitterrific. My friend Jeffrey Zeldman reports a problem where the application would crash just after launching. Another developer friend, Alex King, is having a problem with an authentication alert appearing when it shouldn’t. As a conscientious developer, I want to help these people and fix these bugs. The problem is that I have no tools to do so.

Jeffrey’s problem appears to be something with data that is stored on the phone. Alex’s problem is likely to be an issue with how data is being loaded from the network (from Twitter.) Note that I say “appears” and “likely”; I don’t know for sure, and that’s what is bugging me.

The first problem is knowing where the crash is occurring. The iPhone generates a crash report that automatically gets synced with iTunes. The crash report is stored in ~/Library/Logs/CrashReporter/MobileDevice. Unfortunately, this crash report is “raw” and developers don’t have tools to make it easy to understand (e.g. “symbolicating” crash reports only happens when they are loaded through Xcode’s device organizer.)

And even if I could interpret these crash reports, I’d be faced with another problem. There’s no way to gather additional information about what’s happening on Jeffrey’s and Alex’s device. With a desktop application that’s acting up, developers will often add logging and other kinds of output that track what is occurring around the time of a crash or other misbehavior.

In Jeffrey’s case, I would want to dump out the internal database that’s in use at the time of the crash. For Alex’s bug, I’d want to track the network requests to Twitter and the corresponding response. It’s easy to add this logging to Twitterrific, but the only way to retrieve the results is if you are a registered developer. There is no way I’m going to ask Jeffrey and Alex to spend $99 and install Xcode just so I can collect some debug output.

Assuming that I could get some debugging output, the next step in resolving these problems would be to create a special build with a proposed fix. After having Jeffrey and Alex verify the fix, I’d distribute that same build to a larger group of testers so that we could test for regressions (e.g. we don’t break some functionality in the process of fixing something else.)

The big problem here is that the only way to install software on an iPhone or iPod touch is with the App Store. There are also no provisions for beta testing. Without the ability to sign code, there is no way for a user to get code onto a device: most users fall into this category.

The only way to “test” a fix is to release the changes to tens of thousands of users. It’s the developer equivalent of playing Russian roulette.

(Note: there may be workarounds to some or all of these problems, but with the NDA in place, it’s difficult for developers to share their experiences and solutions.)

Apple has done an fantastic job with the tools that let us develop iPhone software. That’s clearly evident from the fantastic work we’ve seen displayed in the App Store. Unfortunately, the tools that developers use to analyze and debug problems are sorely missing at this point in time.

It’s our hope that this essay will do two things:

  • As a user, please be extra patient when developers tell you that they are working on a problem—it’s hard work at the moment and the time it takes to resolve an issue will be longer than with a desktop application.
  • We hope that bringing these shortcomings to Apple’s attention will help them address the issues and improve the iPhone SDK.

Until then, these problems will be bugging us all.

Updated July 15th, 2008: If you’re a developer, please feel free to submit a duplicate (“me too”) bug on the following Radars:

Updated July 16th, 2008: After fixing bugs for customers, Brent Simmons notes that there are frustrations with the final part of the development cycle: making public releases.

Updated July 23rd, 2008: Brandon Sneed has discovered some techniques for doing remote debugging of iPhone applications.

Updated August 6th, 2008: We don’t have to play Russian roulette anymore.

Updated August 8th, 2008: I discovered how to “symbolicate” crash logs.

Updated November 10th, 2008: Getting preferences and data from customers who are having problems just got a lot easier.

Written on July 14th, 2008 for Development, Observation

Brain surgeons

Unless you’ve been stranded on a remote Pacific isle, you’re no doubt aware of the current furor over third party iPhone applications not being able to run in the background. To be blunt, I’ve never seen so many experts without a fricken’ clue. If you haven’t written code using the jailbreak tool chain, your opinions on the iPhone SDK, based entirely on what you see in a simulator, just aren’t relevant. You might as well be explaining the nuances of brain surgery.

As someone who has been involved in iPhone development for the past six months, please let me offer you a healthy dose of reality.

Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power.

(Those of you under NDA with the iPhone SDK should take a look at the documentation for Core Location. After reading about how it should be used, you’ll understand why getting your location in Maps and similar applications is only done on an “as needed” basis.)

And right about now, you’re thinking “But I’ll be smart about how I use the hardware.” Sorry, bucko, but you’re the exact reason why we don’t have background processing in the current SDK. You’re living in your own little dream world.

What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding.

In my opinion, such a scenario is quite likely. As a satellite device, the iPhone requires contact with other machines to do interesting things. Periodically hitting the network is the primary reason that developers want to run in the background.

Some have stated that Apple is limiting innovation. My opinion is that they are helping us from collectively shooting ourselves in the feet.

It takes several months of actual iPhone development before you eventually realize that the iPhone requires a completely different mindset. Until that happens, you’ll make assumptions based on desktop experience, and that in turn will lead to a lot of bad designs.

For what it’s worth, I think Apple will address this issue in the future. I can imagine a solution based on a plug-in (bundle) architecture that lets your application do things when the phone decides it’s a good time (not when you decide it’s a good time.) If the radios go on because you’re checking Mail, then you get a “network active” notification and a chance to run some short-lived TCP/IP connections. If you take too long, you’d get killed, much like Safari does with Javascript that runs too long.

Do I expect such a sophisticated system to be available in a beta of version 1.0? Hell no. And neither should you.

Written on March 16th, 2008 for Design, Development, Observation, Opinion

Thoughts on downloads

It occurred to me the other day, that the music industry and software developers are beginning to have a lot in common. The proliferation of digital content, both legal and illegal, has radically changed the way people purchase music. But to those of us who have been distributing our work via the Internet since day one, downloads are not a big deal.

Let’s take a look at how software developers do business and see if it sheds any light on the music industry and their period of transition.

The thing that drives software sales is the notion of “try before you buy.” Gone are the days where you walk into a computer store, scan the shelves for an application, purchase a disk to take home, and pray that it solves your particular problem. Now, every customer has the expectation that the application prove its worth before they hand over their money.

Gone too are the days when you walk into a music store. Unfortunately, the record industry hasn’t realized that this is a good thing. They’re still clinging to the notion that your purchase should be based on nothing more than a 30 second sample. Like software, you have to spend a little time with a song or album before you discover how much you like it.

Of course there’s a need to protect your work so that a potential customer will eventually make the purchase. People are lazy, so you need to find a way to create an incentive to buy.

Some software is distributed by leaving out features until a serial number is entered. A similar technique can be used with music. A great example is Team Love Records which made downloads available for the Rabbit Fur Coat album by Jenny Lewis with The Watson Twins. Every track could be freely downloaded except for one: the track getting airplay (“Handle Me With Care”.) This approach worked very well for me—I knew the hit track from the radio and found out that I loved the other tracks just as much. And, in the end, I was a happy customer.

A similar thing happened with Bob Dylan’s Love and Theft album. A friend of a friend of a friend got ahold of a leaked copy of the album. I found it interesting that a couple of the tracks had really crappy sound: someone made a “mistake” and encoded the tracks at 32 Kbps. You could follow along and get the gist of the song, but I was very happy to “upgrade” on the day of release.

Another approach we’ve taken in releasing our software is to provide additional benefits after a purchase. This can be access to support, a special website or even new features or content. The record industry has done the same thing.

A couple of recent releases come to mind: Cat Power’s Jukebox album and Neil Young’s Live at Massey Hall. The incentive with the Jukebox album was the inclusion of an extra CD with four additional songs. Similarly, the Live at Massey Hall package came with a DVD containing footage from the concert. Both were things I wanted, so the decision to buy was easy.

For artists that you love, getting a complete set of their works is important. If I had been given a free copy of the “basic” CD, I still would have “upgraded” to get all the songs and/or video.

Now, let’s look at one thing that works for software distribution, but isn’t going to work for music: the notion of a time limited demo.

We have a reliable clock, a local file system to record usage, and other mechanisms that make tracking relatively easy. Of course, these things can be overridden or disabled by dishonest users, but the vast majority of honest people make up for it. As developers, we have also learned to encourage users towards the purchase: making demands does not work. Pissing people off will turn them into pirates, not encourage them to buy.

A MP3 file doesn’t have mechanisms for tracking. And we all know how the attempts to add them with Digital Rights Management has gone over with consumers. That’s because it’s a system based on demands: you must be authorized.

Finally, the best thing for business is to make sure you have the best product available. That’s both the beauty and the challenge of any “try before you buy” system. Good products win, bad products are quickly forgotten.

I suspect that the root of the music industry’s problem is this: they have been able to produce sub-standard product for many years. I know there are many albums in my collection that consist of few great tracks along with a bunch of crap that I’d rather not listen to.

And the iPod, which makes single tracks viable because you don’t spend all your time moving physical media around, allows people will buy only the product they find interesting. If the music industry wants to make more money, they need to make something besides one big hit plus filler. Can you imagine buying a software product that had one feature you really needed and 99 others that were worthless? The value is in the whole, not the individual parts. If you make compelling albums, people will buy more music from the artists they love.

In the end, however, I suspect that the large music companies will end up in a similar position as the large software companies. They will have the blockbuster product/artists with a lot of recurring revenue from each new release.

But the most interesting part of this ecosystem will be the independents. The people who have a smaller, but much more loyal following. The people who listen closely to these fans and realize how important they are to their creative works. The people who feel the joy of a customer telling them they rock.

That’s the beauty of this thing we call the Internet: it’s a two way street. And all it takes is a web page to start that conversation.

Written on February 17th, 2008 for Miscellaneous, Observation

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

What the iPhone specs don’t tell you…

The iPhone technical specifications mention nothing about how much RAM is included nor how fast the CPU is running. Now that I have a toolchain, it was a simple task to take some code from iPulse to investigate.

Note: Apple has obviously not documented the system level APIs that I’m using to extract this information, so take these numbers with a grain of salt. Personally, I doubt that they would bother to make these low-level functions report erroneous information just to protect some consumer spec sheet, so it’s likely that they’re close if not exact.

First, let’s start off with memory. Calling host_statistics() with HOST_VM_INFO returns a count of the number of memory pages in use (the “vm_stat” tool at the command line does the same thing.) Totaling these counts shows that there are 19,500 pages of memory with each page being 4096 bytes. That’s 78,000 KB or 76.2 MB.

Another way to determine memory size is by calling sysctl() with CTL_HW and HW_PHYSMEM. This results in 121,634,816 bytes or 117 MB being reported for physical memory. Similarly, user memory is reported as 93,605,888 bytes or 89.3 MB—close to the 76.2 MB reported by host_statistics(). These calls are equivalent to using “sysctl hw.physmem” and “sysctl hw.usermem” from the Mac OS X command line.

None of these numbers are the nice round powers of 2 that we’re so accustomed to. I suspect that there is some kind of memory partitioning: something like a graphics chip could be using 11 MB of memory and that combined with the 117 MB of physical memory would bring the RAM total to 128 MB.

Now let’s take a look at the CPU speed. Again, sysctl() is our friend, this time using CTL_HW with HW_CPU_FREQ and HW_BUS_FREQ. The results of our test show that the CPU is specified at 400 Mhz with a bus frequency of 100 Mhz.

There have been various hardware reports that place the ARM chip’s frequency above 600 Mhz. Maybe sysctl() is lying to us, or maybe the CPU is clocked down to give improved battery life. Only Apple knows that for sure.

For those of you who care, the source code used for the tests is available.

Written on August 21st, 2007 for Observation
Newer
Older