As smart-phone adoption continues to explode, gaps between a web app and mobile app experience are going to become more noticeable. Today I was booking flights on Southwest and noticed a subtle, yet important, gap between their iPhone app functionality as compared to their web site.

For a given flight, Southwest provides a nifty suggest functionality that gives you a list of possible airport names and their corresponding airport codes after you start typing in the city name. For example, here’s how it looks on the web site:

After entering “san”, the user is shown the different suggestions that would most likely match the city they are looking for. The other neat thing about this suggest feature is that it recognizes airport codes. So in addition to searching for San Francisco by entering “San …” you may also simply type in “SFO” like so:

Well, it turns out that the suggest feature in their iPhone app is not as smart. It will recognize “San …” but it will not recognize airport codes.

Ideally, there should not be a functionality gap here and the iPhone app should be able to find airports solely based on the airport code. From an engineering stand point, this is the whole point of creating an architecture that is built on top of services. If Southwest had a City Suggest Service internal API, both the web app and the mobile app could make use of it to provide identical functionality.