I started doing Objective C programming with Adium, the instant message client. I'm one of the lead developers of the project as of a few months ago. So I started out a few years really working on patches, starting along those lines. The iPhone is basically a mini-Mac, so I could use the same pieces of knowledge that I had from the Mac working on Adium. The hardest part was really coming up with an idea.

I didn't even have a developer account for the iPhone until I'd actually thought of creating Prowl. I was sitting around over the weekend, and realized just what a good idea it was. So I went ahead and paid for the account, and started setting my phone up. A few weeks after I had the idea, it was already up on the app store.

Prowl took about 400 to 500 hours for the initial version. A lot of the work was on the backend for the web site, because a significant amount of the program is not actually in the iPhone. A lot of it runs independent of the iPhone, either on the person's computer sending to the server, or the server processing the events that are sent from the individual's computer, or the program that is sending the notification. But that's a blessing, because if a random bug pops up, I can usually fix it server-side to either mitigate it on the client on the iPhone, or just avoid it entirely, which is definitely very helpful and a lot different than having to deal with the extremely difficult approval process [by resubmitting the app].

My original intention was probably two-fold: firstly, I wanted really to be notified of messages on Adium when I wasn't there. I also wanted to know when torrents finished downloading, because I'm usually out and about, and if something finishes that's taken like 3 or 4 days, I'm usually interested in immediately knowing. So with that in mind, I tried to focus on a way to really have my computer tell me about things when I wasn't there, and Growl was obviously a choice. Growl actually started as an Adium project before I was involved in Adium, so it's kind of a logical progression.

I wanted it so that nobody had to do any extra work to use the application—no updates, nothing along those lines. I had to create a Growl plug-in, which integrated kind of seamlessly. But there was really no standard way of doing what I was after; there is an MMS plug-in, but it wasn't quite the same paradigm. So I really wanted to just have it be a part that slapped into Growl without any extra work involved for the user, mostly because I think that would be easier for everybody, but also because it lets anything that uses Growl also use Prowl, without any modifications or redistributions. And what's great is that the Windows Growl clone Snarl and Growl for Windows also adopted the ability to use Prowl. It pretty much just expanded to every operating system without really any programs having to be written for it.

It declares itself as a style, which in Growl the notifications are received from the application, and then Growl itself will redisplay the notification on the screen to the user. When Prowl receives the notification for display, it checks its preferences and then tells another plug-in to do the actual display, while it goes ahead and sends to the Growl server, so it kind of works itself as a middle man between another Growl style and itself. But one important limitation is that Growl can only display one particular display style, or plug-in, for a particular message—so in order to avoid Prowl being the most annoying program ever and sending every notification only to the iPhone, you have to do a little hacking around, kind of exploiting how Growl works, to allow the messages to be displayed multiple times [on the computer and iPhone].

Growl plug-ins are very simple. Basically you just have a few parts: one that talks to Growl, one that sets up the preference window, and another one that does the actual displaying. I looked at some of the other plug-ins, and kind of just went from there. It was mostly just implementing a few functions; obviously, the core of it is a little bit more difficult, dealing with Prowl and all that, but I'd say overall Growl plug-ins are easy to hack.

What Prowl offers is the ability to kind of customize what goes on when it receives the message from a particular application. So originally my goal was to use a system of Growl that, at the time, nobody really used: the priorities for notifications. Really, priorities were just used to change the colors of particular styles and, for the most part, Christopher Forsyth, the project manager for Growl, was kind of pushing for removing them. Nobody really thought of them as a useful feature. But I saw them as really a way to finally bring in the right level of controls to the notifications. I had that control in the option to only send, say, high priority messages from the computer to the Prowl application.

And along those lines, I've added in things like only sending it when the computer is idle. I have few other ideas in my head, like Bluetooth proximity, but I haven't really implemented those yet. Mostly the goal is to try and be more intelligent about sending the notifications when the user doesn't really want them to be sent.

When I was writing Prowl, there really weren't a lot of resources to look into the Push notifications. The Apple documentation is good, but it definitely lacks some of the information, like the particular scraping you need to do for the text being sent, things like that. Prowl has to deal with a very wide variety of message-types, so it has to chop the unicode text properly when sending to the Apple server, for example. And the Apple server is very strict about the kind of things it accepts, so if you're wrong at all about the syntax, it will either disconnect you or the client will fail to receive the message. The most complex part of dealing with the Push notifications was just having to deal with an arbitrary text of arbitrary length from users, being sent to something that required a very strict requirement of the type of text displayed. So it's using Push notifications in a broader sense that I think Apple might've envisioned.

Prowl [on the Mac] relays the message to the Prowl server, which then tells Apple to get the Push notification out. Then the user opens the Push notification, or opens the Prowl app, which downloads the notifications from the Prowl server.

It would be nice to avoid the death of having to deal with the Apple's servers, or my server, but it's really just the way it's laid out. It's almost impossible to go any other way.

Right, Apple says that you shouldn't have lots of things connecting [to the Push server] unless you actually need it, and you shouldn't have lots of transient connections either. You can't just open a connection, send a Push notification, and close the connection. I think that'd really be a requirement for an individual computer to connect [without going through the Prowl server]. I'd also have to distribute my SSL certificates, along with the plug-in, in order to connect to the Apple servers.

It does things very simply. Really the only complex thing it does is exploit the ability to relaunch into another application, for which it declares URL types in a particular application. Lots of applications are adding it these days almost specifically for Prowl support too, so that when a notification comes in, the user can be immediately redirected to the appropriate [iPhone] application without having that particular application support Push itself.^[11] So nothing really extraordinarily difficult had to be written for the iPhone application itself: it's just a matter of putting the work together, and organizing it in a way that works.

Originally, it was a little difficult to understand what Apple was expecting in a connection to the Push server. The documentation is there, and the examples are there, but I run into certain problems like the unicode not being cut properly, because I was cutting in the middle of a multi-byte sequence. That's obviously my problem, but it was something that wasn't exactly easy to detect. I'd say a major difficulty was the little unexpected things, like how it expected apostrophes to be escaped, or how some of the text should go through. The server only allows 256 bytes of the data to go to a particular device included inside of a JSON message, which isn't necessarily limiting, but it does make it a little tough to pass the messages around as you'd expect.

About 7 million, last I counted, were sent through the Prowl server since its release. I think about 13,000 users have downloaded the app, last I checked.

Originally I just wanted to get the Push notifications working; the UI wasn't necessarily an afterthought, but it definitely was not a priority. I'd have friends of mine yelling at me: "You have to make a good looking application, or else what's the point." And it's true, when it comes to Mac programming and iPhone programming, it's not quite the same discipline as other types of programming; you have to make an application that actually looks good, or else nobody will use it.^[12] It's not good enough to be useful—it has to be, "it's useful, it looks good, it works good." So I tried to make Prowl as absolutely as simple as possible, and to keep in mind that its goal was to display a notification. Now of course, displaying notifications, playing what you want, launching other applications, those are all possible—but really the core of it is just displaying notifications. I wanted that concept to be easy to follow, so that was the big consideration when putting everything else together. [Figure 10-2 shows Prowl's preferences, which keep it from harassing the user unnecessarily.]

Figure 10.2. Prowl's preferences pane is sparse but carefully considered.

I'm adding some features myself: the second-release 1.1, has quiet hours, new sounds—things along those lines. I don't imagine it's going to really expand beyond what it does, but it's definitely going to have new things added to it. What I like about it is using the public API, it allows anybody to expand Prowl really in any way they want. So you have services popping up like pre-fetcher, which does Twitter notifications specifically through Prowl without your computer being on. There are also two or three services for Google Voice, and other things along those lines. I like to keep my mind focused specifically on the notifications themselves. I let other people work on the angles of specific niche items that can be sent through Prowl; I know that if I had to maintain them along with the server and everything, it would just be an overwhelming amount of work. (Figure 11-3 shows some of Prowl's API calls.)

Working with Growl, I probably would have liked better plugging documentation. I separated the project really into three pieces in the beginning. I created nice repositories before any code was written: the Prowl plug-in, the iPhone application, and the web site. Those are all the three major components. They almost have equal share in my mind of what really needs to be done. IPhone applications are very well documented; it just took a long time to do it, of course. The Growl plug-in took a good amount of reading the Growl code and trying to figure out exactly what it was doing when a notification was received, so that I could kind of duplicate the functionality for how Prowl redisplays into a different style. So, I'd say the major roadblock, toolset-wise, was just trying to understand a program that I myself hadn't written, and really had no experience writing, dealing with the Growl program itself.

Yes, but when you add stuff, some users might be drawn to a particular small thing you implement—but if you try to cover multiple bases in a particular application, you generally don't see a user increase proportionate to the amount of things you add. I've had discussions with some other developers about how they looked at things, and really when you're organizing an iPhone application, if you focus on a specific chunk that you want to work on, and you don't try to do extra, you don't think, "Oh this could go in there also, and all that stuff." You just focus on a specific usage set. I also think it's a lot easier for you to tell users about it that way, than if you had 11 different features you had to advertise at the same time.

I'm a little bit torn on implementing that. I don't really know the Bluetooth code on Mac very well, but I also don't really want Bluetooth on my phone turned on because it's a battery hog. But I also would like the ability not to be told about Prowl notifications when I'm next to my computer without having to really think about it that much myself. Either Bluetooth proximity, or detecting the phone itself is plugged into a USB port, something along those lines—to really to automate it would be nice. In a perfect world the phone would know that if it was next to the computer. The Bluetooth feature isn't necessarily overreaching—it's kind of a logical extension—but it's a little bit beyond the amount of work I wanted to do for the initial release.

Figure 10.3. Prowl's API has opened up the app to some surprising third-party inventions.

There's basically two parts of the web site: what people see, and what the application deals with. As I was writing the iPhone application and the Growl plug-in and the web site, almost parallel, really they had to support what everybody else was expecting. So the Growl plug-in expected to be able to send notifications, the iPhone application expected to be able to receive them, and the web site was kind of the joining force between those two ends. Of course I also had to create a web site that was marginally attractive, and I'm obviously not good web developer, but I try. It had to be attractive and usable, so I tried to keep the organization as specific as possible to what users would be doing: logging in, and either changing settings or adding notifications. So advertising these features on the front page is obviously important.

When I first wrote the application I didn't even think of a public API. People started requesting it, and I thought it was a really good idea, and now that's one of the driving forces of the web page also. So even though users are really using the App Store to find applications, I'd say having a reputable, usable web page definitely helps the process.

The goal was a very simple API that has two or three features, adding notifications, and checking whether or not one of those API keys was valid, which has allowed Growl for Windows and Snarl to add public API-use functionality, along with all the various web services and tie-ends that people are using with Prowl.

I'd say a few days of work definitely went into the API. Really I just wanted it to work in a way that would allow anybody to send notifications to the Growl servers without any extra steps. It's just a basic HGDP post-API that allows you to specify what's displayed in Prowl. But you can also just specify what user receives the message using an API key functionality, so a user doesn't necessarily have to give a third party their username and password.

Originally Prowl was meant just specifically for Growl notifications, but it kind of evolved more into a universal Push notification system after release. It definitely evolved into one of the leading features that allows pretty much anything to happen beyond my imagination, without me having specifically to do it myself.

Well, there are two or three specific web services that revolve around Prowl, and there are also things like a WordPress plug-in that are kind of new. Some people are also just using the command line script to the notifications from particular web site monitoring, or running a rule set that forwards to Prowl on certain events. It's difficult for me to keep up, because unless they really tell me about it I don't really know what's going on. So from my perspective, people are using it for pretty much everything they were using SMS notifications before—but instead of having to pay SMS fees it just goes through Prowl. Nice, simple, fast.

Some of the really awesome ones revolve around weather monitoring. My favorite ones are definitely in Japan: they are using earthquake monitoring going through Prowl, so you get notified of any earthquakes or something along those lines. Other people there are using it for subways delays, things like that. Some of the usages in Japan I didn't even think were possible, but they just aggregate so many sources though Prowl.

I envisioned in my mind somewhere between $3.00 and $4.00, because I have to support it forever, and I have to deal with the bandwidth costs and the server costs. A lot of the 99 cent applications don't necessarily have huge margins cause you're only getting 70 cents out of it. I also knew for sure I didn't want to support a 99 cent application, because I think the mindset of somebody buying a 99 cent application is: "Oh I can use it and complain as much as I want, and I'm still owed everything from everybody." I think that segment of the particular marketplace is a little bit more work.

Yeah, definitely the 99-cent buyers are a lot more difficult to please than someone who is buying a more expensive application. I really wished to avoid the users that would not really understand what they are buying because it requires Growl. If you don't read that text, you're not likely to understand why nothing's happening on your phone. So when something is a little more expensive they are more intent to understand what they're buying before they actually go and do the purchasing.

It's definitely making money. It's worked out very nicely; I'm very happy with the response of people purchasing Prowl. The server costs are lower than my income, and the servers are running spectacularly under this specific load. I think I could scale it two or three times more, but I haven't even to think about adding more servers, which is always very easy to do with the way I have it set up in the backend.

It's incredibly important thing to just understand what you're actually trying to do. Not overreaching is really important when you're developing a small application that isn't necessarily meant to be used all the time. With a utility, you really have to understand exactly what it can (and should) be used for. You don't want to add annoyances, or unnecessary steps; focus on your main usage above than anything lse.