Local Brew is a handy iOS app to help you quickly find your favourite microbrewery in your favourite city.
An App in the App Store
Local Brew is available on the Apple App Store.
Technologies Used in Local Brew
I used technologies, while building Local Brew, that are commonly used in many iPhone designs. A quick summary of the key technologies used:
- Access data via a public API. I decided to use BreweryDB as our data source because it is a robust and well-documented API with a rich set of data. I could pull lots of brewery and beer detail including descriptive text and images.
- Core Location to find user and brewery locations on a map.
- MapKit to build maps.
- Custom delegation to move data around various view controllers.
- Firebase to allow us to create user-generated data.
Probably the biggest challenge developing Local Brew was coordinating the handoff between Core Location and the API calls to the BreweryDB database.
When the app launches, it requests access to the user’s location. Once access is granted, it calls Core Location to learn the user’s geographic location and then use that information (city name, state name, and country) to make a call to the BreweryDB database to create a list of breweries close to the user.
Core Location keeps calibrating and refining the user’s location and during development this caused multiple calls to the BreweryDB database.
There were development problems coordinating the timing of the collection of the user information and making the API call. The app often crashed during development until I isolated and sorted out the issue.
Even though I tested thoroughly and tried to expect user errors, I found problems once the app was published in the App Store. For example, I did not notice that Apple returns city names such as Montreal as Montréal (note the e-acute). The API call does not handle the e-acute very well and crashes the app.
Now that the app is behind me and Local Brew is on the App Store, here are several lessons learned from building the app.
- Managing one API call is challenging. Making two calls for data and trying to hand data from one source to another can increase project complexity and be problematic.
- Control the scope of the project, be attentive to feature creep, and make sure you understand why a feature is going into the project.
- Make sure you test and validate the app.
- Invest the time before the coding starts and plan the project. Layout the views (even on a piece of paper), create the user stories, script some tests, and investigate the unknowns before writing code.
- Avoid or limit allowing the user to input information in text format that you, the developer, uses in the app. We allowed people to change the city and see microbreweries in those cities using text input. We had to create a lot more error checks than we anticipated to deal with this.
This article is part of my iOS Development guide.