I got the formula wrong.

Assume an initial swipe speed of S. Then the speed at time t is:

S_t = S – C * t,

where C is a coefficient of friction.

This means the position P_t at time T is:

P_t = S * t – C * t² / 2.

The total animation time T is when S_t = 0, at time S / C. This also implies that at the end of the animation, the final resting position is:

P_end = P_S/C = S²/(2*C).

It is easy enough to adjust the speed so that at the final end time the animation stops at an even location; simply update the resting location P’_end and solve for S’: S’ = sqrt(2 * C * P’_end).

I had out-thought myself by creating a formula with a constant animation time, but it resulted in “floating” which felt unsatisfactory. This morning I realized that it’s a matter of simply solving for a coefficient of friction, which is close enough to how the real world works that the animation for FlowCover feels “right.”

Doh!

Footnote: Beware that this assumes speed is positive. If speed is negative (because you’re swiping the other way) you need to set a flag that indicates direction, or substitute -C for C in the formulas above. A corner case, of course, is if you adjust the speed and wind up going in the opposite direction. And of course in the last formula, by convention sqrt() returns the positive root, though mathematically there are two roots–a positive and a negative root. (That’s because -S² = S².) So you need to use the negative root if P_end is negative.

From Daring Fireball: Apple Wrongly Rejects iPhone App for Use of Private APIs

After waiting 33 days to hear from Apple after submitting their app Peeps to the App Store, Plausible Labs found out the app had been rejected.
…
The problem? According to developer Landon Fuller, they didn’t use any private APIs — they created their own Cover Flow implementation using the public APIs.

So, Google can publicly admit that their iPhone app uses private APIs and that’s OK, but a small indie developer gets rejected for cleanly creating a feature that looks like Cover Flow.

This actually bothers me enough to tempt me to create my own CoverFlow-like implementation and post it as BSD-licensed software. I mean, I can understand if Apple doesn’t want an application to look like CoverFlow and thus set forth the rules–but to reject an application because it cleanly implements something that looks like CoverFlow? Feh.

With the 2.0 release of the SDK Apple promised to provide some sort of notification mechanism so that third part applications could be notified of incoming messages and potentially even handle those messages. Unfortunately Apple has failed to provide such an SDK, and I think the reason has to do with background processing: Apple doesn’t want a whole bunch of iPhone applications launching executables in the background. The problem, of course, is that any SDK which triggers a background process gives a developer the opportunity to hog CPU cycles, draining the battery and slowing the iPhone down.

I have a modest proposal as to how to handle such a mechanism which would not require a background process to be triggered which could potentially be abused.

There are three classes of applications in Apple’s iPhone suite which receive background notifications. The first class, the SMS message system and the phone system, updates the message count in their application icon, plays a notification sound, and they also post a text string summarizing the message on the home screen before the phone is unlocked. The second class, such as the iPhone Mail application, plays a notification sound and updates the message count in the application icon, but does not display a message on the home screen. And the third class, such as the App Store, displays a message count but does not play a sound.

It seems that one could easily provide a notification infrastructure through the Mobile Me servers to provide the second and third class of service to third party applications.

This would be done as follows:

(1) In order to figure out which phone should be notified, an extension to the iPhone’s API to get the device IMSI identifier would need to be provided. This would allow an application on the phone to obtain and transmit the IMSI, so the user of an application can be linked to his specific phone.

(2) An extension to the Mobile Me service would need to be made to allow a notification message to be sent to a specific device identified by its IMSI. This value would also be linked to the specific receiving application using the application’s bundle identifier, and the packet would allow a limited amount of information to be sent–perhaps around 80 bytes, more than long enough for a UUID or a small token to be sent to the phone. Ideally this would also allow the notification packet to fit within a SMS style packet over WDP.

(3) A new message notification task would need to receive the WDP notification messages for the device. This notification task service would handle receiving the incoming notifications and putting them in a database queue sorted by application identifier.

(4) Each application which can receive notifications would need to be extended with a configuration bundle containing a short snippet of XML which would indicate how incoming messages are handled. There is no application code here; instead, the XML would indicate that when a notification was received:

(a) The application’s notification number should be set to the number of incoming messages, or the number of incoming messages are added to the notification number in the application, or (for applications which send one notification indicating multiple things) if the notification number should come from the message body. (Thus, there are two orthogonal options here: each message represents 1 or more than 1, each message adds or does not add to the existing application badge value.)

(b) If the phone should play a notification message if a notification for that application is received,

(5) A new API which, on application launch, allows the application to get the incoming notifications from the notification service database.

This would allow applications to receive notifications from a remote server without having to actually execute on notification.

Now of course the channel into the Mobile Me notification service should be hardened: perhaps a two-way SSL certificate can be set up so that incoming messages from a developer must use a signed certificate to establish the SSL connection, along with some sort of handshake to verify the identity of the server sending the message and if it is authorized to send messages to the specific application. And naturally the notification service would need to throttle messages from a remote service to prevent ‘spamming’ devices, and a developer’s notification service channel would also need to exist for testing purposes.

But I think this is entirely doable, and would provide what a developer would need to develop an IM-style application or messaging application without running a background process to check for new messages.

Fourteen copies.

I sold 14 copies in the first day; 13 in the U.S. and 1 in Mexico.

I’m not surprised. There are a few things working to my disadvantage: first, I’m not an artist or a sales person; I’m a programmer. If I were to make a serious living at this, I’d get a real artist put together the icon art and the game play art so it’s not so, um, amateurish.

(Don’t worry; I intend to continue to support this game, including a redesign of my iPhone landing page which will link to this blog. I also have an offer from my brother for game music, and I know a few artists through whom I can rev the artwork. So don’t take this as an admission of giving up on Invasion Defense.)

But artists, like programmers, cost money. My original goal in putting this game together was to understand the process, not to make money: making money can come when I understand the process. And here are my observations about the process:

To make a successful iPhone game, you need a marketing person, an artist and a good programmer. I’m of course one third of this; with the other two people I think we could make some serious cash.

You cannot rely upon the App Store to market your product. There are so many applications for the iPhone (10,000 at last count) that it is impossible to rely upon your presence in the “what’s new” section. Research shows that the number of people who browse web pages exponentially drop off as you move off the first page, and new applications only show up on the front page for perhaps a few hours at best. (Now if I wanted to make money I would have gotten an artist to do my application icon and my flying saucer and city icons.) But even with the best presentation, you still blend in with the thousands of others.

It strikes me the reliable money for iPhone development will be in the enterprise. If and when Apple gets its act together and puts together an enterprise development strategy to allow enterprises to provision enterprise owned iPhones with custom software, a huge business will spring up for iPhone development consultants to put together enterprise iPhone software. Until that time, however, its unclear how an enterprise can distribute its products.

One suggestion for Apple (for the three people reading this blog): perhaps if you can mark your application as “private” and/or create a password-protected area on the Apple Store, so that in order to install an application you need the private URL, a password, and perhaps a second provisioning certificate, along with guidelines for how to secure your application, then Apple can satisfy enterprise concerns. Within a company’s internal web site a link to the “enterprise” app site on the Apple Store could be given, along with a password so a corporate user can log in and download the application to his iPhone. It won’t stop internal applications from leaking out into the wild–but that happens regardless. But it would allow enterprise applications to be distributed while allowing Apple to have control over the sole application distribution mechanism.

(It’s one reason why I believe the Google Android based phones are currently well positioned to overtake the iPhone in corporate environments: a Java-based phone with an open distribution network allows enterprise businesses to create and distribute custom software easily. The iPhone, on the other hand, does not currently allow custom enterprise apps to be distributed easily. ‘Nuff said.)

And, more importantly: There is no money in free software. Or, more specifically, there are three ways you can make money at anything: sell it, charge for supporting it, or use it as advertising. In my case, I’m using this web site as advertising: if you need a good Java, MacOS, Windows Mobile or iPhone developer, drop me a line. RedHat makes money charging to support RedHat Linux. And Microsoft makes money off of Windows by selling it.

But if you hire a bunch of programmers and artists and put together a really nice bit of software, without any model for how you’re going to make money, and you give away the game–then how are you going to pay back your investors? If there is no ad space in the game, if you don’t charge for supporting the game (and who will pay for game support?), um, how long can you keep it up?

And that’s the thing I don’t understand. Even with the best put together games, I’m surprised we had such a quick rush to $0 on the App Store, apparently on the theory that quality and low prices will translate into quantity and eventual profit.

Charging $10 for a well put together game makes sense to me–$2 for my amateurish attempt seemed right. Remember: feeding three people implies a burn rate for your company of $300,000/year–which means you must push 45,000 units/year at $7 profit, a far cry from my 14. And the economic model of a game company is simple: with few exceptions you write a game, you release a game, and in the first two months of sales you make that money back. If you have a constant churn of about 6 games a year, that means you need a pipeline of games at various stages of development averaging about 2 months per release. And on average, each game needs to sell 7,500 units at $10 each to make your business an on-going concern.

At $0.99 or $1.99 the profit equation changes: suddenly instead of having to sell 7,500 units every two months to feed your three people, you’re having to sell 75,000 units at $0.99 or 38,000 units at $1.99 for each game created. That’s a lot of units to sell–especially since people don’t remember game makers, only the games they make.

And at Free–um, where’s the money coming from? Good will?

(It’s why game companies rely upon franchises: my simple game took me two weeks of part-time effort just to come up with the idea. A franchise allows you to short-circuit the creative process: get an idea and milk it dry. And a franchise allows you to get repeat business: the same idea with variations can make you a lot more money than that one idea, extremely well executed. Just ask the “(insert musical instrument) Hero” franchise.)

The days of two million people and 100 apps on the App Store is now over.

I’ve heard that it takes about two weeks–and over Christmas it could take up to three weeks–for your application to be cleared by the Apple reviewers and posted to the Apple Store.

Perhaps its because Invasion Defense is a simple game. Perhaps its because I’m not connecting to a remote network (high scores are your own high scores), or perhaps because I’m not doing anything particularly complicated–there is only two screens. I dunno.

What I know is that where everyone else is complaining that it takes your application 2 weeks to be posted to the Apple Store, my app took 48 hours.

Maybe its because Apple has hired some temps to review apps? Or perhaps Apple is applying some reverse engineering in order to determine the flow of your application from the NIB files and Objective C code in order to gain insight into how your application works, so they can then create a review and test plan for the reviewers?

It’s a shame because this next weekend I plan to redo the Chaos In Motion site to create an “iPhone” section, so people who click through to the support site gets something better than my blog.