Talk Funnel

It’s time, once again, for the annual love-fest that is WWDC and that starts next week. I’ve been to each one since the iPhone launch (I know, that makes me a relative newbie) but having spent a good chunk of the past two decades living in San Francisco, I figured I’d combine tech-tips for first-time attendees with social things to do for out-of-towners.

Tech Tips

• You can register and get your badge on Sunday, the day before WWDC starts. That saves you a bit of time doing it on Monday when everyone stands in line to get into the keynote speech. If you do go in on Sunday then you may want to pop into sfMacIndie at Jillian’s in the Metreon at 6pm. It’s across the street from Moscone West. Grab a drink and chat up fellow developers. You may want to pace yourself. The next day is the big event and you want to be able to get there early — at least by 8am if not sooner. They don’t start letting you in until 9:30am so wear comfy shoes. Make sure to say hi to fellow line-standers as you hop from foot-to-foot trying to stay warm.
• This is San Francisco. In June. This means chances of early morning sun are slim to none. Standing in line for the keynote means no moving for hours in the cold, blowing fog. Unless you’re seriously thick-skinned (like the poor, freezing iPorn girls of last year) bring layers and be prepared to discard them as the day wears on and temperatures rise.
• The on-screen keyboard on the iPad is nice, but don’t forget your laptop. You will want to take notes. Lots of notes. And fast. As Marco Arment says WWDC is one giant info-dump and there is no way to absorb everything. You’ll need a real keyboard to keep up. I like to create separate folders for each session and save note files in TextMate. Under each folder you can also save sample code for the sessions. Then I throw the whole top-level folder into TextMate as a project so I can quickly search and find what I’m looking for. I suggest you try to capture as much as you can while there and take time later to go over things. They were pretty quick about posting up the videos of each session last year, but there’s no replacement for one’s own notes.
• Head down to the lunch area on the ground floor around noon. The food’s nothing to write home about (yeah, I’m being polite) but it’s a good chance to meet people and find out common interests. Most of the other times you’ll be standing in line or in-session. This is your chance to have a decent conversation and who knows, learn a thing or two from fellow developers. I’ve always enjoyed these random encounters.
• If you have questions or want to get feedback from Apple engineers and designers, sign up for the labs and do it early. Spaces fill up fast, especially for the UI Design reviews. Drift down to the cafeteria area on the ground floor and find out what the sign-up protocol is. On the rare occasion there isn’t an interesting session, hover around the lab areas. You’ll pick up great info just by listening to Apple folks explain how things work.
• Try to bring a Verizon or Sprint MiFi. The Apple-supplied WiFi network is OK, but most of the time it gets overloaded. Forget AT&T’s 3G network. It’s a joke. With most people carrying a MacBook, an iPhone, and an iPad, your best bet is to bring your own network. The downside to this is you probably won’t be able to access the WWDC attendee-only content accessible to those on the network there. But once you’ve snagged all the goodies you can switch back to your own network and zip along. [Update: OK, maybe not such a good idea if everyone turns them on at once.]
• If you bring your own network, make sure you set a secure password for access to the wireless hub. And for crying out loud, don’t make it the 40-bit WEP. Go for the WPA2. Way too many people running Wireshark or Kismet out there. Also, while you’re at home set up all your network devices to log in, then set the hub to not broadcast its SSID. That way all those other people around you won’t have to scroll through a gajillion wireless hotspot names.
• Bring a comfortable backpack. The one they’ve been handing out to WWDC attendees the last few years is pretty minimalistic. If you need space for all your gear (and an extra sweater) then bring your own. Don’t worry about food, unless you need to snack often. They provide bagels and cookies and whatnot to keep you fueled up.
• Sync up your dev iPhone or iPad at home and back everything up. There’s a good chance there will be a new SDK drop there with a bunch of new goodies. Recommend you not try to download over the WiFi. Walk over to one of the round tables outside the session rooms and plug into the Ethernet firehose. Much, much faster.
• Please, oh please remember to turn down the volume on your phone/iPad/Mac during sessions. Yes, you know you’re on Twitter and now we do too. You can thank chirping bird man for that.
• If your backside is sore from all the sitting down or you feel like taking a quick nap, there are bean-bags on the top floor. First come-first serve.
• If you’re looking for a job or have a job to post there are white-boards in the bean-bag lounge area.
• Stash a power-strip in your pack — it’s a good way to make friends.  Among tech conferences WWDC is one of the better ones for providing power to attendees. Even so, they sometimes run out of plugs. I’m partial to the Monster Outlets to Go units. They’re small and you can charge up most of your devices in one sitting. Some models even come with built-in USB charging ports. While you’re at it remember to bring separate power-to-USB adapters for your iPhone and iPad. The iPhone is happy with the small 5W units but the iPad needs the beefier 10W adapters. If space is a premium you may want to grab a couple of retractable USB cables too.
• If you’re missing anything or forget to bring any hardware, your two nearby geek supply outlets are the Apple Store on Stockton Street and Central Computer on Folsom at 4th.

OK, so much for the conference itself. What about the social life?

Organized Events

Here’s a good reference for organized after-session gatherings: http://wwdcparties.com. On Tuesday between 7:30 and 10:30 pm, however, a lot of people will likely head over to the Apple Design Awards ceremony. A large number will stick around for the Stump the Chumps Experts session. On Thursday night Apple throws a bash in Yerba Buena Gardens. You’ll need your WWDC badge to get in. If you’re of drinking age you’ll need to get a wrist-band at Moscone before heading over. Pace yourself on the booze if you plan on hitting any other places afterward. You get all the food and beer you can consume plus a (surprise) live musical act. And there’s still Friday’s sessions left.

Quick Eats

If you get tired of eating pre-packaged sandwiches and are hankering for something slightly different, here are a few places within easy walking distance of Moscone. However, no guarantee they’ll get you in and out in time for the afternoon sessions:

• Food court at Metreon - Walk across the street, grab yourself something and go sit outside in Yerba Buena Gardens to decompress. Absolutely glorious if it’s sunny.
• Taqueria Cancun - Bit of a hike up on 6th and Market, but decent enough Mexican fare.
• Out the Door – (sorry, Flash site) is by the same people who run the outstanding Slanted Door in the Ferry Building. This one’s in Westfield (Nordstrom) shopping center on Market and 5th.
• Specialty’s – Great sandwiches. Best part is they have an iPhone-friendly ordering service. Closest one is on New Montgomery between Mission and Market.
• The Sentinel – I haven’t eaten there yet, but people keep recommending it and it’s top of my list for lunch places to try. Fancy-looking sandwiches.

Coffee

The swill they serve at WWDC may be fine for getting you over your previous night’s hangover, but you owe it to yourself to get some decent coffee while in town. Good places within walking distance:

• Blue Bottle - Just go. Get the Latte if you’re in a hurry or the drip coffee if you have time. Don’t worry, it’ll make sense once you get there.
• Peet’s - Closest one is on Mission between 3rd and New Montgomery. Strong coffee. Puts hair on your chest, whether you want it or not.
• Chatz - Bit of a hike on 2nd Street between Howard and Folsom, but good place to go if your feet need some stretching.

Local Watering Holes

For some reason after a day of technical brain-melding a lot of people are extra-primed to kick back and partake of adult beverages. Go figure. If that’s what you’re looking to do, here’s a number of local hangouts where you are sure to bump into fellow WWDC attendees:

• Jillian’s – It’s across the street, doubles as a sports bar, has a large selection of beers on tap, and has pool tables in the back.
• Thirsty Bear Brewing – Upscale brewpub. Decent beers and Tapas-style dishes, only a block away.
• Chieftain’s – Grungy Irish pub. First stop for a lot of die-hard old-timers before they inexplicably head all the way out to…
• Tommy’s Mexican Restaurant – A favorite of Apple folks, but it’s all the way out in outer Richmond. With places like Tres Agaves or dive bars like City Bar in the Mission you’d think someone would try to find something more accessible. It’s far away, in the fog zone, and the place is usually mobbed but if you do decide to head out to Tommy’s try to snag a ride with someone else–preferably a teetotaler. There’s a chance you’ll end up slamming tequila shots and trust me, you won’t want to be driving, flagging down a rare cab, or being at the mercy of Muni late at night.
• Harlot – Decent, but small. Odds are there will be a line to get in.
• XYZ bar at W Hotel – Upscale drink spot. Excellent place to hang out if you’re on a corporate expense account or your app just cracked the Top 10.

A little further out — but still worth it

Want to pretend you’re a local? Some are a bit of a walk, but if you get in with a group of fellow developers and want to get out of the Folsom/Howard zone, here are a few places to try (in no particular order):

• Johnny Foley’s - Irish Pub within walking distance. It can get a bit touristy, but there’s nightly live music and (natch) Guinness on tap.
• Zeitgeist - Sort of a cross-road of cultures and styles. No other way to describe it.
• Orbit Room Cafe - Best damn Bloody Marys in town.
• Hotel Utah - Grungy local spot, sometimes with good music.
• Bottom of the Hill - Great place for local live indy bands. Out in Potrero Hill (accessible via the Muni T-line) but the music’s usually worth the trip.
• AsiaSF - The waitresses double as transgender stage performers — and they’re awesome.
• 21st Amendment Brewery - Big with the local tech types floating around 2nd street. Decent brews.

Obviously I’m leaving a lot out, but this should give you a decent starting point. Feel free to post any corrections or favorites in the comments. Hope to see you all at WWDC. If anyone wants to look me up and say hi, I’m @raminf on Twitter.

Update: Added a few more places — for those in a hurry to get back to hacking and getting their mind blown.

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.

Update: AutoPark won Best of Show at Macworld 2010 and got 4.5 out of 5 mice.

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:

If you’re developing an iPhone application that uses WiFi networking or the new Gaming Kit (Bluetooth) at some point you’ll want to test the code on two devices side-by-side. At this point you will realize that:

a) You can only run one instance of XCode on your machine at a time.

b) Debugging one device at a time is a royal PITA.

c) Your only option is to beg, borrow, or steal another Mac then install all of XCode and your code onto it just so you can do some debugging.

I’m here to tell you there’s a better way.

The solution is to use VMWare Fusion with Leopard or Snow Leopard server as a “guest OS.” (In VMWare-speak your regular machine is a host OS while each virtual OS instance running on it is a guest OS.)

The reason this works is because the latest version of VMWare allows you to run OS X Server as a guest OS on top of another OS X host OS. VMWare also allows you to assign specific USB devices to each VM instance so you can tell it that one iPhone/Touch belongs to the guest and the other to the host OS. Now I’ve only tried this with Snow Leopard Server so I’ll stick with that but VMWare says it can also install Leopard Server but I have’t tried that. Since Snow Leopard is still under NDA I’m not going to go into any specifics of the OS itself. Instead, I’ll show you how to set up VMWare so it can pull this off.

To start you’ll want the latest VMWare version (2.0.4 2.0.5 as of this writing). Earlier versions may not support OS X as a guest OS. To get access to the Snow Leopard releases you’ll need to be part of the Apple Mac Developer program. You’ll want the Server release. During WWDC 2009 some people were reporting having trouble installing Snow Leopard under VMWare from a disk image file so you might have to sacrifice a blank DVD and burn it to disc before installing it.

With the disc all you have to do is pop it in and it does the right thing. Or you can walk through and manually choose which versions you want to load.

Technically VMWare is only supposed to run Leopard/Snow Leopard Server which installs a lot of extra background services, etc. and needs a pretty hefty chunk of memory. If you Google around there are ways to patch the VMWare settings files to let it install Client. Far be it from me to suggest you do this, since it’s not certified and is not recommended for production use. All I’m saying is it might be less resource intensive and prevent your MacBook Pro from catching fire after the fans run on full-bore trying to cool down 100% loaded dual-core CPUs. But then again, YMMV.

So once you have VMWare and Leopard/Snow Leopard installed, you’ll want to install XCode (which comes on the OS install disk under “Extras,” or it can be downloaded separately from the Developer Connection website). Once that’s done you’ll also need the iPhone SDK. If you’re a member of the iPhone Developer Program (and really, who isn’t nowadays?) you’ll want to download and install the latest SDK (note that there are different downloads for Leopard and Snow Leopard).

Inside VMWare you’ll want to set up directory sharing. I won’t walk you through that here but if you have trouble getting the VMWare “folder-mapping” feature to work (like I did) one workaround is to turn on file-sharing in the host OS and mount the networked filesystem from the guest OS. If you do this, make sure you restrict access to only your own account on the shared volumes and turn it off for everyone else, otherwise all your pals at the coffee shop sitting on the WiFi and running Bonjour will have access to your source files.

Next you’ll want to end up with two separate projects, one for the host and the other for the guest OS. The reason for this is because each instance of XCode makes changes to the project settings each time you do a build. If you share the projects and load them from two XCode instances, you’ll end up with an endless litany of XCode warnings asking you if it should reload the project from disk. Save yourself a lot of headache. Just create separate projects but keep all your source and media files in the same shared folder. This way if you do actually make changes to the source code during debugging you only have to do it once from either side, otherwise it’s a nightmare keeping track of deltas.

(Handy tip: if you have dual monitors, install VMWare tools and put the guest OS on the second monitor then have it go full-screen. It’s like having two actual systems in one.)

So now comes the fun part: plugging in the actual devices. Make sure you’re not running XCode or any other app that accesses the USB devices behind the scenes. If you have iTunes set up to auto-run and sync when a device is plugged in you either haven’t done much real iPhone device debugging or you have a much higher tolerance for Annoyingly Intrusive Software. I turn off all auto-sync, auto-run, auto-whatever features that iTunes throws in to make itself the consumer-friendly app that it is. But that convenience gets in the way of debugging, so do yourself a favor and turn it all off. Manual sync mode is your friend.

iTunes also installs an iTunesHelper app that runs in the background. I personally take that out too by going into System Preferences > Accounts
then clicking on the “Login Items” tab button, finding “iTunesHelper” and hitting the ‘-’ button (or delete) to take it out. The point is, if iTunes snags your USB port before VMWare gets to it you won’t be able to switch it over.

So now we have the two devices plugged in. Do NOT give in to temptation and start XCode just yet. In VMWare bring up the “Virtual Machine Library” which lists all your VM instances (if it’s not already showing, go under Windows > Virtual Machine Library). Select your Leopard/Snow Leopard instance then push the “Settings” button.

Now go into the USB devices section. Note that you can only make changes to the guest OS once it’s powered up and running. So if the guest OS isn’t already running, boot it up. You’ll be faced with a list of all the USB devices on your host machine, something like this:

Unfortunately VMWare doesn’t actually show the device names as assigned through iTunes so there’s no way to tell which device is which. If you have two iPhones plugged in they both show up as Apple iPhone. You can always test an iPhone against a 2G touch (the Touch shows up as Apple iPod). Then again, if both devices are running the same code it may not really matter.

Turn on the checkbox next to the device you want assigned to the guest OS. If it doesn’t stick then it’s likely you’ve got some other app locking up your USB ports. Go back and re-check (might have to do a clean reboot). I should note that this was the most frustrating part of the whole exercise. The trick that made it work for me was to make sure XCode is not running until AFTER you’ve done your USB port assignments.

Once it’s checked, *now* start up XCode on both sides. The host OS should be seeing one device and the guest OS the other. Verify by loading up the XCode Organizer and seeing that each device shows up with a little green dot next it. If you haven’t done it yet, you’ll want to tell the XCode Organizer that the devices are to be used for Development.

Getting excited? Almost there. Now choose iPhone Device from your XCode Active SDK pop-up.

Ready to hit Build and Run?

Not so fast.

Your iPhone development certificate is only installed on your host OS. The guest OS is a whole other machine and it needs to be set up as if it was a brand new machine. Fortunately, it’s fairly straightforward to get the keys moved over.

Launch the Keychain Access application (in Applications > Utilities) on your host OS. If you followed the iPhone SDK instructions and created a provisioning profile for your application on the iTunes Connect site, you should have a private key certificate installed in your keychain. If you’re like me and have done this a number of times, you’ll have lots of similar looking keys floating around. The trick is to look for the private key with your name and a drop-down disclosure arrow next to it. Open those up and verify that they say iPhone Developer and/or iPhone Distribution next to them. If you’ve followed Apple guidelines you should have one for development and another for app-store or ad-hoc distribution.

While you’re there, it’s a good time to make sure the expiration date is in the future. I got bit once and boy, was it a pain to diagnose. Stuff that was working one minute magically stopped the next. So stay on top of your certificate expiration dates. If the date is pretty close or already gone by go back to iPhone developer site and follow instructions to regenerate new keys, then install them and come back when you’re done.

Command-select all the private certificates you want moved and export the lot of them (File menu > Export Items…) Make sure they go out as .p12 (Personal Information Exchange) files. You will be prompted for passwords. Pick something pithy but memorable and save the exported file to a shared folder you can get at from the guest OS. While you’re at it, you may also want to move over your app’s provisioning profiles just in case you need it later.

Back in the guest OS, double-click the exported certificate file, enter the password, and install it in your keychain. You’ll probably have to restart XCode so it picks up the changes. To verify that it worked, bring up the XCode project in the guest OS, do a Get Info on the target and make sure the Code Signing Identity is selected and is the same as the private key you just installed.

So NOW you’re ready to go. Select iPhone Device from the Active SDK on both sides, hit Build and Run, go grab a cup of coffee or an adult beverage, and wait until both instances come up side-by-side.

So, yay!

That wasn’t too bad, was it?

A few final thoughts: I ended up running Snow Leopard as both host and guest OS since I wanted to run XCode 3.2 with the latest goodies on both sides. You’ll definitely want separate project files if you want to run Leopard in host and Snow Leopard in guest OS. At this point it’s not clear if app-store submissions can be built using unreleased versions of XCode. So you might want to check on the developer forums before doing the crazy thing I did and upgrading everything everywhere to the new shiny version.

Also, there’s no reason this shouldn’t work for three or more devices (for group peer-to-peer or mass WiFi testing) but you’ll need a beefy Mac with a lot of CPU and memory. You’ll also be needing a USB hub (I ended up with this Belkin Ultra Mini model based on advice from @schwa on Twitter) if you run short on USB ports. All it takes is another VMWare instance and assigning the right device to the right OS instance. Lather, rinse, repeat.

Happy debugging!

Update: Make sure you read VMWare update release notes. In the latest release there are two known issues that directly impact this way of using VMWare:

• When being installed on a Mac running Mac OS X 10.6 (Snow Leopard), VMware Fusion does not install MacFUSE

  MacFUSE might cause the installer to fail or become non responsive, so the VMware Fusion installation process does not install it by default on a Mac with OS X 10.6.

• Selecting the Sleep option on a Mac OS X Server guest operating system causes it to stop responding
  The default setting for Mac OS X Server is for it to never sleep. However, if you change the setting or use Apple > Sleep, the virtual machine might stop responding.
  Workaround: Shut down the virtual machine and restart it, and make sure that in the Energy Saver window of Apple > System Preferences, the Put the computer to sleep when it is inactive for: slider is set to Never. Do not use Apple > Sleep.

You’ll definitely want to turn off Sleep mode as soon as you’ve installed the guest OS and before you walk away from the system for an extended length of time otherwise you’ll have to hard-reboot the VM instance. I even turn off the screen-saver. If the system is idle for any length of time the host OS should be the one doing the sleeping and screen blanking.

The first issue is also easily solved. You can manually download and install MacFUSE. It allows you to use not only third-party file systems on top of MacOS, but file systems on local disk, across the network etc. There are some issues with folder sharing across guest/host applications that clean install of MacFUSE might clear up.

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:

Fans of TV’s Seinfeld in the 1990′s will remember an episode where Elaine ponders whether someone is sponge-worthy:

JERRY: I thought you said it was imminent.

ELAINE: Yeah, it was, but then I just couldn’t decide if he was really sponge-worthy.

JERRY: Sponge-worthy?

ELAINE: Yeah, Jerry, I have to conserve these sponges.

JERRY: But you like this guy, isn’t that what the sponges are for?

ELAINE: Yes, yes – before they went off the market. I mean, now I’ve got to re-evaluate my whole screening process. I can’t afford to waste any of ‘em.

In this case, Elaine is in possession of a finite amount of discontinued Today contraceptive sponges and she wants to save her stash for someone really worth it.

There is a large number of blogs, twitterers, and web-sites out there vying for our attention and we have limited time in a given day to spend with them. So a few end up moving up to the top — the people, places, and things with which we have a steady, recurring relationship — in essence making them sponge-worthy.

If you’re a writer, publisher, or content-producer forget unique visitors, friends, or followers. Sponge-worthiness is the status to which you should aspire.

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.

Time Machine is great, especially if hooked up to a network storage device like Drobo so you can just have it run in the background. In my case the Drobo is connected to a Mac Mini acting as a network file server (yes, I know it’s not officially supported, but it works fine under Leopard).

However, lately the backups have been taking a lot of system and network resources, rendering the machine (in this case my development laptop) practically unusable while they run. But since Time Machine runs in the background, it’s OK to lower the backup daemon’s priority and let it run a little slower.

On Mac OS X Leopard, this is the command that does the trick. From the terminal:

sudo renice +5 -p `ps -axc | grep backupd | awk '{ print \$1 }'`

Here’s what’s going on:

• sudo – This runs the command as the root. You will need to enter the administrator password.
• renice – This is the standard Unix command for changing the priority of a running application.
• +5: Process priorities under BSD Unix-based systems typicall run from -20 to +20, with +20 being lowest (i.e. running slowest) to -20 being maximum (yes, I know it’s unintuitively backward, but there’s an old historical reason for it). What we’re doing is bumping Time Machine daemon’s nice priority up by 5 (or any number you want) to let it run slower.
• -p pid – This is the process id of the process you want to adjust. Since this changes every time Time Machine runs, we have to have a way to find it dynamically at runtime — which is where the rest of the line enclosed in ` back-quotes come in. On most Unix shells, items enclosed in back-quotes get executed and the result returned back to the command line. So we’re going to look up the process ID of the current Time Machine server process and return it here.
• ps -axc – The ps command returns a long list of all running processes on the system. We need to filter out the one we want, which we do by piping the output into a grep filter next…
• grep backupd – We’re taking all the output from the ps command and only keeping those lines that contain the string backupd — which happens to be the name of the Time Machine server. So we end up with a single line of ps output that looks something like this:
  

  19041 ?? 1:07.48 backupd

  But what we need is the process ID to pass back up to the renice command. In this case, it’s the first number on the line. We need a way to extract only that, which is where awk — the amazing text processing Swiss-Army knife — comes in…

• awk “{print \$1 }” – By default, awk splits its input into chunks based on whitespace. We’re simply asking that the first item be returned. Any time you do this, you should apologize to awk for so massively under-utilizing what it can do. It’s like driving your Formula-1 car down to the grocery store to buy milk. In this case all we’re doing is asking it to split up some text and return one item to us, something that awk can do practically in its sleep.

When you run this, the sudo part of the command will ask you for your admin password, then proceed to do its thing. Put it all together and you’ve got yourself a simple way to slow down Time Machine so it’s not such a CPU hog.

If you’re enterprising, you can put the whole thing into a shell function and run it over and over. The following code goes inside your .bash_profile file.


function tmslow {
    echo "Reducing Time Machine priority..."
    sudo renice +5 -p `ps -axc | grep backupd | awk '{ print \$1 }'`
}


Start a new terminal session (to make sure the shell function is loaded) then invoke tmslow and enter your admin password. It prints out a little message reminding you what it’s about to do.

Remember, the renice command doesn’t stick, so every time you reboot or a new Time Machine session starts, the process goes back to normal priority. There are ways to automate the priority lowering scheme or even make it permanent, but I don’t recommend doing that. Sometimes, you may want backups to run full-speed. Unix makes it trivial to do what you want by stringing together some built-in commands.