Local Brew is a handy iOS app to help you quickly find your favourite microbrewery in your favourite city.
It is not the first iOS app I created. I recently completed Mobile Makers — an eight week iOS developer bootcamp in Chicago.
The first four weeks of the camp was intense. Each morning we created an app with the instructor. The afternoon (and evening) was devoted to a coding challenge (build an app based on that day’s learning). Every Friday we had a four-hour assessment challenge where we, again, built an app.
The focus was on gaining a working knowledge of the iOS frameworks in both Objective C and Swift. We learned UIKit, MapKit, Core Location, Core Data, and more.
On the fifth week we assembled into small teams and built an Instagram iPhone clone. This took the whole week.
In total, we built over 35 iPhone apps during the first five weeks!
An App in the App Store
One of the key goals of the bootcamp was to produce a more complex, production-worthy app and publish it on the Apple App Store.
I proposed the Local Brew app to the group (there were 18 students in my cohort) and two people joined my team.
We had three weeks to put our new found skills to use to produce Local Brew.
The first five weeks of the training (and my experience completing a Rails bootcamp) taught me to set project goals before plunging into the thick of the things.
Here are the project goals I set:
- The app is a show piece to be used to demonstrate my iOS bona fides. It is not a commercial app for a new venture.
- The app should demonstrate that I know how to pull data from an API, populate a map and table view with the data, use Core Location services, create safeguards to limit crashes and errors, deal with complexities and nuances of the iOS framework, and get an app into the App Store.
- Control the scope of the project. Limit project complexity. And avoid features or functions that can sink the project.
- Create rail guards to manage the team with GitHub version control, bug tracking, and test plans.
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 identify 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.
We did a good job managing the scope of the project and were able to ship the project to the App Store on the final day of the camp. We had to wait about ten days to get final approval from Apple.
Probably the biggest challenge we faced developing Local Brew was coordinating the handoff between Core Location and the API calls to the BreweryDB database.
When the app launches, we request access to the user’s location. Once access is granted, we call Core Location to ascertain 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.
We had some small problems. We did not know that Core Location keeps calibrating and refining the user’s location and this was causing multiple calls to the BreweryDB database.
We also experienced significant issues. We had problems coordinating the timing of the collection of the user information and making the API call. The app frequently crashed during development until we sorted that out.
Even though we tested thoroughly and tried to anticipate user errors, we found problems once the app was published in the App Store. For example, we 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 bootcamp is behind me and the Local Brew is on the App Store, I have had time to reflect on the project and note “lessons learned” while 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. I think our team managed this well, but I feel that the Mobile Makers instructors should have challenged the other teams on their assumptions and saved a lot of headaches.
- 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 cranking out code.
- Agile development was “covered” during our time at Mobile Makers. Every morning we had team stand-ups but I feel that they were a charade. A good team workflow can make all the difference in a project.
- I would 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.