1. Facebook passes you the session key you want. Don’t try and use your typical, cookie or URL-based session – it won’t work. Instead (in php, for example,) start your session with:
   1. $facebook = new Facebook($api_key, $secret);
      $session_key = md5($facebook->api_client->session_key);
      session_id($session_key);
      session_start();
2. If your application is anything like mine, you’re going to have the same FBML content used all over the place – on several people’s profiles, and in the main application itself. Rather than update the contents of thousands of profiles, Facebook provides a handy fb:ref cacheing architecture. USE IT.
3. If you’re using fb:ref (which you SHOULD be), you probably want to be using the “push” method, using named handles. Add the php curl_multi hack for performance, and you’ll be off and running.
4. To take advantage of this (updating huge swaths of your application without any user interaction), you’ll probably want to run a cron job, using an infinite session key. Get yourself one.
5. The name of your application makes a huge difference when it comes to random users adding your application from the application directory. BUT, facebook doesn’t seem to mind if you change the name periodically, even after your application has been listed and you have piles of users. Go ahead and play around, and keep checking your facebook stats to see what works best.
6. Obviously, you’ll want to run a test version. The best way is to have a second application, in developer mode, and mapped to a special port that forwards traffic to your local development machine through an ssh tunnel. Read my previous blog post on how to set this up.
7. In order to not go INSANE managing your test version, make sure you’ve abstracted out the full facebook app path, and keep it in some local config file. (Yes, I realize this should be obvious to any experienced developer). While you’re at it, you might want to check for the best possible facebook url you can get – these things are the new domain names.
8. Facebook templatized actions – you need to use these. Basically, it’s the only way to turn events within your application, into first-class citizens of the facebook news streams. They’re worthy of a full blog post on their own, as I found a whole series of gotchas when implementing them. For starters, remember to use the right fb:pronoun-s.
9. Default FBML - it’s way more important than it seems, since you can’t be sure where the user’s workflow will take them when playing with/installing your application. You’ll probably want to prototype this extensively, and then copy it from your editor into the tiny little form facebook provides.
10. It’s mentioned in all the facebook best practices, but it bears repeating – make sure you’re letting facebook users try out the functionality of your application before requiring them to install it. Not only will it lead to fewer unhappy users, but it maintains the reputation of facebook application developers as a group.
11. Post-remove – You’ll probably find, as most facebook apps do, that you have a HUGE amount of churn in your user base. If you don’t remember to remove local user data from your application database when a facebook user removes your application, it will quickly become cluttered with cruft. (A quick FQL query for whether or not each user has your application installed can be run as a one-time cleanup if necessary.)

I hope you find these helpful – and if you’ve got further tips of your own, let me know!

UPDATE (Sept. 6th): My friend Nick wrote a book that makes this whole process easier:

By happy coincidence, I spent the day hacking away on FB apps with my friend Ben Savage, who showed me how *he* does it – he simply port forwards port 4100 on his local router into his laptop, and then sets the facebook application to use his current outside IP:4100 as the app url.

I didn’t like this for a few reasons – first, it requires admin access to the router, a no-go from Starbucks. Second, I don’t like having to change my facebook application settings every time I change offices. So I decided to try using an ssh tunnel.

After mucking about a bit, I got it working! Here’s what I had to do (and yes, it’s pretty ugly and you probably want to do this on a non-critical junk proxy box you’ve got somewhere):

Changes to /etc/ssh/sshd_config

1. You have to make the ssh connection as root in order to bind to a privileged port (it’s probably trivial to use a non-privileged port for this, but I couldn’t be bothered). So you need to enabled root logins, by adding/changing
PermitRootLogin yes
2. In order to bind to a network address other than localhost on the remote server, you need
GatewayPorts yes

Then you simply run this from console on your local machine:

ssh root@mytunnelbox.com -p22 -N -R *:8090/localhost/80

This will forward port 8090 on your remote server to port 80 on your local workstation, via ssh tunnel. I don’t usually bother to fork into the background, because it’s nice to be able to ctrl-c to finish up.

Now get into your facebook developer application (you probably want to create a test application for this), and change the Callback URL to mytunnelbox.com:8090/. (You’ll only have to do this the first time).

Voila! Local development facebook application work – from Starbucks or anywhere else!