John Gruber – On the Behavior of the iPhone Mute Switch
Andy Ihnatko – Unmuting on The Mute Question
Marco Arment – Designing “Mute”
Guy English – Mute This

Both sides of the argument have valid points-of-view. This really is a situation with no right answer given the current mechanisms.

That got me thinking that there might be something missing that’s causing this ambiguity. I’ve come to the realization that this is a problem bigger than just alarms going off at inopportune moments. What we really want is for the devices in our pocket to behave differently depending on where they’re physically located.

Let’s imagine a new feature in iOS called “Homebase”. A user would be presented with a simple UI that lets them select a location that’s a “safe” environment. After the setup is complete, your Homebase would be recognized by GPS coordinates and/or available Wi-Fi networks. The important thing here is that the user gets to define where they feel safe with their device.

With that information developers can make smarter decisions:

• Alarms that go off while the mute switch is on make noise at Homebase and just vibrate elsewhere. There’s no need to worry about alarms going off in public places (such as concert halls) and you won’t oversleep when you go to bed with a mute switch on.
• The lock screen doesn’t need to display a Passcode lock at Homebase. People who use the Remote app with their Apple TV will no longer be annoyed by an unnecessary security precaution, nor will folks forget to turn their Passcode lock back on when they leave for the local bar (where they’re certain to get a Poopin’ tweet.)
• Apps, like Find My Friends, could use cached Apple ID credentials at Homebase and avoid asking the user for them over and over and over and over again.

Of course, this feature is needed most by people who don’t even know the Settings app exists. It’s my opinion that if developers are careful with this additional knowledge about the user and device, default behavior can be adjusted appropriately without additional confusion. It’s analogous to the Energy Saver on the Mac: people don’t question why the screen dims when the power cord is removed because it just “makes sense”.

The examples above use Apple’s own apps, but the Homebase status would be useful for third-party developers, too.

If you’d like to see something like Homebase in iOS, please be sure to file a duplicate Radar.

The first warning sign was after starting the Installer: I was prompted for an administrator password indicating that this software wanted to run from protected areas of my system. Being a developer, I immediately dug into the installer scripts and configuration files to see that the app is placing items in the Rapport/bin, PreferencePanes, LaunchDaemons and LaunchAgents folders of the main system Library folder. The launch folders indicate that the software will be run whenever my Mac is restarted and will be able to do things a normal user would not (because of elevated permissions.)

I placed my security concerns aside as I need to access my bank website, so I went ahead with the installation. Afterwards, I was directed to a web page describing the new software.

Again, as a developer, my first thoughts were suspicious ones. From experience, I know that it’s not easy to modify Safari’s user interface in the way that Trusteer was doing. My guess that there would be a new, always active, background process was confirmed by the presence of “rooksd” in my process list.

However what happened next really opened my eyes. Safari crashed.

Of course that, in and of itself, isn’t the end of the world. But I was surprised to see a new library named RapportUtil1 while looking at the Safari crash report. It was pretty clear that the new Trusteer software caused the crash. But how?

As a longtime Objective-C developer, I know a thing or two about “method swizzling“. In a nutshell, this allows a developer to replace the functionality of code they don’t have direct access to (typically in the system or other frameworks.)

Seeing “_nsapplication_sendEvent_override” tells me that Trusteer is using this technique to change the behavior of Safari. The function that is being affected is -sendEvent: — the part of every Cocoa application where mouse, keyboard and other input is routed.

Method swizzling is a dangerous activity. You have to make assumptions about how some other code, that you’ve never seen, is behaving. You also need to think about how that code might change in future versions. There are extreme cases where this technique can be effective: overriding the default behavior of my web browser is not one of them.

It’s clear that the folks taking control of my browser aren’t as clever as they think. Do you see a common theme when you search Apple’s discussion forums for “RapportUtil1“?

Even more troubling is the method being overridden: every key press or mouse movement is first being sent to Rapport and then forwarded onto Safari. Since this happens often, the intruding software can do pretty much whatever it wants, whenever it wants. And remember that part of this package is running with elevated permissions in the background.

After mentioning my findings on Twitter, I got back some very interesting replies. Graham Lee (@iamleeg) pointed out that I’m not the first developer to question the technical merits of this software. But then Peter Hosey (@boredzo) dropped the real bomb. Trusteer tacitly admits to recording my password. That’s easy to do when you take control of -sendEvent:.

Essentially, my bank is asking me to install is a keylogger. Just so they can warn me not to use the same password on suntrust.com and playboy.com.

Hopefully, the engineers behind Rapport are smart enough to be using hashed passwords rather than clear text. And hopefully none of the personal information Safari has access to is being forwarded to the Trusteer servers. And hopefully they’re not recording how many times I visited playboy.com last month. But that’s beside the point, because as a closed source product, no one can audit their activity. That’s not true with Safari.

Oh, and there’s one other thing: the Rapport software isn’t supported on Lion. One of the tenets of method swizzling is to test your software early and often with any new release of the system or framework that it’s modifying. As a developer, you need to be proactive about fixing any problems that pop up in the code you are overriding. Not doing so is irresponsible and puts your users at risk. The last update for Rapport was in 2009.

(One could speculate that the new privilege separation architecture for Safari in Lion is causing Trusteer’s developers a lot of headaches. The other tenet of method swizzling is to remember that it’s not a matter of if your hack will break in the future, but rather when it will break and how painful it will be to fix.)

Needless to say, I have uninstalled this software and will never be installing it again. I would recommend this course of action to any end user.

But that leaves me with a problem: how do I access my bank’s website? I have three options:

1) Find another bank. This is a difficult choice, as there are many systems that are hooked up to this account: ACH transactions for sales via iTunes, bi-weekly payroll, automatic payments for services, etc. I’d also like to give SunTrust a chance to reconsider their position in requiring this software (they will be getting a copy of this report.)

2) Use the telephone. I can call the bank when I need the information. Sure they’ll get tired of hearing from me, and it will cost them more for customer service, but it’s their choice to require Trusteer Rapport.

3) Run the Trusteer Rapport software in locked down environment. Once it’s supported on Lion, it should be possible to create a virtual machine that that will only be used to access the bank website. Needless to say this is inconvenient, a waste of resources, and severely limits my ability take advantage of my bank’s services.

In closing, I’ll leave you with one final irony: I will never be able to access my bank’s website from what is arguably the most secure computing device in existence today. That’s because the iPad is not a supported platform. Apple only allows third-party applications to run in a secure sandbox where they can’t affect other applications or the operating system. What you’ve seen above is exactly the reason they’ve done this.

But this post is not to debate these changes to the programming environment. Rather, I’d like to discuss the new documentation viewer and how it has become unsuitable for both Mac and iOS development.

Apple’s technical documentation has always been top-notch: well written with just the right amount of technical detail. Unfortunately, the documentation viewer that we use to read this valuable information has been declining in ease of use over the past few releases.

It has gotten to the point where frustration with usability overshadows the excellent content. The best way to describe these annoyances is by example: I often get the feeling that the writers who create this prose don’t understand how we use it. Hopefully, this critique will help Apple create a viewer that’s just as good as the information it holds.

A corrupt index

A developer coming from Xcode 3 will have a terrible first experience with the new documentation viewer. Any previously installed documentation sets are incompatible with Xcode 4. Methods that you know exist just don’t show up:

There are also problems with the Jump Bar navigation stack not being recorded correctly and the browsing history being unavailable (the back button isn’t available when it should be.)

Presumably, there is a corrupt or incompatible index. The workaround is to delete and re-install the documentation set, but this is far from obvious.

Since I currently have three different versions of Xcode installed (and will continue to use Xcode 3 for the foreseeable future), I’m wondering if this corrupted/incompatible index will continue to be a problem. Fingers are crossed, but at least now we know what to fix if it breaks.

Popup hell

When you hold down the option key and click on a symbol in Xcode, you see the following window:

For novices, this window has some utility—it provides a simple way for them to dig into what is probably unfamiliar territory (”What’s a UIWindow anyway?”).

The problem is that this window becomes a roadblock for experienced developers. We know damn well what a UIWindow is: we need to dig into the details of this important class. Maybe we want to know more about the rootViewController instance or look at some of the methods in UIResponder (because we know it inherits from that.) This helpful popup quickly becomes a hindrance.

In previous versions of Xcode, holding down the shift key along with the option key gave you a quick way to avoid this popup help. In Xcode 4, that shortcut is gone.

Considering that this feature can get in the way hundreds of times per day, this is truly popup hell.

rdar://9149588

No methods

Once you get the documentation index in working order and actually make it past the popup help, your next hurdle is to locate the information you seek. Let’s say we’re looking for some background on what happens when a new -rootViewController instance is assigned. We’ve got the page of documentation, but there aren’t any controls to show the methods for the UIWindow class:

Besides being a pain in the butt, this is wholly inconsistent with the behavior in the code editor:

(Note that typing “ro” is enough to select “rootViewController” in the code editor’s popup menu. That, followed by the enter key gets you to the code of interest.)

From a developer’s point-of-view, the header files and the documentation page go hand-in-hand. Make the UI affordances the same and we don’t have to think about whether we’re looking at code or the words that describe it.

With a little more digging, you’ll find that you can get to the rootViewController documentation with the Jump Bar. Unfortunately, it takes a lot more effort than in the code editor: you have to click on the class name, and then move the mouse until the subcategories appear. Choose “Instance Methods” and wonder why rootViewController isn’t there. Then move the mouse back and try Properties.

Bingo (but you don’t feel like a winner.) And forget about navigating these lists quickly and easily with the keyboard as you can with the code editor.

rdar://9149638

Unmanaged complexity

Our final navigation problem is reading chapter-based documentation. These are the crown jewels of Apple’s developer documentation. Titles like The Objective-C Programming Language, iPhone Human Interface Guidelines, and the Cocoa Fundamentals Guide are essential reading for all developers, both beginner and advanced. As I began learning about Xcode 4, of course I turned to the excellent User Guide.

These guides typically span many chapters when sections that cover a wide range of topics. And this is how you navigate through those chapters:

Managing complexity, indeed.

The pity here is that someone in developer documentation has forgotten that a Table of Contents tells a much more important story than the individual chapters. A roadmap lets you visit the destinations efficiently.

To get an idea of how painful this is, try finding the recommended Singleton implementation in the Cocoa Fundamentals Guide using the Jump Bar. I’ll wait. (For extra credit, count how many menus you open in the process.)

Of course the documentation viewer has a search function, but even that’s a bit laborious because you have to click on a lot of disclosure triangles to find the right item in the results. Why aren’t the relevant results opened automatically? (And, yes, option clicking the disclosure triangle can be used to achieve this goal, but the question still remains: why isn’t this the default action?)

Updated March 29th, 2011: Matt Neuburg has discovered that for some documents, search results don’t show where your term occurs; you’re shown a higher-level page, but not the actual page.

The root of the problem here and with the method names in the class documentation, is that a deep hierarchy is too hard to navigate. Present the information in a single list and it becomes much more useful. Imagine how bad the code editor navigation would be if it presented a hierarchy based upon classes, properties and methods. It’s flattened into a single menu for a reason: and those same reasons exist in the documentation viewer.

The Jump Bar is a great addition to Xcode, but it’s true power lies in having a predictable end point. With code, that end point is a function, property or method. With documentation, that end point is elusive: it varies depending both with the type and the structure of the documentation you’re viewing. And that’s a real problem when you’re looking for something.

rdar://9149683

ePub, not PDF

While we’re on the subject of this long-form documentation, why isn’t more of it available in the ePub format used by iBooks? It’s pretty safe to assume a huge majority of Mac and iOS developers have an iPad and like to use it for technical documentation. Searching for “Apple Developer Publications” in iBooks results in only six books. That’s a great start, but there is still a lot of documentation available only in PDF.

PDF is, of course, an option for iBooks. But turns out to be unsuitable because there is no back button. If you click a link in the PDF file, it’s a one way proposition. And for technical documentation, that’s a deal killer.

ePub also has the advantage of better font control and image viewing.

rdar://9149845

Some good news

Fortunately, it’s not all bad news. This new version of the documentation viewer seems to keep track of its place on the page much more reliably than in the past. Gone are the days where hitting the back button put you back as the top of the page (instead of the method or property you were looking at previously.)

This one simple fix will save developers a huge amount of time. Thanks!

Ingredients

This situation with the Xcode document viewer has gotten so bad two developers, Alex Gordon and Jean-Nicolas Jolivet, have taken matters into their own hands. This ultimate workaround is an application called Ingredients.

Ingredients parses the HTML files used by Apple’s own viewer and persists the information with Core Data. The result is quick access to the documentation you need with advanced options to filter and sort to your liking. Recent work by Troy Gaul added an item to the Services menu so a keyboard shortcut can be created to view the selected symbol from any text editor (include Xcode.)

If the problems mentioned above affect you adversely, take a look at this alternative documentation viewer. And please take a moment and file duplicate bug reports using the Radar links above. This is the best way to give Apple an idea of how much this is affecting our daily work. Thanks!

Updated March 22nd, 2011: The developers of Ingredients are now accepting donations.

Let Twitterrific count the ways:

1. First use of “tweet” to describe an update (see page 86 of Dom Sagolla’s book.)
2. First use of a bird icon.
3. First native client on Macintosh.
4. First character counter as you type.
5. First to support replies and conversations (in collaboration with Twitter engineering.)
6. First native client on iPhone.

And more.

First, let me congratulate you and everyone at Apple on the release of the iPad. From my dealings with your company, I know it wasn’t easy. Thanks to everyone for busting their asses: a lot of very complex puzzle pieces came together during those last 60 days!

I recently had an encounter with Bill Atkinson. I told him that “I haven’t had this much fun with a computer since 1984.” He laughed, said “Thanks!”, and went back to working on his iPad app. We, and many other developers like us, are completely smitten with this new device.

After owning an iPad for a little over three weeks, it feels like we’re dealing with something much bigger than that Mac we all got excited about over 25 years ago. I’ve been struggling to define exactly what that is: beyond the technical specifications like the beautiful screen with its large multi-touch surface. Those specifications define what the device can do, but not what it means in our lives. I want to understand the magic.

Last week, much of that meaning came into clearer focus at a birthday party for my brother, niece and nephew (April is birthday month in our family!) My wife had loaded our iPad with photos from a recent trip to see the desert wildflowers in Anza Borrego and my 50th birthday party from the week prior.

Predictably, people’s initial reaction was “Wow, that’s the new iPad!” But that quickly faded as I opened the Photos app and passed the device around. My family was more interested in sharing the photos than talking about the new technology.

I was particularly interested in how my mother, the quintessential technophobe, would react to the device. She picked up on things quickly and was flipping through photos in no time. It astonished me how the interface disappeared for her: at one point she subconsciously licked her finger before “flipping” to the next photo.

As interesting as it was to see someone non-technical use the device, the real eye opener was how several people could interact with the iPad at once. Much of my mother’s fear of computers was overcome because she was looking at the pictures alongside my sister-in-law who helped her out when she got stuck. Learning was organic.

My niece also discovered some of the games I had on the device. One, Abca, was a hit because many people could play it at once. I’ve always played the game by myself and was surprised at how much fun it was to have other people guessing words simultaneously. A group of people transformed the software into something no developer had ever expected.

All of this led to the revelation that we’ve begun a new age of “communal computing.” The desktop revolution centered around empowering individuals: this new revolution will extend that empowerment to groups of people.

The iPad was naturally passed around amongst the partygoers. Many people interacted with it during the evening, and I lost track of who had it at any given time. And therein lies a fundamental problem.

My iPad has a lot of personal information on it: email, business documents, and financial data. When you pass it around, you’re giving everyone who touches it the opportunity to mess with your private life, whether intentionally or not. That makes me uneasy.

It’s hard to fault Apple for this shortcoming. The secrecy of the project undoubtedly limited the amount of group interaction your designers and engineers would experience with their new creation. The social aspects of this device is probably just as much as revelation to them as it is to me.

I can envision several ways to solve this problem: either with a traditional login screen or with something new like folders that require a passcode to open. I have no doubt that your designers can find something elegant that gives me peace of mind as I share my iPad with friends and family.

Thanks for your time and consideration,

Craig Hockenberry

Updated April 30th, 2010: I filed Radar #7922808 for this issue and it was marked as a duplicate of Radar #7584426.

Apple currently lets each iPhone developer, whether a company or an individual account, assign 100 devices for testing purposes. A large chunk of those available devices get used by employees with multiple devices. We also have a valuable group of external testers that we use for Ad Hoc beta testing. Many of these individuals buy the latest and greatest hardware, so each time there is a new product introduced, we use up more devices from our list.

On April 3rd, almost everyone on our beta test list will be buying an iPad and want to run Twitterrific on it. Unfortunately, some of these testers are going to be out of luck because we don’t have enough devices left to allocate. I have no idea what we’re going to do if the next version of the iPhone OS is introduced before our iPhone Developer account gets renewed.

As a developer, I never like turning a valuable tester away from my product. But that’s what we’re doing now.

To be clear, I think Apple’s policy is justified. Developers were abusing the system, so something had to be done. The problem, in my mind, is that the throttling valve is being put on the wrong piece of pipe.

As developers, we want to maintain a pool of testers, not devices that they test on. Devices are ephemeral: they change as new hardware is introduced and replaced. The thing that remains constant are the people who test our products.

A tweet from Mike Piontek crystalized this thought: the limitation for Ad Hoc provisioning should be based around individuals, not the devices that they own. It makes more sense to regulate Apple IDs rather than UDIDs. I want John Gruber to be able to run my apps on whatever devices he currently owns. I want to put my own name on the provisioning list and enable the five iPhone OS devices sitting on my desk. All that Apple cares about is that are only 98 other people besides Gruber and me.

(I suspect that Enterprise IT has similar problems and would welcome a solution based on employees rather than the hardware they own. I can only imagine the headaches of managing thousands of devices.)

Of course, there’s a huge amount of infrastructure around verification based on UDIDs: the Program Portal, device firmware, and our own internal processes would require changes. But I think it’s a good goal to work toward, because the current system isn’t scaling well and will only get worse as Apple introduces new products.

Updated April 13th, 2011: It’s been over a year and the situation just keeps getting worse. Please take a moment and duplicate rdar://9255432. Thanks!

In spite of plenty of advance warning from Twitter, we got caught by the Twitpocalypse bug.

For the 2.0.1 release, we had tested our software extensively. I actually wrote an emulation layer on top of the code that reads data from Twitter that added a large number to every ID read from Twitter. This testing uncovered several bugs which were fixed and incorporated into the MGTwitterEngine open source code.

Unfortunately, this testing didn’t take into account that the library we use to parse the data (YAJL) includes a range check that ensures signed values, which are allowed by the JSON specification, will fit into 32-bit storage. The “YAJL Error 3″ is that library telling us that the range check failed.

In hindsight, I should have fed the parser some large unsigned integers. In the wonderful world of software development, we call this a brain fart.

How did we respond?

Unfortunately, the Twitpocalypse occurred on Friday evening, just as my wife and I were heading out for a high school graduation. I quickly shot off an email to Twitter asking a few questions (I had mistakenly thought that there were problems with data being returned by an authenticated connection.)

After a couple of hours of iPhone email and SMS, it was clear that we were going to need do a new release. We had a critical bug that affected thousands of users. And our fear was this submission would take longer than normal: many developers are submitting 3.0 updates.

Life officially sucked at this point, and the graduation ceremony was memorable for all the wrong reasons.

After getting a few hours of fitful rest, I opened up Xcode on Saturday morning and started looking for the problem. It took just a few minutes to find the bug and another few minutes to fix it. Our concern at this point was getting the update to users.

Apple saves the day

In spite of it being the middle of weekend after a busy week at WWDC, we were able to get in touch with Apple Developer Relations. Our contact was able to expedite the approval of the application.

To say that this was a relief would be the understatement of the century. The update for the free version started showing up in iTunes on Sunday evening. The paid version was updated on Tuesday morning.

What can we learn from this?

Developers are human. We make mistakes. It’s interesting to note that Loren Brichter and Buzz Anderson, fellow developers whose skills I hold in high regard, were also affected by the Twitpocalypse. It really does happen to the best of us.

It’s also interesting to see that Loren and Buzz reacted in the same way I did: by fixing the problem ASAP. In Loren’s case, that meant finding a hotel with WiFi in order to distribute his update. Buzz released a new beta in a matter of hours.

In my experience, these brain farts are problems with easy fixes. It’s something like checking for invalid bounds, getting a Boolean state wrong, or something else of that nature. It’s not a complex problem: it’s an oversight.

The problem, therefore, is not how fast we can react to fixing critical bugs, but how fast the App Store reviewers can react with an approval.

As a device that’s constantly connected to the Internet, the iPhone taps into a stream of data that is unpredictable. Data in “the cloud” can change at any time, and web applications naturally adapt to these changes with a quick deployment strategies. Those of us who are building client applications on top of this network infrastructure need the ability to adapt quickly, too.

Security issues are another area where a quick response is a requirement, not a luxury. If I discover something that puts a user’s private data at risk, it’s my responsibility to fix the problem as quickly as possible. Time spent in a review queue is time spent being exposed to a flaw.

At the same time, we shouldn’t blame Apple for these delays in reviewing applications. In the year that they have been selling our products, the App Store has been more successful than anyone imagined. It’s clear to me that reviewers and others involved in the approval process are overwhelmed by this success.

How can we fix it?

Fortunately, I think there’s a simple way to solve this problem for all developers selling products on the App Store. The inspiration for this solution will be obvious to anyone who’s used Apple’s Developer Technical Support (DTS.)

When you purchase an ADC membership, you are given a number of “incidents”. These DTS incidents can be used when you have a problem that can’t be solved through documentation, support forums or hours and hours of debugging. It’s for the hard stuff, and usually involves getting an engineer at Apple involved to understand and fix the issue.

As a developer, I’m very careful to use these incidents wisely: they are a last resort. There are some years where I don’t use them at all, those are the good years.

A similar system could be put in place for critical bug fixes on the App Store. If every developer was given one or two “prioritized reviews,” it would act as insurance for the brain farts. You’d have a way to raise a flag and say “I need special attention for a critical bug.”

If another developer has a critical bug, I have no problem with my review process for a feature release taking a little longer. And since prioritized reviews would be a scarce resource, they won’t be open for abuse because developers will think twice before using them.

Because it’s not a matter of if you have a brain fart that leads to a critical bug, it’s a matter of when.

iPhone 3G?

It’s entirely possible that Apple will keep the same name as the previous version. There’s precedence in the Mac product line: we’ve had MacBook Pros for several years now with various ways of distinguishing different product iterations (”Late 2008″, “Unibody”, etc.)

Given Apple’s reluctance to publish any of the device’s hardware capabilities, this would seem to make sense.

Except for one small problem. It’s likely that the new iPhone will have a faster processor and more memory. Some applications will be written to take specific advantage of these improvements. And that, of course, means that you need a way to let iTunes customers know if those applications are compatible with their device.

I don’t see Apple putting “iPhone 3G (2008)” and “iPhone 3G (2009)” anywhere in the iTunes UI. It’s just too confusing.

iPhone 4G?

What about having artificial product designations like they did with PowerPC desktop Macs: “G3″, “G4″ and “G5.”

The problem here is that 3G refers to a network service, not a product generation. If this naming convention is used, customers are bound to wonder if a “4G” product works on their 3G network.

iPhone 3G Plus?

So maybe they do something like we’ve seen with the iPod product line. Using terms like “Classic”, “mini”, “nano” and “shuffle” to differentiate the products.

The problem here, of course, is that there’s only one product on sale. Unless Apple plans to keep the current product on sale (at a reduced price,) this just doesn’t make sense.

I’m not going to make any predictions on the device’s name, but I will be paying close attention. The ultimate choice is likely to offer some subtle clues regarding Apple’s plans to evolve this product in future revisions.

And then one day it dawned on me: an iPhone toolbar with an action sheet is like a menubar with menus on the Mac desktop (turn your phone upside down and there is even some visual similarity.)

After investigating some of the design patterns for NSMenu and NSMenuItem, it was clear that this would work well on a mobile interface as well. My implementation is a subclass of UIToolbar named IFActionToolbar.

In it’s simplest form, you attach a list of items to one of the toolbar’s bar button items:

@interface MyViewController : UIViewController
{
  IBOutlet IFActionToolbar *toolbar;
  IBOutlet UIBarButtonItem *barButtonItem;
}

...

@implementation MyViewController  

...

- (void)viewDidLoad
{
  [super viewDidLoad];

  IFActionToolbarActionItem *actionItem = nil;

  NSMutableArray *actionItems = [NSMutableArray arrayWithCapacity:3];
  actionItem = [[[IFActionToolbarActionItem alloc] initWithTitle:@"One" target:self action:@selector(firstAction:)] autorelease];
  [actionItems addObject:actionItem];
  actionItem = [[[IFActionToolbarActionItem alloc] initWithTitle:@"Two" target:self action:@selector(secondAction:)] autorelease];
  [actionItems addObject:actionItem];
  actionItem = [[[IFActionToolbarActionItem alloc] initWithTitle:@"Cancel" target:nil action:NULL] autorelease];
  [actionItems addObject:actionItem];
  [toolbar attachActionItems:actionItems toItem:barButtonItem];

  [toolbar update];
}

The IFActionToolbarActionItem is just a simple wrapper object that associates a title with a target and action. These action items are used to automatically construct the action sheet when the user taps on barButtonItem. If you’ve ever constructed an NSMenu using NSMenuItems, this will feel quite familiar.

Additionally, the toolbar supports an -update method. This method calls the assigned delegate to enable or disable toolbar buttons, set the image for the toolbar item, change the title of the action sheet, hide or show items in the action sheet, and define the cancel or destructive buttons in the sheet. Again, similar in pattern to how NSMenuItems are maintained.

Any time you call this update method, the UIToolbar is configured automatically. It makes it much easier to reflect the state of your controller in the view.

I’m not going to spend too much time discussing the inner workings of this class: the picture of a sample project is worth a thousand words.

One thing I would like to caution you about: don’t get too carried away with enabling and disabling items in the action menu. In our UI testing, we found that changing the list too much was confusing for users. It’s like the “adaptive menus” used in Microsoft Office: it’s very difficult for a user to adapt to your interface if it’s constantly changing. Just because you can doesn’t mean you should.

Again, I hope this code is useful in your own iPhone projects. Enjoy!

In particular, this post addressed a problem that every iPhone developer has encountered: any kind of settings or form UI is a pain in the butt if you follow Apple’s sample code. And, of course, this is exacerbated because these essential interfaces aren’t very fun to code. For both Twitterrific and Frenzic, it’s been a frustrating experience: I wanted to fix how this standard UI was created and maintained.

The motivation

Before I start talking about what I did using Matt’s concepts and code, I’d like to discuss the need for settings in an application.

There are some people who think that settings should only be in the Settings app. There are others that think they should only be within the application. I can honestly see how both groups are right, but what both sides fail to realize is that it’s often a matter of context.

If you’re working on a simple application with simple needs, relying on the infrastructure provided by the SDK is fine. You may have some additional support load for users who have problems finding your settings, but that’s a reasonable tradeoff for saving development time. Sophia Teutschler’s Groceries app is a fine example of where the built-in settings shine: I turned off the Marker Felt font several months ago, and I haven’t touched it since.

In the case of Twitterrific, there were three main reasons why we built the settings into the application:

1. We could not split the settings between two locations. From a user’s point-of-view, it’s incredibly confusing to have an application’s configuration in two places. This would have happened if we had put the account settings in the application and everything else in the Settings app.
2. Some of the settings are things that people will change on a fairly frequent basis. For example, the dark theme works best at night, while a light theme is better during the day. Leaving the app to make these types of adjustments is inconvenient.
3. The Settings app can’t handle preferences that are “dynamic.” An example is a vibration setting for the notification: there’s no way to make this appear on an iPhone but not on an iPod touch.

The solution

I’ve taken the basic concepts that Matt presented in his article and extended them to create a pixel perfect replica of what you see in the Settings application. Instead of configuring applications using a property list, you do it with some very simple code in a view controller. (Domain-specific languages, such as those found in Ruby, were an inspiration for the methods used in this code.)

And if you’re not doing settings, the classes are still very handy for making user input forms. They were used in all of the search forms used in the new version of Twitterrific.

To give you a quick taste of how it’s used, here’s a complete implementation of a table view controller that presents a single group with a text field and a switch control. In just six lines of code:

- (void)constructTableGroups
{
  NSMutableArray *cells = [NSMutableArray array];
  IFTextCellController *textCell = [[[IFTextCellController alloc] initWithLabel:@"Text" andPlaceholder:@"Placeholder" atKey:@"sampleText" inModel:model] autorelease];
  [cells addObject:textCell];
  IFSwitchCellController *switchCell = [[[IFSwitchCellController alloc] initWithLabel:@"Switch" atKey:@"sampleSwitch" inModel:model] autorelease];
  [cells addObject:switchCell];
  tableGroups = [[NSArray arrayWithObject:cells] retain];
}

The real beauty of this code is that it’s incredibly easy to change. Settings and forms tend to evolve over the lifetime of a project, so using these simple declarations for the table view layouts makes it much simpler to adapt to new requirements. If I need to change the switch control shown above into a choice list, I can do it in a couple of lines of code.

So without further ado, here’s the source code in a sample project. The code is well documented, so you shouldn’t have any problems figuring out how it all works. Start by looking at the RootViewController, then take a look at the SampleViewController, followed by the SampleAdvancedViewController. If you’d like to incorporate this code into your own project, just grab all the classes with the Iconfactory prefix (”IF”.)

The license

Previously, I’ve released source code on this site without any licensing at all. This time, I’m going to try something new. You can do anything you want with this code with one requirement: you need to give the Iconfactory some link love in your product.

For more details on the licensing terms, check out the Licensing.rtf file that’s included in the sample project. If you can’t abide by this restriction, please get in contact and we can try to work something out.

I hope this code saves you as much time as it has saved me. Enjoy!