Archive for the 'iPhone' Category

More good iOS games

Saturday, May 25th, 2013

Inspired by this post from last year by Mike Lee, here’s a list of the best games from my iOS app library.

Many games are excluded, for any of these reasons:

  • Games on this list must not be violent (e.g., I excluded Carmageddon and even Bastion, Sonic 2, and Sonic 4)
  • Games on this list must not be Zynga-tastic (e.g., I excluded Draw Something)
  • Games on this list must not be on last year’s list (see Mike’s post)

Also, I’ve restricted myself to iOS games. Some of the games below are available on multiple platforms, but all of the links are to the iOS App Store.

The games

(Enigmo violates the “not on Mike’s list” requirement, but I gave it a pass for two reasons: because I linked to both the iPhone and iPad versions, and because I linked to the sequel.)

iOS device user guides on the iBookstore

Sunday, October 16th, 2011

Apple has user guides for their three iOS devices (not counting the TV, in which iOS is an implementation detail), for both iOS 4.3 and 5, free on the iBookstore:

iOS 4.3

iOS 5

Conferences 2011

Monday, September 12th, 2011

It’s that time again! Just like last year, there are a bunch of different conferences going on; unlike last year, I’m not going to even attempt to list all of them.

The two that I have a reason to mention are:

  • Voices That Matter. This time it’s in Boston, November 12 and 13. Their early bird pricing is still on through September; I’ll let their site tell you more. As I do whenever I mention it here, I have a coupon code for it, which is BSTBLOG. As usual, due to time and expense constraints, I won’t be attending this one.
  • MacTech Conference. I’m presenting again—same topic as last year, how to recognize, find, and fix bugs in Cocoa applications, but this time it’s the Xcode 4 edition. The early bird period has ended, but you can get the same $500 off by signing up through this referral link. The time and place is November 2, 3, and 4 in Universal City, California.

Last year at the MacTech Conference, I brought with me some of my useful Cocoa links business card. I’ll be doing that again this year, so if you attend the MacTech Conference, feel free to ask me for one.

I hope to see you at the MacTech Conference!

How to make me lose all interest in your app and not even want to try it much less buy it

Tuesday, April 26th, 2011

Choose any—or, preferably, none:

  • Make custom buttons, but don’t hire a professional designer to design them. Draw your UI in your pirated copy of Photoshop and make the best buttons you, fellow non-graphically-superpowered programmer, can manage, which look like you downloaded them from GeoCities in 1995 or got them out of a “1001 Buttons!” book from the same year.
  • Make custom UI controls (especially buttons) simply because you can.
  • Fill your App Store page’s “screenshots” section with images that are not purely screenshots. Showing an iPhone 4 with your app on it is a minus. Showing an older iPhone is another minus. Putting in your own inane blather marketing copy with your paint program’s text tool is a minus. Putting the iPhone and/or text on any kind of background is a minus. Any image that does not show the app at all is 500 minuses.
  • Show screenshots, but only of some of the app. Leave me wondering whether your app has the feature or UI pattern I’m looking for. (If your app is free, I’ll try it and find out. If it’s not, I won’t.)
  • Custom backgrounds without (good) custom UI. Extra debit if your background is plain white.
  • Abbr btn nms.

How to keep me actually interested and maybe even get me to buy your app:

  • If you make custom UI, make it awesome. Make a truly original UI that would belong on the cover of Macworld. Make it a custom UI with a purpose that guides and justifies the customizations. (Beware the difference between “purpose” and “theme”.) Otherwise, stick to plain Cocoa Touch controls wherever possible. Functional beats ugly.
  • If you go functional, follow the HIG. Either way, keep things clean and well-organized. Don’t force too much into a single screen. If you “have to” pack multiple things on a line, that’s too much. If you “have to” abbreviate words, that’s too much. Consider cutting features; simplicity is a virtue. If you need to break things out into other views, do it.
  • The screenshots section is for screenshots only. If you need to indicate a gesture, composite in a finger and an arrow, and don’t do that in more than one screenshot. No added text. Ever.

Don’t miss the comments. I’m sure some of you have some other don’ts to suggest that I forgot.

The application delegate and the new singletons

Friday, March 18th, 2011

Here is a global variable:

Wizard *gWizard;

I’ll call this a zeroth-order global, on the premise that I need to talk to exactly zero objects (including classes) to gain access to this object.

Next, let’s look at a singleton:

[Wizard sharedWizard]; //hope he's not busy

I’ll call this a first-order global, as we need to ask the class for it (1 step) to gain access to it.

Now, here’s a second-order global:

MyAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

(I use UIApplication here because I see this most frequently in Cocoa Touch code, but the pattern applies equally to Cocoa.)

And here’s a third-order global:

Wizard *wizard = [appDelegate wizard];

I need to (1) ask the UIApplication class for the application object, (2) ask that for its delegate, and (3) ask that for the wizard. (Assume here that wizard is a property, not a factory method that creates Wizards on the fly.)

None of these is any less global. If I can get to it from anywhere in the program without knowing about it directly, it is global.

Therefore, all the problems of globals apply:

  • What if two threads want to use the same Wizard?
  • What if the Wizard has a delegate of its own, and I have two objects that want to be its delegate?
  • What if the Wizard keeps internal state that may be corrupted by multiple objects trying to use it? (Nothing should have to worry about this outside of the Wizard itself.)

Your application’s objects form a graph. It should not be a complex one like this:

At the top, the application object. From it, its delegate. From it, your controller objects and a wizard. From each controller object, a path (colored in red) back to the delegate and then to the wizard.

Whenever you have paths bouncing around off of other objects like that, that’s a problem. The red arrows in the problem graph show where you violate the Law of Demeter.

Your object graph should, instead, be straightforward:

At the top, the application object. From it, its delegate. From it, your controller objects. From each one, a wizard.

Note that each of your controllers should own—or, if you prefer, hire—a Wizard all to itself. This eliminates contention between objects and reduces the likelihood of contention between threads (assuming each of the owning objects is supposed to only work on a single thread and not juggle multiple threads).

If contention is not a problem and you have a good reason why there should be only one Wizard, such as memory pressure or union regulations, then use a singleton. But use a real singleton, and only when necessary, and beware of singletons in disguise.

The new and improved Cocoa links card

Tuesday, March 15th, 2011

I’ve previously mentioned that I made a business card full of useful Cocoa and Cocoa Touch links to give to new Cocoa and Cocoa Touch programmers at events such as CocoaHeads.

Today, I have updated it and given it a web page. 1-up and 10-up (US Letter) PDFs are available there, as well as the full list of unshortened links.

I encourage you to print out the 10-up onto perforated business card paper, or have it professionally printed (keeping in mind that you probably won’t need 1000 of them), and make the cards available to novice Cocoa and Cocoa Touch programmers at the CocoaHeads or NSCoderNight events you attend. Just please be sure to print both sides, since my credit link is on the back.

Apple documentation search that works

Sunday, March 6th, 2011

You’ve probably tried searching Apple’s developer documentation like this:

The filter field on the ADC documentation library navigation page.

Edit: That’s the filter field, which is not what this post is about. The filter sucks. This isn’t just an easy way to use the filter field; it’s an entirely different solution. Read on.

You’ve probably been searching it like this:


(And yes, I know about That often isn’t much better than without it. Again, read on.)

There is a better way.

Better than that: A best way.


First, you must use Google Chrome or OmniWeb.

Go to your list of custom searches. In Chrome, open the Preferences and click on Manage:

Screenshot with arrow pointing to the Manage button.

In OmniWeb, open the Preferences and click on Shortcuts:

Screenshot of OmniWeb's Shortcuts pane.

Then add one or both of these searches:

For the Mac

Chrome OmniWeb
Name ADC Mac OS X Library
Keyword adcmac adcmac@

For iOS

Chrome OmniWeb
Name ADC iOS Library
Keyword adcios adcios@


Notice how the results page gives you both guides and references at once, even giving specific-chapter links when relevant. You even get relevant technotes and Q&As. No wild goose chases, no PDF mines, no third-party old backup copies, no having to scroll past six hits of mailing-list threads and Stack Overflow questions. You get the docs, the right docs, and nothing but the docs.

For this specific purpose, you now have something better than Google.

Another Voices That Matter conference coupon

Friday, January 28th, 2011

The next Voices That Matter iPhone developers’ conference is April 9–10 in Seattle. Early-bird pricing lasts until February 25, and the coupon code this time is SEABLOG. The total for the “core conference” with both discounts is $395 USD.

As usual, I don’t expect to be there. Have fun without me!

End of the Graveyard

Saturday, December 4th, 2010

The iPhone Application Graveyard is now closed.

I’ve been meaning to do this for months; I’m just now getting around to doing it.

I have a few reasons:

The Graveyard has served its purpose.

The iPhone App Store today is more open and more free than it originally was. The rules are now available to App Store developers, and several apps that Apple previously either rejected or “pocket rejected”, most prominently Google Voice, are now available in the Store.

I don’t know how much of this is attributable to the Graveyard and how much is just Apple having figured these things out, but to whatever extent the Graveyard is responsible, it has done all it can.

The Graveyard can do no more.

Apple’s made very clear that they intend to “curate” the App Store. It will never be a completely free, do-as-thou-wilt market like the Mac market still is, and I have no hope that Apple will ever make the iPhone App Store optional like the Mac App Store will be.

I see no way that the App Stores can ever be more free without losing that curation factor. And it is a factor—I can’t ignore that Apple checking every application probably, hopefully filters out some effluent from the influent stream.

I don’t update it.

I’ve got a dozen different things to do that are more important than updating the Graveyard.

I want to work at Apple.

Cold, hard reality is that I want to work for Apple, and they will not hire a person that has a page on their website decrying their policies. (Don’t get me wrong: I wouldn’t expect them to.) This isn’t the only reason why I’m killing the Graveyard—everything I wrote above is true—but it is one of them.

So, this position is now open.

If you want to keep the Graveyard alive, you can do that by taking it over.

The Graveyard is implemented as a couple of plain-text hand-edited databases and a Python script that converts them to the web page (as a static HTML file) and Atom feed (as a static XML file). This is how the Graveyard stayed up in the face of being Fireballed, Macworlded, etc.

You can keep it that way, or you might turn it into a wiki. I leave the choice to you.

If you want to take over the Graveyard, email me. I’m sure you know my email address by now. I’ll send whoever I think can best run it a zip archive of the data files and Python script.

You may also be interested in the Application Submission Feedback site. I don’t know who runs it, but it’s a great guide to what you can’t do in the App Store.

An iTunes imagine spot

Thursday, June 10th, 2010

Nik Fletcher writes:

If you’re an iPhone developer, you’ve probably been using AppViz, AppFigures or AppSales Mobile to download an process your iTunes sales reports. Today, however, Apple have released a new app of their own: iTunes Connect Mobile (iTunes Store Link)..

Wouldn’t it be cool if they released a version of iTunes Connect that could upload music and movies as well as view app statistics?

Imagine, for example, a moviemaker recording a movie on their iPhone 4, editing it in iMovie on their iPhone 4, and uploading it to iTunes from their iPhone 4.

Setting the iPhone API documentation to iPad display mode on your Mac

Monday, April 5th, 2010

Those who’ve bought iPads have noticed that the iPhone API documentation comes in a special iPad-optimized flavor:

Basically, like an iPhone app for viewing the iPhone documentation. Here's a screenshot of the page in Safari on my Mac.

Yes, that’s desktop Safari showing it.

Contrary to my expectation, it does not use user-agent sniffing to detect an iPad. In fact, it’s detected by a JavaScript script (credit) when you go to an iPad-specific front page.

The code has a debugging feature, which they left in and you can (for now) enable to use the iPad display mode in your WebKit-based browser. Here’s how to enable it:

  1. Open any page on
  2. Open this URL:

    javascript:localStorage.setItem('debugSawtooth', 'true')
  3. Go to the iPad documentation list.

There are actually two interfaces, corresponding to the two orientations of a physical iPad. The one I showed above, with the API tree in a sidebar, is the landscape orientation; portrait moves the API tree into a pop-over, under a button labeled “Library”. The page chooses one or the other by the aspect ratio of the window.

“Sawtooth” has some drawbacks:

  • On a Mac, your scroll wheel (or two fingers) won’t work; you must drag the interface instead, which corresponds to finger-dragging on the actual device.
  • Once the interface loads, its size and orientation are fixed; it won’t adapt to a window resize until you reload. This, too, is only a problem on a Mac (you can’t resize your iPad).
  • There’s no way to copy a link to a specific document, unless you can find an internal link (the API-tree table view doesn’t count). This can be a problem if you want to link to, say, a framework reference.
  • You can’t get the Sawtooth interface unless you go through the iPad front page. If you go to a framework reference, class reference, programming guide, or other more specific page, you’ll get the regular interface. Same thing when going through the regular front page.

Even so, it’s pretty spiffy. I wish I had a version with all of the above problems fixed for viewing Mac API documentation.

* Credit: JR Ignacio found the JavaScript code and excerpted it into a GitHub paste.

Voices That Matter iPhone Developers Conference 2010

Monday, February 22nd, 2010

I’m still Mac-only, so I still won’t be there, but here’s the information for this year:

  • The conference is in Seattle, Washington on April 24th and 25th.
  • The speakers, including Aaron Hillegass, Jonathan “Wolf” Rentzsch, Erica Sadun, and Eric Buck, will cover many different topics, including Core Data, Core Location and MapKit, in-app purchasing, UI design, and OpenGL ES.
  • Early bird pricing is $200 off until March 12th.
  • If you use the coupon code “PHBLOGS”, you’ll get another $100 off.

(I do still wonder what the “PH” stands for…)

If this sounds good to you, register for the conference.

See also Brent Simmons’s post about it. He wants to play pinball with you.

An introduction to Cocoa and Cocoa Touch

Wednesday, February 3rd, 2010

If you know someone who’s recently taken up programming the Mac or the iPhone (or both), please give them one (or both) of these links:

As a frequent answerer of questions on Stack Overflow, I see certain patterns—not just frequently-asked questions, but also frequently-unasked questions: Things that are biting the questioner that they don’t know about.

Sometimes they’re thinking about things the wrong way (e.g., using property list objects where they should have a model). Sometimes there is a route to a solution (“my app is slow” “run Instruments”), but they don’t know about that route. Often, they’ll use wrong terms that are right on another platform (like “member variable”), like a speaker using their native language’s pronunciation rules when speaking a foreign one.

To help people over these speed bumps, I’ve composed an introduction for new Cocoa and Cocoa Touch programmers. (Both of the above links redirect to it.)

If any part of it doesn’t help them (i.e., is unclear or wrong), I’d appreciate it if you’d let me know, either here or by email.

The iPod Radio Remote and Griffin Navigate

Saturday, January 9th, 2010

Some of you know that I use a second-generation iPod nano (the best iPod ever) with an iPod Radio Remote. There are two generations of iPod Remote; here they are side by side:

iPod Remote and iPod Radio Remote

The original is on the left. It was for the 2G iPod (that’s what I had, anyway) and possibly some other models. That remote didn’t have a radio tuner in it. The one on the right, the one that has a Dock connector and looks like a 2G iPod shuffle, is the iPod Radio Remote.

The iPod Radio Remote never did work with the iPhone and iPod touch. Every introduction of a new iPhone or iPod touch model (including the originals) made clearer that they’d either make a third generation or kill it. Sometime around the time when they introduced the new Apple Remote, they chose the latter.

At some point, Griffin Technology introduced their Navigate. I spotted one today at Walmart for $20 on clearance and snapped it up. Walmart normally sells it for $50, and MSRP is $60.

Not only does the Navigate work with my 1G iPod touch, it adds a display showing the current track. The iPod Radio Remote never had this! The picture on Griffin’s website doesn’t do it justice; it actually looks much better, as shown in this video:

(If you want to really see how good it looks, click through to the YouTube page and watch it there.)

Like the Radio Remote, the Navigate has a clip. Unlike the Radio Remote, it’s not a moving part; it’s just a fixed, flexible (but not too flexible, but not too stiff, either) bit of plastic. Time will tell how easy it is to break.

True to its name, you can even use it to navigate your music: It will let you pick a playlist, artist, or album to listen to, and change the shuffle setting. However, it does not let you go straight to a specific song, which makes that feature useless for me. I understand why that limitation exists, though: It would be much more difficult to scroll to it with the Navigate’s buttons than with the iPod’s own click wheel or touch screen.

Navigating the FM band isn’t exactly easy. When moving along the frequency band itself, next and previous move one frequency-stop at a time. You can set presets, but only four of them. It’s not at all obvious how to set and use them; I’ll leave it to the manual to explain it. Ameliorating this problem is that it remembers the last station you had tuned, so it’s not like you’re going to have to deal with the preset menu every time you turn on the radio.

I do have a couple of significant problems with it.

The first is that it doesn’t remember your volume setting. (The Navigate has its own volume setting, separate from the iPod’s; the iPod’s volume setting has no effect on audio through the Navigate. This is another difference from the Radio Remote, which had no volume of its own.) The Navigate doesn’t have a battery; it relies on the iPod for power, so it goes dead when you unplug it. Then, when you plug it back in or plug it into a different iPod, it’s back to the default volume, which is quite loud for me. This will probably grate on me a bit.

The other problem is that it doesn’t fit in my iPod touch’s Dock connector with its SeeThru hard case on it. My iPod nano doesn’t have a case on it, so I don’t have that problem with that iPod. If you don’t have a case on your iPhone or iPod touch (or other iPod), or you use a different case that won’t conflict with Griffin’s Dock connector, then this won’t be a problem for you.

I hope a future version of the Navigate will remember the volume setting and have a slightly thinner Dock connector so that it isn’t blocked by my iPod touch’s case. Even now, though, I consider the Navigate a worthy successor to the iPod Radio Remote, primarily because of the display, secondarily because of the iPod touch (and iPhone) compatibility.

Here, have a coupon

Sunday, July 26th, 2009

Voices That Matter: iPhone Developers Conference
October 17th and 18th.

This October 17th and 18th, there’s a conference for iPhone developers in Boston, which the organizers asked me to attend.

The conference is called Voices That Matter: iPhone Developers Conference, and the titular voices include Aaron Hillegass (famous for his book), Erica Sadun (famous and infamous for her jailbreak work and advocacy), Bill Dudney (famous for his book), Stephen Kochan (somewhat famous for his book), Jonathan “Wolf” Rentzsch, Fraser Speirs, and Daniel Jalkut.

As most of you know, I’m not an iPhone developer—I write for the Mac only. So I declined that part of the offer.

The other part was a coupon for you, my readers. I know many of you probably are iPhone developers, so I asked whether they would still like me to give you that coupon code. They agreed, so here it is:


(Those of you who read Jesper’s weblog may recognize it.)

Without the coupon, the registration fee is $495 until September 12th, $695 thereafter. The Word document they sent me says that that the coupon will knock $100 off.

Enjoy the conference!

finetune vs. Pandora

Tuesday, January 13th, 2009

The most popular mix-and-match-music app, according to the completely objective score of how often I hear its name, is Pandora.

Pandora's application icon.

Most of this popularity came with their release of an iPhone app back in July 2008. The iPhone app makes the site portable: previously, you could only listen to Pandora while chained to a browser (or a SSB), but now you can listen to it anywhere that’s in cell range.

Pandora now has competition.

finetune's application icon.

It first appeared in AppShopper’s free iPhone apps feed on 2008-11-08, but I didn’t see it then (I probably scrolled past it). I did see it when they released their 1.1.3 update back on 2008-11-31.

Its name is Finetune. Like Pandora, it’s free.

The differences:

  • Unlike Pandora, Finetune doesn’t require an account.
  • Pandora has an option to jump over to the iTunes Store to buy a song; Finetune has no such feature.
  • Finetune only creates stations based on artists; Pandora lets you name an artist, song, album, or composer.

I think Finetune does a slightly better job of selecting songs that are similar to the work of the requested artist. (Sometimes this is hard, as in the case of the Beatles, who produced very diverse work.)

One major drawback to Finetune is that, since it only lets you select based on artist (performer), not composer, it really sucks for classical music. (The service has it, but it’s little better than shuffle-play.) If you want a customized classical station, Pandora is currently your only option.

(Note: I wrote this before Pandora 2.0 came out, but it’s still accurate. If anything, Pandora 2.0 is even better for classical now, since you can now make stations by genre.)

Review: BurnBall

Tuesday, January 13th, 2009

On 2008-12-12, Tim Haines, the developer of BurnBall, contacted me on Twitter to offer me a free promo code. I accepted, and played the game on my first-generation iPod touch.

The game is basically Qix with a Sonic-the-Hedgehog-esque theme. Based on that, I give you this pull-quote:

If you like Qix, you’ll like BurnBall.

As it happens, I don’t like Qix. The main thing about Qix that frustrates me is that enemies can kill you just by touching your trail while you’re cutting off another piece of the level. This makes some sense for the Tron-based theme of some of the other Qix work-alike games, but it has the effect on gameplay that you can’t make any but incremental progress, especially after the first few levels, as the number of enemies goes above 2. Your only hope is that your enemies will see some shiny thing and leave you alone long enough to let you complete your wall; otherwise, you can only complete the level a little bit at a time.

One way in which somebody could improve Qix would be to let enemies go right through your wall, and compensate by making them more aggressively pursue you. Then, you’d stand a reasonable chance of completing the wall, if you can just dodge the enemies. Another way would be to have enemies bounce off the wall, which would provide you with a way to restrain them while you draw more wall—but that may make the game too easy.

BurnBall is graphically different enough from Qix that it could pull off either change, although it probably should be an alternate game mode.

So, basically, the only reason I dislike BurnBall is because I dislike Qix games in general.

That said, BurnBall is a very good Qix game, being both well-drawn and responsive to your control. (Since I originally drafted this post, there’s been an update that tweaked the tilt response; I haven’t tested it.)

BurnBall has an advantage over Qix work-alikes on other platforms, in that you can move in any direction—you’re not limited to up, down, left, and right. You move by tilting the iPhone.

Another advantage of BurnBall over other Qix work-alikes is that Haines holds high-score competitions with monetary prizes on the app’s Facebook page. He also posts a free promo code every time that page gets another 100 subscribers, so you may not even have to buy the game.

If you’d rather not wait for the next promo code, the app is 99¢ on iTunes.

iPhone app settings

Wednesday, January 7th, 2009

One of the ongoing debates among users of iPhone OS devices is whether an app’s settings belong in the app itself, or the Settings app.

I’m of the opinion that this wouldn’t even be a debate if it weren’t for Apple’s prescription in the iPhone HIG that every iPhone app’s settings should be in the Settings app. Mac apps don’t come with prefpanes for their preferences (with the exception of faceless background apps like Growl). Windows apps don’t, either, that I know of. GNOME and KDE apps don’t pollute Ubuntu’s Control Panel.

The iPhone is the only OS I know of whose developer recommends that app developers put their application settings in the system-wide Settings app.

As we’ve seen several times on every platform, it’s OK to break one of the local Human Interface Guidelines if and only if the violation makes the interface better.

I think this guideline is one that iPhone developers should violate flagrantly.

But there’s a problem. The iPhone doesn’t really have an icon for a Settings button. Most developers seem to use the Info icon that one of the frameworks apparently provides, but this isn’t the proper use of that icon. The Info icon means info, not application settings.

Another choice is the gear icon for Action buttons:


But, again, we have a conflation of functions. The button in question is not an Action button; it is a Settings button. This icon is not a Settings icon. (I suspect that most people who use the Action icon use it because it doesn’t have any particular association with “action”, either, other than Apple’s endorsement of it for that.)

The Iconfactory, wisely, chose differently in Twitterrific. I suspect that this was largely coincidence, as the Mac version of Twitterrific came first and already had a Settings icon; for the iPhone version, the developers simply used the same icon. It works well enough:

as seen in this screenshot of Twitterrific.

But it’s not perfect. A wrench does not say “settings”. (I offer myself as evidence: When I first saw it in the Mac version, I didn’t know it was the Preferences button.) Generally, a wrench means “edit this”, as in the context of a game.

What we need is an icon that says “settings”. Ideally, this icon should either convey the notion of a changeable state value (as the previously-favored light switch [Mac OS X through Tiger] and slider [Mac OS] did), or build on an existing association with the concept of settings.

Let’s go with the latter. I nominate the Settings app’s icon:

iPhone Settings icon

Familiar enough, wouldn’t you say?

That’s Apple’s version. Here’s my button-icon (a.k.a. template) version, in the 16-px size:

Settings button icon 16-px version.

I tried it out in the iPhone version of Twitterrific on my iPod touch. Before and a mock-up of after:


After I created this icon, I wondered what it would look like in the Mac version of Twitterrific.

Here’s the original:

…with the wrench icon.

… And right away we have a problem. These buttons are already framed; my white frame will glare here.

Fortunately, that’s easy to solve. With ten seconds of work, I created a frameless version. Here’s what that looks like:


I think we could all get used to this icon. This wouldn’t have worked at all before Apple changed the icon of System Preferences to match the iPhone Settings app, but now it can.

I don’t think it’s perfect. Perhaps a real icon designer (I’m just a programmer) can refine it. But I think it’s a good first draft. I’m curious to hear your opinions; please post constructive feedback in the comments.

If you want to use this icon, go ahead. Here’s the original Opacity document , from which you can build all the many variations of the icon. (Click on Inspector, then Factories, then find the version you want in the list and click its Build button.)

Solved problems

Sunday, November 23rd, 2008

Here are some types of apps that I’m tired of seeing over and over again on the iPhone App Store. In some of these categories, I’ve picked a winner that completely solves the problem; you’re welcome to nominate winners for the others.

  • Flashlight (solution: myLite)
  • Tip calculator (solution: Calculator—seriously, is subtotal × 0.2 so damn hard?)
  • Any app with a checkmark icon, regardless of function: Think of a different icon, please. At this point, you might as well just make the word “app” your icon.
  • App to help you find your way back to your parked car: The main problem is that all of these use Core Location rather than just tracking movement through the accelerometer. That makes the app useless if you don’t have an iPhone 3G and you’re out of cell range or don’t have a cell antenna (iPod touch).
  • One-tap contact dialer (also includes 911/999 dialers)
  • Apps that fake receiving a phone call
  • Fortune-telling/decision-making apps
  • The Puzzle desk accessory
  • Sudoku (solution: ACTSudoku and its free light version)

There’s nothing wrong with competition, but these are saturated markets. If you’re not going to solve the problem in a completely different way (e.g., by not using Core Location to set the location of the parked car), then don’t waste your time—write something else.

If you have any suggestions for other categories that should go on the list, feel free to leave a comment.

iPhone sudoku follow-up: ACTSudoku

Tuesday, July 29th, 2008

A couple of weeks ago, I posted a list of requirements for an iPhone sudoku app. At the time, no app satisfied all of the requirements, but one did come close.

Pierre Bernard of Houdah Software posted a comment that his sudoku app, ACTSudoku, satisfied all but one of the requirements I listed. The only one remaining was rotational symmetry, which he asked about.

In response to our dialog on that post, he added rotational symmetry in ACTSudoku 1.1, which Apple has now approved. You can download it now for $2.99 USD (or free if you bought one of the earlier versions).

UPDATE 2008-08-01: As of yesterday, there’s now a free version of ACTSudoku, which only generates easy puzzles. This is good if you’d like to try it for yourself, but you don’t want to spend $3 just yet.

The interface is simple enough:

ACTSudoku's interface is a sudoku grid on a wooden background, with the difficulty below it on the left and the timer below it on the right. At the bottom is a toolbar with three items: A + button, an Info button, and an X button.

Notice that there’s no row of numbers for input. The obvious thing to try is tap on a cell, and it works:

Tapping on a cell brings up a square pop-up containing nine numerals, possibly colored by pencil-marks.

In other words, the interface is obviously postfix. The key word there is “obviously”: One of my requirements was that it must be obvious how to input numbers.

The input method is not perfectly obvious, however. One thing that stumps a lot of people (going by Bernard’s response to some iTunes reviews) is the fact that simply tapping on a number in the pop-up enters a pencil-mark, rather than locking in the number. You must hold down briefly to set a number in the cell. In the comments on the previous post, I suggested swapping these behaviors; I maintain that suggestion. (UPDATE 2008-10-29: ACTSudoku 1.5 added a preference to do this. It does, indeed, make a tremendous difference in the app’s usability.)

You may be wondering what all the green dots are. Those are pencil-marks, filled in automatically by the game. This is optional; you can turn it off in the settings, if you want to be completely free to make mistakes.

ACTSudoku's settings are in the Settings app; the only control there, as of 1.1, is a light-switch controlling the automatic pencil-marks.

With the automatic pencil-marks turned on, the game will not let you enter a wrong number. With them turned off, the game will let you enter a wrong number. Either way, you can clear the cell by tapping again on the cell and holding down on the giant number.

If you tap on a cell with a number filled in, the pop-up has only that number, and it fills the entire size of the pop-up. Holding down on it clears the cell (and, if automatic pencil-marks are turned on, restores the marks). In this screenshot, the cell has a 4 filled in.
Hold down on that giant 4 to clear it from the cell.

Of course, ACTSudoku is not perfect. It has some minor problems:

  • The interface confusion that I noted above. A long tap sets the number, whereas a short tap sets a pencil-mark. This arrangement makes no sense with automatic pencil-marks turned on—and they’re on by default. It would make much more sense to have the tap lengths the other way around.
  • The northern, eastern, southern, and western blocks are have dimmed-looking gray backgrounds, for no apparent reason. This is slightly distracting (but not enough to qualify as “garish”). I would prefer if all the blocks were uniform white.
  • I’d like to be able to turn off the timer. Again, I find this distracting.

However, it satisfies all of my requirements, so I declare ACTSudoku the winner of the iPhone sudoku race. Congratulations to Houdah Software!