I made an app about fishbuns

Say what?

Alright, seems like I have to explain myself.. (again).

Initially, I had something completely different in mind. A few months ago, I was walking through downtown Hamburg on my lunch break. The place I currently work at is situated in a very tourist-attracting area, so there are always people around, taking pictures of all kinds of stuff.

This made me think.. People take pictures everywhere they go and a solid amount of them get uploaded to Instagram, a lot of times with location-tags attached to them. So.. wouldn't it be cool to have a display of popular locations around you, based on how many pictures are taken there?

> I guess that's nice, but "cool"?

The cool part is, that you would end up with a universal travel guide that works pretty much everywhere Instagram is used (which probably covers a big part of momma earth). You wouldn't need to go through each location manually and look/ask for interesting places.

So the concept was to write an app, that gets the current location of a user, looks for Instagram locations around, and then puts them in relation to each other based on the amount of pictures taken there.

Theory and Practice

I'm trying not to expand on this too much but I've basically worked on this idea for a couple of weeks until I figured that it won't really work out in the end. There are two main reasons for this:

API Limits

You can ask Instagram for locations around you, but only for a maximum radius of 5km. In practice, that is not a lot. So I tried to work around that by getting locations for the user's location, and 4 additional locations around (x/y +- 5km). However, that means 5 API calls, just for getting locations for a single user request. I haven't even calculated any media counts yet. Here's where another problem kicks in:

Instagram doesn't provide a "media-count-for-location"-interface, you have to ask for the media for a location and then count yourself. This wouldn't be a problem, if Instagram wouldn't provide such media to you in chunks of 10-15 items at a time. So for a popular location with say 2000 items, that would be ~ 200some API requests (for a single location).
Given that you are permitted a total of 5000 API requests per hour, that system wouldn't scale very well at all. I've tried to optimize the API usage by storing media counts in a database (after all, these don't have to be updated each time), but even if I could eliminate all media count requests, I'd still have to do those 5 location requests per user (Which would only let me do 1000 users / hour, ~ 16/minute).

Dumb locations

This one is even tougher to swallow, because it's not really a technical limitation, but rather a user-created one. In my attempt to scan all the locations in my home town (which took almost a week of constant API requests, by the way), I've noticed some really dumb locations. Besides the casual "at my mom's house", "in my bed", or the always re-occuring song title as a location (WTF?), which you can eliminate easily because they usually don't have a lot of pictures, there are some pretty odd ones.
For example, there is a location in the airport area of Hamburg, called "London", which has hundreds of pictures!

I'm not sure if these are people that forgot to post while they were over there, unaware of the fact that you can click on a location and see where that supposed "London" is at, but stuff like this occurs. And the only way I see to monitor these issues would be to manually blacklist locations. Which goes against the entire purpose of the system, not to do anything manually.

Alright, now what's with the fish buns?

Right at the time I worked on all of this, it was brought to my attention that my city was hosting an app contest. Basically: Write whatever you want, as long as it's related to Hamburg and somehow economically relevant.
So the smartass I am, I thought I could just finish my location-finder app, brand it as a Hamburg-location-finder and submit it. As mentioned, that didn't really work out so a month before the contest deadline I had nothing.

Aww, maaaan!

I've invested all this work trying to figure out how to use MapKit, CoreLocation, the Instagram API, how to integrate a backend database and a local storage .. for nothing? That sucks!

Hence, "Find my Fischbrötchen" was born. A "Fischbrötchen" (literally translated "fish bun/sandwich") is a traditional snack around here, especially in Hamburg's harbor area. It's really just fish on a bun, basically.
But that fish on a bun was at least an opportunity to use some of the components I've written already and build a Hamburg-related app in the very limited amount of time I had. So that's what I did!

The core of the app is the database behind it. I'm using a Parse backend, mainly because it's free for my small scale and very easy to use. The database contains all the places to get Fischbrötchen at, full with name, coordinates and thumbnail image. The app then pulls that data at launch and presents it on a map/in a list. If the user wishes to share his/her location, I can tell him/her which location is closest and how to get there (via Apple Maps navigation).

Yes, this ended up pretty simple in functionality but it was still a huge amount of work to do on my own, especially since I had to juggle college assignments and work at the same time, in addition to this. Still, I'm happy with the result. The app works properly, I consider it ~~pretty~~ not ugly, and I've advanced my skills in AutoLayout so far that I'm (accidentally) supporting landscape-orientation as well!

Fortunately, the app went through App Review in time for me to submit it to the contest, three days before the deadline! It is online now, if you feel like it, you can check it out here!