Posts

By: Carol Vercellino, CEO & Co-Founder

Today, I’m going to highlight our top 3 programming languages in 2021 and discuss their benefits. I’m going to talk about Javascript, Python, and Swift. And also the reasons why we’ve selected these three as our top picks. 

If you’re new to the programming world, make sure to use this video in conjunction with our other video, How to Choose a Programming Language for Your Product

But, let’s get to the programming languages.

Javascript

First up, we have Javascript. Javascript is widely used now because it was first used for prop and programming language. What that means is it’s used to render the very first thing that your eyes see when you go to a web page

It also began being used on the backend as well, which is all that code on the back that tells the server what to do. And it was really facilitated by Google in trying to help people learn more software development. And so, that’s why it’s a top pick for 2021.

Python

Next up, we have Python. Python has been around for a long time. But, it’s widely used for statistics and science, and pretty much anything. You can spin up a website really quickly with Python, and you can do a whole lot of complex things on the backend, especially for a complex app. It continues to grow because of interest in data science and analytics. So, that’s why it’s our second top pick for 2021.

Swift

Finally, we have Swift. If you google the top languages for 2021, Swift may be a little bit lower on the list. And, yes, I am biased because we do use Swift a lot in our company. But, Swift is the language you would use for an iOS application, or a Mac application, or anything that’s going to run on an iPad.

It’s not only growing for those types of apps, but it’s also starting to be used on the server side. You’ll see Apple really push Swift going forward for the next few years. And we’re super excited to see what they do with it as well.

For 2021, we’re going to keep that as our third top pick at Oak City Labs.

 

I hope this was helpful, and let us know what programming language you’re interested in learning more about in the comments. We’d love to create more content that helps you as you’re developing your software or app.

 

Know what programming language you want to use? Read this post next about setting expectations for your software development project.

By: Carol Vercellino, CEO & Co-Founder

One of the hardest questions you’ll ask when you start developing your software product is what programming language should you use?

Let’s talk through some of the concerns and considerations you should make when choosing your programming language. 

But, before we dive in, if you aren’t familiar with some of the most popular programming languages, we recommend watching our video on the top 3 programming languages in 2021 first. Then come back to this post.

Let’s dive in.

 

Carol: So Jay, when it comes to creating software or apps, what factors do you need to consider when choosing a programming language?

Jay: Well, there are a couple of things you have to think about. One of them, to start with, are there some requirements?

For iPhone apps, you’re going to do those in either Objective-C or Swift for a native app. If that’s the thing you’re looking for, those are your two choices. Objective-C is sort of the legacy at this point, and most new developments use Swift. Similarly, for Android, you’re going to look at Java or Kotlin, Kotlin being the new thing.

On the backend, you’ve got a lot more flexibility. There are several languages: Python, Ruby, Go, Swift, and some others you can use for the backend. 

Another important thing you need to think about is the availability of developers in your area. You’re probably going to start with one developer, so you just have to find that one. But as your product and your team scale, you’re going to need to augment your team and hire people. Is there a big pool of developers in your area who are familiar with that technology?

Carol: So, JavaScript is super popular, right? And it’s mostly used on the frontend, but a lot of people are using Javascript on the backend now?

Jay: Yeah, people use JavaScript on the backend with Node. I think it’s really popular. It got popularized by folks doing frontend work who wanted to do backend work and didn’t want to learn another language. Google sort of facilitated that with developing Node and taking their javascript engine, and making it available on their server.

A lot of people feel like it’s easy to slide from frontend development to backend development with JavaScript.

 

Carol: Like the chicken and egg question, should you choose your programming language first and then find a software developer who understands that language or the other way around?

Jay:  It’s really hard to say. It depends on your project again. If you’re in one of those situations where your project and the space you’re working in determines what language you’re going to use, then that’s pretty much it. 

If you’re building a more generic backend thing, like an API for a service, you’ve got some flexibility there. So, you have more freedom to choose or interview different developers and maybe let them make some of those technology decisions.

Carol: What if you found a developer you really liked, and, not to be too controversial, they use Perl or PHP. What would you say to that?

Jay: Those are both sort of what I would consider legacy languages. Perl especially and PHP moreso. That’s certainly not terrible. A lot of the web runs on PHP. 

Again, as you scale your team, you attract new developers that are going to be versed in that kind of thing. Younger developers aren’t going to be into PHP, and maybe some older ones want to move away from PHP. So, those are some of the concerns you might have.

 

Carol: And let’s wrap up with talking about potential roadblocks. What are some common mistakes people make when choosing a programming language?

Jay: The most common one is to go for the new shiny thing. The new language comes out, and it’s all built cool, and they’ve got really good demos, and they solve some problems. Maybe they take something that used to be hard in an old language, and they do it really, really well because they made the language to do that. 

But, once you get into a really serious project, you have problems with, for example, is their tooling around that? Is it too young to have really good tools to work with? Is it robust? Can it handle edge cases that maybe some of the older languages have already worked out? 

Does it have a really rich library of tools to interface with other things? Python is a really old language at this point. There is a Python library for just about anything. If you need to access this weird service, some dude somewhere in a basement in Nebraska, wrote a library to do it. 

A lot of the newer languages just don’t have that sort of coverage. 

Carol: And support too, just community support. Can you google it and find an answer to it?

Jay: Exactly. Do you want to be out there on the bleeding edge? Maybe not.

Carol: I think we did a video about interviewing software developers, so it might be helpful for people to check out as well.

**The above interview has been transcribed for clarity and brevity.**

Need to find the right developer for your project? Make sure to ask the right questions to get the best fit. Learn how in our video, How to Find an App Developer

How to Find an App Developer

So you’re an entrepreneur, and you’ve got this amazing idea for an app.  Now you’re probably wondering how to find an app developer who can deliver what you envision and help you bring it to market. 

Building an app can be really expensive. A lot of folks have a budget for basically just one shot at version one. So you want to make sure you get the best app for your money, and get a good start to your business. My business partner Carol is joining me to discuss how to screen developers and pick out one that might be right for you. 

Read on or watch the video to learn more about how to find an app developer that’s right for you. 

Jay: Carol, where do we even get started looking for developers?

 

Carol: Well, oftentimes, I would suggest people can ask around in their network. And a lot of people these days might do a Google search. But more often than not, a referral is the very best place to start.

 

Jay: Okay, so we need a referral. Maybe get a couple [of referrals] you’d want to talk to. What kind of questions do you ask those developers?

 

Carol: I might ask them different questions than a lot of people, but most importantly, you want to ask them about their experience. Ask what kind of apps they’ve built before and if they’ve built anything like what you’re looking for. Or if they haven’t built what you’re looking for, maybe learn more about their track record and their history. 

And I often learn from people based on what questions they ask. So just kind of going through that process should help you out. 

Also you may want to ask about things like quality. How did they build quality into the product? How long do their projects typically take? You probably can’t figure out the cost on the first round of questions. But focus on experience, quality – things like that.

 

Jay: Okay. So when you talk to developers, a lot of times you get sort of a firehose of tech speak coming at you. If you’re not really technically-minded, how do you decode that?

 

Carol: So the way I do things is – for example, if they use an acronym, I will ask them to explain it to me like they just met me on the side of the street. And I have no problem being completely ignorant to what somebody is talking about. And I will ask them over and over to explain it to me until I get it, which you are probably familiar with, Jay! But it doesn’t matter if you don’t know what they’re saying, but know that if they can’t communicate a complicated topic to you, then they may not be a good partner for you.

 

Jay: That makes sense. And what kind of red flags do you look for?

 

Carol: Oh, my goodness, let’s see. Red flags you might look for are if they’ve never done development before, or if they can’t explain complicated topics to you. If they don’t know what testing is. You may want to ask them to explain things like the difference between a unit test and a functional test, and then ask them how to [perform] those tests. Ask them what types of tools they use for testing and what kind of language or platform they’re going to use to build your project. 

And then ask them why. If they’re going to do a cross platform app for you, ask them why they like that. And ask them if that makes it a buggier app, or how easy it is to troubleshoot a cross-platform app. Or if they’re going to go [with a] native [platform]. Ask them about how they know what Android would look like, or if they are going to start with iOS, what that development process would be like.

 

Jay: And what other advice do you have for folks who are looking for a developer for their project?

 

Carol: General advice would be looking at that history that we talked about, making sure that they understand testing and have good quality software development practices. Ask them how they stay up to date on things and make sure that they have an excellent explanation as to the tools and the languages that they use. 

You know, sometimes it’s not always the best to go with a developer that uses the latest flashiest network or language that’s trending that day, because it’s going to make it hard for you to find developers to take that project over in the future. And the same thing [is true] with the older languages. I hate to say it, but PHP may not be used for new projects these days. And so if you talk to developers that are going to build your whole app in PHP, see if that’s a trending job post on Indeed in your area, and it might give you a good idea of whether that’s a good idea or not.

 

Jay: All right, well thanks for taking us through all that today, Carol. I always hate to see somebody who sinks a huge chunk of cash into a project that ends up with a bad app or an app that just doesn’t work. So folks if you have an app idea or more questions for us, you can contact us on our website and be sure to follow us on social media and subscribe to our YouTube channel for more tech tips. Thanks.

 

Contact the Oak City Labs team to discuss your app idea!

Mobile App Testing

Questions to Ask Your App Developer About Testing

By: Carol Vercellino, CEO & Co-Founder

Mobile app testing sounds really important, but as an entrepreneur with an app idea, what do you really need to know about it? What questions do you need to ask the developer you’re going to work with to build your app to ensure it’s being tested thoroughly, especially if you don’t have a software development background? 

I’m Carol Vercellino, the cofounder of Oak City Labs, and this is my cofounder Jay Lyerly, who also serves as our chief technology officer. He’s going to share his knowledge of testing. 

Watch the video or read on below to learn more.

Carol: Alright Jay, let’s start with the basics. Why is it even important to test your mobile app?

Jay: Testing is all about risk management and how you can manage any changes to your application. So as your app grows and develops, it becomes more and more complicated. It’s easier to introduce problems when you make changes. So, a good solid testing foundation minimizes those kinds of issues.

Carol: So, risk management. Does it also help with the expense later down the road? Does it make it cheaper later?

Jay: Yeah because since you’re doing that risk management, you can feel safer in making changes later. And those later changes are less likely to cause catastrophic failures that sneak up on you.

Carol: You wouldn’t know anything about that! (laughing)

Jay: (Laughing) No, no no!

Carol: So if you were an entrepreneur and you were going to hire an app developer, what advice or what things would you ask about testing?

Jay: So the first thing I would ask is just really generally, “What kind of testing do you do?” Hopefully they don’t say “None!” So what you’re looking for after that is what kind of automated testing they do. Some developers will just do it all by hand. Manual testing is an important step, but you also want to have some automated tests to go with it. 

[You’ll also want to] talk about test coverage. That’s how much of your application gets tested in an automated way. It’s really hard for an end user application like a mobile app to have 100 percent test coverage just because there are a lot of weird cases that aren’t worth testing. But you probably want at least half, 50 percent. Up to 70 or 80 percent would be great numbers to hear.

Carol: Okay, so if a developer said yes, they do automated testing, and have over 50 percent coverage – or they say 100 percent coverage – are there any red flags someone should look for? Especially if they really don’t know what automated testing is, or what test coverage really even means?

Jay: Well, 100 percent test coverage is a little bit scary because there are always some bizarre cases that are really difficult to reach, and that’s not really an efficient use of a developer’s time. As far as other red flags, you might ask about how those tests get run. Is it all part of an automated, continuous integration kind of thing where they have a system that reproduces tests and builds the product for them? Or is it by hand, just sort of on the fly from their laptop?

Carol: Okay, or you can do what I do. Just ask what tools they use and madly Google them afterward to see if they’re actually legit. (Laughing)

Jay: (Laughing) That’s also a good idea, yeah!

Carol: Alright Jay, before we close – just one question I have to ask. Can you share a nightmare, or a war story from where you should have had a test, but maybe you didn’t test, and things didn’t go so well?

Jay: So one of the hard things is [deciding] how much to test. So we had an app we built one time where people made a list of stuff and could share the list with their friends. And their friends could pin those lists so they could come back to them later. And we had an issue where if a user pinned somebody’s list and they came back and unpinned or deleted that pin  later, there was a database mistake and it would cascade that deletion. It would actually delete the list, which was obviously super bad.

Carol: Yes!

Jay: We had tests to check if the list would go away if the [author deleted his own pin]. But we were not checking for those sort of secondary effects. So, that was a surprise and not good. But you know, the first thing we did was go back and add the test for it. So that’s an interesting way you can use testing to do bug fixes. If you get a bug, you can write a test that illustrates that bug. Then you go fix the bug and that test turns green, which means it passes. That’s a safety check in the future so when you make more changes down the line, you don’t reintroduce that bug back.

Carol: That also could be a good interview question for an entrepreneur who is hiring a developer. You could ask them, if you get bugs, what do you do? Ask about their process with bugs and if they’re writing tests.

Jay: Absolutely.

Carol: Jay, thank you so much for your wisdom on testing. I know you have helped us a lot at Oak City Labs with that, and we’re very thankful for that. If anyone has any questions or would like to hear more about testing or any other topic, just feel free to leave a comment, like this video, follow us on social media or go to our website www.oakcity.io. Thank you!

Contact the Oak City Labs team to discuss your app idea!

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text]

When you set out to build your next custom software project, be it a web app, mobile app or API, cost is and always should be a concern. Custom software projects are almost always accompanied by a substantial amount of development hours to bring them to life, the cost of which can be a hard pill for cash sensitive startups, entrepreneurs and organizations to swallow. So you’ll likely find yourselves faced with the question: do I hire local or outsource overseas?

Today, we’ll be discussing the details of overseas development and why a local software team can often save you in the long run.

Communication, Communication, Communication

In our experience, a project’s success often hinges on successful communication between the client and the development team.

Yes, practical details such as time zones and modes of communication are important (Can you pick up the phone and call the development team? What about a face-to-face meeting? Will your questions be answered in an acceptable amount of time?), but beyond the nuts-and-bolts, it’s important to place value on the ability for your development team to truly understand your project. Do they understand what you are asking to be built? Does the team understand your overall strategy for the app? Are they able to push back and offer alternative solutions or advice during technical challenges?

Building a custom app is rarely a cut-and-dry project and quality communication as your big idea is being brought to life can make all the difference.

Total Cost, not Hourly Rate

It almost goes without saying but is still important to mention here that when considering the dollars and cents of the development team you hire, think about what the total cost will be, not the hourly rate.

An hourly rate of $150+ for an experienced local developer may seem like a lot when compared to an overseas developer charging one-third of that (or even less), but take the time to consider the value that can be provided during that hour. An experienced local developer may work more efficiently and avoid many more pitfalls than a potentially inexperienced overseas developer. In the end, you may find yourself coming out even or ahead by staying local.

Quality of Work

Building a web app or mobile app is no easy task. Besides the strategy of the app itself, you’re also juggling marketing, revenue models, operations and more. The last thing you want to worry about is the quality of the work you’re paying for.

At Oak City Labs we know the value of quality assurance, continuous integration and automation, which shows in our final product. Whether you’re working with a team based locally or overseas, it’s incredibly important that you feel confident in the quality of the work being produced. When your app has its public launch in the app store and you see hundreds and thousands of downloads that first day, you won’t want to find out at that time that the quality is far less than you expected.

As you are evaluating the quality of any software team (local or offshore), consider the following questions:

  • How often is the software team going to provide beta releases so you can review and test? How soon during the development phase will you see these?
  • Who on the development team will you be talking to during the project? Will you be able to speak with the developer working on your project? Does the team provide regular status updates or weekly reports reviewing progress?
  • Will you have access to the code base (even if you aren’t technical) should your relationship go awry?
  • What is the software team’s experience with the release process? Have they successfully released projects to the App Store, Google Play Store, etc.? Do they have a tried and true method they follow for QA, bug fixes and releases?
  • What is their philosophy on building products from scratch vs. using existing third party libraries?

If you’re looking to get started on developing your custom app idea and need help navigating the pros and cons of working with a software team locally vs. overseas, we’d love nothing more than to chat with you further!

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

If you’ve ever found yourself seriously thinking about building a mobile app, but have no idea where to even begin, this post is for you! In a world where it seems like everyone has an app idea, the truth of the matter is that there is plenty of room for innovation and new ideas in the marketplace. But to take your idea and make it a reality, you’ll need to keep the following in mind.

First: Market Research

At Oak City Labs, we’re passionate about market research and strongly believe that it is the key to your success. Before writing the first line of code, it’s important to make sure that your idea is fully thought through. And while market research is definitely the most strategic route to take when your app is still just an idea, it’s also the route that can end up saving you money in the long run.

To take that first step in getting your app idea off the ground, begin by doing some free research. That’s right: FREE! Using everyone’s trusty friend Google, you can find information showing you what your app idea’s total addressable market (TAM) could be. Along the way, you’ll find competitors and possible features. You’ll also start to refine what your app idea is and what makes it unique. We also encourage those in this stage of the process to talk to people and conduct Voice of the Customer surveys and, ultimately, create a value proposition statement. The goal with all of these steps? To help you refine your app idea, discover what makes your idea unique and set you up for success as you begin the process of building the app.

Next: Partner

After doing your fair share of research and being confident in your decision to move forward with building your app, it’s time to find a partner that can help bring your idea to life. When looking for a development company, we encourage you to prioritize the following:

  1. Reputation: How experienced is the development team? How many apps or custom software projects have they led or developed before? What do their clients have to say about them?
  2. Relationship: How are they planning to communicate with you throughout the project? Will there be weekly check-in calls? Will they help you flesh out your idea strategically, advise of feature prioritization, consult with you on growth strategies and more?
  3. Results: Are they going to be able to solve your problem? Is this partner able to help you achieve the results you’re looking for?

We created Oak City Labs to answer a lot of these questions – to give you the missing pieces to transform your app idea into a real, quality product that makes a difference. Our team has spent decades in diverse roles across multiple leading tech companies. From this experience, we understand how to deliver on all facets of the app creation process – from the technical considerations, to project management, to product-market-fit, and all the important questions you might not think to ask. We’ve learned these lessons so you don’t have to.

We know how all of the pieces of development fit together so we bring a fully informed approach to your final product. By building strong client relationships – guiding you through every step, valuing your feedback, and collaborating on the process with you – we craft the well-designed, marketable app that you want to build.

Then: Build

Assuming you’ve properly validated your app idea and selected the best strategic partner, it’s now time to begin building your app. The process involved can include everything from wireframing and user testing, to visual and interaction design depending on your specific needs.

At Oak City Labs we make sure to have a full feature list in place before beginning development. Then we prioritize the feature list to ensure that the most important things are built first. If budget or time becomes an issue, we always want to ensure that your high priority needs were taken care of in the beginning.

As development proceeds you should expect lots of testing through frequent beta builds provisioned by the development company to your device. And you should expect lots of testing on their end too.

Don’t Forget: Marketing

It would be easy to wrap up this post with the next step and call it a day. But the truth is that successful apps won’t take off and have a hope of succeeding if there isn’t a marketing plan in place. While your app is in development (and, quite honestly, long beyond that), you should be working on and executing your marketing plan. From a website to social media, and even press kits, your marketing plan can make or break your app’s chances for success.

Finally: Launch (& Rinse and Repeat)

It’s the finish line! Well, sort of. At the completion of the build and testing phase of the project, it will be time to launch your app and we’ve created a whole checklist to make this process successful here, here and here.

Once that first release hits the store, you should celebrate! What an accomplishment! But keep in mind that it’s really just the beginning. Following the launch, your app will need to be nurtured on an ongoing basis if you hope to grow your audience (and therefore your business!). You’ll need to address bugs, add new features, adapt to new technology challenges and much more.

As with any business idea, there’s a lot that goes into going from an idea to a bona fide product. At Oak City Labs, we love helping entrepreneurs make their ideas a reality. If you have an idea and think we’d be a good partner for you, we’d love to chat!

As a web and mobile app development shop, we love to talk about technology choices. Many people don’t really care what technology solution is used to solve a problem as long as the problem itself gets solved. And that’s OK in the “Wild West” days of a startup. However, as a business matures, sometimes the technology choice will hinder you during the growth phases. When a business reaches a certain scale, they will often end up rewriting the entire application. It’s not always avoidable but we like to try our best to manage the risk of a full rewrite later on.

At Oak City Labs, we approach technology choices with what we like to call a “sniff test.” It’s called a sniff test because it’s brief and not all encompassing. It’s also not meant to delve into great detail since we aim to make timely decisions looking at trends. This sniff test is very much business oriented, which really ought to be the driver behind most of your choices. It’s also why we don’t recommend cross-platform development and why we don’t throw the latest Javascript framework into production heavy work. That’s a whole other discussion which should be aided by beer, wine or your calming beverage of choice (Mt. Dew counts!).

Sniff Test Quiz

1. How long has the language or technology been around?
We’re not looking for the most mature, but we like to see longevity for projects and languages. This tends to influence answers for the rest of our quiz.

2. Is there widely available support, including forums or consultants?
This is very related to #1. Is a fix at 2:00 am in the morning just a Google or Stack Overflow search away?

3. For open source projects, how active is the community?
When was the last commit? How often are releases? How many contributors?

4. Is there support from scalable cloud services like AWS and Google Cloud?

5. Can we easily and readily hire a developer with little ramp up time?

6. Is the project or language trending up or down?
Not always a perfect measure but can be telling. Google Trends and Stack Overflow can help with this analysis. Again not perfect but it’s what we’ve got without in depth technical analysis. Here’s an example over the last five years between three prominent languages.

7. Was the project or technology bought or started by a large company?
This can be a good thing but we tend to shy away from backend service providers that might get shut down as Facebook did with Parse. Our preference is to build an app so the full stack is modular and not reliant on a single provider.

Ultimately we want to make choices that will provide long term growth and scalability for our clients. For example, while PHP may be a great choice for some niches it might be tough to hire in your local area for a PHP developer or it could even be on the decline in usage. And sometimes we’ll use a technology for a small part of an app but not for the whole application. For example, a database like MongoDB might be good for caching trivial data but we wouldn’t use it for mission critical features of an application.

We also like to choose technologies that fit business cases. Let’s say a company is in the life science market and will be performing data analysis. We would likely recommend Python because it’s somewhat mature and has all the science and math support needed for detailed analysis. It’s also widely used by the scientific and research community. If you’re in the Fintech space, you might choose Microsoft products because of the enterprise level support and prevalence of .NET developers already in finance.

The sniff test still remains the same when considering long term viability of the technology stack regardless of the market or software application. It doesn’t mean all of your choices, or ours, will be correct up front, but it does mean you can help manage the risk. If you’re thinking about an idea for a web or mobile app, contact us today and we can discuss performing a sniff test (and more!) for you.

NinePatch drawables in Android offer a way to create resizable bitmaps that only stretch the sections of the image that you specify. This is useful for creating backgrounds for TextViews, Buttons and any view whose size may vary depending on the content, as well as when creating splash screens that have a logo whose aspect ratio you don’t want to be distorted.

NinePatch drawables consist of the original image surrounded by a one pixel border of empty pixels by default. The top and left side one pixel border is used to specify (with black pixels) what vertical and horizontal slices of the image can be stretched to make the image to fit its container (instead of simply stretching the image and changing its aspect ratio). This way areas of the image with content you do not want to be stretched can remain at their original aspect ratio. The bottom and right side one pixel border is filled in with black pixels to specify the area of the image that any content that sits on top of the image should reside in (essentially, the padding for the view that this image will serve as the background for).

The following is an example of a NinePatch image:

The black sections of the top and left one pixel border are circled in red. The logo in the center will maintain its aspect ratio while the vertical slats designated by the top one pixel border will be stretched horizontally and the horizontal slats designated by the left one pixel border will be stretched vertically. When two or more stretchable slats are specified for a dimension as above they will maintain their size relative to each other when stretched (so the logo will stay centered).

It is important to note that if you don’t want to specify the content area (the padding) and would like content to fill the entire image, you should fill the right and bottom side 1 pixel border with black pixels as in the example above. If the content area is not specified (the bottom and right sides consist of only empty pixels), the content area will default to the area designated by the top and left side one pixel border.

Android Studio has a tool to generate and edit NinePatch drawables. To access it, right-click on your image file in the Android Studio file browser and find the “Create 9-patch file…” option. You’ll want to give the new 9-patch file a unique name so it doesn’t conflict with the existing image resource (or just delete the original). Now find the newly created NinePatch image (it will have “.9” prepended to the file extension, i.e. your_image.png becomes your_image.9.png) and open it. A full tutorial for the Android Studio NinePatch editor can be found here.

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 2: Snap a super artsy picture of your keyboard and wrist rest

Step 3: Send it to your friends (Some names below may or may not be based on the many nicknames of Burton Guster)

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.

Technical Breakdown:

  • Mobile Developer:

    • 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
  • Backend Developer:

    • 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

Non-Technical Breakdown:

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.

Technical Breakdown:

  • Mobile Developer:

    • 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
  • Backend Developer:

    • 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

Non-Technical Breakdown:

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:

Non-Technical Analogies:

  • 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.

Technical Analogies:

  • 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.

Subscribe for the latest updates

Where problems get solved.

© 2020 Oak City Labs | A Well Refined Website