22: App Development Lifecycle Series - Deploy

In Part 4 of our App Development Lifecycle Series, Tim breaks down the final stage of development: deployment. We share our process for shipping production-ready code to the App and Play Stores, what to expect during the review process, and how this phase loops back to the strategy phase.

In this episode, you will learn:

• What you need to submit an app to the App/Play Stores
• How to deal with an app rejection
• Why you should release your app using phased rollouts

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

Recorded February 19, 2019 | Edited by Jordan Daoust

Show Notes

• App Store Review Guidelines
• Google Play Developer Policy

Episode Transcript:

Welcome to Constant Variables, a podcast where we take a non-technical look at mobile app development. I'm Tim Bornholdt. Let's get nerdy.

Today on the show, we are wrapping up our mini series on the app development lifecycle with the fifth phase, deployment. At this point in our life cycle, we've completed our strategy phase where we created our user stories and that details what the app should do. We then went into our design phase where we ended up with our asset catalog, which tells us how the app should look and function. And we've ended our development and testing phases, which is where we took the user stories and the design and we created it in code. And then we tested that code to make sure that it met the user stories. So by the end of this phase, your app will be live on the App andor Play Stores. And all of your users will be able to download and use your app. Yes.

So as with previous episodes, you can take this phase and apply it to both a brand new app or an existing app. In this case, I'm going to focus on the case of it being a brand new app. And if there's things that differ with an existing app, we'll break that down for you as well. So first, when we enter this phase, we generate production builds. And I actually don't think I've covered this yet in this series. So this is now as good a time as any to kind of talk through what that actually means. So let's talk about the difference between staging and production. So staging, which you might also hear as development or test, that environment is where you're able to test your code and do whatever you want and break stuff. And that won't have any impact on your existing users. The production environment though, is where all of the actual data and everything about your users lives. So when you're testing these apps, you want to make sure you're testing in the staging environment because obviously, if something breaks, it's better to impact you know, zero users as opposed to testing in production, which is going to impact a ton of users.

Typically, the staging environment and the production environment are mirror images of each other. And from the back end perspective, so if you're using AWS, or Linode, or whatever, you basically spin up an environment that matches your production environment for your staging environment. The nice thing about doing it this way is within your staging environment, you can spin up resources as you're testing it, and then scale back down. So you're not wasting money. Or you could just turn off the instance all together if you're not testing anything, and that kind of helps everything work out financially, from your end.

When we're building an app from scratch, and you haven't launched yet, typically, this is the point where we want to make sure that we scale up your production environment and make sure that you're ready to start handling all of your users. We also need to make sure that the app itself is talking to the production environment and not the staging environment. So while you're testing out the app, you're usually at the beginning of the lifecycle. If you're doing a brand new app, everything will be done pointing to the staging environment. And then at this point is where we switch everything over into production, test it in production, and the builds that we actually send to the App Store, obviously, we want those to be production built. We want your users to use the live production environment, and only you and any of your testers would be allowed to have access to the staging environment. So we want to make sure that we generate builds that get rid of any references to the staging environment, and we're just pushed to the production environment.

At this point, there's a couple of other technical things that we do on our end. First, we check to make sure that the production environment is actually up to date. So if we've made any changes to the server, this is more applicable if you have an existing app, but this is the point where if you have an existing app, we would push any changes of the staging environment into the production environment, and then we test it again right away to make sure that everything is working as expected. Also, we want to make sure our source control is up to date. Without getting too technical on this, we just want to make sure that our code is always in a place that anyone, any of our developers, can grab a copy of that code at any point, and it's always the production code, and then they can make changes and fix things as we go. Because, inevitably, if you have an app around for long enough, you'll need to push what they call "hot fixes," which would be something like the server has a critical bug that we can't run through our normal process. It's like, just fix the bug. And that's why our source control is like it is. So again, not to get too technical, but those are two things that we would want to make sure at this point are ready to go.

So now that we have our production build set, and we have our server environment, and the production environment is ready to go, now we can submit the app for review. So if you're used to web development, or if you've ever deployed an old school desktop type of app, you might be used to just kind of submitting your code and putting it into production. And that's it, you're done. In the world of iOS and Android, though, that's not exactly how it works. Both Apple and Google review apps before they appear in the stores.

Now they're checking for things like broken and buggy apps, obviously malware, inappropriate content, intellectual property violations, that kind of thing. And I'm going to leave a couple of links in the show notes for you, if you are at all going to be building apps for either environment, which I'm assuming you are, since you're listening to this, you want to read these documents. Not a lot of people do, but if you do, it'll put you ahead of a lot of people. That would be the App Store review guidelines for iOS and the Google Play Developer policy for Google for Android. And both of these documents detail in plain English what reviewers are looking for and what your app might possibly get rejected for.

Now on Google Play, the app review process is almost entirely automated. I think some people, no one really knows, it's kind of a secret sauce sort of thing. I think there are humans that intervene at certain times. But for the most part, the process is automated. So the pros of that are review times are really quick. I mean, we've seen apps get reviewed and done within like 15-20 minutes. The cons, though, are, the store sometimes has more junk that gets through it. And I think users kind of see that. And it's, I guess that's really not a con for you as an app owner, because you're not going to be putting out shoddy work, right?

On the App Store, this is totally different, though. The process is partially automated and mostly human reviewed. So that means that app review time is a lot longer. It used to be when we first were starting development, it would take upwards of a week, sometimes more than that, like 10 days. Now it's more like 4 hours to 72 hours is about what we see in an average review time. The pro of this though, with having a more human centered review is that they catch things you might not have otherwise caught. So they use a lot of different devices when they're testing. They'll use iPads. They'll use old iPads. They'll use old iPhones and iPod Touches. And they'll let you know if things look wonky. If your app says it supports an old iPod Touch, then it better support an old iPod Touch, right? But you might not have one laying around. So it's kind of nice that they also do this.

Now, rejection from the App Store is a very common thing. We get rejected all the time for a ton of different reasons. Again, those links that we had in the show notes, check those out, because that will give you the rules that you'll want to abide by. But here's a few examples of things we've been rejected for in the past. On iOS specifically, they really are taking a hard line stance and they always have on user privacy. So we have one app that is an app for other people, it's an app for a business, and they have their employees on the app. And the app is in the public App Store. And when you create an account, you specify your address and your birthday and your gender. And when we submitted a bill not too long ago, they rejected us because they said, "Why are you collecting this information? You don't need this information at all." And we had to reply and say, "Well, for tax purposes, and for some other purposes, we needed to collect, you know, birthday and address." And I mean, we actually don't really need to collect gender. So we stopped collecting that. But then they replied and said, "Well, on your signup forms, you have to specify, like you have to give like a reason why." So I mean, they really do take privacy very seriously. Another thing that we've been rejected for is if you are creating an app that's tracking someone's location in the background constantly, and you ask for the permission of "I want to track someone's location in the background," Apple will absolutely make you say why you're collecting this information and then you have to be very forthright with it and allow your app also to work without that permission in there. So they really care, again, about user privacy. Another thing that, specifically these last ones have been, again, very much Apple rejections, but you kind of want to make sure it's also good on Google, just you want to have a similar experience, right? One thing that Apple has rejected us for several times in the past is if you have a social network type of feature in your app where any user can post content into it, you need to give all of your users the ability to flag or report inappropriate content as well as to block it. So that's actually tripped us up a few times. And now, you know, we've learned our lesson. So we don't, if we see any content like that in the app, we make sure that we're abiding by those rules. But that's something that you might not know that you have to have that in your app. And now when you're looking at any iOS app, you'll start seeing flag and block stuff in all these apps and that's really why, again, like I said above, another reason that we get rejected is bugs and crashes. It's embarrassing when our tested app has some kind of bug that gets caught. But again, we don't have every single device that's ever been made by Apple. So sometimes weird things happen. And that's the whole point for app review is to kind of catch those things.

Finally, one of the weirdest rejections that we've had is, we, at one point in our app, we had a credits section where we were thanking all of our developers. And we had both iOS developers and Android developers. And we were rejected because the app reviewer said that in the credits, we wrote the word Android, and we're not allowed to mention Android in iOS apps. I think that restriction has been lifted. But it's just, you can see that there's a wide range of reasons you can get rejected.

And, you know, that leads into our next point, which is what happens when you get rejected. Well you get a notification that says you have a message from App Review. They tell you exactly why you've been rejected. And you're asked either for more information, like, again, in the case of us collecting user information, they're asking, "Why are you collecting it?" And in the case that you're just blatantly violating a policy, they will tell you what policy you're violating and how you can make yourself in compliance. And then at that point, you just fix the problem. That's really it. It's really not a big deal to get rejected. You really just work with your developer team, fix the problem and move on.

So what do you need in order to submit your app to the store? Well, there's a few things that you need. The biggest thing would be your marketing materials. So we need to obviously have your app name, the description, search, keywords, things like that. And all that, we'll be working with you well in advance before we get to this point so you're thinking about it, but that's definitely one thing that we like to get your feedback and help with. Next thing would be an app icon, which we generate on our side. Just so you know, it's a PNG that's 1024 by 1024 pixels. The next thing is a privacy policy. Thanks to GDPR and things like that, both Google and Apple are very hard nosed about having a privacy policy. So there's all kinds of resources that you can find one. I would recommend talking to your lawyer to make sure that you're fully in compliance with anything that your lawyer might come up with. But you have to have a privacy policy if you're going to list your app in the App Store, and if your app collects any sort of user information, which at this point, most apps do do that. Finally, the last thing that you need is screenshots. So you can get screenshots of all the different screen sizes that you want. Apple's been a little bit better lately about being able to reuse bigger screens on smaller screens. So like thinking of the 10R versus the 10s, the 10s Plus, you know, there's all kinds of screen sizes. So it's nice that you can kind of recycle those. But that's still something that you're going to want to consider is what kind of screen or what kind of presence are you going to be showing your users when they're searching for your app through the app store.

Once you have all of that content, what happens at this point is the developer takes your marketing material, the app icon, the privacy policy, all that stuff, and they take the production build of the app, and they upload it to App Review. And they mark it to be held for developer release. So what holding for developer release means is, we're able to, on our own schedule, say, "Alright, let's start rolling it out." And that kind of helps in a couple of ways. If you want to be in parody with when you release your iOS and your Android apps, then you can wait until both are approved and ready to be released and then you can hit "Go" at the same time. The other common reason you do this is if you have a marketing reason, like you say you want your app to be released on the first of the month, then we can hold it so that it's just passed review, now we're ready to go into production when you give us the go ahead. Once you do give us that go ahead, now we do what's called a phased rollout. So what a phased rollout is is where the app is, it's gradually released to a small percentage of your users. Usually it's, you know, 10 to 20%, depending on how many users you have. But what this does is we can release the app to small numbers of people. And it lets us test to make sure that your users are having a great experience, there's no crashes, there's no lost data or anything like that. And it's really nice, because if you do have a problem, you're only impacting a small percentage of your users instead of obviously impacting everybody. So this also really helps because again, your users are going to have devices that you don't have, especially on Android, where there's hundreds and thousands of different devices out there. You want to make sure that you have a wide range of people that are testing your app. So it's good to get that feedback before the entire world has it, if that makes sense.

And the way that you check to make sure that you're pased rollouts are going well is to monitor crash reports. So we use a service called Crashlytics. There's a lot of different crash reporting tools. But basically, all of them collect data as people are using the app, and you can monitor and see, you know, if you have version one released already, and you're just releasing version 1.1, or something like that, you can check to see "Okay, is everyone on 1.1 of that 20% of the tiered rollout are those people doing well? Okay, now we can release it to 30% and 40%, and so on," until you're finally at 100%. Once you've reached 100%, you are fully rolled out. And now we are all the way done with the deployment phase.

So coming out of the deployment phase, we've shipped a production ready, fully tested app that meets all of your user stories. And that app is in the hands of all of your users. So now we can loop all the way back to strategy. So again, this is a lifecycle. It's a cycle. It's a loop. And as we're approaching the end of the development and testing phase, and especially as we're getting into the deployment phase, we are working with you to figure out what the next phase is going to be, and what features are going to go into it. The reason we don't just go from development and testing straight into strategy again, though, is because we obviously want to collect the feedback from your users. They're going to tell you what's great, and what is not great about your app. So you want to make sure you've got their feedback incorporated as you're going through that strategy session. So once you do get that feedback from your users, you take it into a strategy session, you create user stories around that strategy, you design a solution to those stories, you code that out, get tested, and you ship it, and you go back, rinse, repeat, recycle.

And that is the end of our app development lifecycle phase. I would love to hear what you thought of this mini-series. If you have any feedback at all, good or bad, please do reach out to me. You can get in touch with us by emailing Hello@constantvariables.co or you can find me on Twitter @TimBornholdt and the show is @CV_podcast. Show notes for this episode can be found at constantvariables.co. Today's episode was edited by the opulent Jordan Daoust. This episode was brought to you by The Jen Mahonis Group who builds mobile software solutions for the ondemand economy. Learn more at JMG.mn.