Instead of explaining the game to you, check out my demo with TUAW:

Summary

For those who didn’t catch the beginning, back in March I came back from a SxSW excursion to the unsettling news of what was going on in Japan. I read that many indie developers were donating their proceeds for a day, or sometimes a week, to various organizations to help with the relief. I wanted to do something similar, but was in the fortunate position to go big. See, just a few months ago I decided to take a break from the indie life and get a real job (at a small tech startup, but real nonetheless). Each month my deposit from Apple is just a nice little bonus, and was a luxury I could do without.

I decided to donate all of Opetopic’s app proceeds for a full four weeks, and split the donations among three different organizations: Doctors Without Borders (50%), UNICEF (25%) and the International Red Cross (25%). Further, I made sure that the donations were never earmarked for only the Japan relief, which forces the funds to be used in the country of Japan, even though the operations may extend to other countries. And as one final move to bolster the effort, I agreed to match all donations out of my own pocket.

Renewed Interest

Four weeks is a long time to keep my interest concentrated on one thing. A really long time for me. But each day brought more news of the developments in Japan and surrounding areas. Weeks after the events we still get new videos showing the destruction of the tsunami surge, and we still do not know the long term effects of the Fukushima fallout. It kind of feels like I should just keep this going…

The Numbers

I didn’t have time to post a weekly summary last week, so this time I have two weeks worth of numbers:

Unfortunately these numbers were a little lower than our first two weeks, but $850 is nothing to sneeze at. With my matching the following donations were made:

• Doctors Without Borders (50%): $850
• UNICEF (25%): $425
• International Red Cross (25%): $425

And combining the previous two weeks of donations (week 1, week 2) we have the following breakdown of donations:

• Doctors Without Borders (50%): $1888
• UNICEF (25%): $944
• International Red Cross (25%): $944
• Total: $3776

Thanks to everyone who helped and retweeted my obsessive self-retweets.

For the Indie Devs

As a side note to the indie devs reading, this series of posts could technically serve as a “numbers post” that is so popular in the indie community. Honestly I am not a big fan of those types of discussions, but for a little more context you should know that the distribution of sales across all of my apps falls somewhere around 2:1 for IsoCards:IsoWords (all languages of IsoWords).

So, we made $490, and with my matching we will be donating $980! The breakdown for my chosen organizations:

• Doctors Without Borders (50%): $490
• UNICEF (25%): $245
• International Red Cross (25%): $245

In total we have donated $2076!

We have two more weeks of this, and I will be pushing a lot harder (prepare to be annoyed if you follow me on Twitter). Also, tell anyone and everyone about this — they get a kickass game for two bucks, and some awesome organizations get a donation.

• IsoWords
• IsoWords Español
• IsoWords Français
• IsoWords Deutsche
• IsoCards

Note that this is after Apple’s 30% cut, so all-in-all we netted $548! And as I promised in my previous post, I have matched this to make a total donation of $1096. The final split among my 3 chosen organizations is (along with links to the donation confirmations):

• Doctors Without Borders (50%) : $548
• UNICEF (25%) : $274
• International Red Cross (25%) : $274

I don’t have a confirmation for IRC yet because my bank actually locked my account for suspected fraudulent activity! I’m sure it will be sorted out soon enough though.

Thanks again to everyone who supported this, and spread the word… we have 3 more weeks!

I just got back from a week and a half long trip to Austin for the SxSW Interactive+Music festivals. I had a mind blowing good time, but could really feel the bubble surrounding me when it came to news about the tsunami in Japan. It’s understandable, we have been working ourselves to the point of breakdown leading up to this festival and we were all there to do something great.

Now that I am back in New York I have caught up on the news and the gravity of the situation set in. I’ve already made my donations to a few organizations, as you probably have too. Remember, donate to organizations, not just the disaster relief which unfortunately earmarks money for only Japan instead of the entire relief operation, which will spread across many parts of the world for many years to come.

As I wrote in the postmortem of my indie game development career, the revenue of my apps have transitioned from being a very meager living (pre real job) to just a nice little bonus I get each month (post real job). Well, this bonus is a luxury I can certainly live without.

So, for the next month I will be donating all proceeds of my apps to relief related organizations. I will also match the proceeds from my own pocket to further bolster the effort. Since I only started a real job a few months ago I probably have to cap my matching to something, but let’s just see how things go.

I will also be splitting up the proceeds in 3 ways:

• 50% to Doctors Without Borders i.e. Médecins Sans Frontières i.e. MSF
• 25% to UNICEF
• 25% to the International Red Cross

This breakdown is influenced by the fact that Japan is a very wealthy country with a modern infrastructure. They will get back on their feet very soon. But MSF fills a need that even rich nations need when something this scale hits.

If you found this page from a friend, then hopefully they can vouch for me that I’m a good guy. I just want to help anyway I can. Each week I will post a summary of my sales and make a donation (even though Apple pays me roughly once a month).

So, if you would like to help Japan by just buying a couple of kick ass games, check mine out:

• IsoWords
• IsoWords Español
• IsoWords Français
• IsoWords Deutsche
• IsoCards

Every iPod owner knows that as soon as you unplug your headphones the music stops playing. It’s a nice little detail since it gives you quick access to stopping your music, but it is a pretty obvious thing for the iPod designers to do.

I was just jamming out to my buddy’s music wearing my headphones when I decided to switch over to streaming music to my speakers via AirPlay. When I unplugged my headphones the music continued playing.

An amazing attention to detail.

CCParticleSystem

All of the core logic and computation of the particle systems takes place in the class CCParticleSystem, which inherits from CCNode (as does anything that gets drawn in cocos). However, there is no drawing code in this class. Instead, all of the drawing is done in either CCParticleSystemQuad or CCParticleSystemPoint, both of which inherit from CCParticleSystem. The former class draws a single particle using two a quad (4 vertices, 2 triangles) and the latter uses GL_POINTS. It turns out that quads are faster on armv7 architecture and points are faster on armv6, so there is a nice little macro defined in CCParticleExamples.h that allows you to target both architectures at the same time:

#if defined(__ARM_NEON__) || defined(__MAC_OS_X_VERSION_MAX_ALLOWED) || defined(TARGET_IPHONE_SIMULATOR)
#define ARCH_OPTIMAL_PARTICLE_SYSTEM CCParticleSystemQuad
#elif __arm__
#define ARCH_OPTIMAL_PARTICLE_SYSTEM CCParticleSystemPoint
#else
#error(unknown architecture)
#endif

Rendering a particle system with CCParticleSystem is actually quite efficient because its internals are pretty much straight C. However, things can get very sluggish if you use many particle systems at once, and especially bad if you allocate them on the fly as you need them. Each particle system requires its own glDrawElements call, and each allocation results in a hefty malloc.

Reusable Particles

I will describe a few small changes I made to the particle system classes that allow one to allocate a large pool of particles just once and then reuse them for every particle effect in your game (even for effects with different parameters and textures). The idea for these changes came from a post on the cocos2d forum, and in particular the work of “zombie”.

I won’t go over every single change I made as you can refer to the code for that, but I will describe the overarching idea. In order to be backwards compatible with the current system I added a boolean ivar, reuseParticles_, that determines if want to use this feature or not. When this boolean is set to YES we prevent particles from “extinguishing” in the -update: method, and instead moves them offscreen and marks them as inactive. A method was then added, named -spawnParticles:(int)n, that simply looks for n particles that are inactive and reactivates them. The point at which new particles are created is governed by the centerOfGravity ivar, so you should set this point just before calling spawnParticles.

Now all particles are drawn with a single glDrawElements call. The -draw method is also updated so that no elements are drawn if all particles are marked as inactive. This could possibly be made more efficient by using glBufferSubData to buffer only the particles that active, but I haven’t taken the time to implement it.

All of the parameters that define the particle system (gravity, color, size, etc.) are stored in each particle rather than globally as an ivar. This means that in between spawnParticles calls you can change the parameters in order to manage many different kinds of systems at once. I even added a method named -setAttributesWithDictionary that sets the system’s parameters from an NSDictionary, which would most likely be loaded from a plist and/or created by Particle Designer.

The code

These changes to the particle system classes can be found in my fork of the cocos2d project on github. I haven’t pulled the latest from the main codebase in a while, but it doesn’t look like there have been too many major changes to the particle system classes. If you are working on your own custom copy if the cocos2d library you can simply download my repository and copy over the following files:

CCParticleSystem.h and .m
CCParticleSystemQuad.m
CCParticleSystemPoint.m

The changes in these files are 100% backwards compatible with the current particle system classes. I have set up another github repository that shows exactly how to use the added features.

Ok, not really corporate. Let me explain.

Lots of devs have written inspiring stories of quitting their day jobs to pursue the indie lifestyle. I love those stories. But, I kind of did it backwards. I got into this indie state of mind while in graduate school, so I’ve never really had a day job. I was a grad student at the math department of Stony Brook for 4 years. Working on a Ph.D. is very similar to being an independent developer. On the negative side is the frustration and self doubt knowing that your failures fall squarely on yourself. Fortunately, the positive side is a strong community of passionate people and the freedom to work on things that interest you.

It isn’t uncommon to take a break from research to explore different topics while in grad school. I spent most summers in small study groups with colleagues trying to understand areas of math and physics that were completely orthogonal to my own field. It is cathartic to work on something with no pressure tied to it, and most importantly for which you truly do not judge yourself and do not care if others judge you.

During one particularly dry period of research I decided to mess around with iPhone development. I’ve programmed for many years, so I was mostly interested in understanding the platform. A small device with GPS, accelerometer, touch screen and pressure sensitive microphone lends itself to lots of experimentation. This distraction decided to stick. The thought of working on my ideas, but this time actually making a living from it, really appealed to my academia pedigree. Eventually I decided to leave grad school and go into full time development.

Soon I realized that my indie undertaking had become exactly like my grad school undertaking. Days are filled with freedom and creativity, but also doubt and self loathing. To mix things up a little I took on some freelance iPhone work and found it to be incredibly lucrative… perhaps bubble lucrative. Mobile developers have a nice little window where the demand for developers (iPhone in particular) greatly surpasses the supply, and I took advantage of that. Shortly after my freelance work I came into contact with a small tech start up here in New York and began working full time.

It has been nice to work on products for which I only hold myself accountable up to the product itself and not its overall success. This is analogous to what I needed while in grad school, except now I’m making some money. I’ll be putting most of this money towards doing my own projects right; I will be hiring top notch artists and musicians from now on. I also now find myself more productive during the little bit of time I get to work on my own projects. My next game, Battle Nation, is even making a little progress recently.

So, while I am not advocating iDevs take up a corporate job in lieu of going indie, I am suggesting that you might want to scoop up some of this bubble money floating around. Then you can properly fund your next project.

I’ll end with an anecdote. The day I learned that I would finally have an iDevBlogADay spot, after months of waiting, was the exact day I started my real job, and now two weeks later, the day of my 2nd post, I got my first pay check. So. Many. Conflicting feelings…

In-App App Store

I am certainly not very good at the whole marketing thing for apps, but one thing obvious to me is the need to cross promote your apps. As soon as you have multiple apps in the store you should make it easy for users to purchase any app from within any other app. The idea to create your own little app store that you will embed in every one of your apps. This is what we are calling an “In-App App Store”, which we will abbreviate to IAAS from now on.

You place a button somewhere on your root view that gives a hint of a call to action, such as a little wiggle or pulsating animation. When the user taps this button one of two things happens: if the user is on an iPhone, display a full screen, 320×480 modal view, and if the user is on an iPad show a 320×480 popover pointing at the button. Inside this view you put whatever you want to help cross sell your other apps. I chose to write a very short blurb about Opetopic and then display the icons to my other apps. Here is what it looks like in IsoCards and my new game, Battle Nation:

Tapping any of the buttons in these popovers takes you straight to the app in the App Store (via my Linkshare affiliate link of course).

Implementation Details

Creating your own IAAS is certainly nothing new among iOS developers, but I’ve outlined a nice implementation below along with some sample code to make it easy to create your own. The content inside the popover/modal controller you see above is simply a fullscreen UIWebView with a simple html file fed in. The html page and assets are hosted on my website and bundled within the app itself. Initially the controller will try to load the page from the internet, and if that fails it will fall back on the local version.

So, let’s get down to the gritty details. I created an entirely separate Xcode project to develop this. The project consists of just a root view with a button on it so that I can test the popover, and the code and asset files for the IAAS. I wanted all the files for the IAAS to be as self contained as possible, so it simply consists of a view controller and a bundle folder for the html and asset files. See the pic on the left for the structure; OAS stands for “Opetopic App Store”, and this the prefix I use on the related files.

If you don’t already know, a “bundle” is simply a directory that has been given the *.bundle extension. When you do this Mac OS X will treat it as a single file, which makes it a little easier to just drag and drop into a project. You can think of it as exposing the interface and hiding the implementation, if you will.

The interface I settled on for my OASViewController is quite simple. It just has a delegate and a few methods:

@protocol OASDelegate;
@interface OASViewController : UIViewController <UIWebViewDelegate> {
   id<OASDelegate> delegate;
   NSString *oasURLPath;
}
 
@property (nonatomic, assign) id<OASDelegate> delegate;
-(id) initWithURLPath:(NSString*)path;
-(void) closeButtonPressed;
 
@end
 
@protocol OASDelegate
-(void) OASDidClose:(OASViewController*)oas;
@end

So, you create an instance of the OAS by providing a URL to the “online” version of the app store. If you choose to set a delegate then you can also be notified when the close button is pressed (I only show the close button on iPhones since popovers can be dismissed by tapping outside the view).

In the implementation I create all the UI elements (a webview and a close button) in the viewDidLoad method and add them to the view hierarchy. The code to create the webview, load the “online” version of the OAS and attach it to the view might look something like:

UIWebView *web = [[UIWebView alloc] initWithFrame:CGRectMake(0.0f, 0.0f, 320.0f, 480.0f)];
web.hidden = YES;
web.delegate = self;
[self.view addSubview:web];
NSURLRequest *r = [NSURLRequest requestWithURL:
                   [NSURL URLWithString:oasURLPath]];
[web loadRequest:r];
[web release];

Note that I hide the webview initially. This is to prevent the view from “flashing” as the content loads.

Next I create the close button. If you look at the project tree in the image above you will see I have a “close.png” image in there (hm… note to self: make a close@2x.png version). So I can create a button with this image and attach it to the top-left corner using the following:

UIImage *closeImage = [UIImage imageNamed:@"OAS.bundle/close.png"];
UIButton *closeButton = [[UIButton alloc] initWithFrame:CGRectMake(2.0f, 2.0f, closeImage.size.width, closeImage.size.height)];
[closeButton setImage:closeImage forState:UIControlStateNormal];
[closeButton addTarget:self 
                action:@selector(closeButtonPressed) 
      forControlEvents:UIControlEventTouchUpInside];
[self.view addSubview:closeButton];
[closeButton release];

Then I can use the UIWebView delegate method to detect when the UIWebView successfully loads, and unhide it:

-(void) webViewDidFinishLoad:(UIWebView *)webView {
   webView.hidden = NO;
}

In order to allow users to follow links in the HTML page you need to implement one more UIWebView delegate method:

-(BOOL) webView:(UIWebView *)webView 
   shouldStartLoadWithRequest:(NSURLRequest *)request 
   navigationType:(UIWebViewNavigationType)navigationType {
 
   if (navigationType == UIWebViewNavigationTypeLinkClicked)
      [[UIApplication sharedApplication] openURL:[request URL]];
   return YES;
}

We are nearly done at this point, and in fact some may wish to even stop here. Right now you can create an instance of this view controller, attach it to a popover or modally present it, and it will display your online IAAS. But, what if the user doesn’t have an internet connection at this moment? Should we just show a blank screen? A much better alternative would be to show a local version of the IAAS so that the user could at least see your app collection, even if they cannot buy anything right now.

To do this we need to catch when the UIWebView fails to load the online IAAS, and then try loading the local version. We can potentially enter an infinite loop of failing requests if the local version fails to load for some reason. So we need to make sure that we only try to load the local version once. We could do this by creating another ivar, but webviews have a “tag” property that can use instead. Here is the code:

-(void) webView:(UIWebView *)webView 
   didFailLoadWithError:(NSError *)error {
 
   webView.tag++;
   if (webView.tag == 1) {
      NSString *html = [NSString stringWithContentsOfFile:[[[NSBundle mainBundle] pathForResource:@"OAS" ofType:@"bundle"] stringByAppendingPathComponent:@"index.html"] encoding:NSUTF8StringEncoding error:NULL];
      NSURL *base = [NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"OAS" ofType:@"bundle"]];
      [webView loadHTMLString:html baseURL:base];
   }
}

Good god Objective-C is verbose! I tried adding some whitespace to make this more readable, but it’s futile. Just know that I first load the content of the file OAS.bundle/index.html into a string, and then load that string into the webview, but with the base URL pointing to the OAS.bundle directory. This allows all the relative references to CSS and images inside index.html to continue to work.

We now have sleek, flexible in-app app store component that we can drop into projects. An added benefit to having an “online” version of the IAAS is that we can update it at anytime and it will be instantly propagated to all users (who access it via the internet at least). So you can add new apps to your repertoire without updating all your other apps at the same time.

I put together a full sample of everything discussed above on my GitHub account, so take a look.

Git Submodule Fanciness

Once you are ready to add your IAAS to some of your apps, what are you going to do? Maybe copy/paste the view controller and bundle files into all your projects. Well, that is utterly ridiculous. You are just setting yourself up for a world of hurt. What are you going to do when you need to make an update or bug fix to your IAAS? Copy it again to all of your projects?

I’m going to assume that every piece of code you write is under version control. If not, you gotta do this ASAP. My first VC experience was with Subversion, but now I get the chills whenever I think about it. I’ve fully converted to Git now, and would never go back. It doesn’t have as much to do with Git as it has to do with a version control system that has branching and merging as first class citizens (see also: Mercurial, Bazaar). The things I will be discussing now are going to be in the Git vernacular, but I imagine it can all be translated quite easily to other systems (e.g. see svn:externals for Subversion).

A Git submodule is like having a repository inside a repository. For example, right now I have a repository devoted to the Opetopic App Store (OAS), and a repository devoted to my new game Battle Nation. I would like to be able to add the files from OAS to Battle Nation, but in such a way that I can push and pull changes from the OAS repository. That way the OAS files will always be in sync across all projects.

This is quite easy to set up. First I add the OAS repository to my Battle Nation repository via:

git submodule add /path/to/OAS OAS

This will create an OAS directory inside my working directory (which will have its own .git structure), and it will create a .submodules file in my root path that lists all of my submodules. At this point none of these files are committed, so I need to commit:

git commit -m "Added the OAS submodule"

At any time I can pull the most recent changes to my submodule via the git-submodule update command:

git submodule update

And now I can keep everything in sync very easily. So, next time I release an app I can update the HTML in my OAS project, push to my Git server, pull to all of my other apps, and submit updates to those apps publicizing my newly released app. In fact, I’ve got one more fancy trick up my sleeve. I also have a post commit hook set up in Git so that every time I push to the OAS repository, all of the HTML files are automatically uploaded to my FTP server, and now even those files are always in sync.

The Trip (condensed form)

First you need the context of our trip as it traversed the full spectrum of travel, from comfortable and predictable to digging a hole in the ground for a toilet and “oh my god were we just kidnapped?”. We spent only two days in Cairo to see the most popular sights, the pyramids, the museum, and the bazaars. Although Cairo is an amazing city, it is just another urban sprawl, and we were itching to get into an adventure.

The Route

From Cairo we took an overnight train to Aswan and stayed two nights. In Aswan we visited the great Abu Simbel temples, had dinner in a Nubian village and relaxed. We departed from Aswan on a felucca, a traditional Egyptian sail boat capable of carrying about 12 people with no internal areas. We slept on the felucca on the shore of the Nile, and in the morning finished our ride in Luxor.

Felucca-ing down the Nile

Luxor is filled with ancient sites such as the Karnak Temple and the Valley of the Kings. After two days in Luxor we started the arduous journey to the desert. The journey is far too long to do in one sitting so it consists of many stops in small towns.

The first leg was a 9 hour drive to the Dakhla Oasis, a basic town in the middle of the desert. After only one night it was back on the road for 5 hours until we reached the small town of Farafra. The only reason we stopped in this nondescript town was to wait out the sun, for the next leg of the trip consisted of swapping our bus for a 4WD Jeep and heading straight into the desert.

Barreling through the Sahara on one of these is crazy fun.

After another 4-5 hours of driving and sight seeing we were setting up camp in the White Desert just in time for the sun to set. In this case camping means just throwing our sleeping bags on the sand; no need for tents here, but watch out for foxes and giant beetles. After smoking shisha and singing around a fire all night we slept under a million vibrant stars and counted shooting stars until we fell asleep. We were up first thing in the morning and on the road heading to Bawiti, a necessary stop on our way to Siwa.

An 8 hour drive brought us to the Siwa Oasis near the Libyan border. Due to its proximity to Libya everything going into and out of Siwa is highly controlled, which means one must pass through many checkpoints along the way. Siwa was by far the most conservative city we visited in Egypt with most women donning a burqa. At the same time there was a bit of a hippy feel to the city, including a little cafe that played tons of Bob Dylan and Rolling Stones.

Sunrise from our desert camp

After two days in Siwa we were on the road again heading to Alexandria on the Mediterranean. Alexandria is a beautiful modern city with tons of sites and culture to explore. True story: we were nearly kidnapped our last night here (I’ll tell you about it later). I wish I had more time to spend here, but after two days we had to take a train back to Cairo, and then it was a flight back to New York.

The Hardware

Each of us brought our own iPad: my 16GB WiFi iPad and Sindy’s 32GB 3G. The only other electronics we packed were our iPhones (both 3Gs), my Nikon D80 camera with two lenses, and the camera connection kit.

WiFi was ubiquitous throughout Egypt. Most hotels had wifi in the lobby for a small fee (5-10 Egyptian pounds, ~1-2 USD), and many museums, libraries and attractions had free wifi.

Ruggedness

The iPad gets an unexpected win in the category of ruggedness. As you read, our trip was quite an adventure. An overnight felucca ride on the Nile, nearly 20 hours of 4 wheel drivin’ through the desert, camping in the White Desert without tents, train rides, bus rides, camel rides, donkey rides, etc. Our iPads were with us the whole time protected only by a plastic ziplock bag in case of water damage.

Never once did I worry about the iPad’s safety. I would take it out for a moment, look something up and then throw it back in my bag. It’s slim profile made it easy to slip into any opening in my backpack or daypack. It’s solid one piece construction and lack of external buttons made me that much more comfortable throwing it around knowing that there was nothing that could break off or snag on something inside my backpack.

The iPad’s lack of edges and seams is also a huge plus. I would not have busted out a laptop or netbook in the middle of the desert because cleaning out sand from under the keys and crevices would have been a pain in the ass. But just a quick wipe down of my iPad and it looked brand new.

Camera Connection Kit

The camera connection kit is awesome. The RAW images in my Nikon D80 weigh in at around 10.5MB per image, and I survived the trip with only a 4GB SD card. Every night I would dump the entire memory card to Sindy’s 32GB iPad, which allowed me to take over 1,600 images in total. Looking over the day’s photos before going to sleep became a bit of a ritual.

I also carried my Flip HD recorder, and shot over an hour of video. There was still plenty of room on the recorder by the end of the trip, but there is nothing like being able to transfer the videos to the iPad and watch them at full resolution at the end of a long day (only iOS 4.2 will play videos imported from the camera kit).

My biggest complaint with the camera kit is speed. It takes on average 11 seconds to transfer one RAW image from the memory card, which means nearly 30 minutes for a full transfer on heavy shooting days. This could be because the iPad creates jpeg thumbnails of the images as it transfers, but I still want better performance. Luckily you can exit the photos app and do other things while the photos are transferring even without iOS 4.2 multitasking.

Another annoyance is the inability to view the full size images right off the memory card without importing them into the Photos app. The camera kit has the potential to be the greatest card reader in existence. At one point a fellow traveler wanted to show me some images from his trip, and it would have been great to pop in his card and browse the photos. Another use for this would be the ability to delete subpar photos directly from the memory card rather than importing and then deleting.

The camera kit desperately needs compatibility with the iPhone and iPod touch. Ideally I should be able to carry just my camera, iPhone and connection kit, and when I need to clear my memory card just whip out my phone and dump the images. I would never pull out my iPad and do a transfer in the middle of a shooting session. It’s just too bulky and I was shooting in some very sketchy areas.

For transferring the photos to your computer I suggest using Apple’s Image Capture application instead of iPhoto, which I found to be glitchy and slow.

Mobile iWork

Pages and Numbers for the iPad really impressed me on this trip. In fact, I wrote the majority of this blog post in Pages while flying back to New York. It could have just as easily been written in Notes.app, but seeing headers and pictures right in the document made it easier for me to structure the post. I also used Pages to keep a brief journal of some of the memorable stories that happened. Again this could have been done in Notes.app, but I could enhance the journal by adding pictures from the day.

During our layover in Rome Sindy remembered that she forgot to create and send an important report to her colleagues. It was amazing to watch the fluid back and forth switching between Mail.app, Numbers and Goodreader, pulling data from one app, entering it into another. Within an hour she had a moderately complicated spreadsheet put together, formulas and all, and thanks to the recent Numbers update she could mail off an Excel file before we boarded our flight to Cairo.

Sindy is a bit of a work-a-holic

Reader

I used the iPad quite a bit for reading, but unfortunately iBooks was useless to me. Most of the documents I wanted to read were in PDF format, and iBooks as a PDF reader is crap. It really needs to provide access to the PDF’s metadata (e.g. table of contents), as well as a better way to organize documents instead of the bookshelf metaphor. So, for my reading needs I turned to Goodreader. It’s user interface can be a challenge sometimes, but it’s organizational capabilities and PDF metadata access makes it indispensable for me.

Outside of the few non-fiction books and novels I am in the middle of (Rework, Being Geek and Cat’s Cradle), I also loaded a bunch of travel books into Goodreader (Lonely Planet guides, historical books, web clippings). Having multiple travel books on the iPad was very convenient and a better experience than the dead tree version. Searching and annotating the book is much easier, and flipping back and forth between different books was painless.

IsoCards

I already have a more detailed blog post on this topic, but I want it to be known that IsoCards is awesome for traveling. It doesn’t matter how bumpy the ride or how harsh the environment, I could always play a game of poker with friends.

Most Used Apps

Here is a list of the apps I used the most on the trip, and the ones that just really surprised me at how useful they are.

• Pages: Great for writing this very blog post and keeping a journal of the unforgettable moments from the trip.
• Goodreader: An excellent e-book/PDF reader, if slightly cumbersome.
• Ludo, IsoCards, any board game simulation: Nothing like being able to play card games and board games on a bumpy bus or train ride with a group of friends. Also see my more detailed blog post about using IsoCards while traveling.
• OffMaps: I used OffMaps to download street maps of all the cities I visited so that I could easily find my way around while exploring.
• Numbers: Indispensable for Sindy so that she could get critical work done while away from her computer.