50: Implementing “Easy” Features

Some app features are seemingly easy to develop but are actually complex to implement, driving up development costs. These are features we see everyday, and therefore take for granted. Rob and Tim chat about the nuances of features like data sync, search, push notifications, in-app purchasing, messaging, and more to help you understand where to get the most value with the least amount of effort when building your product.

In this episode, you will learn:

• The nuances of syncing data online, offline, and across multiple users
• Why returning relevant results in a search feature is tricky
• The intricacies of push notifications
• Whether you really need a messaging feature within an app
• How to be a considerate steward of user data when using location tracking
• Why in-app purchase options start easy conceptually yet are hard to implement
• What to consider when integrating credit card processing within an app
• Why you want to use as few third-party API integrations as possible

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded October 26, 2020 | Edited by Jordan Daoust | Produced by Jenny Karkowski

Show Notes:

• MNCraft Beer App
• Learn more about push notifications in Episode 49
• Half Staff App
• Kindu App
• Kwikly
• Stripe
• VSI

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at all things technical. I'm Tim Bornholdt.

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

Tim Bornholdt 0:22
All right, it's our 50th episode extravaganza, Rob. We made it. Ah, yeah. And what better way to celebrate than to talk about some app features that might seem easy to develop, but are actually complex to build and can drive up your development costs.

Rob Bentley 0:39
A lot of these things as a user, you just kind of touch the thing on your screen, and it looks real easy. It can be easy to take for granted how much work actually goes into these things.

Tim Bornholdt 0:50
Exactly. So we thought it would be a good time to dispel some of those myths and cover some pretty common features these days that are actually pretty difficult to implement and give you a chance to determine whether it's the right choice for your app or not. So what do we got first, Rob?

Rob Bentley 1:05
I guess the first one I'd like to cover is data sync. If you've ever used Google Drive, which we are right now actually for our show notes, you can just type things in and the other person sees it in real time. Uou can both type on the same sentence, and it seems like it comes out right every time.

Tim Bornholdt 1:27
Yeah, it's really, really hard to keep data in sync. And what we mean by that, here's a common example we always use, for example, a to-do list app. If you were going to add items to a to-do list and check them off, if you're not both online at the same time, you have to make sure that when I change something, and you change something that they both sync up at the same time. That's actually a pretty complex problem to solve. Because humans can take a look at that, and pretty easily make a judgment call as to who's correct and who's not. But computers have to be told how to fix problems as they come up and what methods they use to do that. So that's where it takes a long time if you have a complex app that you're trying to keep in sync, there's a lot of things and a lot of variables that we have to consider. And so that's really what drives up the cost there. With data sync, I think one of those features, too, that a lot of people ask for is, can it work offline? And then when I come back online, everything is just set back to the way it was. And I mean, that's not easy. Is it, Rob?

Rob Bentley 2:30
No, it's definitely not. Because then your app will have to determine which version of this am I supposed to keep, especially if you have that coming from multiple sources.

Tim Bornholdt 2:43
Yeah, especially like the Google Doc example you had before, if we were offline and I had typed up five paragraphs, before we went offline, and then you went online and changed two of the paragraphs, and I went online and changed two of the paragraphs, and then we both went online at the exact same time. How do you solve all those conflicts? It's not an easy problem to solve. And hence, that's why it's the leading problem here today on our podcast.

Rob Bentley 3:15
Anytime that you have input for data for more than one user that they can contribute to, you're going to be running into a few headaches that you'll have to solve.

Tim Bornholdt 3:24
Yeah. And sometimes it can be easy to solve. You can make some pretty rudimentary decisions. But a lot of times people don't like those because it can lead to data loss. And we don't want to lose anybody's hard work. So those are just some of the problems that we as developers have to face when you want us to make sure that we sync up apps, when we sync up app work after it's been performed inside your app.

Rob Bentley 3:47
Yep. Another one that we can talk about is search.

Tim Bornholdt 3:51
Yeah, the dreaded search.

Rob Bentley 3:53
Just because Google has made this look so easy. You can type anything in, get all the most relevant results in under a second. You can misspell it. You can type in a sentence and it gives you usually what you want. If it doesn't, you can usually just change your search slightly and it does. It works very well. And depending on what you're searching, it's been a lot of years of work. And there's a lot of things that go into delivering the right results.

Tim Bornholdt 4:26
Yeah, and the Vikings game, for example, this is something that we were talking about. Just insider baseball, we recorded this whole episode once already. And then we lost one side of the conversation. I won't say who.

Rob Bentley 4:38
It was me.

Tim Bornholdt 4:39
But someone lost one side of their conversation. So we're redoing it. But one of the examples that we were talking about was, you can cue off your searches based off of so many different criteria, and one of them would be location. So here in Minnesota, if I type in Vikings into the search engine into Google, it's going to assume that because I'm here in Minnesota and a Vikings game just happened, that you're probably looking for information about the Minnesota Vikings football team. But if you're in Norway, for example, and you type in Vikings, you might be looking at more historical records. Or if you were in any other part of the US, maybe it'll show the Vikings but it'll try to maybe show results for the HBO series Vikings. So there's so much nuance to search that a lot of times our clients will come to us and say, We need to have search in our app. And it's like, Okay, cool. Yeah, we do need to be able to search things. But how do we determine what we're searching, and that can be a very complex problem to solve and make sure that we actually return back the right information in the right context to what you're looking for.

Rob Bentley 5:48
And sometimes it can be relatively easy if it's a small data set and the parameters of the search are really simple. So like the Craft Beer app that we made, we have a list of breweries that are just in Minnesota, and we have a search bar in there, and it can search by the brewery name or by the city it's located in. And that was not a super difficult challenge to do. But once you start getting larger datasets, bigger apps, more possibilities of what people want it to be, that's where it can get just really confusing as to how to make it return relevant results.

Tim Bornholdt 6:22
Yeah, it's never a challenge to return results. The challenge is when somebody's searching for something, and you just present them with a box and a cursor to type in, it's returning relevant results. That's the challenge. If what you're searching requires a lot of specific context, then it's going to require a lot of work on our end, so that we can return the right results quickly, too, because nobody likes to sit and wait for a long time while we comb through all this data. We've got to find ways to make it snappy and return the data quickly. So searches is just, again, one of those fun features that it's easy on the surface, and Google's made it very easy, but it's not easy to implement.

Rob Bentley 7:07
The next thing we'll talk about is push notifications. Love them or hate them, they're there, and they're necessary for a lot of apps to work. Some are not necessary. But we've covered that in other episodes.

Tim Bornholdt 7:21
Yeah, there's so much nuance to push notifications too because just like search, how we were talking about context is everything when it comes to returning the right search results, context is everything when it comes to sending push notifications. And again, just like with search, it can be easy to send a push notification. One of our apps that we built early on, the Half Staff app, it sends a push notification the night before a flag is supposed to be set to half mast. And when we built it, I basically just send out a notification at 8pm Central Standard Time to everybody. But you know, an app like that, you could easily configure it so that, you know, some people might want to receive notifications the morning of or maybe they want to receive two days beforehand, so they can prepare something. When you get more custom with when push notifications get delivered, then that can also lead to more complexity, obviously, to build it out and test it and make sure that it's working correctly for everybody.

Rob Bentley 8:23
And then the timeliness, again, not just when it's delivered, but the timeliness of the data. So we have push notifications in one of our apps Kwikly, which it sends out job listings to potential candidates that might want to take the work. When you send out that push notification, one person will click into it, find the detail screen for that job and take the job. But then the 20 other people who click into there, once the job has been taken, what happens then? And so you have to think about all these little things when you route to different screens to make sure errors pop up appropriately because the data might be old at the point that they get to it.

Tim Bornholdt 9:01
Right. So yeah, you have not only displaying the push notification and sending it at the right time, but like Rob just said, making sure that it actually gets taken away when the data is no longer relevant. That's like a whole nother can of worms. You can also really push that and make it more complex, you know, with something like a pizza delivery app. Maybe you want to have your marketing team segment down and only send push notifications to anyone who's ordered pizza in the last 90 days or cross referencing other lists to say, send out notifications to people that created an account but haven't ordered pizza from this specific location. There's so many ways you can slice and dice the data and send it to specific people. And again, it seems like, Oh yeah, just send a push notification to the people that haven't had pizza in the last 30 days. But it's not easy.

Rob Bentley 9:54
Also another consideration that you'd want to do if your app has quite a few different kinds of push notifications is giving the user the control over which ones they want to receive and which ones they don't. Like Facebook, for example, I don't care if someone liked a comment that I post on someone else's post or something like that, in fact, I have all of them off.

Tim Bornholdt 10:16
Right. Because who wants notifications from Facebook? Seriously. But you know, there are times, like LinkedIn for example, I might want to turn on my direct messages. But I certainly don't want to receive like, Five people have posted status updates to LinkedIn. It's like, I don't care. I'll see that when I see it. But yeah, making those customizations and those different controls, it might seem easy. But again, it's not.

Rob Bentley 10:44
Also any apps that either are centered around or have a feature that is about chatting with someone or live messaging, those can be quite challenging.

Tim Bornholdt 10:56
In what way?

Rob Bentley 10:56
Keeping the right amount of data on the screen, so that you can still scroll up and see historical things that people chatted but also making it appear right where the newest messages are coming in without overloading the system. And also making sure you can do all the fun things like posting gifs and videos and all of that stuff that people expect to have in a chatting system.

Tim Bornholdt 11:21
Yeah. And it's funny because a lot of people, they have this whole other idea for a whole different platform. And then on top of it, it's, Oh, yeah, inside the app, they should just chat with each other. And it's thinking about, is somebody going to want to use your app to actually communicate with other people? Because we already have so many inboxes across so many different services. Do we really need to add in another service at another place for people to be like, Where did I have that conversation with that person? Was it in Signal? Was it in Facebook Messenger? Was it a text? Was it an email? And having to have that mental load of trying to figure out where it is, it's just like, yeah. I mean, we're talking about features that are easy to conceptualize, but hard to implement, but I mean, that's just messaging in general. That's always my question. When someone's like, We need to have messaging in the app. It's like, do you? Do you really need messaging in the app?

Rob Bentley 12:13
Yeah, think about it carefully. A feature, though, that I do find really useful most of the time when an app has this is location tracking, such as when you get a delivery, and you can see the driver on their way, or you're waiting for an Uber or just something like that.

Tim Bornholdt 12:29
Yeah. And location tracking, it's easy enough to get the latitude and longitude point from the system, but there's so many things. I mean, the biggest thing with location services, I guess, is battery usage, right? When you have someone's GPS radio turned on, that sucks up so much battery. And so you need to be a considerate steward of the user's device to make sure that you're only turning it on when you need it and not at the highest accuracy as well. That's just one consideration when it comes to location tracking.

Rob Bentley 13:03
Yeah, it really depends on the use case. But yeah, you really want to find that sweet spot with how much power you're using on someone's phone, because everyone's using their phone for so much. And they depend on it to last through the day. So if you just suck all the battery, it's not going to lead to a good user experience. And it just takes a lot of fine tuning to get to that right spot.

Tim Bornholdt 13:24
It really does. And yeah, and I think a lot of times too, naively you might think like, Well, of course I need 100% accurate information of where they are at all times. But you know, you probably don't. A lot of times, a lot of apps, you only really need to know, are you in this time zone? And if you really need to be that accurate, then you can just barely turn it on and off. But then other apps do need to know like, Yeah, I was on this exact intersection at this corner at this time of the day. And so yeah, it's a balancing act for the battery for the most part with location tracking. But the other thing to consider with location tracking is you have to build up some robust privacy in it as well. Because as much as you want to be able to see all this information, you've got to make sure you're not storing it forever and doing things that could be considered pretty sketchy with your users' personal information.

Rob Bentley 14:16
Especially if people sort of expect it to work in the background as well. Kind of like, Oh, I want my phone to let me know when I get into this building, so I can open the door, do something. You know, it always has to be looking for, are you there? Are you there? Are you there? And doing that kind of stuff too can be difficult to manage, a, because you're not hands on using the app, but also just because the phone's in the background and it needs to stay on to keep looking for what it's looking for.

Tim Bornholdt 14:46
Yeah, then the next big feature that's easy to conceptualize at least but hard to implement is anything around payments, but we kind of have two different types of payments to cover, both in-app purchases and credit card payments.

Rob Bentley 15:00
Yeah, I guess we can start with in-app purchases. This again, it seems easy when you're just clicking a button that says buy and you enter in your Apple ID password or use face ID to authenticate it, and then it just goes through. But the way you go about doing this in code is not very straightforward. And there's lots of errors that can happen that are sometimes really difficult to track down as to what it is. Apple and Google have made it relatively okay to implement this, but it's still not just a simple, Oh, yeah, just throw it in there sort of thing.

Tim Bornholdt 15:33
When it's another one like search that it can scale up. It can start conceptually easy, but scale up to be pretty difficult. Like, if you're building out a system that you have different decks, you know, thinking of Kindu, or other kind of subscription type of in-app purchases, that's another, you know, it's easy to conceptualize. But there's so many edge cases around subscriptions. Like, what happens if someone's credit card expires? What happens if someone has a fraudulent card? What happens about refunds? There's so many different variables that, if you use in-app purchases, you kind of get spared from a lot of that, because it's just, Well talk to Apple or talk to Google. But it's still things that you kind of have to consider on the outset when you're building these out. And so there's a lot of kind of behind the scenes work to implementing in-app purchases that you might not recognize just from looking at them.

Rob Bentley 16:24
Yep. And so that covers the easy part of payments. So now if you're rolling out a custom solution.

Tim Bornholdt 16:31
Yeah, yeah, I mean, we use Stripe for pretty much everything that we do that requires credit card capturing, and Stripe has made it super, super easy to implement their SDK. But even that, there's still so many things to consider when you're talking about credit cards. And it's one of those things, Rob, like we had talked about before, where when you walk into Target, and you use face ID or Apple Pay or whatever, and you double tap the side button and your phone like does a little "ca-ching". And it has a little green checkmark. And you're just like, Oh, cool. I just sent money from this glass thing in my hand to Target without exchanging any credit card or anything else. It seems like magic from your end. But whenever I see that little spinner thing going, all I can think about is, Okay, well, this number is being routed to the bank, who is then verifying the funds are there, who is then sending a thing to fraud detection to see if this is somewhat of a valid payment or not. And there's so many things while that little spinner is happening that are going on in the background. I mean, I don't know if that's what you think about but that's what I'm thinking about all the time when I use those kinds of payment services.

Rob Bentley 17:37
I wouldn't say every time but I definitely have thought about it. I mean, it is so simple to use that I definitely don't think about it every time, which is, you know, hats off to the people that made it.

Tim Bornholdt 17:47
Yeah, and maybe saying every time is a bit of a stretch on my end. But I think about it more often than not, especially when I'm using my watch, or I get a new device that you can use Apple Pay with. It's like, Man, it's so crazy that you can just do that. But yeah, if you're thinking it's so easy because Apple did it, and so it's easy for us to do, that's like a whole nother story. Because we don't have the power that Apple has to be able to flex and make banks do things.

Rob Bentley 18:16
Right. And usually, it depends, but you're usually going to be working with a third party framework for your payment system, because rolling out your own payment system is a nightmare. And so you have to live with how they integrate with Apple's payment system. And it's different for each one. So just because we may have done it in one app, and now you're trying to do it in a different one, it doesn't mean it's just going to be the same thing for us.

Tim Bornholdt 18:42
Right. Yeah, cause there's apps, for example, we've built where, I'm thinking for VSI, we built out a system that allowed for credit card payments, and that client of ours has a lot of clients in Asia. And so dealing with Asian banks, I've never had to really worry about that side of the Stripe API before. But there's certain regulations that different banks in Japan and Korea and China require you to have, versus there's regulations also in Europe now for secure pay. And there's things happening in the US. So when you're dealing with software, it's easy to get things working right at your local level. But then as soon as you branch out globally, everybody's system is weird and wonky, and you have to find out how to make your app work with it.

Rob Bentley 19:33
Yeah, and just the amount of errors that are possible when any payment is going through, which I think you already touched on. But again, it's like, there are so many things that could go wrong in that little few second process that it's amazing that it goes right as much as it does.

Tim Bornholdt 19:49
Well, yeah, I think that's a good point too. We've touched on it before but a lot of these features, if you just follow the critical path, so to speak, and just do, on the base level, like sending a push notification, to get it to just work right for one case is not that hard. It's pretty straightforward. But what makes all of these features hard is that there's so much variability. And yeah, with credit card payments especially, there's all the different vendors, providers, different regulations you have to worry about and laws around the world. Yeah, it is amazing. And it is no wonder why it's so impressive that we can actually trade money at all digitally. Easy to conceptualize, hard to implement.

Rob Bentley 20:35
Yeah. And then the last thing we have, which I already kind of said about payments, is third party API integration. You're definitely going to want to use one of these for a payment system. But you want to use as few as possible when you're developing your app. Reason being, anytime you're using one, you're kind of stuck with how they develop their library. And if there's a bug in it, you can't always fix it. And then when you have all these different frameworks trying to communicate data with each other, it can get real dicey real fast.

Tim Bornholdt 21:12
Yeah. And I mean, there's a lot of situations you can't get around using someone else's framework, right? Like, if we were building an app to look at, you know, the Kelley Blue Book value of cars, for example, we'd have to hook into the Kelley Blue Book's service, right? There's no getting around it. But the thing is is, it's easy, again, to get the initial connection usually to an API. But at some point, like when you get deep into it, you're playing in someone else's world. And you have to spend a lot of time trying to acclimate yourself to how they set their universe up, you know. What rules do they have in place? How do you deal with security with authentication with making requests of those services?

Another thing to keep in mind is, whenever you implement a framework, for example, if you were to implement Facebook's sign-in with Facebook, you have to plug in their whole SDK. And you don't know what they're doing with it, like they could be sending back and do send back so much information about your users, how they're using the app. So you have to keep that in mind when you want to just do like, Oh, yeah, we should just quick throw in a sign in with Google and sign in with Facebook. It's like, it'll work once, and it'll work fine. But especially with the Facebook sign-in thing, Rob, you saw that like a couple of weeks ago, where they had a bug in their system. And it was like for a few hours, there was like millions of apps around the world stopped working, because they had the Facebook SDK signed in, and their SDK had a bug in it. And so it just kind of screwed everybody over for a little while. So it's just another thing to keep in mind.

Rob Bentley 22:55
Yep. And that was kind of my next point, too, was, you know, you spend three months working with like the Kelley Blue Book one, for example. You get all of your data set lined up, it's working great. And then they decide to change something. And so now you're at their mercy too of if they keep their code the same or if they don't. And if they change, that means you have to spend hours and change your stuff to match it as well. And that can happen at any time when you're using a third party API.

Tim Bornholdt 23:21
So yeah, moving into our final thoughts here. I didn't want to put this episode out to try to dissuade anyone from doing anything. You know, I think a lot of this is more of an exercise for people to understand there's certain things about app development that are difficult, and there's certain things that aren't. And I think it's easy to get a lot of these things started. But you have to think about the long term costs of adding these things in. And that's why we really stress the whole minimum viable product aspect of development, is because we want you to just get the features in that are going to solve whatever business problem you have, and provide value for your users, without having to throw in so many features that you have to maintain. Because if you throw in a messaging system into your app, and then you turn it off, you're going to hear from at least a couple people that are pissed off because they were using your messaging app as their main communication with all their friends or something. It's crazy what happens in the long run with these things. So my final thought is, just think hard before you put in a feature to make sure that it's something that you actually want to spend the time investing in and doing it correctly.

Rob Bentley 24:35
And if you just talk to us too, we can help you figure out where to get the most value with the least amount of effort. So you might think it needs to be something that is actually really hard to do. And maybe we can scale it down to a solution that still works that takes a lot less time and effort. So you know, again, just talk to us and we'll be able to help you kind of navigate what's hard and what's not.

Tim Bornholdt 24:58
That's a great place to end it. 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 @TimBornholdt on Twitter and the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by the willful Jordan Daoust.

If you have a minute quick before you leave, we would really love it if you left us a review on the Apple Podcast app. It does not take much time at all. And it seriously helps new people find our show. So just head to constantvariables.co/review and we'll link you right there.

This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at JMG.mn.