Talk Funnel

There’s been a lot of behind-the-scenes activity around these parts and I hope to be posting more actively from here on out. But first I’d like to announce my first iPhone product on the AppStore, published under the FrolicWare label:

AutoPark: Say Goodbye to Parking Tickets. It lets you keep track of time on your meter so you avoid parking tickets. It uses push notifications to send out an early-warning and a separate meter expiration alarm. The intent behind it, however, was to be an all-in-one driving assistant so it does a few more things, like:

• Help find a parked car using the GPS.
• Remember where you parked in a parking lot (floor, section, color zone, etc).
• Work with or without push alarms enabled (if away from the data network).
• Track time on parking meters or with pre-paid parking machines.
• Attach a text and picture note — handy for remembering what that rental car looks like.
• Email all parking data out via a rich HTML message with embedded map and links.
• Get a list of nearby local services (bank, gas station, bathrooms) you might need when you’re parking your car or right before leaving.

it’s available for $4.99 on the AppStore and the first user reviews have been pretty positive. It’s already made it into MacWorld Magazine!

But this isn’t just about a single iPhone app. There are a lot of posts rattling around my head that I’ll be rolling out gradually: from the evolution of the UI and graphic design, to running a one-person development shop, the economics of app development, the transition to iPad, tips and tricks on developing a push server, and the process of marketing an iPhone app. From conversations with fellow iPhone developers I get the feeling this is information that could be useful to others in their own efforts.

When the AppStore was first announced, I remember thinking this is the first time an individual or a small team can easily bring a software product to market without having to worry about a lot of the hassles of full-bore software publishing. I still think that’s the case, but I was off by an order of magnitude on the it’ll be easy department. I’m going to write about this experience because I think it’s good to get these things out there for all those people dreaming about starting their own gig.

In the meantime, here’s a presentation I gave at the January 2010 Silicon Valley iPhone Developer Meetup on development of back-end servers for iPhone apps. I tried to avoid making it about a specific product but it relies heavily on the experience of putting together the AutoPark push notification server.

This is only the first app out of the chute and this is the first post on what goes on behind the scenes. So stay tuned…

---

P.S. I’ll be showing off AutoPark (and maybe a peek of an upcoming app) at MacWorld Expo in San Francisco February 9-13, 2010 at the Mobile Application Showcase. This is the first year they’re featuring iPhone apps so it’ll be interesting to see how they’re received in a historically Mac-only conference. It’s also my first time as an exhibitor (and yes, I’ll be blogging about it).

Feel free to pop over and say hi.

[ This ended up being a fairly long and somewhat technical post. I edited it down as best I could, but I think it's an important topic in the iPhone world and something that has to be laid out in its entirety. I suspect it won't be of much interest unless you're an iPhone app developer, a highly technical end-user, or a masochist masquerading as a layperson. You have been warned. - Ed.]

The news dropped like a bombshell on the iPhone developer community yesterday: Apple is now allowing In App Purchasing in free applications. Hip Hip Hooray!

But wait. What does that mean?

I won’t repeat what I’ve already said in a previous post but the upshot is it’s now possible to ship a free application on the iPhone appstore then ask the customer to purchase an ‘unlock’ token once they’re done evaluating it. The common consensus (as much as what is said on blogs, mailing lists, and twitter can be considered so) in the developer community is that it’s a positive move. Marco Arment (the developer of Instapaper) called it a “… great move for both users and developers.”

The Good

With this seemingly small change in policy consumers can (finally) try out an app before they have to pay for it. No more buying an app then realizing it doesn’t work and getting stuck with a dud. The immediate effect will most likely be fewer impulse sales–which means lower short-term revenue–but in the long-term users are more likely to be happy customers instead of accidental ones.

It’ll also mean that app developers should be able to increase their asking price for well-made apps, because users will have had a chance to take it out for a test run. On the other hand, there’s no guarantee this will end up increasing per-app revenue given the low conversion ratio from free to for-pay apps. In fact, I’d strongly question the logic of $0.99 apps even bothering to offer an evaluation version. All those impulse and let’s try this purchases probably account for a more substantial portion of sales than most developers care to admit.

But the initial developer reaction seems to be positive. Most indy developers in it for the long run would rather have fewer happy customers vs. a lot of unhappy ones.

The Bad

First, let’s take a little detour and define what we actually mean by an evaluation app.

In the regular computer world (versus, you know, the iPhone Candyland) a developer creates an application then offers it to the user for evaluation in one of two possible ways:

1. Degraded mode: this is where the application has some of its features disabled, for example, no saving or only printing with a watermark. The user gets to experience what the app does, but only up to a point. How much functionality is included is up to the developer but it’s in their interest to allow as much as possible to make the sale without giving up too much.
2. Time-limited mode: this is where the application is fully functional for a limited amount of time (usually two weeks to 30 days). After that either the user buys the app or it stops working. A slight variation is where the app reverts to degraded mode when the eval clock runs out.

The main difference between a Time-Limited and a Degraded app is what the developer allows the user to experience during that period of time. That’s an important distinction because the end-user experience was noted by Apple as the main reason they initially didn’t allow In App Purchasing in free apps. The reasoning was that a user should not be told an application is free, then be forced to pay for it. But it appears that concerns for application piracy and loud complaints from developers have overridden those worries. But the problem is still valid. Hopefully Apple will make changes to the Appstore to better communicate the actual fully unlocked price to avoid end-user confusion.

There’s also a subtle issues unique to the Time-limited app on the desktop and that is what to do when the user tries to get around the evaluation restrictions — ostensibly to keep using the application in full evaluation mode ad infinitum without having to pay. The two most common methods are settings back the system clock (to make the app think the eval time hasn’t run out), or to uninstall then reinstall an app to reset the meter.

The solution to both of these problems is fairly simple: the app can write an already run token and periodically save a time-stamp in such a way that persists beyond an application getting uninstalled. Then it’s fairly easy to detect if the clock has moved back or if an app has been reinstalled.

But that’s the desktop. What about the iPhone? The problems are the same. Some users may be tempted to keep an eval app (especially a high-priced one) running. Can the clock reset trick work? Yes, it can. Most users leave their phone’s clock in its default auto-update mode so they can use their phone to keep track of time. But it’s fairly easy to reset it manually. All you have to do is run the Settings application, go under General tab and disable Set Automatically then set the clock to whatever date and time you want. The down-side to this is that so much of what you do on a typical iPhone relies on the system clock so it’s unlikely someone will be willing to put up with having a constantly skewed clock on their phone for the sake of just one application. But you never know.

What about the delete/reinstall method? On the iPhone, once an app has been deleted all associated files are also removed so there would have to be a way to save a persistent token that outlasts the app install-delete cycle. On the iPhone, unlike the Mac, no such place exists. The app developer could always save the unique device ID (UDID) of the phone on a server, but the Apple developer license explicitly forbids saving private user data off the phone. Does the UDID count as private data? It certainly is unique. We’ll have to see. But at the very least, it means each developer has to maintain server infrastructure to track this sort of thing.

So as it currently stands it’s too easy for a user to simply remove and reinstall an app or to fiddle with their clock and continue using an app in its fully-functional eval mode. I’m pretty sure this isn’t what Apple had in mind when allowing In App purchases.

That leaves Degraded mode. This means that the application the user would download from the Appstore for evaluation wouldn’t be the full version. In an earlier draft of the developer license agreement shipping this type of app was explicitly forbidden. In the newly revised version, well, it’s not so clear. In Attachment 2.4 it is clearly stated that:

2.4 You may not use the In App Purchase API to send any software updates to Your Application or otherwise add any additional executable code to Your Application. An In App Purchase item must either already exist in Your Application waiting to be unlocked, be streamed to Your Application after the purchase transaction has been completed, or be downloaded to Your Application solely as data after the purchase transaction has been completed.

This means that the full application functionality must be installed on the phone–no way to send up updated binaries. So all the code is there ready to go but a little key is needed to unlock it. On the desktop this type of app is derisively (and deservedly) called crippleware.

In other words, as of today, what Apple is allowing app developers to ship is crippleware for your iPhone. I could be wrong on this but this clearly falls under the category of Unintended Consequences.

The Ugly

The user plays with the eval app for 30 days (or so) then purchases the unlock token via In App Purchasing. The token is saved on the system so from now on the app launches in its unlocked state. But what form is that token going to take and where is it going to be stored? Given the current sandboxed architecture of the iPhone app, There are two places where an application can actually write data:

1. The filesystem under the application’s Documents folder. This can be a text file, a user preference plist, a record in a SQLite database, or a CoreData store.
2. In the keychain as a secure key/value data item.

Apple has intentionally stayed out of the business of what shape or form this add-on functionality or unlocking feature should take. It’s up to the individual developers to decide but odds are it will be one of these two methods.

Trouble is both these methods will actually make it easier for apps to get pirated.

On a regular iPhone no app can cross the sandbox line and access another app’s private data. But on a jailbroken phone no such lines exist. So a few minutes after the app is installed on a jailbroken phone, that special token can be easily extracted and plastered all over the internet. Now you don’t even need to resort to apps like Crackulous to get your free fully-functional apps.

The solution is for each individual app developer to implement tighter security around the application, by implementing secure unlock tokens, perhaps even tied to a specific handset so even if they’re removed from a single phone they won’t be usable on any other phone. But that involves knowing quite a bit about the pros and cons of cryptography and your typical iPhone app developer is not going to have the time and patience to implement anything like that.

So they’ll take the quick and expedient way–they’ll offer crippleware and save the token into a user preference plist or keychain — and hope and pray nobody bothers looking there. Or they’ll sign up with outfits like Urban Airship, iLime, or Push.IO to take care of it for them for a fee.

But this doesn’t mask the fact that with no Apple-defined standard, it’s going to be a free-for-all.

The final bit of ugliness heading our way has to do with user reviews. In the early days of the AppStore anyone could leave reviews — regardless of whether they had bought the app or not. This rendered the system useless since most of the initial write-ups consisted of, um, price-resistant customers (endearingly called freetards by developers) complaining about the price, no matter how low. It didn’t take long for Apple to clamp down on this by requiring only those who had actually purchased an app to review them. This substantially cut down on the noise and helped keep Appstore reviews an important part of the consumer decision-making process.

But now with the advent of free evaluation apps we’re going to go back to the halcyon days of price-gripes, where a user will download the free version of the app, take a look at the price for obtaining the unlock token and submit a 1-star review, complaining about, yes you got it, the price of the app. The current AppStore filter will not work since they’ve officially downloaded the app and technically count as having purchased the app.

One step forward. Two steps back. In other words, it’s going to get ugly. Again.

Unless…

You’ve been so patient. I won’t keep you waiting. Here are a few steps Apple needs to take for this eval system to work:

1. Offer a simple, official API for supporting both Time-limited and Degraded evaluations. This means associating some application metadata with each app when it’s installed and forcing Springboard (the iPhone application launcher) to honor these settings before running the application. Springboard already does this when it installs an app–that’s how the App Store application updated can tell what version you’re running vs. what’s on the store.

   To prevent the remove-reinstall workaround, there has to be a way to save some information that lives outside the sandbox and survives application removal. This can be on the phone or on a server. Again, Apple already does both these things. It saves data to the system keychain and it keeps track of what apps you’ve “bought” on the AppStore (so when you go reinstall, it knows not to charge you twice). So it would be easy for them to let the app-developer mark the application as eval, whether Time-limited (and or how long) or Degraded.

   I would even argue that anything having to do with application installation or unlocking belongs in the AppStore/OS domain, not left to individual applications. Anything having to do with In App purchasing of extra grenade-launchers, leave it up to the app.

2. Far, far more importantly (and I can’t emphasize this enough) Apple should provide a simple API for an application to verify that the current user has purchased the app. This will do far more to cut down on application piracy than allowing free evals. The app developer can periodically and at random times invoke this API and ask two simple questions: Has the current user bought this app? and When?.

   A developer would be wise to sprinkle calls to the API throughout the app. Yes, the application binary can be patched and the API call removed, but that’s a higher wall for your typical cracker to climb than simply modifying a single entry in a text file.

In the absence of a network connection, the default would be to let the application run a limited number of runs (until the user gets back to the network).

But what about the When? question? The answer would be a timestamp indicating when the user paid for the app. That piece of information is important to app-developers who currently have multiple free/pay versions of applications on the appstore (or who want to continue using that model). For these folks to move from a free/pro model to an eval/buy model means that their end users would have to obtain a new version of their application. There would have to be a way to tell whether the current user paid for the full version of the app during the pre-eval period and not force them to go through the whole purchase cycle again.

I should also emphasize that with this API the application will never have to be given access to any private user-credentials. Something like the following added to UIApplication will work wonders to ward off app piracy:

+ BOOL isAppPurchased;
+ NSDate* dateOfPurchase;

3. The last thing Apple could to do help eval/buy apps a success is implement a policy where only users who had purchased the unlock token would be allowed to post comment and reviews on the AppStore. Let’s maintain the status quo instead of taking a step back. The problem, however, is given the totally unstructured way the current In App Purchase model is implemented, there is no viable way in which an extra rocket-launcher token can be distinguished from an unlock application token.
   
   I would argue that unlocking eval applications, verifying proper ownership, and restricting access to the review system should be the responsibility of the entities that control application installation and launching–i.e., the operating system and iTunes–instead of individual developers. But in lieu of that, Apple should give developer tools to properly implement an evaluation system that welcomes legitimate users and cuts back on potential abuse.

In summary: The In App Purchase mechanism is a great system for supporting application add-ons. But it’s wholly unsuited for supporting eval applications and does nothing to fight application piracy. Having properly implemented eval apps is important to the future of this ecosystem. Apple shouldn’t leave it up to individual developers to figure out how to get there. It should be part of the core functionality of the operating system.

I agree with most everything Karl Adam says about the limitations of the Apple Push Notification Service, especially the problem with its failure to stack notifications so they’re not missed.

I posted a bug report a while back (rdar://7054632) offering a simple solution to get around this particular problem: save each incoming push payload into Messages.app as a separate entry. That way if I get a push and don’t have time to get to it I can ignore it and come back to Messages later on and retrieve it and all received Push messages are kept until I choose to get rid of them.

The entry could be in the form of a special URL link that shows the alert message, but when clicked generates the same JSON payload format as a regular push event and invokes the app in the same manner so no extra coding would be needed (OK, maybe just a little bit of code on the server to check against processing duplicate requests). It would take care of a lot of problems with push usability.

An even more pressing issue I have with Push is if you are on a WiFi network behind a bunch of firewalls and more than one NAT server. This happens often in corporations or in homes with multiple routers acting as range-extenders. In these cases pushes fail to reach you — until you get back to a 3G network.

For some people Push is doubling as a remote event timer (since Apple won’t let us access the phone’s alarm database or submit local cron tasks). This makes it really hard to issue reliable time-based alerts.

If Apple would just open up true background tasks and/or timed alerts and let the user decide whether they trust an app to let it access those services (much like location-based or push services) a lot of these hassles would go away.

Also, a European friend brought up that whereas SMS is included in most phone plans, push incurs data usage charges. Could be a hassle if you’re traveling and continue getting pushes.

Over all, I’d say push on the iPhone is a work in progress. As much as I’m intrigued and excited by its potential, I’m frustrated by its current implementation and limitations.

Popping up a modal dialog on the iPhone is a fairly straightforward process:

	modalDialogViewController *modalController = [[modalDialogViewController alloc]
            initWithNibName:@"modalDialogView" bundle:nil];
	[self presentModalViewController:modalController animated:YES];
	[modalController release];

Dismissing it then is a simple matter of the modalController invoking:

	[self dismissModalViewControllerAnimated:YES];

But what if you want to show only half a page’s worth or maybe you need the underlying view to continue being available for user viewing or interaction. Or maybe you want to show a pop-up toolbar where users are asked to choose something before continuing. You might think “Aha! I’ll just have my modal dialog view be half as tall and make the background transparent.”

Go ahead, give it a try. We’ll wait… (* … the girl from Ipanema goes walking … *)

So now you know that the standard modal dialog can only be full-screen and maintains a solid black background. What’s more you can’t interact with what’s behind it because, you know it’s modal — and modal means users shouldn’t be able to do anything else until they’re done with the front-most task (unless you’re the search box in the Contacts app in which case apparently it’s OK to be kindasortamodal).

So what we’re going to do is have a view that can be modal but takes only part of the top view, the space above it remaining visible. What’s more, you can choose to have it so tapping on the background view hides the modal view, or even go full-bore and let the background remain responsive to user input. This technically makes the view semi-modal so let’s ignore the sirens and the UI Police banging on the door and go with that.

The first thing you need is a view that has something interactive on it. The easiest way to build one is in interface builder, so go ahead and make yourself one. For the sake of expedience make it only a fraction of the screen. Here’s an example of a half-height view along with some user controls. The background is set to fully transparent. The view is connected to a UIViewController that reacts to user input:

In this case, the view is the same height as the whole screen because we want the upper portion to be see-through but not react to user input. If we wanted it to be truly interactive, we could make the view height be as tall as the actual content (i.e. half-screen) but that would make it a bit strange for the user because it would be hard to tell apart the actual content from the modal view. But hey, it’s your app. You can do what you want.

Another option is to set the background of this view black and partially transparent. That would look cool and show a nice smoky cover while we’re in modal mode… unless you’re mucking with color (like we are in this example) in which case it’s best to leave it fully transparent.

Next throw the following code in the parent UIViewController. Load up the UIViewcontroller/UIView you just created and pass the view to this routine instead of calling the standard presentModalViewController method (substitute your application delegate for MyAppDelegate):

    // Use this to show the modal view (pops-up from the bottom)`
    - (void) showModal:(UIView*) modalView
    {
    	UIWindow* mainWindow = (((MyAppDelegate*) [UIApplication sharedApplication].delegate).window);

    	CGPoint	middleCenter = modalView.center;
    	CGSize offSize = [UIScreen mainScreen].bounds.size;
    	CGPoint offScreenCenter = CGPointMake(offSize.width / 2.0, offSize.height * 1.5);
    	modalView.center = offScreenCenter; // we start off-screen
    	[mainWindow addSubview:modalView];

    	// Show it with a transition effect
    	[UIView beginAnimations:nil context:nil];
    	[UIView setAnimationDuration:0.7]; // animation duration in seconds
    	modalView.center = middleCenter;
    	[UIView commitAnimations];
    }

What this does is add your view as a top-level above the main window, effectively rendering it modal. It also uses Core Animation to move the window from offscreen bottom up until it’s fully shown. You should adjust the timing to suit your view’s actual height. I’ve found that the taller the semi-modal view, the more time you should give it to become fully visible.

Now let’s go through the hiding action. Note that we use the animation completion handler to do the actual removing of the item from the parent view and cleaning up. We also use the context parameter of the animation call (which was thoughtfully provided for exactly this sort of thing) to keep track of what view to clean up afterward:

    // Use this to slide the semi-modal view back down.
    - (void) hideModal:(UIView*) modalView
    {
    	CGSize offSize = [UIScreen mainScreen].bounds.size;
    	CGPoint offScreenCenter = CGPointMake(offSize.width / 2.0, offSize.height * 1.5);
    	[UIView beginAnimations:nil context:modalView];
    	[UIView setAnimationDuration:0.7];
    	[UIView setAnimationDelegate:self];
    	[UIView setAnimationDidStopSelector:@selector(hideModalEnded:finished:context:)];
    	modalView.center = offScreenCenter;
    	[UIView commitAnimations];
    }

    - (void) hideModalEnded:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context
    {
     UIView* modalView = (UIView *)context;
    	[modalView removeFromSuperview];
    	[modalView release];
    }

What I’m not showing you here is the way to trigger the show/hide action. That’s entirely up to you. In standard iPhone modal dialogs this is often a button in the toolbar or navigation bar. In the case of the semi-modal dialog, however, you have even more flexibility. Basically it comes down to the show/hide elements being:

• Explicit: Provide an Accept or Cancel button on your view.
• Implicit: You can simulate an action toolbar that shows and hides this way. Put a row of buttons on the view and wire it so tapping each one invokes hideModal before going on to the actual action.
• Other: Tapping anywhere else on the screen dismisses the dialog. You can do this by placing a full-screen sized view (or custom transparent button) behind your modal dialog and wiring it so it a tap-down action dismisses the dialog . For best results, try making this full-screen view black and semi-transparent (e.g. opacity=0.2). This way the user’s main view darkens so they get a sense your modal dialog is in focus but they still get to see what’s behind.

Here’s a movie of the above semi-modal view in action. It lets the user select a color then confirm or cancel the action. The modal view in this case also has interactive controls on it. As the user changes color the background image changes in real-time so they can visualize what the end-result will be like. Once they’re done they can tap the checkbox or X/cancel buttons to make the modal go away.

The semi-modal dialog is a handy UI interaction component but it’s important to think about how to dismiss the dialog and what to allow in the rest of the visible region on the main window to avoid confusing the user. Also note that there are no restrictions on the shape or size of the overlay view as long as the background color is set to [UIColor clearColor]. You can use the same method for irregularly shaped pop-ups.

Go nuts and have fun.

I’ve been trying to get the iPhone Push notification services introduced in OS 3.0 working with Python (specifically, Django). It took a while but I figured I’d post my notes so it’ll spare someone the suffering I had to go through.

Other attempts at this (apns-python-wrapper (aka APNSWrapper) and Lee Packham’s code) both use the standard ssl libraries which I couldn’t get to work under Snow Leopard and Python 2.6.

I eventually got it going with Django and pyOpenSSL libraries. The easiest way is to get the prebuilt pyOpenSSL binaries from eGenix. If the test server is running on Snow Leopard the Python 2.6 UCS2 version seems to work best.

The thing about pyOpenSSL is that it expects the certificate and private key to be in separate .PEM files so you have to export each one from KeyChain Access in .P12 format then convert them to .PEM from the command line. For the development key it’s easier to specify the password during export then strip it out on the command line. In production you may not want to do that.

   % openssl pkcs12 -clcerts -nokeys -out devcert.pem -in devcert.p12
   % openssl pkcs12 -nocerts -out devkey.pem -in devkeypw.p12
   % openssl rsa -in devkeypw.pem -out devkey.pem

Now copy devcert.pem and devkey.pem (with no password) into the server directory.

The following bit of code is in a file called PushSender.py and does the actual talking to the push server (I heavily edited out project-specific bits and standard exception and error-handling stuff. Hopefully didn’t bork it too badly

Also, in this example the actual communication runs in a thread. In some cases it might make more sense to run it as a main routine:

import os, sys
import struct, binascii, ssl, datetime
import threading
import simplejson as json
from socket import socket
from OpenSSL import SSL

class PushSender(threading.Thread):
def __init__(self, sandbox, token, message, badge, sound):
	super(PushSender, self).__init__()
    		self.token = token
    		self.sandbox = sandbox
    		self.message = message
    		self.badge = badge
    		self.sound = sound
    		self.ctx = SSL.Context(SSL.SSLv3_METHOD)
    		if sandbox:
    			self.apnHost = "gateway.sandbox.push.apple.com"
    			self.ctx.use_certificate_file(os.path.join(PROJECT_ROOT, "devcert.pem"))
    			self.ctx.use_privatekey_file(os.path.join(PROJECT_ROOT, "devkey.pem"))
    		else:
    			self.apnHost = "gateway.push.apple.com"
    			self.ctx.use_certificate_file(os.path.join(PROJECT_ROOT, "prodcert.pem"))
    			self.ctx.use_privatekey_file(os.path.join(PROJECT_ROOT, "prodcert.pem"))

    	def run(self):
    		payload = {}
    		aps = {}
    		if (self.message):
    			aps["alert"] = str(self.message)
    		if (self.badge):
    			aps["badge"] = self.badge
    		if (self.sound):
    			aps["sound"] = str(self.sound)

    		payload["aps"] = aps

    		token = binascii.unhexlify(self.token)
    		payloadstr = json.dumps(payload, separators=(',',':'))
    		payloadLen = len(payloadstr)
    		fmt = "!cH32sH%ds" % payloadLen
    		command = '\x00'
    		msg = struct.pack(fmt, command, 32, token, payloadLen, payloadstr)
    		sock = socket()
    		s = SSL.Connection(self.ctx, sock)
    		s.connect((self.apnHost, 2195))
    		s.send(msg)
    		s.shutdown()
    		s.close()

[ PushSender source ]

To invoke it in a thread (the first param is True for sandbox and False for production server) from the main routine:

	from PushSender import PushSender
	...
	pushsender = PushSender(True, token, pushmessage, pushbadge, pushsound)
	pushsender.start()

On the phone the token returned by the didRegisterForRemoteNotificationsWithDeviceToken method is in the form <xxxxxxxx xxxxxxxx ...>. To pass it along to the server you have to strip out the <> and spaces. The unhexlify method then converts this string into a 32-byte hex binary value. The easiest way to strip out the extraneous stuff is to just do it on the client-side:

    NSString *deviceToken = [[[[tokenString description]
			stringByReplacingOccurrencesOfString:@"< " withString:@""]
			stringByReplacingOccurrencesOfString:@">" withString:@""]
			stringByReplacingOccurrencesOfString: @" " withString: @""];

One last thing: at least with the sandbox if the phone is running on WiFi sometimes push notices don’t come through. This may be due to router NAT or firewall configuration issues. One way to check is to go into XCode Organizer while the phone is tethered and run your app, then under the Organizer Console you can check for errors. To get around this you’ll want to turn off the WiFi on the phone and go with 3G. This usually makes push notices arrive as expected (and strangely enough the WiFi method goes back to working for a few minutes).

There’s more that needs to be done to make it production-ready but at least it’s good to know it’s doable:

 

Word came today that Apple’s WorldWide Developer Conference is going to be running from June 8-12 2009 in San Francisco.

Since Apple’s no longer going to be participating in MacWorld this is one of the few public conferences where Apple and its partners can make public product announcements. So now’s a good time to start floating outlandish rumors
predictions as to what’s going to be announced.

Since Apple already announced its intention to release iPhone 3.0 software around that time, a lot of products will be taking advantage of those features. One of them was access to the external USB port. The announcement demo featured a heart-monitor. My prediction is it will be totally upstaged by one of these:

One of the loudest complaints about the iPhone AppStore has been the lack of support for eval or demo applications. In the desktop world users can often download an application and use it for a period of time before deciding whether it’s worth paying for. But in the iPhone AppStore universe (where all transactions occur) there is no such support. Developers are then faced with the option of offering a lite version for free (or inexpensively) and a full version of their apps. The problem is that this still doesn’t allow the end-user to test out the full app and then choose to buy it if it fits their needs. And switching from a free to a full app involves installing an entirely independent application.

What we really need is a way to upgrade an eval app to the full version once the user decides the app is worth paying for.

Yesterday Apple publicly announced the developer release of iPhone 3.0 software (it won’t be publicly released until this Summer). To the dismay of many developers, there was — once again — no mention of support for eval applications among the 100 new features and “1000 new APIs.” So again, we are left without the option of letting users download an app, take it for a test run and then pay for it.

Or are we?

One of the features announced publicly was support for In App Purchases. This was presented as a way for users to obtain add-on levels or objects directly within games. The transaction (or more precisely, micro-transaction) still goes through the AppStore and gets charged to the same account. Despite public detractions I belive this is a Good Thing — especially since the feature can be used to legitimately support eval applications, even if the AppStore doesn’t officially support it yet.

Here’s how:

• Developer offers application for free on the app-store. This is a fully functional version (i.e. not lite or crippleware).
• User downloads and runs the application and is informed that the application is in eval mode and will stop working after a period of time.
• After the eval period (say, 1-4 weeks) the application puts up a notice indicating the eval period has expired. It can either stop working or drop into a degraded mode.
• At this point the user is given the option of performing an In App purchase of the full application.
• If user accepts, the application contacts the AppStore and purchases the add-on — which would be priced at what the full-price of the App would otherwise be. Once completed, the app downloads an add-on key indicating the app has been purchased.
• The presence of add-on indicates that the full app has been purchased and the timeout is taken out. All the application has to do each time it is launched is to look for the presence of this add-on.
• Everyone’s happy.

There’s a key assumption here — that the AppStore keeps track of already purchased In App purchases the same way it does with full applications today. In other words, if the user tries to re-download an In App purchase that they’ve already purchased with the same iTunes account, they shouldn’t be charged twice. If a user deletes the app or moves to a new phone, all they have to do is download the free version of the app, perform another In App purchase (for free this time) and off they go.

However, if this assumption is not true and In App purchases are tracked separately than full applications (or the application itself is responsible for keeping track of those transactions) then the developer will have to implement a way to track In App purchases that works across multiple app installs — most likely a simple web-server to keep track of eval vs. purchased apps. Let’s hope it doesn’t come to that (the documentation on the Store Kit is not out as of this writing and even if it was, developers under NDA won’t be able to talk about it publicly until the public release of the 3.0 software).

There are some other issues that need to be hashed out, mainly what happens if unscrupulous third-parties find out what this add-on looks like and make it available for free download? The iPhone application sandbox makes it a non-issue since only the application itself is allowed to write to its Documents directory or modify its user settings — unless the phone has been jailbroken, in which case the concerned developer may want to support more complex security (like cryptographic signing) for the add-on. Given that the AppStore DRM appears to be compromised using this technique does not significantly increase the risk of software piracy.

Another potential issue is the user who downloads the fully functional eval version, uses it for the full eval period, then deletes it, re-download and installs it so they can get another free eval period. If this is an area of concern, it can be handled through a simple web-service that keeps track of how many times the same user has installed an app. Personally, I don’t think it’s worth the hassle given that deleting an app also gets rid of all user-generated data. But that’s me.

Note also that when I’m talking about downlaoding something, I don’t mean literally downloading a chunk of code, but some sort of token that takes away the eval time limit. The whole operation can be performed very quickly once the In App transaction is completed.

I firmly believe having support for eval apps is critical for medium to high-priced applications to flourish on the AppStore. A user will hesitate to fork out a high price for a full-featured app without having the option to kick the tires beforehand. This method can easily solve the problem and let developers do eval apps as soon as the 3.0 software is officially released.

Update: Apple has since announced that free apps can not use StoreKit. This is to avoid a potential bait-and-switch situation where the consumer downloads what they think is a free app and then get hit with a fee. However, I think it’s a misguided policy. A developer who does that will quickly get down-reviewed (if they even make it out of the app-review chute). A more likely scenario would be to allow users to use an app for a limited period of time, but give them the option to unlock the app for continued use.

Another more fundamental issue, however, is whether app developers even want an eval feature. I’ve heard from several Android developers that the Android store return policy has severely impacted sales of their apps. Their argument is that returns should be based on faulty apps, not because someone found their game too hard. Presumably, enabling eval apps will cut down on a lot of impulse-then-discard purchases that go on today.

Certainly a topic worthy of further discussion.

If you’re debugging on the iPhone and encounter a lot of NSArray objects, you’ll notice that dumping out the contents doesn’t give you too much information. To help remedy this situation, I whipped out a quick-and-dirty ‘helper’ to show a bit more detail. As with the UIView helper all you have to do is include the NSArrayDebugExtras.m file in your project and build it. This works through the standard Objective-C category mechanism by adding an extra method to an existing class.

To use it, set a debugger breakpoint and enter:

(gdb) po array-variable-name


What you will get is a recursive dump of the array and its contents. If the array contains strings, labels, text fields, or text views, the actual text value is shown. If it contains other arrays, it recursively walks down the array of arrays and shows the contents.

Since there’s no garbage collection on the iPhone, probably the most useful information is the retainCount for each array and item.

If the array contains a lot of custom objects, of course, you’ll only see rudimentary information. In that case, I suggest you make a point of defining a debugDescription method for each object so the contents can be properly shown.

Of course, you’re welcome to tweak the display format to show whatever information makes sense to you, but this should give you a good starting point.

[ Download: NSArrayDebugExtras.zip ]

Update: The [obj className] method is no longer accessible. Fortunately, the runtime function object_getClassName(obj) provides the same service. The attached code has been updated. Thanks to Howard Katz for noticing the problem.

Almost overnight a lot of apps have popped-up for the iPhone and many of them are games. Quite a few of them look like they were developed by hobbyists over a weekend (not that there’s anything wrong with that). But developing a quality, professional game for the iPhone is still a time-consuming and difficult task.

Once you’ve settled on the game concept, you have to create the play logic, then generate the graphic assets and multimedia. And somewhere along the line you actually have to write the code to make it all happen.

To build a serious iPhone game you currently have several choices:

1. Create a custom one-off app in Objective-C (or C++): This gives you the most control but it means your game is pretty much going to stay on the iPhone. No desktop version. No Wii. Just iPhone. That might be fine, but if you’re investing tons of hours in content creation and game design, you may want to think hard about whether it makes business sense to leverage all that work and hit more platforms. Building a custom one-shot app also means that all your development effort is only for that one game. Instead, you may want to…
2. Develop a general-purpose iPhone gaming engine: Where the gaming logic and media content are kept separate and defined in configuration files. This way, you can get two, three, maybe even 100 bangs for your buck. Hopefully, the configuration language is expressive enough so you can build a whole class of apps, not just the same thing over and over. You should be mindful, however, that the iPhone SDK prohibits use of scripting languages, so you can’t embed a Javascript, Lua, or Python interpreter into your code. If you don’t have the know-how or are short on time, you may want to…
3. License a third-party gaming engine: This takes you away from the pleasure of writing raw Objective-C code (I’m not kidding — it actually is a lot of fun) but it also gives you support tools like 3D modelers, asset managers, physics engines, networking, etc. so you can focus on the high-level logic instead of low-level coding. Most also support some sort of scripting, but get around the SDK restriction by compiling it into executable code.

I have worked on several Objective-C-based iPhone apps so far and developed a custom animation engine for a client, so I have squarely followed options #1 and #2. But I also have ideas for quick, fun entertainment/game apps that I’d like to whip out quickly without spending months on building a custom animation engine. I’d rather spend my time on polishing the game logic and generating nice looking multimedia assets instead of working around iPhone Core Animation’s strange quirks (please, don’t get me started).

So I decided to look around and see what’s out there and came up with the following. To be fair, I haven’t had time to dig too deeply into each one, but as a public service I figured I’d share what I’ve found so far. If I’ve missed any other platforms or made any factual errors, please feel free to post a comment and I’ll issue an update.

Here they are (in alphabetic order):

		ShiVa (with the iPhone Authoring Tool) from StoneTrip.
		Torque Game Builder (with the iPhone SDK addition) from GarageGames.
		Unity iPhone.

In terms of features it’s hard to tell them apart from their spec sheets. They all feature 2D or 3D graphics, support a variety of media and content (including shaders, sound, movies, etc), handle physics and collision detection, and playback audio and video. On the iPhone, there’s also support for the accelerometer (for tilt moves). All three engines support server-based multi-user playing which requires licensing their servers (or their hosting services). It’s not clear at this point whether they support WiFi-based Bonjour peer-to-peer networking which the iPhone and Touch both support.

What differentiates the three engines is what other platforms they support and their pricing model, so let’s dig into that.

ShiVa

ShiVa comes in three versions, PLE, Advanced, and Unlimited (here’s the feature comparison table). The development platform runs under Windows (or Parallels on the Mac). The PLE version is free and allows you to create an application, but you can’t publish the output commercially. For publishing you’ll need the Advanced or Unlimited versions. Advanced costs €169 Euros (approximately $235 at today’s exchange rate) whereas Unlimited will set you back €1,499 Euros (approximately $2080).

The main difference between the two seems to be that the Unlimited edition has additional benchmarking and optimization tools and supports team development. There is no extra cost for output to iPhone (and it looks like they intend to support Windows Mobile and Symbian). You can also target your game so it can run in a browser, but it requires the user to download and install a plugin. A standalone desktop app generator lets you target Windows, Mac OS X, and Linux. However, you’ll likely need to repurpose your media to fit the different screen sizes.

As far as console platforms are concerned, not much there yet.

To support multi-player mode, you’ll need to license the Ston3D Server which comes in PLE, INDIE and PRO flavors. PLE is free but is limited to a single application and 6 simultaneous users. Clearly, it’s intended only for development and testing. The INDIE version runs on Windows, Ubuntu, and FreeBSD, but is limited to 64 sessions (game instances) and 4 sessions per server. It runs €359 Euros (approximately $500) and the PRO server without the session limitations runs €599 Euros (approximately $832).

There are also extra server-side features like managed hosting, payments module, and direct messaging to the user (via SMS, MMS, and email).

Torque

GarageGames offers a dizzying array of products and Torque variations, targeted at anything from simple 2D to networked 3D games. The basic 2D package is the Torque Game Builder which runs $100 for Indie apps (those earning less than $250K per year) or $495 for Commercial version. The Pro version also gives you access to the source code for both the engine and the editing tools ($250 for Indie, $1250 for Pro).

If you want 3D support then there’s Torque Game Engine ($150 Indie, $749 Commercial). In both cases, you get a lot of tools that support building levels, media, sprites, etc. and take care of a lot of the low-level grunt work for you.

But that’s not all, Bob. There’s also Torque Engine Advanced ($295 Indie, $1495 Commercial). This gets you all the tools to develop advanced 3D games for consoles and desktops. To deploy your game to a console, you’ll want to look at Torque Wii or Torque 360 (for the XBox 360). License fees for these have to be negotiated.

But it’s the iPhone we care about and to output there, you’ll want Torque for the iPhone. First you’ll need a license to one of the existing ‘builder’ tools (Tool Builder for 2D, or Engine for 3D). for the 2D version, you pay an additional $500 for an Indie license. That lets you publish a single iPhone title. Each additional title you want to publish requires an additional $100 license fee. You also have to show the GarageGames splash screen when the game starts and mention them in the game credits (and app web-site). 3D game support on the iPhone hasn’t been released yet so there’s no price listed.

Want server-based networking? The basic server is open-sourced under GPL. If you want to use it in a commercial app, however, the cost is $295 for Indies and $995 for Commercial apps (consoles are separate). This is for games delivered on Windows, Mac, or Linux. It’s not very clear if networking is supported on the current iPhone version, but I imagine it’ll be there soon.

Unity

Unity supports 2D and 3D content with a visual editor to help you develop and design your game content. The underlying scripting technology is based on C# and Javascript but their iPhone Publishing product spits out an XCode project that they claim ‘just works,’ compiling the scripting code into fast ARM assembler code (and thus avoiding the iPhone SDK’s edict against built-in scripting languages).

Under Unity, the Editor is the main point of creating apps. You visually adjust parameters and get live previews, then create scripts to handle game logic. In iPhone ‘preview’ mode, you adjust settings on your desktop screen inside the visual editor and watch it update live on the target test iPhone. It’s a very cool way to quickly adjust and position your objects and verify that they look right on the iPhone screen.

To develop Unity apps, you need the editing system ($199 for Indie developers earning $100K or less — with free 30-day eval, or $1499 for Pro) which lets you generate output for Mac, Windows, browser plugin, and OS X dashboard widget. To output to the iPhone you can got for the Basic iPhone license for $399 for Indie developers and requires showing the Unity splash screen, or $1499 for the Advanced license. Wii/WiiWare output is separate and carries a hefty license fee ($15K-$30K per title).

The Advanced edition also gets you .NET sockets. This means that you can write your own back-end server and aren’t locked into theirs, but you don’t necessarily get Bonjour/WiFi support. You can also stream assets on-demand (which requires an asset-server client license for $499) but I can’t imagine anyone wanting to stream assets unless the user was on WiFi.

Risks

There are inherent risks with using a third-party middleware. Will the platform continue to be supported? Are they actively fixing bugs? What happens if they go out of business and you want to continue developing your app? If these are concerns, then you may want to consider Torque’s Pro versions since they come with source code.

On a resource-restricted platform like an iPhone there’s also the matter of having a whole extra layer of runtime between your app and the OS. If your app is going to be pretty media-heavy you may want to roll your own and keep tight control over memory use.

Don’t be scared by these caveats. For certain classes of games these engines will amply make up for the risks by letting you concentrate on content instead of engine technology and getting your app out that much sooner. If used properly, they can also act as ‘force multipliers’ if you are an individual developer or a 2-3-person team. With these tools, you can rapidly create cool apps that would otherwise require a small army of coders and designers.

Which one?

Which one you choose will depend primarily on what features you need, so the first thing I suggest is to download and try out each package (here are direct download pages for ShiVa, Torque, and Unity). All three have free or eval versions and offer Indie pricing for small developers. If your app turns into a big hit and brings in enough revenue, it’s easy to justify the cost of the Pro or Advanced licenses.

If you intend to eventually move to the XBox then Torque is the only way to go. If Wii is where you might be heading, then it’s Torque vs. Unity. All three platforms support standalone desktop apps. I’m not sure with the prevalence of Flash in the browser if anyone’s willing to download and install a browser plugin just to run an application, so I’ll call web-based delivery a wash.

If licensing fees are a concern, then you may want to go with ShiVa. If you only need 2D support, then Torque may work for you (although their iPhone per-app licensing fee is a little too strange for my taste). Mac-only developers will want to look at Unity or Torque Engine Advanced . All others require Windows (but may work under Parallels or VMWare).

iPhone-only features

At this point, nobody seems to support peer-to-peer Bonjour-based networking on the iPhone. Quite a lot of games support that feature. Unlike a Nintendo-DS which allows two players to form an ad-hoc network just by sitting near each other, this only works when all the players are on the same WiFi subnet. It works pretty well when players are in the same room or dorm floor and doesn’t require going out to a central server. It’s especially handy in places where data access is metered and hitting a central server through the cell network can get expensive. Hopefully Bonjour support is something that will be supported soon.

All three engines appear to have decent support for the accelerometer but no mention yet of other iPhone-only features like multi-touch, GPS, or camera. One other thing to keep in mind is that all the license terms and prices listed apply to games only. If you want to develop a social networking or business app you may have to negotiate a separate license.

Bottom line

Which one will I use myself? My development environment is currently 100% Mac based and I have a lot of 3D, graphics, and sound production tools there so that will probably influence which way I go. That makes Unity a strong contender for me. However, I’ll defer final judgment until I’ve had a chance to seriously beat up each platform.

Remember that regardless of platform, you’ll need to sign-up separately for Apple’s iPhone development program (a $99 cost for individuals) to get a distribution certificate. You’ll also need to do the actual legwork of submitting the application to the app-store. And once the app is out, there’s the matter of marketing and promoting so your app stands out against all those other ones out there.

Ah yes, marketing. Let’s leave that for a future post…

Update: For those interested in going the open-source route, SIO2 and Oolong Game Engine are two 3D gaming engines for the iPhone/iPod Touch. (Many thanks to Justin Hall for the tip.)

Both look plenty capable for iPhone-only game development (NOTE: there’s no desktop or console output support). Based on a casual first-pass, it looks like SIO2’s tight integration with Blender 3D editor and support for Lua scripting makes it easier for those who want to focus on content-creation instead of low-level coding. Oolong, however, is targeted more at C++/Objective-C coders. According to the Oolong source code site it is the technology underlying Torque Game Builder for iPhone (see above).

The user interface of the iPhone is based on a series of nested UIView objects, arranged in a view-subview/parent-child relationship. When building a complex application with a lot of views, sometimes it’s handy to be able to see exactly what that relationship is.

But if you try to print out the value of a UIView in the debugger (or through an NSLog function) you’ll be sorely disappointed. In this example we have a variable called front that is derived from a UIView. Setting a breakpoint in the XCode debugger, I type in a po (print object) command to show what that variable contains:

(gdb) po _front
<BCCardSideView: 0x106b020>


What you see is that the variable is of type BCCardSideView and its hex address. Not very helpful.

One solution is to take advantage of the Objective-C dynamic runtime and override UIView’s default describe method. This is the method that is called every time you try to display the value of an object. Here we have just such an override that recursively walks the view tree and dumps out the values. The code is contained in a file called UIViewExtras.m. All you have to do to enable it is include the file in your XCode project. There are no explicit methods to call.

Here’s the same output after UIViewExtras.m is included in the project (the indentation is a little messed up because of the column width of this blog. In the debug window, it should look fine):

(gdb) po _front
+ BCCardSideView retain:3 - tag:0 - bgcolor:(r:0 g:0 b:0 a:1.00)
bounds: x:0 y:0 w:130 h:80 - frame: x:5 y:5 w:130 h:80 - center: x:70, y:45
++ BCCardBackgroundView retain:4 - tag:0 - bgcolor:(r:255 g:255 b:0 a:1.00)
bounds: x:0 y:0 w:130 h:80 - frame: x:5 y:5 w:130 h:80 - center: x:70, y:45
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:0 g:255 b:255 a:1.00)
bounds: x:0 y:0 w:100 h:20 - frame: x:0 y:0 w:100 h:20 - center: x:50, y:10
text (len:4 - color:r:0 g:255 b:0 a:0.00): 'name'
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:255 g:255 b:0 a:0.00)
bounds: x:0 y:0 w:100 h:20 - frame: x:0 y:20 w:100 h:20 - center: x:50, y:30
text (len:5 - color:r:0 g:255 b:0 a:0.00): 'title'
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:0 g:0 b:255 a:1.00)
bounds: x:0 y:0 w:100 h:20 - frame: x:0 y:40 w:100 h:20 - center: x:50, y:50
text (len:5 - color:r:0 g:255 b:0 a:0.00): 'email'
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:255 g:0 b:0 a:1.00)
bounds: x:0 y:0 w:60 h:20 - frame: x:0 y:60 w:60 h:20 - center: x:30, y:70
text (len:7 - color:r:0 g:255 b:0 a:0.00): 'phone.1'


For each view object you see:

• The retain count.
• The tag value (if specified).
• The background color value in RGBA. RGB values are scaled up to 0..255 and alpha is shown as a floating point value between 0 and 1.
• View bounds rectangle (x, y, width, height)
• View frame rectangle (x, y, width, height)
• View center (x, y)

If view is a UILabel or UITextField, you also get:

• - Length of text
• - RGB value for text itself (vs. the background)
• - Actual value of the ‘text’ inside the field.

Subviews are indented by multiple “+” (plus) signs. So the top-level has one ‘+’ all its subviews have two ‘+’ signs, *their* subviews will each have three ‘+’ signs etc.

I personally find this handy in debugging views — especially those created dynamically. I hope you do too.

[ Download: UIViewExtras.zip ] (Update: Link updated.)

Update 2 [06-Oct-09] : Modified method of obtaining class name so it should work with newer SDK releases.