As I went down the lines counting, I could not believe the amount of stress that I induced in those being counted.  People quickly began to worry about whether they were too far back in line to get a phone, or even if they were in the right line.  I was stopped about every 25 people asking what their number in line was. I had to explain over and over that I wasn’t counting for any purpose.

For the record, by the time 7 AM rolled around there were 700 total people in the two lines.  During that time I’m sure the line grew, because I started with the no-reservation line first, and then proceeded to the reserved line, which wound around the building in a different direction.  Between 7AM and 7:20, another 82 people showed up in the reserved line behind me.

I have kept all the weekly sales reports going back to when my applications were first available. So I was hoping I would finally be able to see my grand total for each app. The only problem is that the grand total is based on daily reports, not weekly reports.
So I created a small command line tool called SplitWeek that would break each week file into 7 daily files.

Each sale is assigned randomly to one of the seven days in the weekly period, so there are no rounding errors.

Operation is simple. Just run the command from Terminal, passing the path to the weekly file as the first argument:

./build/Debug/SplitWeek reports/S_W_20080825.txt

The 7 files will then be generated and saved to the current working directory.

2009-10-29 11:05:36.933 SplitWeek[53735:903] S_D_20080825.txt
2009-10-29 11:05:36.934 SplitWeek[53735:903] S_D_20080826.txt
2009-10-29 11:05:36.935 SplitWeek[53735:903] S_D_20080827.txt
2009-10-29 11:05:36.935 SplitWeek[53735:903] S_D_20080828.txt
2009-10-29 11:05:36.936 SplitWeek[53735:903] S_D_20080829.txt
2009-10-29 11:05:36.937 SplitWeek[53735:903] S_D_20080830.txt
2009-10-29 11:05:36.937 SplitWeek[53735:903] S_D_20080831.txt

Once you have created all your daily files, zip them up, and upload them to MyAppSales using the web server built in to the application.

And speaking of the built in web server, here is a quick tip on how to connect to it. When you enable the server, it will show the IP and port you need to enter into Safari to connect. In the screen shot here, I’m using the simulator, so it doesn’t even give an IP.

Instead of entering the IP and port, just use the Safari Bonjour support, and you will find it listed under Webpages.

Being security conscious he turned on the passcode lock and disabled SMS Preview.

This screen shot shows the SMS preview disabled:

This enables a mandatory passcode. If a message is received during the passcode entry or while the screen is locked, a generic message of “New Text Message” appears, to prevent viewing of messages without unlocking the phone:

If however the phone is placed in emergency call mode, any incoming SMS messages are previewed instead of presented as the generic messages. Thus all I need to do to intercept the messages from his girlfriend is to place the phone in emergency mode and wait 30 seconds for the next sickly sweet message.

This was in iPhone version 2.1 (5F136), the currently shipping version. Since I have no access to beta of non-released firmwares I can’t test to see if it has been fixed since then. For those how care, this is bug 6267416. I don’t have much hope for it being fixed soon, because my security bug 5368148 from July of 2007 is still marked as open, and still unfixed in 10.5.5.

Send questions via email

Those of you solely interested in my sales number can check them here.

Background

I have been writing Objective-C code since the early days of NeXTSTEP (20 years). I work as a contractor and it is one of my many “day jobs”, along with system administration for LAMP systems, and a few other odds and ends. I also have to deal with other languages like Java, Perl, Python, PHP, and so on.

Development on the iPhone is almost exclusively Objective-C. You might think that I would have an extreme advantage, but honestly I don’t think so. Objective-C is easy to pick up if you have any C based language development experience, including C++, C#, or even something like PHP.

Yes the syntax is different. Every language has a different syntax, but it is all the same bits and pieces such as loops, conditionals, assignments, functions, etc.

Yes the framework is different, but then again, most of the iPhone UIKit framework is not a one to one match for the Cocoa AppKit framework.

So my Objective-C experience gave me a good start, but I know several people who have picked it up with little work, even when coming in with little to know serious programming experience.

I bought 2 iPhones on the day they were released and gave them as gifts to a client. But with no development path I couldn’t see buying one for myself.

When jailbreaking became a real possibility and tool chains and documentation started to appear, I finally bought a phone for myself and my wife.

I paid tangental attention to the open source tool chain, and then when the October announcement of a pending real SDK came out, I set aside plans to build apps until the real SDK was released.

Becoming an iPhone Developer

As the SDK announcement approached, I began to track programs on other mobile platforms, and began to think of potential applications to write. I also started to make guesses and observations about what the iPhone development ecosystem would be like.

In most cases I guessed right. In quite a few I got it wrong, or I have no idea whether I’m right or wrong. I’ll discuss that more later on. But the important point is that if you want to have any kind of success as an iPhone developer you need to think about the future of the platform and be prepared for the change, because the iPhone ecosystem is still undergoing radical changes. Items like push notification have been off, on, and off-again.

I felt that using my personal iPhone for day to day development probably wasn’t the best route, so I ordered another iPhone, and an iPod Touch as well.

I applied for the developer program right when it was announced. In the first 2 weeks it seemed that no one was approved. Then rumors of approval started to filter out, and the assumption was that Apple was processing them on some fair basis, such as first come first served, or approving ADC Premier members first. Neither ended up being the case. I was in the same boat as many other developers, with no idea why I wasn’t being approved, or what I could do to help the process.

I downloaded each version of the SDK, and worked on some early code.

WWDC

In 2007 I had attended WWDC, but now I found myself facing a dilemma. I still hadn’t been accepted as an iPhone developer, and the primary reason to attend WWDC would be to learn more about iPhone development, and one-on-one interactions with Apple engineers about iPhone development. I sent a note off to ADC about the problem with attending WWDC without being able to develop for the iPhone, and got the equivalent of a “just wait” notice.

At the time the simulator was even worse than it is now. Major features like Open GLES simply did not work in the simulator, and those are the exciting aspects of the iPhone. Given my background, getting to play with a simulated NSDictionary and some simulated buttons wasn’t something I would need help with at the WWDC level.

I ended up not attending WWDC. A friend of mine (ADC Premier) got accepted as an iPhone developer less than 2 weeks before WWDC. It was at this point that I started to really notice what I call the “If the guards have stopped my beatings, they must have stopped all the beatings of everyone else as well.” mentality. His assumption was that since he had gotten his developer accepts, I must have gotten mine. An alternate assumptions was that everyone going to WWDC was getting one.

Unfortunately neither was true. I ended up getting mine a few days after July 11th when the App Store opened. I know people who attended WWDC who got accepted even later than myself.

In general Apple did a poor job of communicating about the process of becoming an iPhone developer, and they are still doing a poor job. And by communicating, I mean they are just not responding to some questions. They seem to be trying to be deliberating opaque in their answers, walking a path around the truth instead of just explaining this clearly.

An example of this is the $99 fee for the Apple iPhone Developer program. Many are still confused as to whether this is an annual fee or one time fee. As I have previously participated in Apple Developer programs, I was expecting it to be an annual fee. But I still see new developers coming to the platform who aren’t sure, and the signup pages for the program are very unclear. They just say “Standard Program $99″.

While Apple does have a press release that causally mentions it is a yearly fee, that doesn’t make it obvious, and one would think that if the question keeps coming up, Apple would be more active in addressing it on the iPhone Developer signup pages. A $99 yearly fee should not be treated like a source of shame.

An iPhone Developer

Once I had been accepted as a developer I went through the process of generating the various keys, getting certificates, and provisioning profiles. I had about 90% of the application written at this point, and I fired it up on the iPhone.

The results were not good.

Because the simulator runs at native Desktop speeds, it cannot be used to get an idea of the performance of your application. And HazMat, which ran perfectly acceptably in the simulator was slower than molasses on an actual test device.

This is another one of those items were there just doesn’t seem to be any kind of pro active communication from Apple, and with the NDA still in effect, I’m discouraged from publishing my own experimental benchmarks that might help other developers get realistic expectations out of their product ideas.

But enough negativity. Let’s talk about the development.

HazMat Was Three Projects

The first project was to gather and clean the raw data. This consisted of some data in spreadsheets, others in PDF files, and other in CSV files. I had to clean up typos, oddities and the such and get the data into a common set of CSV files.

The second project was to take the CSV files and get them translated into a SQLite database. This second project would lead me to discover errors in the first project, and I would cycle back and forth between the two projects.

The third project was the actual iPhone application which then reads the data from the SQLite database and displays the result. This then lead to another revelation about the data needing to be massaged for performance and display quality. About 30 commodities had very poor name choices. For instance Gasoline is also called Gasohol,which while it is shorter is more confusing to United States users. So I had to hand mark preferred names for certain commodities.

I also at this point started using the app myself, and learning more about particular usability features and performance. A redesign was done for the detail display to break it into General Info, Fire, Spill, and First Aid instead of one long page.

I did the icon work myself using Photoshop and Adobe Illustrator. A lot of images were based on inspiration from various Google image searches, and the App icon is based off a set of free HazMat placards done in Adobe Illustrator by Ian Albert. The original icon was a NFPA icon, but I ended up changing it when I pulled the NFPA data from the application.

Many items were pulled from the first version of the application, because I quickly saw HazMat becoming a huge time sink. I perform development and system administration services as my livelihood, and I already knew at this point that HazMat would not only be a niche application, but probably the most niche application in the AppStore, and that meant a very small amount of income for a lot of work. I decided it would be better to get a solid first version out, and then add more sections to the first screen as time went on. That way it could continue to be a part time effort from me, that wouldn’t burn me out.

When it came to sales, I also had in mind a specific idea of how many units of HazMat whould actually sell. Unlike a game or a productivity utility HazMat has a very narrow audience. My estimate was 2-3 copies s day, with maybe a peak of 14 or so at the beginning. I also formed a mental benchmark of 40 per day as the number at which I was wrong about my estimates.

Pricing

Based on my guess of 3 copies a day average, I guessed maybe a thousand copies in the first year. To recoup my actual time I would have to charge what I felt was an unreasonable amount of money. I felt that while releasing it for free would result in a lot of people downloading the application it wouldn’t provide any benefit to me, not even a psychological boost.

While 99 cents was an option, I quickly saw it becoming the “price of crap” in the App Store. Chris Rock tells a joke about minimum wage, in which he points out that

“You know what that means when someone pays you minimum wage? You know what your boss was trying to say? It’s like “Hey if I could pay you less, I would, but its against the law”.

So it is with the 99 cent price. It acts like a signal that the developer wants something, but that the application would be cheaper than 99 cents but Apple won’t let them charge less. I understand the dilemma for Apple. It is hard to make profit on 10 cent internet sales that cost 25 cents to process.

In the end I decided to go with pure signaling with the application. I choose the $3.99 price to signify that the application was a significant body of work designed for a specific audience. I didn’t choose it to maximize revenue, or because I did great research, or to match price in other mobile devices. I choose it as a pure signal. I believed then and now that I would have the same number of sales of the app whether I priced at 99 cents or $7.99. $3.99 just sent the right signal.

I would have considered 99 cents if there was a way to raise the price and charge for upgrades, where I could slowly raise the price as the value of the app increases. But that isn’t an option in the AppStore and likely won’t ever be an option.

So in the final analysis, over the next 3 years, I might make $2.80 per copy, with about 3000 copies being sold. That comes to $8,400.00 over 3 years. That works out to PFV of about $7,500.00 which is about how much time I have put into the application. I’ll probably put another $15,000.00 of work into the application over that same time period. In short this application is a money loser, but a labor of love and a personal itch. A hobby of time.

All of this was capped with me needing to actually get all the banking information setup in expectation of maybe getting an occasional wire transfer from Apple. For such a small amount, I almost wish they would have given me the option of taking it in Apple Store credit.

Submitting the App

Submitting the app took a couple of tries. Learning how codesigning work, and how to use the codesign command line utility is essential, because when Xcode is not setup correctly it will say the build succeeded even when it didn’t sign the application.

The ApplicationLoader used to submit the zip file also produces some cryptic and misleading error messages. On the positive side it does detect several common errors such as incorrect icon sizes, or invalid zip files.

I work on about two dozen Cocoa applications, so I have a common build and deployment script and practice, where all development builds have a DEVELOPMENT version number, and the build process changes the Info.plist in the app wrapper during deployment. Those builds are done on an old G5 that I have stuck in a corner. It regularly builds each svn repository, detects deployment versions, does the app-casting and so on.

However the G5 can’t build iPhone applications, and even though I have a half dozen Intel boxes, they are all in active use and not ready for corner of the closet retirement.

So I built the application by hand, and forgot to change the version from DEVELOPMENT to something else. IIRC, the Application Loader detected this and rejected the binary and explained the version number was invalid. So I changed it to “1″, and then rebuilt. Unlike my other build process I can’t change it after it is built because the Info.plist is one of the signed resources.

I submitted version “1″ and then waited.

About 2 days later my application still showed “Waiting for Upload”. I have gotten the distinct impression that all the pieces of the App Store are not directly linked. It seems common for people to report that their application says “Waiting for Upload” for hours after they upload and “In Review” even when it has gone on sale. Again something I wish Apple would be clearer about.

But after 2 days I figured there might be a problem. So I sent an email. At about the same time, Apple was sending an email to me.

Rejected

The version number “1″ is not allowed.

Apple sent me a paragraph that detailed the requirement for version numbers, which basically requires they have a decimal point. So “1.0″ is valid, “1″ is not. Foolishly I figured that if Application Loader knew that “DEVELOPMENT” was not valid, it would have told me if “1″ was invalid as well.

So I carefully read the rules and resubmitted with a date encoded version number “2008.08.18″. Normally I don’t do this for OSX applications, but with the mandatory review process it is unlikely I will ever have 2 versions submitted on the same day.

So I submitted, and the next day checked. “In Review”

And then waited, and waited.

Again, there is that feeling that maybe they forgot my application. So everyday I would login, check, see the In Review, and then work on breathing and meditation exercises.

Finally in the early evening of August 29th , I got the email that my application had been approved and was now available for sale. It still showed “In Review”, and I couldn’t find it in the App Store. However I took them at their word and quickly worked up the web site, and a simple FAQ, and then waited.

Later that night I could finally find it in the US App Store, but not in some foreign stores. My belief is that again the process is not a instant worldwide single button deployment, but rather a series of loosely connected systems. I went to sleep happy.

The version posted to the store was the previously not allowed version number “1″. I would let Apple know, but who can I communicate with in a timely manner about this mistake that could possible solve it?

The Sales, The Reviews, The Spreadsheet

The next morning I got up and checked iTunes Connect to see whether I sold a copy. Incredibly I had sold 3 copies. Two in the US, and one in Canada. Pretty much right on target. I congratulated myself on my wonderful prediction.

I also started to notice reviews. Two of the first reviews were complaints that it should have been free, and another that it was overpriced that it should have been 99 cents, but that I was basically smoking crack if I thought I would sell any copies at $3.99. After some meditation and breathing exercises I got over it. Rather than sock puppet a bunch of reviews, or post my own railing at their lack of understanding of capitalism and economics, I instead found solace in two items.

First, I clipped their comments down and posted them on my web site as endorsements.

Second, except for those pointless whining rants, the rest of the reviews were from people who like the app, and were mostly giving it five stars. It seems I had hit an app that at least a few people wanted or appreciated. I also got two emails from people expressing their pleasure with the application, and pointing out ideas for future versions.

The next morning, I logged into iTunes Connect to see how I did on my first full day of sales.

91 copies, with 76 in the United States.

That was a lot more than I was expecting. I put it down to a big first day boost, and went back to work on other projects. I was sure that by tomorrow it would be down to my previously mindset value of 14 or below, or at the most 40 or so, all depending on whether it was a quick crash or soft landing down to 3 copies.

Instead the next day it was 86 copies. Still way larger than I expected. Sales continued for the next several weeks to be higher than expected. After 2 weeks I’m still not below 14 copies. Instead I seem to have soft landed at about 25 copies a day. I started watching and graphing the values on a Numbers spreadsheet.

That third day was August 31st. I added up my sales to that point and realized that I had made $389.00 in royalties. While not enough to retire on, it was still a pleasant surprise. That meant that I should be getting a check for my two-ish days of sales in August. From other posts I had heard that Apple takes about 10 days to settle on the sales, and then about 10-15 days later actual transfers the money. The idea of getting a “check” at the end of September helped sooth the logical part of my mind that said this was not a business project but rather a hobby.

The total for the first 14 days is $1,541.23 of which about $278.43 is in miscellaneous foreign currencies that aren’t large enough for Apple to perform the wire transfer.

My expectations were and remain so low, that each day I wake up to gleefully check iTunes Connect for sales figures.

The Check

On September 10th, I got the email from Apple indicating that the actual financial reports for August payments were ready for download. I expected that there might be a small discrepancy, but was interested in finding out how close to the $389.00 amount the payment would be.

The answer was a bit depressing. No check. No payment, $53 US sales. And onesie-twosie sales in other regions.

I sent a note to the email address for the payment people. For all my previous moaning above about the lack of communication with Apple regarding the development side, let me say that the payment and contracts people are the exact opposite. Every email I have sent them has been very quickly replied to, and questions are honestly and completely answered on the very first response. That group seems to have the process down to machine like precision.

I had made 2 incorrect assumptions. The first is that August meant 8/1 to 8/31. Apple doesn’t pay on calendar month, but rather on financial month (2008 2009). The contract and payments group was kind enough to send me the exact financial calendar they use. Not only for this financial year, but next financial year as well. For August of this year, the financial month was 8/3 to 8/30.

But even with the calendaring mistake I sold more than $53 worth on 8/30 alone. My second mistake was in thinking that the delay from 9/1 to 9/9 in getting reports out was to settle all the outstanding credit card charges, since Apple doesn’t charge credit cards at the same time the end user downloads HazMat.

Instead that time is just for them to reconcile all the transactions. So downloads on 8/30 are transactions, but only some of them are financial sales. Those people who got credit card receipts via email on 8/30 count, those that Apple didn’t charge till 8/31 or 9/1 don’t count.

In the end, I’ll still get paid, just at the end of October instead of September.

Bullets in Hindsight

• I didn’t make a lot, but more than I thought, and it is nowhere near as I expected.
• Niche apps can sell on the store. Even though Apple is promoting games, there are people who want other items.
• Was it better to write something niche that isn’t likely to be duplicated, or better to write something everyone can understand because it isn’t unique?
• I was in books. This meant I stayed on the front page longer.
• The iPhone shows the first 5 apps without scrolling. iTunes shows the first 21. Moving to number 6 didn’t decrease sales. Moving to number 22 did. More people buy on the desktop than on the phone. However I dropped to #22 on 9/11, so can’t be sure if that was the contributing factor.
• Some of the people who downloaded my app probably have no interest in hazardous materials, but found the application to be appealing because of the sense of a source of “secret” information.
• Getting listed at the end of the month sucks.
• You will get bad reviews no matter want. Don’t let the bozos get you down.
• The NDA didn’t stop me from writing code, but it does stop me from sharing 20 years of experience as it relates to this platform.
• There are lots of reasons to sit and whine about iPhone development, there are a thousand reasons to pound out the code.

While most people are blissfully ignorant of what signs like these on a side of a truck mean, I have learned that the code identifies the specific commodity that is hazardous on the truck.

I do a lot of cross country driving and a tool I’ve always wanted for my iPhone is a HazMat lookup guide, so I can find out what trucks are carrying. A program like this also has uses not just for the curious like me, but also for people in the industry who work with these hazardous materials, and first responders.

So with that in mind, shortly after the SDK, as a part time diversion, I wrote HazMat for the iPhone.

With that in mind I offer these quick tips:

1. Xcode comes with all the documentation for pretty much everything you need to write code for Mac OSX and Mobile OSX.

It is hidden under the Help menu, which 99% of OSX apps have, and is ignored by every OSX user, because only 1-2% of them actually have any useful help in them.

The documentation is vast. I hesitate to guess that printed it would be 20-30 feet across on a shelf. That leads to hint #2

2. You can hold down the option key and double click any function or method and jump immediately to the matching documentation.

For instance if I option double click on NSLog in this code fragment.

This comes up in the documentation window. Notices that NSLogv is a hyperlink to the documentation on that function.

3. If you are the kind of person that find a quicker answer in header files, cmd-double click to go to the header file that defines the function or method.

This also works with your source code as well. If you have a method called doTheThing: and you can’t remember if it takes a string or int as you are typing code to call dotheThing, just command double click and you will go to the method in your code. You can then go back to where you came from with the Go back short cut, Command option left.

4.There are a ton of keyboard shortcuts, and you can change them.

You can find most of them in the xcode preferences panel under KeyBindings. A lot of them are based on emacs key bindings.

With just 20 or 30 key bindings you can pretty much navigate your entire project, build, run, and test without ever taking your hands off the keyboard.

5. While debugging you can hover over a variable to see the value.

Here you can see I’ve set a break point on line 175 (the blue marker), and that the program has stopped there (the red arrow indicating the current program counter). By just placing the mouse over favorites and waiting for a second, I’m treated to the information that it is supposed to be a NSMutableArray called favorites, and that it is currently a nil pointer and therefore has zero objects.

xxxxxxxxxxxxxxx

The second time through I find that it has now been created, is actually a NSCFArray, and has seven objects.

6. Xcode is based on standard open source tools

Under the hood Xcode uses GCC for most compiles, and GDB for the debugging. So if you know or can find a book about gdb or gcc or a web site about them you will be able to do amazing and clever things. On top of that advanced features used for performance tracing use dtrace, also open source and also with a large support community.

This also means when you find a problem in Xcode, you can go down to the command line and duplicate or work around the problem. For instance I have an executable that Xcode never will play nicely with when I’m debugging. So I can debug the same app from the command line using GDB.

7. Research Assistant

Research Assistant is not as well polished as other parts of Xcode because it is relatively new. Like the documentation, you find it under the help menu. Leave it open and as you type it will show a quick documentation snippet for the code to the left of the insertion point.

It updates live as you type, showing not only the arguments, but also providing hyper links to them, and showing sample code that uses the class, function or method:

I find it a bit too slow updating and unreliable for my tastes, but for a beginner it can be very useful.

8. You can move things around in condensed mode

I tend to run Xcode in condensed mode and found myself getting pretty frustrated having to move between Files, Targets and Other.

Quite by accident I discovered that you can move things between them. To switch sections while dragging just drag over the tab:

You can use the same trick to drag files from the project to particular build phase of a target using this method as well.

9. Code Completion on demand

One developer I worked with thought the only way to get code completion to work was the settings in the Code Sense pane of the preferences tab. He was constantly tweaking the delay setting up and down depending on the code he was working on.

If you need code completion NOW, and don’t want to wait the 2-3 seconds for the popup, you can use these key bindings:

10. [Withheld]

I had a tenth tip, but I didn’t think it all that great. So I have withheld it for a future post. In the mean time, send me any more tips you have and I’ll collect them and post the best.

Applications downloaded from the App Store are stored inside your Music folder as ipa files.

Inside that folder is an ipa file for each application you have downloaded.

But ipa files are really just zip files. Lets pull apart Super Monkey Ball as an example:

First, work on a copy of the ipa file.

Rename from ipa to zip

Double click to unzip, and you find a folder with 3 items inside:

iTunesArtwork is a jpeg format image that contains the application icon.

iTunesMetaData provides information on who bought the applcation, what version it is, when it was bought and other useful meta data about the application.

The folder Payload contains the actual iPhone application. By using the contextual menu you can go further inside the application.

You may notice that most of the png files show up as a question mark in Preview:

This is because they are in a special iPhone format designed to make them more compact. You can use fixpng to undo the compaction. Sometimes the colors will be off:

And there you go.

On the list of top 25 apps the cost is $0.99:

But on the detail page the application is free:

If I was an iPhone developer and found my app being given away for free I would be a bit miffed.

If I was an iPhone user, and found that it was ther other direction (free on the list, cost in the detail), I would be equally miffed.

Some interesting surprises about Epocrates Rx.

The first is that during startup it sends your firmware revision, device name and device ID to their servers. Not sure they could do much with that, and I think they are probably just trying to gather statistics.

The second though is that some component of the software continues to run in the background after you have quit the app.

A few seconds after quitting I noticed this traffic:

20:20:36.744796 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806

At first I though it was just a stray packet still making its way out the wire after I quit. But during the testing of the next app the traffic continued. About once a minute some program was trying to connect to http://63.241.66.151/

20:21:08.786246 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806
20:22:12.873043 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806
20:23:16.960316 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806
20:24:21.048086 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806
20:25:25.129605 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806
20:26:29.211306 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806
20:27:33.293013 IP 10.10.10.248.49400 > 63.241.66.151.http: F 215:215(0) ack 24179 win 32806
20:28:37.374242 IP 10.10.10.248.49400 > 63.241.66.151.http: R 216:216(0) ack 24179 win 32806

A quick nslookup returns:

%nslookup 63.241.66.151

151.66.241.63.in-addr.arpa canonical name = 151.epocrates.com.
151.epocrates.com name = honors.epocrates.com.

Is this proof that an app can communicate after it terminates? Or just a quirk of the iPhone OS?

– Added 7/14–

Followup: Looks like it isn’t an artifact of the OS but an intentional setting that allows apps to keep network connections open in the background.