10: Explaining Common Mobile App Terms

Mobile app developers throw around a lot of jargon and buzzwords, but you don't need to fear them! In this episode, Tim and Rob explain several common acronyms and terms you'll hear when working with a development team.

In this episode, you will learn:

• The difference between the backend and the frontend of your app
• How an API lets you add third party services into your app
• When applied properly, a SaaS revenue model can be a great way to make money
• Why Rob is the real MVP

This episode is brought to you by The Jed Mahonis Group, who builds mobile software solutions for the on-demand economy. Learn more at http://jmg.mn.

Recorded March 15, 2018 | Edited by Jordan Daoust

Show Notes

• Mobile App Development Glossary - The Jed Mahonis Group Blog

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables a podcast where we take a non technical look at mobile app development. I'm Tim Bornholdt.

Rob Bentley 0:05
And I'm Rob Bentley. Let's get nerdy.

Tim Bornholdt 0:23
Alright, Rob, what are we talking about today?

Rob Bentley 0:25
We're gonna go over a list of terms that are common to developers, but maybe not so common to people who aren't developers.

Tim Bornholdt 0:31
Yeah, I think sometimes we, in any industry, there's a lot of jargon and terms that get thrown around and we really pride ourselves in our job being to demystify mobile app development and make it so it's not so unapproachable and scary. So part of that, as part of this podcast is we want to actually show you or just explain these common terms, so you don't seem confused or feel foolish or anything talking to a developer.

Rob Bentley 0:58
So the big one we're going to start talking about is API, you'll probably hear about this in almost every project we build.

Tim Bornholdt 1:04
Yeah, so an API is essentially a way for a server or wherever your data is being stored to communicate with your app. So it's basically the server says, You give me requests this way. And I'll give you a response that way. And you know, Facebook has an API, Twitter has an API. Every place if you want to plug into a third party system, you'll do so through an API.

Rob Bentley 1:28
Exactly. It's a way for a phone to communicate with a server or your computer or anything to get the actual data.

Tim Bornholdt 1:34
Did we even say what an API was?

Rob Bentley 1:37
You mean, like what the acronym stands for? Application Programming Interface.

Tim Bornholdt 1:40
Yeah, just in case you really needed to know. But everyone will just call it an API. Now, you know. These are in more or less alphabetical order. But we also clumped together some terms. So the next term we have here is the back end, which then obviously leads to the front end. But Rob, why don't you start with what's the back end.

Rob Bentley 1:59
The back end is where your data actually lives. And we'll refer to this as the server, sometimes interchangeably, or the database. But that's all on the backend. It's parts of your application that users generally aren't going to see. And you might not even see, but we have to deal with it.

Tim Bornholdt 2:14
Yeah. Which then conversely, the front end would be everything that your user does see. So that's typically everything that you see on the actual mobile app that your user downloads from the App Store.

Rob Bentley 2:24
So you can think of the backend as like the data in the database and the front end as the user interface. And then the API connects the two.

Tim Bornholdt 2:31
Exactly. Next, we have three terms that kind of all relate together. So we have beta, APK, and test flight. So when you go into beta, all that means is it's a designator for what level your software is at. So beta would be it's not quite production ready, but we want to send out a build to show you so that you can see where your app is at currently.

Rob Bentley 2:52
Yeah, all these words are basically methods or like terms we'll use about distributing your app to you before it's live in the App Store or the Play Store.

Tim Bornholdt 3:02
Right. So an APK is the file that we'll send you for Android. And testflight is the app that we can't really send you a file directly to your phone. So you have to download test flight, which acts as an intermediary for your iOS devices. So then we can send you builds for your iPhone and iPad.

Rob Bentley 3:19
So when you're testing builds of Android, we send, you're gonna hear either beta or an APK, like, Oh, I'll just send you an APK. Or you sign up for the beta program. For iOS, you run apps that you're going to test through testflight. That's how you install them on your phone.

Tim Bornholdt 3:34
And with build too, all that means is it's just a version of the app as it exists now. So we write all the code out, which kind of looks like English, but we write it all out in, you know, Objective C, or Swift or Java or whatever. And then we compile it. And that's what a build would be. So it compiles it into actual ones and zeros that the phone can run, you know, directly interfacing with the memory and things on your phone. So that's all a build is.

Rob Bentley 3:59
And kind of related to back end as the CMS.

Tim Bornholdt 4:02
Yeah, so a CMS is content management system. So this is the infrastructure that you use to change things in your app without needing to send new builds to the App Store. So you can say, if you have a CMS for a blog, that would be where you would go to post new blogs and set the title, put the content in there, add some pictures, whatever. And then when you've added it there, and you hit publish, then it appears on your app or your website.

Rob Bentley 4:27
Or you can use it to edit an existing blog or delete one or any of those actions. That's what you do on your content management system.

Tim Bornholdt 4:34
Yeah. Next, we have corner and edge cases.

Rob Bentley 4:38
So after we distribute the builds to you through beta, APK, or testflight, then you're going to start finding things that are wrong with the app. We actually call these bugs. But sometimes bugs are harder to reproduce than others. And then we call these corner cases or edge cases and Tim will explain the difference between the two.

Tim Bornholdt 4:59
Yeah. So a corner case is a situation that you put yourself in as the user where you weren't really, we weren't expecting that as programmers. So let's say that you have an app that does a random workout generator. And you go in and you push one button to generate a random workout, or you set the parameters to generate the workout one way or the other. But you end up setting something that we didn't expect. That would be a corner case. I don't know if you have a better example of a corner case. That was kind of an odd example.

Rob Bentley 5:31
Maybe you haven't set things up to accept special characters, and someone tries to do a username with just a bunch of apostrophes and at symbols, or something like that.

Tim Bornholdt 5:41
Right. That's a good one. Yeah. So like, most people are going to use the standard US keyboard or whatever, to input things. But yeah, what if you have a user that's using an Arabic keyboard, or German keyboard with whom eyelets or whatever?

Rob Bentley 5:52
Or Chinese where you actually draw the symbols in and then can your application handle that?

Tim Bornholdt 5:56
Yeah. So that's a really great example of a corner case. An edge case, conversely, is where you are pushing the app to its absolute limits to the edge. So this would be let's say, you have an RSS reader, like you have a news article reader. And generally you have, you know, 100 or 200 articles that you might have on read that is pretty typical use. But let's say you're a power user, you are some kind of journalist and you have hundreds and 1000s of feeds. And now you have a million unread articles in your RSS feed. Well, the point of an edge cases, you could say, Okay, we would expect the edge of a reasonable user to have a million things in their database. So then you would go through and test out the app with a million in there. And the thought being that if you've tested it with a million examples in your database, then it should work just fine for 100, or for 100,000 or 500,000. Basically, anywhere from your zero to a million, you can assume that if it works well, with a million, it works well with everything.

Rob Bentley 6:54
Yep, exactly. We'll talk about now, hybrid versus native app development. And what we do at The Jed Mahonis Group is native app development. But there's also another way you can do it, which is hybrid. Basically, the difference between the two is, when you're writing native apps, you write one code base for each platform. So iOS has its own code. Android has its own code. What hybrid allows you to do is write one code base that would work on both platforms. And it sounds like a better idea right away. But it isn't always.

Tim Bornholdt 7:25
Yeah, there's a lot of weird things that happen when you try to write what we would call write once run everywhere. The biggest thing is that an Android experience, what a user is expecting on Android is not the same as what an iOS user is expecting. So there's usually issues there. Second is you are introducing another layer between what's like native on the phone and the code, which what that means is it can make things slower or quirky. Or if iOS issues the next version of iOS, iOS 12 in this case, and there's a new feature in there, you have to wait for whoever wrote the hybrid app library to support these new features. So there's always just weirdness that happens when you write hybrid apps. And sometimes users can tell; sometimes they can't. But even if they couldn't explicitly say what's wrong with an app, you can usually tell something's a little different about the experience you're using with a hybrid app versus a native app.

Rob Bentley 8:23
You can get away with a hybrid app, if you're doing very simple applications, that pretty much only display data. But once you start getting into things where you use like phone hardware, like the camera or accelerometer, then things can kind of start to go wonky, because the experience is just way different between the two in how you program it.

Tim Bornholdt 8:41
So that's why we prefer native because you just have the highest possible user experience, which we'll get into that terminology a little bit later. But next up on our list is the IoT.

Rob Bentley 8:52
The Internet of Things.

Tim Bornholdt 8:53
That's right. So IoT is essentially a definite, it's a term that's used to describe making dumb hardware smart. So thinking of like appliances is the obvious one. So making your refrigerator smart, and making your toaster smart, you know, all those components that can basically now speak to the internet and do things on your behalf or automatically or something that you can configure. This is what we would call the the internet of things.

Rob Bentley 9:23
So you can basically program yourself simple like chain of experiences, I guess where you hook your alarm up to then tell your coffeemaker to turn on and tell the lights in your kitchen to turn on and things like that, make your toaster start going so as soon as you arrive in the kitchen, you're toast and coffee is ready.

Tim Bornholdt 9:41
It's one of those things where people are like, Why would I want my toaster to be hooked up to the internet? And at first, yeah, it does seem ridiculous.

Rob Bentley 9:48
So it can spy on you.

Tim Bornholdt 9:51
Just like the lady in the cylinder that Amazon sells. Yeah, that'd be part of the internet of things as well. Next up on our list is MVP, which in Rob's case is the most valuable player, right?

Rob Bentley 10:05
Yes.

Tim Bornholdt 10:06
But in this case, we're talking about minimum viable product.

Rob Bentley 10:10
What this is, is you come up with an app idea. And as you're coming up with your idea, you start thinking of all these things your app could be. What we try to do is get your idea down to an MVP when we're doing an initial build out, because it's takes time and money to build apps. And so what we try to strive for is what's the one feature that your app needs to do and do it really well. And then we call that the MVP.

Tim Bornholdt 10:32
And it's about getting something into market fast, so that you can iterate and find what actually is going to make you money quicker. Because the way software used to be built was they call it the waterfall approach where a bunch of people sit in a room and write out a giant spec doc of, Here's every feature the app needs to have. And then you quote out, it's going to be $150,000. And then you sit through and you go out for eight months, and you build this thing, and you come back and say, This is great. And you deliver it to the world. And they're like either, A, we didn't want any of this, which is the worst case, or B, we only wanted one component of this giant thing. That's all we really care about. So in this case, MVP is just, it's a methodology for developing apps that helps you hone your idea to the point where you're going to get it out the door as fast as possible and start making money, which is obviously the key to the success in this space.

Rob Bentley 11:24
Exactly. You wait for user feedback to kind of determine what your next features are. And you keep throwing them in one at a time instead of waiting long periods of time.

Tim Bornholdt 11:33
And one really good example that we always throw out with MVP is, when you're thinking about a vehicle to transport you from point A to point B, you might have a car in mind at the very end of it. But you might start with a skateboard. And then you might put a handle on it and turn it into a scooter. And then you might put an engine on it and turn it into a moped. And then you might put an even bigger engine on it and turn into a motorcycle. And it's iterative movements that are pushing you towards that ultimate goal of having a car. But you don't necessarily have to drop all the money on a car right away. You can get from A to B with a skateboard just fine.

Next up on our list is OS.

Rob Bentley 12:08
This we'll often ask you while we're doing our testing, because especially on Android, there's a lot of different operating systems and devices. And that's what OS means is operating system. So we'll have to ask you what your OS is.

Tim Bornholdt 12:22
Yeah. And you can find this going into your settings In About, on every device that will tell you. But the operating system, what that does is it actually takes, it acts as the layer between the software that's running on your phone, and the actual hardware components, like your processor and your hard drive and the battery and all those things. Everything goes through the operating system in order to go to the actual physical hardware. So at a nutshell, that's what the operating system is. But for you, what we care about is, are you testing this on a super old version of Android? Or just what version of Android are you using? Or are you able to run iOS 11? Or is your phone are you running on an iPhone 4s, so we can't do it? There's different OSs give you different quirks while you're developing. So having that base level of environment to know what you're using helps us to debug issues more quickly.

Rob Bentley 13:12
Yeah, there's usually major releases on the OS for Android and iOS once a year. And the new ones allow different things, then you can still do a lot of things on any OS, but there are some where it might be too old for a certain feature you want or things like that.

Tim Bornholdt 13:28
And OS is, on the Apple side especially, they tend to support devices for a long time. Whereas Android, they pretty much want you to just buy a new phone. You know, that's the whole point of making money on Android. So you might just be stuck with what OS came with your phone. But regardless, for us to be able to do our jobs, and for you to be able to get your bug fixed, that's a very important piece of information that we would need to know in order to solve your problem.

Rob Bentley 13:56
Speaking of testing apps, we're going to talk about production and staging now.

Tim Bornholdt 14:00
Yeah, so these are both terms that we use with regards to the back end. Your production environment is the live environment. It's the system by which if you were to visit the JedMahonisGroup.com, that's what you would see as our production server. There, the difference would be for staging, you don't want to fix bugs or test out new things while you're in production, because you might introduce a bug and crash all your users data, and so on and so forth. So what we do is we set up a second environment called the staging environment. And this is as close to the production environment that we can get. But instead of using live user data, we have test data inside the app. So let's say your pushed. The app is live and people are using your app now. When we make a bug fix we'll first push it into staging and say, Can you test it out in staging to make sure that it works well? If it does, then we deploy it out to production. So like Rob said, this is a term that we use mostly for testing is, check it out in staging, and then we'll push it into production.

Rob Bentley 15:05
It's a safe area for us to play around and make bug fixes and add new features, making sure we don't harm any of the actual data.

Tim Bornholdt 15:13
Alright, next up along that same lines is QA.

Rob Bentley 15:17
QA, it means quality assurance, but it's our general term for testing. Whenever we build a new feature or fix a bug, we then test it, and we have you test it. And that's called QA in a nutshell. I mean, it's more in depth than that. But I think that covers it.

Tim Bornholdt 15:35
Well, yeah, there's a few different types of QA that we do. There's automated testing, manual testing, regression testing. There's all sorts of things we can go into. But in a nutshell, QA is what makes sure that when we push an app live to the App Store, that if there are bugs in there, at that point, we at least know about them. And we think they're small enough that it's fine. But for the most part, we do QA before we push any software to your users so that they don't have a bunch of crashes.

Rob Bentley 16:01
Yeah, just basically how we make sure that what we did works. And then this is a little bit different, I guess. But this has to do more with like interfaces. It's called responsive web design.

Tim Bornholdt 16:12
So yeah, when we were talking about native versus hybrid apps, sometimes a hybrid app might qualify in this case, where it's just basically a native app that shows a website. And you can do that through responsive web design. So back in the day, when I was first making websites, everyone had a monitor that was 1024 by 768, like that was your monitor size, everyone knew it. So you made your websites accordingly. Nowadays, there's, you can get every single possible way that a website can look, it can be on a laptop, where it's long and tall. Or you can get it on a phone where it's super skinny, but very tall. Or you can get on a tablet where it's almost like a square, it's more rectangular. But you know, there's different ways that a website can look. So responsive web design is a principle where you design a website not to be a certain length, or width, or whatever. It's designed so that it responds to whatever screen parameters are thrown at it, whether it's a phone or a TV or everything in between.

Rob Bentley 17:12
And you can tell if a website is responsive or not with a simple test. If you load it up on the browser on your computer, and then just drag your window from left to right to make it smaller, the width smaller, all the views on there should kind of move around while you do that. And if it doesn't, if it just stays there, then it's not responsive design.

Tim Bornholdt 17:31
Yep. But pretty much everything you'll see these days is responsive. It'd be pretty foolish not to.

Rob Bentley 17:37
Next we have SaaS, which is software as a service.

Tim Bornholdt 17:41
Nice. Yes, I love SaaS.

Rob Bentley 17:43
You'll see this written as two big S's and two little A's crammed inside the Ss.

Tim Bornholdt 17:49
And SaaS is essentially a way for you to make money. And it's one of the most popular ways. So back in the day, if you wanted to get Photoshop, you'd have to get in your car, you'd drive down to BestBuy, you'd walk through the CD ROM section and you'd buy a CD. And that's how you'd get the software is you'd buy it. It'd be all pre compiled, everything would be good to go. Well, nowadays, that's not really how it works. You go on the internet, and you download something. Well, people also expect your software to be updated regularly. So what SaaS tools do is it's basically, usually they're websites, but they can be anything. And it's basically a way that you can offer continual upgrades to users for a subscription price. So you can say, Hey, subscribe to, like, and we always go back to our friends at Kwikly, If you are a dental office, you can subscribe to their system and either for a month fee or as you use it, you would be getting the ability to request dentist hygenists. But with a SaaS tool, it's constantly evolving whether or not you know it. And that's kind of the beauty of SAS tools.

Rob Bentley 18:55
Yeah, you pay monthly, but you keep getting a better and better product as time goes on.

Tim Bornholdt 18:59
Exactly. Next up, we have SSL certificates.

Rob Bentley 19:03
Secure socket layer. I just learned this one. I mean, I knew what SSL was, like I'd just never heard it like,

Tim Bornholdt 19:13
just what the acronym was.

Rob Bentley 19:14
Yeah, I only have heard it referred to as the acronym.

Tim Bornholdt 19:17
It, you know, a lot of these, it's like, we never really say like content management system or application program interface. You only use the acronym because it just makes sense. But yeah, the SSL certificate is a way for traffic to be encrypted from your device, all the way to your server. So what this is, is instead of like, it basically enables like credit cards and any data that you don't want other people to snoop. That's what SSL does is it encrypts all that data from you to wherever your destination is, and then once it gets there, then they can read it.

Rob Bentley 19:52
This is a basic layer of security for your server and website and apps.

Tim Bornholdt 19:55
Yeah, and you know, even five years ago, this wasn't standard per se. But now, thanks to Apple has required all apps to communicate over SSL and it just makes sense, especially in the days of post Equifax leak and everything like that. It's free, you can go to a website called Let's Encrypt, and they'll give you an SSL certificate for free. So why not encrypt your stuff? Even if you don't have private data, at this point in the game, every app you make should have an SSL certificate associated with it.

Rob Bentley 20:29
Next, we have UI. And then also GUI, which is GUI, user interface or a graphical user interface. And then UX, we'll talk about all it all of it, because they're very closely related, but a little bit different.

Tim Bornholdt 20:45
Yeah. So a user interface is just how you interface with an app. It's what the user actually taps or touches, or speaks to, or whatever UI is gonna be in the future. But most of the time, when you're talking about an app, it's a GUI, which is a graphical user interface. Sometimes, you know, if you're talking to the Amazon woman in a tube, or if you're talking to, you know, Siri, or whatever, that would be a vocal user interface. But that's all it is, is just a way for you to interface your users to interface with your app.

Rob Bentley 21:16
And then when we talk about UX, that means user experience. So this is not necessarily how it looks, but just how it works and how it functions. And is it easy? Is it not easy? Does it get the job done quick? Is it cumbersome, things like that.

Tim Bornholdt 21:31
So all these terms together would represent your design. And we want to make sure when an app is well designed, it not only looks pretty, which would be the UI, but it also functions properly, which would be more on the UX.

Rob Bentley 21:33
Which I guess we could have just talked about our last term in here too, which is wireframes, which is where the UI and UX start.

Tim Bornholdt 21:51
Yeah, so a wireframe is if you just picture somebody pulling out a napkin and sketching out what an app would look like, and drawing connections from screen to screen to screen. That's what a wireframe is.

Rob Bentley 22:01
It can be as basic as that, or as complicated or not complicated, but as professional as doing a design in Photoshop, or Sketch or any of those programs.

Tim Bornholdt 22:10
Right. Yeah, they can be basic or well conceived. But either way a wireframe helps to convey, it's interesting, as soon as you have the idea in your head, writing it like actually tracing your phone and making a wireframe yourself of what the app could look like. It helps right away for you to see where some lot like flaws in your logic or your thinking of what the app could look like. You can find those pretty easily just by wireframing out your own app concept.

Rob Bentley 22:37
And it also helps you start asking necessary questions before we do.

Tim Bornholdt 22:42
Yeah, like how does the screen populate with this? Or you said that this screen does this, but this other screen contradicts that. So which one should be right? Those things all get flushed out through the wireframes?

Rob Bentley 22:53
Yeah well we made it through the list.

Tim Bornholdt 22:55
Yeah, that wasn't too bad.

Rob Bentley 22:56
No.

Tim Bornholdt 22:58
So our final thoughts for today. This is a good place to start for some acronyms in our space. I mean, there's a lot of buzzwords and a lot of things that you'll hear while you're getting your app developed. And any competent, or like any person with some amount of humility, will be happy to empathy, would be happy to explain any of these terms to you if you have a good developer. Because the last thing you want to be when you're developing software is ignorant and not know like these terms. It's not like they're super complicated, but it's really helpful for you to be able to speak the same language as your programmers.

Rob Bentley 23:34
Yeah it's just one of those things where if you know it, you know it if you don't, you don't.

If you want some more detailed information on these too, we did a pretty massive blog post about this last summer, and it's really long and in depth and there's way more terms and technology related acronyms that we put in here that if you want to check it out, check out the show notes in the podcast here, and you can check it out for yourself. Yeah, you good, Rob?

Yep, I am.

Tim Bornholdt 24:01
Alright, let's wrap this thing up. Show Notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@ constantvariables.co I'm at Tim Bornholdt on Twitter. Rob is at Scott Mahonis. Today's episode was edited by the harmonious Jordan Daoust. This episode was brought to you by The Jed Mahonis Group who builds mobile software solutions for the on demand economy. Learn more at jmg.mn.