I’ll take the other side of Phil Wolf’s criticism of iPhone’s push notification service. Phil says it sucks; I say it rocks.
To summarize and to be fair to Phil (as I like Phil very much, as a neat guy and a bright boy), his criticism centers around user interface, architecture and basic network philosophy. He points out that notifications kill foreground sessions, which can surely be user interface naughty. Agreed. He also points out that it breaks good network architecture by tying user’s hands as all notifications have to come through it. Agreed again, with a suggestion that just like the Sabbath being made for the man, not the other way around, good network architectures and principals are are good because they server people better.
Here’s why I think Phil is wrong here: push notifications bring insane value to the enterprise by enabling the business process. Arguing against it is like complaining to the doctor that you only use heart defibrillators with aluminum paddles, not steel, and could he please just find a better one. Push notifications are the heart of business process improvement for nearly every case I find, and it holds true for mobile workers, remote workers and consumers involved in the process. Remote notifications enable dissemination of data to the general public. Remote notifications provide decision support by delivering information to the right person at the right time. Remote notifications can kick off other applications to bring data back in from the field. It’s hard for me to imagine a more important feature and capability to communications enabled business process design, and I applaud Apple for figuring this out.
I can’t believe I’m about to say this, as I know my telecom history well, but this might be another case where a more reliable and guaranteed service is more important than intellectual purity. It is this feature alone that will drive me as a CEBP developer to invest time and energy into the iPhone platform.