If you don’t already know about push notifications, a brief primer: they’re basically just like text messages, except they can be routed/categorized in ways that make them useful to individual applications on your phone.  Instead of getting a generic SMS text message when someone DMs you on Twitter, you can instead use push notifications to have the Twitter app on your phone realize a new DM has come in and alert you according to your personal settings.   When you “view” a push notification, you can be taken to a web page or app that’s relevant to its content.  Best part: the messages don’t count against any text messaging limit (for now).

I started using Prowl about 9 months ago.  My three main uses were:

• Notifying me when certain types of e-mail messages are received (using a combination of Procmail and prowl.pl)
• Notifying me when I’m addressed or mentioned in certain IRC channels (using the prowlnotify.pl script with irssi)
• Notifying me when I’m mentioned on Twitter (using Preyfetcher)

Prowl worked great, and I was very happy with it for these uses.

Recently, I had an itch to scratch with push notifications, and when I looked for someone else who might have already scratched that itch, I noticed that Prowl was last updated in August 2009.  Some of the things I wanted to be able to do with Prowl would need to be custom built.

But wait! There was this hot new app/service called Notifo that seemed to have a much more active user community developing cool new uses for its platform (including a solution for the itch I wanted to scratch).  With plans to launch an Android and Blackberry app soon, releasing their iPhone app (last updated in September 2010) for free, and a well thought out API infrastructure, Notifo is clearly positioning themselves to be THE realtime mobile notifications service.

And it turned out to be a drop-in replacement for Prowl.  The most recent version of the Twitter app for iPhone now includes push notifications, so I’m down to two uses for Notifo:

• Notifying me when certain types of e-mail messages are received (using a combination of Procmail and a custom notifo.pl script using WWW::Notifo)
• Notifying me when I’m addressed or mentioned in certain IRC channels (using the notifonotify script with irssi)

I’m also playing with some other uses:

• Notifications when new items appear in certain RSS feeds
• Notifications from our Nagios-based server monitoring infrastructure
• Notifications when certain activities happen on blogs that I maintain
• Re-routing my real SMS notifications through Notifo so I don’t need to pay for an SMS messaging add-on to my phone plan

Prowl remains a usable and time-tested solution, but the app isn’t free and the community around it seems stagnant.  Notifo is newer and shinier and will probably have some growing pains, but they’re doing it right as far as I can tell, their app is free, and their interface is more flexible.

If you’ve tried one or both out, what do you think?

Regardless of what you think of it, the “realtime web” is here, and I’m enjoying playing around with what it has to offer.  (Beyond the scope of this blog post is addressing the fundamental question about whether or not it’s a good thing to be increasing the number of disruptive, “look at me now” events I have in my daily life, but your smug comments on this matter are still welcome.)

Ever since I upgraded my iPhone to IOS4 (the latest version of the phone’s operating system), the Mail application has been flaky when it comes to syncing mail messages via IMAP. Duplicate messages, empty/blank messages, messages dated 12/31/1969, messages that are deleted and then re-appear, and so on.

At first I thought it might be my phone hardware, which had been cursed from the beginning (a story for another time), but after that phone died and Apple replaced it with a brand new one with fresh firmware and settings, and it STILL happened, I was convinced it’s the software on the phone.  Other people are having the same issue all over the place.  But it can be hard to make Apple believe this – said the Apple Genius Bar worker at the Apple Store in Chicago, “they’re probably all just using the phone wrong.”  Wha?

So I decided to look at the source code of the iPhone mail program to see if I could find the problem, but Apple doesn’t make that source code available.

So I decided to turn on the Mail program’s debugging options to have it output the results of the IMAP sync sessions, but it turns out the Mail program doesn’t have any debugging options.

So I decided to look at the log files on the phone’s operating system to see if they reported any software issues I could address, but actually I can’t look at those log files even if they exist because Apple doesn’t let you look behind the scenes.

So I decided to report the issue on the project mailing list that all of the iOS4 developers monitor, and it turns out that no such mailing list exists.

So I decided to go report the issue to Apple to see if they can help.

After submitting a case online, I was called back in 27 seconds (FAST!) and talked to Chris from Apple, who works in iPhone support.  He was very good at gauging my level of tech savvy and talking to me at an appropriate level, so he quickly confirmed that I’d already done all of the normal troubleshooting steps they recommend.  I asked him if this was a known bug, and he said not as far as he could tell.

Chris then connected me with Shawn who is a senior adviser on the iPhone tech support team.  Shawn told me that in fact I had identified a known bug with the iOS4 firmware.  VINDICATION!  He said that they’ve mostly been seeing it in gMail syncing issues, but that they’re aware of it as a wider IMAP issue.

I asked Shawn for the unique identifier number for the bug so that I could go follow the progress of a fix on their public bug tracking system, but it turns out that Apple doesn’t publish information about known bugs until they’re fixed.

I asked Shawn how I could learn more information about when this would be addressed or other recommended fixes in the meantime, and he said I would just have to wait and see.

(Chris and Shawn at Apple were excellent tech support reps within the confines of what they’re allowed to do and say.)

Bottom line: these are the horrors of using a closed-source, proprietary product for a key piece of tech functionality in my life.

What Apple can do better:

• Test its Mail software’s IMAP syncing functionality more thoroughly before releasing it to production.
• Publish information about known software/hardware issues BEFORE they’re resolved so that people having those issues can see what’s up and possibly even contribute to the resolution.
• Train its store Genius Bar workers so that they don’t dismiss a legitimate complaint about functionality problems with smiling condescension.
• I’m pushing it here, but hey, it’s my blog: release the source code for iOS and related applications.

If you’ve had this issue with your iPhone, or similar software/hardware troubleshooting experiences with other vendors, feel free to share in the comments.

Update 9/17/2010: After installing iOS 4.1 a week or so ago, all of the IMAP syncing issues seem to have gone away.  I’ve seen a few reports that problems remain for others, but it’s clear that this release included some fixes for the mail application that weren’t described in the release notes.

I’m using a 1.5GHz Powerbook G4, which uses the PowerPC (PPC) architecture. I downloaded version 2.2 of the iPhoneOS SDK, build 9m2621-final.

After the regular installation of the iPhoneOS SDK (which is really just the regular Xcode install with some additional packages thrown in) was complete, the Xcode new project menu was notably missing the option to choose the iPhone platform. On the advice of this 3by9 article, I took these steps:

1. Mount the SDK installer disk image
2. Open the packages folder
3. One at a time, install all of the .pkg files that begin with “iPhone”, using the default install destination
4. When done, you’ll have a “Platforms” directory in the root level of your Mac’s hard drive. Move the contents of that directory into the /Developer/Platforms/ directory. If you’re like me, when you’re done, you’ll have three directories in /Developer/Platforms: “iPhoneOS.platform”, “iPhoneSimulator.platform” and “MacOSX.platform”.

Once that step is done, you’ll be able to launch Xcode and create new projects that use the iPhoneOS platform and application types. But, you still won’t be able to build or run those applications, because Apple has hardcoded the “i386″ (Intel) architecture as the only valid one to compile for. Thanks to a variety of comments on the above 3by9 post and comments 23-25 on this TUAW article, here are the remaining steps to address that:

• Close Xcode and edit this file (perhaps after making a backup): /Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications/iPhone Simulator Architectures.xcspec
• Change line 12 to read Name = "Standard (iPhone Simulator: i386 ppc)";
• Change line 16 to read RealArchitectures = ( i386, ppc );
• Add this chunk before the last closing parentheses:

       // PowerPC
       {
            Type = Architecture;
            Identifier = ppc;
            Name = "PowerPC";
            Description = "32-bit PowerPC";
            PerArchBuildSettingName = "PowerPC";
            ByteOrder = big;
            ListInEnum = NO;
            SortNumber = 106;
       },

• Save the file and close it. Now relaunch Xcode.
• With Xcode open and your project loaded, right click on the project name under the “Groups & Files”, and select “Get Info”
• Under the “Build” tab and in the “Architectures” menu, change these options:
  Set Architectures to “Native Architecture of Build Machine”
  Set Base SDK to “Simulator – iPhoneOS 2.2″
  Leave Build Active Architecture Only checked
  Edit Valid Architectures to be not only include armv6, but also “ppc” and “i386″.
  (I think some of these may be redundant, but it’s the combination that’s working for me.)

When you next build your project, you shouldn’t get any errors about VALID_ARCHS.

I hope that’s helpful. Since this is only one particular combination of build hardware/architecture and SDK software version, I’m sure there are other combinations out there where the above may not work, your mileage may vary.

Now, back to working on building an actual application…