Construction

Reader, I built it.

I decided after presenting my “looks like, feels like” milestone in mid-March that I wanted to move full steam ahead on building a live, functional, native iOS app in Xcode.

xcode01

This was something I’d never done before, which was part of the goal. All of my previous mapping prototypes had been built in some combination of HTML, JavaScript and PHP. But since I’d conceived of a mobile app, it seemed natural to build it out properly.

It wound up influencing the design significantly, as live data tends to do. For instance, my product grid had always had rectangular image thumbnails, largely because I’d been using images in my mockups that looked good when cropped that way. I soon learned that there’s a reason that every single e-commerce site uses square thumbnails: unless you’re going to carefully photograph all of your own product images, you’d better get with the program, because most images just do not look good when randomly cropped as a rectangle.

My structural plan of attack was to build out two screens — search results, and map. In the end, I dove deep into Apple’s Swift documentation, which turned out to be unusually coherent and useful. I also leaned heavily on a couple of additional Swift tutorials I found online that really catalyzed my progress with MapKit and bought me some time to implement other fancy features (sorry, I added some parallax to my product grid).

I spent a lot of time trying to find data that would be reliable enough to prototype with. Ironically, e-commerce came to the rescue — the prototype relies on Amazon’s Product Advertising API for item details, thumbnail images and categories. The prototype is effectively a bridge between Amazon’s listings and Yelp’s listings — I created a database that aligns their categories, so that once a user selects an item the app pulls businesses from Yelp’s API that match the item’s category.

All of this backend logic occurs on a server I set up, where these APIs are called and the results are merged and thrown into a JSON output that the iOS app is able to easily parse. It’s effectively set up as a private API.

This usually works well enough, though there are some interesting errors — for instance, if you search for a kitchen appliance, you’re just as likely to see a result for a kitchen & bath showroom as a houseware store. Ah, well.

The inventory count listed for each store is random.

I also leveraged both Apple’s MapKit API and Google’s Directions API to automatically plot directions on the map. This is because MapKit does not yet offer API access for transit directions. So each time a user taps on a map pin, walking and public transit routes are calculated and the shortest one is posted. I’ve color-coded the public transit polylines based on Google’s very helpful API, which includes the hex code for every subway route in the city. Driving directions are not included, because let’s get real, it’s New York. If you were driving, you’d just go to that Costco in Sunset Park.

Jetsam | Afterword