Since joining the team at Oak City Labs last year, I have had many conversations with friends, family and prospective clients about mobile app development. When I show them an app we’ve built, like CurEat, they often tell me that it looks great, and then ask me to show them which parts of the app I made. While seemingly an innocuous comment intended to allow me to showcase my hard work and reap some easy praise, this particular request typically leads me to release one of my patented <heavy sighs>.
But Cory, why do you heavy sigh at such a polite, ego-boosting request, you ask? Well, fellow human, I release the air from my lungs at a much faster rate than usual in an exasperated manner because users of our apps don’t actually see anything I have made. They see the work of the design team in the visuals of the app. They see the buttons, lists, login screens and settings menus that Jay (iOS) and Taylor (Android) have coded in. They even see the legalese a lawyer somewhere put together. So when I tell people that I spent over a year working on an app after explaining that there is no visual evidence of my work at all, they get this sort of half-confused, half-amused look on their face.
Of course, I could simply tell people that I am a backend developer who helped make the Python Flask server, PostgreSQL database structure, RESTful API and Angular webapp that allow the mobile app to be more than a sad, functionless, empty shell. This jargon only helps those with a technical background, and usually leads most others to say something along the lines of “Oh, OK…” when in reality, they’re thinking “Was he even speaking English?”
And so, through a long, arduous process of trial, error, confused looks and copious amounts of feedback, I have concocted what I believe to be the ultimate formula in explaining what my actual role is in the app development process.
To aid in understanding my role as a behind-the-scenes magician, I will refer to the Snapchat app as an example.
For those who aren’t familiar with Snapchat, let’s run through a typical Snapchat use case. This is assuming you already have an account and are logged in.
Step 1: Open the app
Step 2: Snap a super artsy picture of your keyboard and wrist rest
Aaand we’re done! I have now sent a poignant photo of my keyboard to two of my closest imaginary friends. Soon, they will receive a notification of the photo and will be able to open and view it for themselves.
This is the process for using the app, but to understand how we are able to get to this point and do such a thing, we need to step back to the very beginning.
Here is the terminology I will use in the following examples:
- Mobile Developer - Somebody who builds the actual app that a user sees on their mobile device
- Backend Developer - Someone (like myself) who works on the behind-the-scenes details such as the server, API and web framework. If this doesn’t make sense, that’s OK - we’ll get there!
- Snap - A snap is an image that you exchange with friends on Snapchat
When the app loads, you have the option to log in or sign up. So far, this is all the work of the mobile developer. They created this screen, pulled in images from the designer, added some text onto buttons, and bam. This screen is born:
Now let’s say you click Log In. You are then taken to this screen:
This screen lets you log in with your account information and takes you into the part of the app where you can actually send and receive snaps. Every “usable” thing on this screen was added by a mobile developer: the input areas for username and password, the “Forgot your password?” link and the “Log In” button. So far, the backend developer hasn’t played a role in either of the previous screens.
Now, what happens when you press the “Log In” button? Does the phone magically know whether your account info is valid or not? If that information were only stored on your phone, how would you be able to log into Snapchat on a new phone with the same account?
The answer: You wouldn’t. Your account information is not even touched by the mobile developers!
*My Time to Shine!*
There are a lot of behind the scenes details happening here that the backend developer is responsible for, so let’s break down the differences between the work of the mobile and backend developers in the above scenario.
Create app screen with inputs
Send username/password to server
Receive output from server telling the app if the login was successful
Continue on to the next app screen if the user logged in successfully
- Tell server how to handle a request to log in a user
Tell server how to check with the database to confirm/deny a login request
Tell server how to send a request back to the app if the user logged in
The mobile developer creates the code for the login screen, the backend developer creates the code for all of the actual “logging in” and checking of whether you are a valid user or not.
Let’s go back to the scenario of sending a snap to your friends.
Starting with my super duper artsy photo again, we can examine this screen. All the interactions on this screen are completely up to the mobile developer. A few examples are the ability to save this image or add text to it. Now, let’s say the user clicks the button in the bottom right to choose which of their friends to send the snap to.
We’re taken to this screen. The app displays a list of names which are all of the potential friends you could send your snap to. You select the ones you want, then click the send arrow in the bottom right to send your snap to these friends. Everything visible is presented with code from the mobile developer still. Except...
Let’s back it up.
Where did your friends list come from? Does your phone just magically know which of your friends have snapchat and also have you as a friend? How would you add or remove a friend? And what are those numbers and emojis next to the stars on the right side of each name row?
That’s a lot of questions, so let’s do a breakdown like we did before.
Request list of friends and friend information from server
Display list of friends
Display information about each friend (such as the numbers and emojis)
Allow the user to select which friends will receive their snap
Tell the server who the user wanted to receive their snap
Build a list of friends and friend information for the given user and return the information to the app
Perform the actual sending of the snap to all of the selected friends.
Notify all the friends that they have a new snap
The mobile developer creates the code that displays all the friends and let’s the user choose who to send the snap to, but the backend developer creates the code that tells the app who the user’s friends are and the code that actually sends the snap to those friends.
At the end of the day, there’s a lot of communication that needs to happen between mobile and backend developers, because as you can see, they depend on each other very much. Without a mobile developer, all the backend logic and data and snap sending would be pointless. Similarly, without a backend developer, Snapchat wouldn’t actually be able to do anything. It might sit there looking pretty but you wouldn’t be able to send your snaps to anybody, which would be quite sad.
I hope my examples helped, but if not, here are a few analogies to provide more clarity:
A mobile developer is like a news anchor. Without the backend developer (teleprompter), the news anchor would just sit there looking pretty without knowing what news to tell viewers about.
Alternatively, think of a mobile developer like a grocery store, choosing how to display all of the food that the backend developer delivers. Without the shelves and organization from the mobile developer, all of the food from the backend developer would be too chaotic and unstructured to give to the shoppers. But, without the backend developer, there would be no food at all to give to the shoppers.
A mobile developer creates your Gmail app, but without the backend developer, your email would never show up in the app.
A mobile (or web, in this case) developer would create the Netflix app or website, but without the backend developer, no shows would show up or be watchable.