The most important point: If you want a great application with a user experience you’ll be proud of, build a native application using Apple-blessed developer tools and resources. Apple’s developer tools are outstanding applications and the iPhone frameworks provide useful, battle-tested, mature code that lets you do a lot without reinventing the wheel every time you need to build even basic functionality. Best of all, Apple gives their tools away for free.

Don’t screw around with stuff like PhoneGap or Adobe’s Flash-to-iPhone binary whatsit just because it might be a little closer to your comfort zone. You’ll risk writing an application with a library that gets left in the dust when Apple releases a new version of the SDK with great new features. You’ll also risk having your application rejected if Apple decides one morning that the tools you used are accessing private methods, running interpreted code or disrespecting some other element of the SDK agreement. Finally, you’re not going to be working with the same design vocabulary expressed by every popular iPhone application.

With UIKit, Apple hands you an enormous pile of outstanding interface classes that are exceptionally clever, attractive and versatile. They’re yours to build with and do as you please. Thousands of hours of interface coding that you don’t have to do, saving you time and allowing you to write an app with an experience that’s consistent with everything your users will expect on the iPhone.

With Core Data, you get a powerful object modeling framework with built-in persistence. What does that get you? If you’re building an application, you’ve got data. Lots and lots of data, sometimes. You’re going to need a way to define and encapsulate that data so that you can keep track of relationships between different chunks, pass information around the application and store it for later use. This can be tedious, laborious, time-consuming work. Core Data does all of the heavy lifting for you.

For me, those are the biggest freebies you get with approaching iPhone development “the right way.” That barely scratches the surface, though, since Apple provides powerful APIs that let you accomplish drawing, manipulating the filesystem, performing network operations, dead-simple threading, and many other useful things.

Hopefully you’re intrigued. You’ll need to be, especially if you’re starting from scratch. There’s a big chunk of learning you’ll have to do. It’s worth it, though. The iPhone is a really fun platform and there’s something potent about developing for a mobile device that’s always in your pocket.

Find the section that describes you below and proceed from there for my advice on great learning resources.

You’ve never coded anything, ever (or, C-based languages scare you)

Let’s start with C. C is a venerable language with a long history, born in 1972. C is important background to have for iPhone development, since so many Apple APIs use either C or Objective-C, a related language we’ll talk about next.

Luckily, Dave Mark has you covered. Learn C on the Mac assumes no pre-existing experience with any programming language. You’ll get a friendly explanation of everything you need to understand C and the basics of programming. This is ground zero, indispensable knowledge for anyone who is approaching this with no experience. The best part is that Dave has written for someone who will be using Apple’s developer tools, so you’ll be getting a perspective that will be useful for your iPhone efforts a little bit later.

You’re comfortable with programming and C, but not Objective-C

Objective-C is built on top of C, so if you’ve got a basic comfort with programming in C, you’ll have an easy time getting up to speed. Objective-C lets you build object oriented code. Whuzzat? It’s Legos for programming. You can build your own bricks and trade them with friends. Put simply, object oriented programming (OOP) lets you build modular software that maximizes code reuse. Reusing code is good! Chances are, if you solve a problem once in your project, you’ll need that solution again later. OOP lets you easily package up these solutions and deploy them anywhere they’re needed in your code.

Confused? You won’t be after you read Learn Objective-C on the Mac. You’ll learn all the details of how Objective-C works. The book is packed with clear explanations of how to use object-oriented programming and practical exercises to get you comfortable with building useful code in Objective-C. You will not enjoy learning iPhone development without a solid foundation in Objective-C. You’ll get one here. Many lightbulbs will turn on for you.

You understand Objective-C but you’re not yet confident enough to build an app with it

If you feel great about Objective-C and you can’t wait to get started, go on to the next book. If you want to build a little more confidence, it might be worth spending some time practicing with Objective-C and how it interacts with Apple’s Cocoa API. What’s Cocoa? It’s a huge collection of pre-made building blocks you’ll use to build applications. (Not to be confused with Cocoa Touch, which is a version of Cocoa custom-tailored for the iPhone, which you’ll meet later.)

Cocoa Programming for Mac OS X is great introduction to Cocoa. You’ll learn about using Objective-C with Cocoa, use Interface Builder to construct some interfaces and walk through plenty of exercises. You even get to play with Core Data. By the first dozen chapters or so, you should be ready to rock. Many of the Cocoa goodies you play with on the desktop will be waiting for you on the iPhone.

You’re comfortable with programming and Objective-C

It’s time to get rolling with the iPhone.

I own several iPhone development books. None is a better, more useful introduction to developing for the platform than Beginning iPhone Development. It’s Dave Mark again, alongside Jeff LaMarche, with everything you need to get started. Beginning iPhone Development is a comprehensive exploration of building software for the iPhone. The authors provide friendly guidance as they break you in gently. You’ll learn how to construct interfaces, master table views, and how to store and load data, even using Core Data. The book is filled with useful, practical exercises that you’ll be able to use for your own projects. Dave and Jeff are great about providing code that is both understandable for learning and yet practical enough to serve as a springboard for solving your own problems in your own apps.

If you’re learning how to develop for the iPhone but you don’t have their book, you’re doing it wrong.

They don’t stop, there, either.

Jeff and Dave’s latest, More iPhone Development, is loaded with meaty chapters on advanced topics. My favorites: several chapters on Core Data (nearly half the book) and an outstanding tutorial on how to use Xcode’s debugging tools.

The breadth and depth of these titles together is unbeatable for a beginner iPhone developer. Between both books, you’ll have answers for most quandaries you’re likely to encounter in your early projects.

On teaching yourself

So how do you use these great learning tools? I’m a passionate, lifetime autodidact. Here’s my advice:

At least one hour, every single day.

The books I’ve described present their content split up into chapters. Read and work through at least one chapter per day. Don’t try to cram it all into a couple of weekends, skimming examples and reading exercises instead of trying them.

Even if you’re starting from the ground up, you can easily get through every single book I’ve described here within three or four months.

You’re setting up your own little school. Make a point of setting a time when your studies begin and end and make a habit of sticking to that schedule. If you have to miss a night of your programming school, give yourself some time to make up for it the next day.

Equipment

Get the PDF eBook editions of the books you need. You can never lose them, forget them at the office, spill coffee on them, whatever. They’re instantly searchable and much easier to work with in a nightly home school setting than paper books. They’re sometimes cheaper than paperbacks, you don’t pay shipping and you can get them instantly via the web. I have a blend of paperbacks and PDFs — I’m much happier with my PDFs, especially when traveling.

If you’re serious about programming, you’re going to need a second monitor as well, unless the one you already have is enormous. One day you’ll have real projects to work with, which means a debugger window, some documentation open at all times, and plenty of other clutter. A second display will make your life manageable. During your programming school, having a second display for your eBooks will make working through your exercises on the main monitor much easier.

Finally, you’ll need a notebook. As you work through books and exercises, make note of the important, central concepts and create lists of basic vocabulary. You’re going to have a lot of new knowledge to sift through. Make it easy on yourself by building your own cheat sheets to reference in the middle of exercises or when you make the jump to the next level of learning. It’s a lot easier to consult your own notes than try to figure out which book had which handy tip.

Start

Just get started. Pick a book, pick a time and start. It’ll be weird at first, especially if you’re new to programming. That’s okay. Wikipedia is close by with a wealth of technical articles on anything you might want to know about. If you have questions and don’t know who to ask, Stack Overflow is filled with knowledgeable (and not so knowledgeable) members who will be eager to point you in the right direction, no matter how specific or arcane the query.

Good luck! This is an exciting time to develop for mobile devices. The iPhone is the most potent and exciting handheld computer ever. You’re going to have a great time — once you get started.

(Note: Apress didn’t sponsor this post or anything but I notice they make up almost all of my recommendations. Kudos to them for hiring outstanding writers who care about relating their wisdom in a clear, enjoyable manner. Their books have great layout and intelligent structure, so they work as well for reference as they do for sequential, hands-on learning. Truly a great publisher who understands the needs of its audience.)

DCSoundServices.h:

#import <Foundation/Foundation.h>
#import <AudioToolbox/AudioToolbox.h>
 
@interface DCSoundServices : NSObject {
 
}
 
+ (void)playSoundWithName:(NSString *)fileName type:(NSString *)fileExtension;
+ (void)vibrateDevice;
 
@end

DCSoundServices.m:

#import "DCSoundServices.h"
 
@implementation DCSoundServices
 
+ (void)playSoundWithName:(NSString *)fileName type:(NSString *)fileExtension
{
 
	CFStringRef cfFileName = (CFStringRef) fileName;
	CFStringRef cfFileExtension = (CFStringRef) fileExtension;
 
	CFBundleRef mainBundle;
	mainBundle = CFBundleGetMainBundle ();
 
	CFURLRef soundURLRef  = CFBundleCopyResourceURL (mainBundle, cfFileName, cfFileExtension, NULL);
 
	SystemSoundID soundID;
 
	AudioServicesCreateSystemSoundID (soundURLRef, &soundID);
 
 
	AudioServicesPlaySystemSound (soundID);
 
	CFRelease(soundURLRef);
 
}
 
+ (void)vibrateDevice
{
	AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);
}
 
@end

Assuming you’ve got a sound file named click.aif in your application bundle, you can play a sound in just one line of code:

[DCSoundServices playSoundWithName:@"click" type:@"aif"]

Or, vibrate the device:

[DCSoundServices vibrateDevice]

Much tidier than having to import AudioToolbox into every UI that ever plays back a sound.

The structure works like this:

The first row of your CSV is considered to be the header. The code will use content from the header row to create key names. For every subsequent row, the code will create a dictionary, associating the content of each column with the key names from the header. The dictionaries live in an array which is written out to a Plist file.

This is handy if you’ve got a bunch of spreadsheet-type data you’d like to use as the basis for a static reference in your app. Say, data about the periodic table, airport listings, trivia questions, whatever. You can sift and sort your data in a user-friendly environment like Numbers or Excel, then dump it out to CSV and put this code to work.

It uses cCSVParse to read the CSV file.

//	NSLog(@"Converting %@",pathAsString);
 
	CSVParser *parser = [CSVParser new];
	[parser openFileWithPath:pathAsString];
	NSMutableArray *csvContent = [parser parseFile];
	[parser closeFile];
 
	if (pathAsString != nil)
	{
 
		NSArray *keyArray = [csvContent objectAtIndex:0];
 
		NSMutableArray *plistOutputArray = [NSMutableArray array];
 
		NSInteger i = 0;
 
		for (NSArray *array in csvContent)
		{
 
			NSMutableDictionary *dictionary = [NSMutableDictionary dictionary];
 
			NSInteger keyNumber = 0;
 
			for (NSString *string in array)
			{
 
				[dictionary setObject:string forKey:[keyArray objectAtIndex:keyNumber]];
 
				keyNumber++;
 
			}
 
			if (i > 0)
			{
				[plistOutputArray addObject:dictionary];
			}
 
			i++;
 
		}
 
//		NSLog(@"Plist output array %@", plistOutputArray);
 
		NSMutableString *mutableString = [NSMutableString stringWithString:pathAsString];
		[mutableString replaceOccurrencesOfString:@".csv" withString:@".plist" options:nil range:NSMakeRange([mutableString length]-4, 4)];
 
		NSURL *url = [NSURL fileURLWithPath:mutableString];
 
//		NSLog(@"Write to URL %@",url);
 
		[plistOutputArray writeToURL:url atomically:YES];
 
	}

That’s from a simple desktop app I built for the purpose. It takes the path of your CSV, via drag-and-drop, then spits out the Plist beside it.  You can grab the source at Google Code. You can also download this compiled binary if you want to get crackin’ right away.

That’s a big number.

I can’t tell you the secret to success in the App Store. I haven’t discovered any magic formulas. The one thing I can tell you with 100% certainty is this: if you ship a product with bugs that genuinely piss off your customers or, worse, make them unable to use some portion of your hard work, the road toward success just got much longer and a lot more miserable. Even with “prioritized review” requests, once your buggy app is on the store, the review queue means you could be waiting a long time before your customers can enjoy your bug fix.

You will not sleep well at night.

The good news is that this problem has been solved a thousand times over. A thorough beta test can save you from this terrible outcome and the sleepless nights that come with it. With a bit of diligence, you can ship an app with awesome stability to match your great ideas.

I’ll share how I run my betas. This is about process — the technical side of Ad Hoc distribution is thoroughly documented by Apple and others. The tools I use are simple and free. They work. If you have suggestions for better ones, I want to know about them before my next test! Please share in the comments.

Gather Your Testers

You’re going to need testers. If you use a volunteer testing pool, figure that 80% of testing will be done by 20% of your volunteers. That means to have any hope of gathering meaningful feedback, you’ll need at least 10 volunteers. 15 or 20 would be the ideal minimum.

Next, you’ll need to start early — but not so early that your testers’ enthusiasm cools by the time you ship your first beta build. Try to get the word out between three to six weeks before you’re ready to test. If you have a particularly strong network, you may need less time. If you’re relying more on the kindness of strangers, though, make sure to give yourself plenty of lead time. Use your website, your blog and your Twitter to solicit volunteers but don’t be a pest.

Most importantly: if you have contact with existing customers from previous versions or perhaps other products entirely, send a quick, polite email explaining what you’re going to test and encouraging them to join up. Customers who have emailed you in the past with feedback or feature requests may be especially keen on seeing your latest work.

Understand Your Testing Pool

You need to know things about your testers. What kind of hardware will they be using? What version of iPhone OS? What’s their geographic region? (International testers are crucial for finding your screwups with localized formatting and other geographic issues.) Most importantly, you’re going to need to collect their UUID.

I use Forms for Google Docs to collect most of my feedback. It’s an easy-to-configure way to store structured data. Since you can designate required fields, you can ensure your testers don’t forget to include anything crucial when reporting issues. Best of all, you can embed the forms into existing web pages, allowing you to include them alongside testing guidance, version history or other information that might be useful.

Here’s the form I use to collect beta tester info:

It’s not short. The other benefit to using a form is to ensure you only get testers who are reasonably skilled at providing detailed information. Everyone who makes it past this filter has a decent shot at actually telling you everything you need to know later in the beta.

Betas Worth Testing

If your app doesn’t look somewhat close to the final product, don’t distribute it for testing. If you’re relying on a volunteer testing pool, you want them eager to use your stuff. If your overall UI is incomplete, you’re not ready to test. You’ve got a limited amount of time and attention with your testers. Don’t squander it on early builds you could easily test yourself. The closer you think your app is to shipping, the more useful your testers will be to you.

You do yourself no favors if the last bit of functionality you add affects previously-solid features that now need a whole new round of testing.

Believe me.

Distributing Your Binaries

So you’ve toiled away and you’ve finally got an app you feel is ready to be tested.

Don’t email the binary.

Depending on the size of your app, the attachment may not be properly delivered to the recipient, especially if they’re using Exchange-hosted email. Instead, host your app and the necessary provisioning profile on the web.

I also recommend a simple checkout system. When you’ve got a new build ready for testing, send your testers a link to a one-question form that asks for their email address. On the form confirmation screen, you can provide a link to the binary. This lets you get an idea of who is participating. It also lets you answer an important question: am I getting zero feedback because there are no bugs or because there are no active testers? With a checkout process, you’ll know for sure.

Use clear versioning with every distributed build. You need to be certain you and your users are talking about the same build when they give you feedback. Beta phases, version numbers, dates, whatever you need to make things clear for everyone involved. Make sure that somewhere in your app, your code pulls the version number out of your app’s Info.plist file and displays it in the UI. Here’s some code to get that string:

NSString *currentVersion = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];

Update your Info.plist’s version number religiously before distribution. Even better, update it automatically.

Communication

You need to communicate with your testing pool. Keeping them regularly updated, without being spammy, is crucial to keeping them excited about what’s going on.

When you send out a new build, explain what’s new. Give specific testing guidance so that your testers know where they should focus their efforts. New method of rendering cells you strongly suspect has a bug or two? Share your hunches. Built a new import subsystem you’re suspicious might break with legacy data? Provide an example data set or encourage existing users of the old version to give it a whirl. If you’re manipulating data that lives only on the user’s device, tell them to back up their iPhone before running your beta. And tell them why. Don’t be a douche on this: never take for granted the importance of your testers’ application data, especially if you’re lucky enough to have your existing customers helping you. Yes, we all know, betas are risky. Still, the iPhone isn’t the desktop and if you’re testing an upgrade to an existing app, your customers may have data they created before accepting the risks of a beta.

If it has been more than seven to ten days since your last build, send a quick update to the pool. Call out awesome testers and let them know they’re making a difference. Share the score of resolved issues you were able to fix thanks to the pool’s feedback. Most of all, thank them. Their efforts are helping you to not look like an idiot.

Sandboxing Helps

If you’re making an all-new app, you can skip this section. If you’re testing an upgrade to an existing app, read on.

Your early beta builds should use a different app identifier than your shipping app. This way, your beta will be installed as a distinct application alongside your currently shipping version on the user’s device, instead of overwriting it. This lets you ensure that no shenanigans happen to legacy data if you’ve got customers from previous versions in your testing pool. Toward the end of your beta, after much internal testing, you can start distributing builds that overwrite previous shipping versions. You’ll want to ensure that the app properly imports legacy data and preferences and, of course, ensure nothing otherwise disastrous happens when iTunes distributes your updated app to existing customers with existing data.

Gather Useful Feedback

You need to know things about how your application is failing. The forms I use are inspired heavily by what I saw once upon a time during the iPhone OS 2.0 Enterprise AppleSeed beta test. I think it covers the basics. Of course, don’t be afraid to add other questions specific to your application’s circumstances. For bugs, measure how well you can reproduce the bug and its overall severity while capturing the reproduction steps. For feature or enhancement requests, measure the tester’s impression of the request’s importance along with what they’re asking for.

However you gather your feedback, ensure that every single message you send to your testing pool includes brief instructions on how your testers should report their bugs. Never make them hunt around for it.

Ship

You haven’t added or changed anything for a couple of builds. You’ve fixed plenty of bugs and no one has reported regressions. You’ve sent emails to your top-performing testers and they’re giving you a thumbs-up.

Give it one last test yourself. Thirty minutes, minimum, actually doing things your users are likely to do. Is it kosher?

Then ship it.

Then, while you wait for approval from Apple, test it some more, informally, yourself. If somehow a show-stopping bug pops up while you await approval, you can reject your binary and submit a fix before it ruins anyone’s day.

Better, I thought, would be to always ensure that when a partially-visible cell crops up, the UITableViewController will quietly nudge things to be completely visible.

vs. 

In the first image, you can see the only part of the top and bottom cell. In the second image, the cells have been nudged so that everything visible is completely visible. This took a little noodling around with math but it wasn’t hard to do. Put this method into your UITableViewController subclass:

- (void)snapBottomCell
{
	NSInteger cellHeight = 62; //Cells for my view are 62px tall. Sub your own height here
 
	NSInteger offsetOverage = (NSInteger) self.tableView.contentOffset.y % cellHeight;
	//Use the tableview's contentOffset property and the cell height to determine how much is being cut off
 
	if (offsetOverage > 0)
	{
		//If the overage is more than 0, we should figure out what the new offset needs to be
 
		NSInteger newOffset;
 
		if (offsetOverage >= (cellHeight/2))
		{
			newOffset = self.tableView.contentOffset.y + (cellHeight - offsetOverage);
			//If the overage is greater than or equal to half the height of a cell, pull the cell up so it's fully visible
		}
 
		else {
			newOffset = self.tableView.contentOffset.y - offsetOverage;
			//Else, push the cell out of view
		}
 
		//With the new offset determined, animate the movement:
 
		[UIView beginAnimations:nil context:NULL];
		[UIView setAnimationDuration:0.5];
		[UIView setAnimationCurve:UIViewAnimationCurveEaseOut];
		[self.tableView setContentOffset:CGPointMake(0, newOffset) animated:NO];
		[UIView commitAnimations];
 
	}
}

You’ll need to implement these two delegate methods as well:

- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView
{
	[self snapBottomCell];
}
 
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate
{
	if (decelerate == NO)
	{
		[self snapBottomCell];
	}
}

And that’s it. If more than half of the bottom cell is visible, the cell gets nudged completely into view. If less than half is visible, it’s pushed out of view.

You could change snapBottomCell to accept cellHeight as an argument if you need to accommodate cells with variable heights. You might sort out a particular cell’s height like so:

	NSIndexPath *indexPath = [self.tableView indexPathForRowAtPoint:CGPointMake(0, (self.tableView.frame.size.height - 1))];
	//Get the index path of the cell currently visible at the bottom edge of the tableview
 
	UITableViewCell *cell = [self.tableView cellForRowAtIndexPath:indexPath];
 
	[self snapBottomCell:cell.frame.size.height];

There are cases where this isn’t useful: long lists whose primary function is selecting data for loading in another view, for example. Still, any time you’re using UITableViewCells to house controls or chunky bits of data, it might be good to ensure that only whole cells are displayed.

Once upon a time…

Tallymander was born because once upon a time, I worked for the man and that meant wearing fancy pants and shirts that buttoned (the better to establish my image as a professional and advance my career). About once a month I rounded up my finery, counted it, and took it to the dry cleaners.

My mental math abilities could be bested by a fruit fly so I wondered if the App Store had anything to make the counting easier. They did, but it was either crap or too limited for my needs. The idea for Tallymander was born. I wanted to make something simple but useful.

I expected to make about $40 off of it, but I knew I wanted the challenge so I plowed ahead anyway. 1.0 shipped and people liked it. Really liked it! I got a handful of emails with kudos and feature requests. I wanted to get cracking on GlobeJot but decided I would spend a little time adding some customer requests to Tallymander first. A couple more weeks of development and Tallymander 1.1 was submitted. I forgot all about it.

Until one night, around midnight, when I got the “Ready for Sale” email that iPhone developers live for. Tallymander 1.1 was live.

And an App Store Staff Favorite. I peed myself a little. There followed a slew of copycat apps following this prominence. So it goes on the App Store.

The future

Tthanks to a handful of enthusiastic users and a little help from Apple, Tallymander managed to make me a tidy bit more money than the $40 I had expected. About $4,000 to date, in fact. Not bad for an app that started as a two week UX trial.

It wasn’t enough for me, though. The best thing about Tallymander was getting emails from customers with wildly unexpected and diverse use cases. I haven’t gotten a single one that’s like another. The greatest commonality across all the customer emails boiled down to two main themes: better organization and data analysis.

My customers weren’t the only ones with ideas on how to make Tallymander better. A minor point release with a bug fix was rejected by Apple in April. The reason? The reviewer didn’t understand how an existing interface element should work and rejected because it didn’t work according to his expectations.

The rejection was dumb — the previous major release that had introduced the interface element in question had been approved just fine. But then it dawned on me: the interface sucks.

Kill the sacred cows

Tallymander’s interface had won many fans, even at Apple, but there was one problem: it was too inflexible. To tally, you tapped anywhere on a tally’s cell:

Each cell had a little indicator that showed what mode it was in: addition or subtraction. You could temporarily change all modes globally with a sort of “shift key” in the toolbar. 1.2 introduced a “caps lock” style option for this shift mode, which is when the whole UI, for me, went to hell.

Mission 1: Fix the interface

Tallymander’s interface, where it worked, worked really well. First, you could count an infinite number of things. Since it used UITableView, which can store as many cells as you want, it could scale to many tasks. Whether you’re counting two things or twenty, Tallymander had you covered. This was an enormous advantage over some of the other early tallying apps.

The other major benefit was ease of interaction. The hit box for the user to interact with any given tally was 320 x 80 pixels. Large targets are easier to hit. Big win, especially if your attention is on something other than your iPhone.

The secret sauce to Tallymander, the reason why people love it, is the one that has evaded almost every other competitor. There’s a user-definable tally setting that lets you shake the iPhone to increment the count. Tallymander  vibrates when a successful tally is registered this way. The first time someone does this, their eyes light up. Then they do it again. And again. And again. It feels good. So no matter what else, that had to stay.

Aside from these things, it was time to take the rest of the UI out and shoot it. Shift mode? That sucks. Separate modes to reorder and edit? That’s crap.

Ending shift mode meant add and subtract had to live together, in harmony, at all times where you’d be tallying. It took many sketches to get something I wanted, but I ended up with this configuration:

Tap anywhere on the left, you get subtraction. Tap anywhere on the right, you get addition. The hit box is still pretty generous and the tradeoff in the ease of switching between those two tasks — just move your finger — made it worth doing. The cell itself is also smaller so that more tallies can appear onscreen at once. The other major change: no more alarm clock style numerals. They had to be pre-rendered as images and while I liked the look, the pre-rendering limited the kinds of data that could be displayed in the counter field. The new counter is stylized in homage to the old, replacing its seven-segment grunge with clean OLED-style pixelation.

The death of shift mode is exaggerated. It’s still around, but now it makes more sense. It is config mode and it shifts all cells into a very different realm of tasks: resetting counts and changing tally-specific settings.

This works very well. You can switch into config mode, make all the changes you like, then get back to your tallying. This is a lot closer to how the user works: adding and subtracting both fit in the same basic mental mode, in the end, and it’s counterproductive to separate them.

Best of all, deletion and reordering were reunited as one edit mode:

With addition and subtraction living in one spot with no clearly defined button, it was important to give the user some kind of visual feedback. Most buttons on the iPhone darken as the user touches, then register an action when the touch lifts. This was inappropriate for Tallymander — counting needs instantaneous feedback. Delays lead to confusion. Instead of darkening a region, Tallymander 2.0 glows according to whatever interaction the user has selected:

The glow matches the color of whatever gem corresponds to the action the user selected. Here, the user has tapped the addition side of the cell. There’s also a satisfying click sound, for users who want it.

Finally, I hated the initial look of the UI and rebuilt it. The shipping app looks like this:

The last excision of suck was the reset confirmation. Previously, Tallymander popped up an action sheet asking the user to confirm whether or not they wanted to reset a given count. Time consuming. Worse, this option could be switched off on a per-tally basis, leading to inconsistent expectations. In 2.0, tapping a cell’s orange reset button puts it into a temporary “are you sure?” mode, changing its title label with instructions to confirm. If the user taps again, the count resets. If not, after a brief delay, it switches harmlessly back out into its normal mode.

This lets experienced users quickly reset things while preventing accidental data loss. It’s a small detail but it’s one of my favorites.

Another small refinement: the table that contains the tallies will never come to a stop with a tally half-on, half-off the screen. The cells are always nudged so that they’re completely visible.

Mission 2: Customer requests

You’ve got a lot of data. You’ve got questions about your data. What do you do?

If you’re using a spreadsheet, you type up an equation for some quick analysis. I’m a huge spreadsheet nerd, so I like this freeform approach. Customers wanted percentages of this and that and while I could easily provide a one-size-fits-all, pre-canned percentage tool, that’s not how I roll.

Tallymander 2 lets you build chains of equations, called computations. Comps can use any tally as input. They can also use other comps. You build comps with this UI:

Each step uses the result of the previous step as its first input, lets the user select an operation, then a second input. As each input changes, the result of the computation is updated accordingly. You can even format the final result as a percentage. This kind of data analysis has a lot of benefits, especially for those keeping scores for athletics or tabletop gaming.

I’m pretty happy with how this came out, with one snag: since there’s no way to do PEMDAS with this, you need to set up other computations to handle parenthetical parts of a given equation. 3 + (Red roses x – 4, for example, would require the creation of two computations. I think I can solve this by allowing sub-computations that don’t show up in the many tally list. Something for 2.1

The other big request was the ability to group tallies together.

Done. Set up as many groups as you like. An implementation detail currently means you can’t move a tally from one group into another. I’ll find a way around it for 2.1.

Mission 3: Object Model

Implicit in any new version of Tallymander was the need to create a proper object model. The Tallymander 1.x model was, and I’m cringing here, a collection of NSDictionary objects stored to, yeah, NSUserDefaults. C’mon! This is not how you want to build your object graph, folks. It was an easy way to wrap my mind around the data I needed to store early on. It worked in the beginning but only with much nasty, nasty code.

Luckily, two things happened since I first wrote Tallymander. First, I learned how to build model objects and their relationships by hand. Second, Apple brought Core Data to the iPhone, which does all that heavy lifting for you. For 2.0, I was ready to do it right.

Joyful. That’s the only word to describe working with Core Data. It’s an outstanding, powerful and well documented framework. What would have taken me days to code by hand I can set up in Core Data in one afternoon. I hit an occasional bump or two but always had Stack Overflow to get me back out of the woods. Very glad to have this tool as a developer. 2.0 would have taken a lot longer without it.

But I wasn’t done with my rickety NSDictionary-based model from 1.x. I got to play with it one last time when I wrote the import code that converted the old data to use the new, shiny model. The worst code is what you wrote eight months ago, I swear it.

Kitchen sink

Thanks to Core Data, it was easy to build a pile of new options for tallies. Some of these are customer requests, some are just ideas I had that might be fun.

One of my favorites is the icon picker:

Twirl the wheel to change the icon. There are about fifty to choose from. Of all the UIs I’ve ever built, this is one of the most fun to use. The icon in the preview at the top updates as the wheel is moved. I like playing with it.

The icons are from the excellent Glyphish collection. Awhile back I contributed to the author’s Kickstarter project. As a backer, I was rewarded with access to the source vector files that make up the icons. Useful stuff and a great starting point to build Tallymander’s icon collection. Sadly, Tallymander is not blessed with the Glyphish “awesome” designation, but you can’t win ‘em all.

If the built-in icons don’t strike your fancy, you can insert one from your library, too.

I’m also liking the color picker:

Another advantage of ditching pre-rendered graphics for the counters: color options galore. I picked some tasteful ones, mostly from Apple’s Crayon Picker palette.  I like this arrangement better than picking colors off of a list. Everything is visible on the screen at once.

Broke some new ground with custom UI in 2.0. In all, I like how it came out. These are big wins that add a lot to the user’s ability to make Tallymander their own.

Sharing

The final chunk of functionality that needed to be built was better sharing options. 1.x allowed an email report to be sent from the application. This was decent but with all the new features and depth in 2.0, I wanted to go further.

CSV export ended up being much, much easier than I could have guessed. So that’s in there, it works and I’m happy.

More exciting is every time I play with the new, full-on sharing feature. Tallymander will let you send your whole setup to someone else.  It’s a combination of Core Data, Amazon S3 and the ASIHTTPRequest API. ASIHTTPRequest is a superb bit of code. Drop it in, read the docs and you’re putting and getting data from the web. Stable, easy to understand and an enthusiastic developer at the wheel. Saved me much pain, I’m certain.

And beyond

So that’s 2.0. Already I have a mounting list of new refinements and additions I’d like to make. It’s a fun app, though, and my proudest yet. Thanks to my enthusiastic customers. I couldn’t have done 2.0 without your excellent feedback. It was quite a trip: Tallymander 1.2 had about 2,000 lines of code in it. 2.0 has around 8,000 and it’s a complete rewrite.

I’m excited to keep tearing into the future of Tallymander and my other apps. As the first full-featured app I’ve built since going full-time, Tallymander really helped me find my tone and style as an iPhone developer. This stuff is so much fun.

It blew my brain open. It’s the coolest retail experience in the history of the world.

There’s only one problem: you gotta keep track of a lot of data if you want to get out of there with everything you wanted to take home.

Enter SwedeShop, my unofficial IKEA shopping list app. Find out more at the main site:

http://www.danilocampos.com/apps/swedeshop/

There are a laundry list of problems facing the growth of the App Store. I won’t bother to rehash them here. Let’s focus on the one that most thoroughly jeopardizes the future of developer businesses: Customer Service. Every other problem can be overcome or worked around but without the power of caring for your customers, your business has no reason to exist.

In an aside to a link last month, John Gruber muses:

I’m wondering how much of the problem is that the App Store is built on the foundation and framework of the iTunes Music Store, which was designed from the outset specifically as a venue for selling 99-cent downloads.

This is the most crucially important point: the iTunes Store was never designed to sell software. Among other things, Craig Hockenberry enumerates all the ways in which the App Store is hobbled by this historical truth. It’s a good, important post that you should read if you care about this kind of stuff. But it doesn’t address long-term outcomes related to customer service that will doom the developer community.

As an iPhone developer, I have no control over my storefront – Apple manages it for me, with basic data I provide. On the one hand, this is incredible news: access to a huge pool of customers, a complete distribution infrastructure and – best of all – I never have to worry about payment processing.

There’s just one issue: Apple doesn’t give a damn about my relationship with my customers.

Generous, attentive, impassioned customer service is an important piece of any successful business. My customers mean the world to me. Unfortunately, iTunes does not provide a clear, encouraging feedback channel.

User Reviews

When you’re selling music, user reviews are a simple tool. Much is subjective, but overall quality will be reflected in the reviews.

With software, the reviews have become more complicated. The most tantalizing way for a customer to speak out about software that is giving them problems is to write a review. And that’s what they do. Bug reports, feature requests and anything else that comes into their minds gets dumped into the reviews. And why not? The ability to write a review is prominently featured and uses a built-in, official form. It’s infinitely more seductive than leaving iTunes to write an email to the support contact. It’s also a venue provided by the same service that is taking the customer’s money, so it feels more intimately linked to their purchase than anything they can do on an external website or in their email client.

This is infuriating since the communication is strictly one-sided. There’s no way for the developer to follow up on these reviews to ask for more information. Without that information, acting on a bug report is often impossible. The worst part is that without dialogue, it’s impossible for the customer to learn more about their problem, discover workarounds and discover that there’s a living, breathing person who truly cares about the quality of the software they’ve just purchased.

Like it or not, the iTunes user review becomes the support form of last resort.

The Consequence

There are ways around this. Tap4Help is an interesting example, providing a built-in feedback and support request system. Developers, like Lucius Kwok, report some success explicitly declaring their email right in their application description with a call to action encouraging its use. I do this, too, but it doesn’t catch them all.

Why not? Nothing will ever come close to the power and authority of iTunes itself. I theorize that part of the reason so many customers prefer the review form to using a support email or link is that they know that iTunes will provide them satisfaction. No matter what, iTunes will show their review. They will be heard.

By keeping these customers so thoroughly at arm’s length, Apple retards the formation of relationships that will build developers’ business. I’ve turned angry emails into loyal customers through the power of honesty and genuine interest in customer issues. I’d desperately love to provide that dialogue for every customer, ever, but iTunes, under the current system, will continue to siphon off some portion of those opportunities into its black hole of customer reviews.

Having good conversations with your customers is as essential and non-negotiable as having an engine in your car. When Zappos tweets at me in thanks for my praise, I feel as though my relationship with the company has been further validated. When Netflix gives me complete and generous support when I have trouble with their service, I feel respect for them, since their conduct conveys respect for my business.

It’s all about how the customer feels. If you never get to talk with them, you’ll never get to impact that feeling.

Let’s Do It Better

This is not a hard problem to solve. If you happen to work on the iTunes Store infrastructure team, you may feel differently, but the company you work for is in the business of accomplishing the impossible on a fairly regular basis. My sympathy is limited.

Developer Review Replies

This is the easiest part. Let the developer reply to user reviews. This isn’t groundbreaking and I’m the eight thousandth developer to suggest it. So make it happen. The developer can join the conversation and solicit additional information so that bug reports that go into the reviews can actually be productive. Notify whomever left the review that they have a response via email. For bonus points, let the customer reply directly to that notification to reach the developer.

Feedback/Support Form

Let the user provide feedback or support requests through an official, iTunes-embedded form. Send the feedback to the developer via email, with an anonymized reply-to address, like craigslist uses, so Apple can cover their ass on privacy concerns. For bonus points, provide a rating for each application that states how responsive each developer is to requests sent via this form.

There is no step three. With those two provisions, an open dialogue has been created for anyone who bothers to seek one. Software, even for the iPhone, is not music. The one-sided echo-chamber conversation of the iTunes Music Store does not work in the App Store. With the two modest tools I’ve described, developers will have an infinitely easier time creating the relationships they need to build their business.

I’m not going to hold my breath. Hopefully Apple is working on this stuff, but in the meantime, I need to figure out better ways to put myself in easy reach of my customers.

But they called me. I had a job.

And I loved it. I’d never had more fun in my life. Thanks to a handful of adult mentors, I went from being shy and insecure in front of strangers to being outgoing, helpful and outrageously courteous, as befitted Publix’s customer service mission.  I got to meet people, learn about their lives and help make their day better, all in the time it took to bag up an order and pack in a car. Publix has a firm “no tipping!” policy and this was spelled out on a button affixed to my apron at all times. Despite this, not a week went by where a kindly retiree or harried but grateful parent didn’t stuff a couple bucks into my hand or pocket, buying me a sandwich or drink to end my shift. With a home life that was terrifyingly unpredictable and school that was tedious and unsatisfying, Publix, the people and the tangible benefits of my work there, became an escape that I craved.

There was plenty of reward in the fun of the job, but I found that throwing myself into my work with such gusto had other perks. When all of the front service clerks got reviews, there was much kvetching in the break room. Nickels and dimes, my teenaged colleagues moaned. They barely gave them anything for a raise. When my turn came, my boss, Mr. Starkey, called me into his office. After rattling through his estimate of my performance, I was given a fifty cent raise. It was the largest, Starkey confided, that anyone in my group had gotten. In retrospect, too, I realize that I was rarely tapped to do cleaning chores, since my management seemed to prefer me in front of customers as much as possible.

It was all so perfectly Randian, in a way that satisfied my then-Randroid brain. I gave honest effort in exchange for honest reward and recognition. Love your work, I thought as I pushed a pile of carts back into the store, and nothing feels like work.

Of course, it wouldn’t last. Home, as was its wont, took another lolloping, staggering jolt. For the second time in less than a year, we were moving away. Mr. Starkey was crestfallen. He’d been eager to groom me into cashiering and beyond. These were remarks that were and remain deeply flattering – it didn’t seem like he especially enjoyed terribly many of the other kids who had my title. At my request, he eagerly typed up a letter of recommendation. My favorite line, then and now:

“I would rehire him immediately if he were to return to Sarasota.”

I enjoyed it both for the heartfelt endorsement and for the tiny, whimsical implication that I was somehow in control of my existence.

I went on to be a salesman, an intern, a marketing manager and a project manager. With each job, I hoped to find the feeling I knew at Publix. The feeling of throwing myself into my work, enjoying every minute, and always hungry for more.

To be sure, I had some amazing jobs in the years since. Tremendous opportunities that provoked growth and change. But none of it could ever recapture the lost innocence of that first, magical time I worked at the supermarket. This realization, each time I started a new gig, was always a tiny disappointment.

For almost a decade, I’ve drawn a paycheck from someone. Until now. Not having been to the office, or any office, feels vaguely like retirement. Except there’s a ton of work to do.

And it’s back: that magic Publix feeling.

I love my new job. I’ve spent the last week building a new iPhone app from scratch. My new boss, me, really likes how it turned out. This is the most incredibly rewarding productive activity I have ever chosen for myself. The app is about done; I’ll have more to say about it soon. The most tremendous and powerful discovery came through its creation: I love developing applications for the iPhone. I can do it all day and night until my fingers hurt and still want more. It’s the most satisfying thing I’ve ever invested my working time doing. All I want is to get better and keep building.

Like Publix ten years ago, it doesn’t feel like work. It’s fun. It’s… wonderful.

Time will tell if this feeling and the products it creates will be sufficient to feed and house me. For now, I’ve got enough to hold out for awhile and give it everything I’ve got.

It’s a scary prospect to abandon security and regular cashflow, move across the country, and go into business for yourself, all the while hoping to hell everything will work out okay. Like many projects, it’s one of those things where if you truly took the time to consider all the attendant difficulty, complication and risk, you’d never bother to do it all.

It’s the best decision I’ve ever made.

The good news is that nearly two weeks ago, GlobeJot’s major issues had been diagnosed and corrected. The bad news is that, until Apple gives the go-ahead, the fixed version is not available for your enjoyment.

Learn more at the main site.