How to build a mobile app: App lifecycle Management

App lifecycle management, which we’ll be referring to as ALM from now on, is the totality of managing the processes, systems, and people that make your app: market research, ideation, coding and design, testing, launch, analytics, and updating your app throughout its time on the App Store or Google Play.

Let’s explore ALM:

ALM

Step 1: Ideation

There’s two ways ideation can come about; from inspiration after being presented with a pain point in your own life, or from conducting market research which exposes a niche market with an unsolved pain point of their own. If it’s the former, make sure to conduct your own market research to determine just who exactly your niche is.

If you’re looking for ideas and methods for coming up with marketable apps, visit our blog on the topic.

Step 2: Requirements gathering

After solidifying your concept, you’ll want to develop out the requirements of your app – basically, what it does and how you want it to achieve those things. This covers everything from your app’s feature set to the SDKs and APIs it utilizes. Then, break those down sets and systems into individual, detailed tasks, so you and your PM can easily manage and track the progress of these tasks.

Your feature set will be based upon user stories. User stories are detailed, step-by-step use cases of what a user will do during a session in your app in order to accomplish solving your pain point.

You’ll also want to plan out which platform(s) your app will launch on, if you haven’t already. This should be partly influenced by your market research. Knowing which platform you’re building for will dictate every following step – and if you are building both an Android and iOS app version, you’ll need two dedicated development teams.

If you’re looking for more info about planning your app’s feature set, visit our blog covering the topic.

Step 3: Design

When you have a plan solidified for what your app will actually do, you can move onto design. Start with wireframes and color options on your home screen, and after settling on the right layout for your app, begin designing the other screens and how your users will actually interact with the functionality your app provides.

If your app has graphics, this is the step you’ll implement those – anything visual that your app requires should be complete before coding begins (if your app requires heavy backend infrastructure, start building that out as soon as possible). Make sure to build out a prototype so your software engineers have something to reference while they code.

For more information about proper app design methods, visit our blog covering the topic.

Step 4: Develop

This is where the actual coding begins. Your programmers should build the UI based on the prototype to ensure all of the requirements are met. Assign those requirements, incidents, and tasks to your team. For every incident that is completed, run tests to check for errors and vulnerabilities. After that iteration has passed a code review, add it on to your master branch.

For a lot more tips on avoiding development mistakes, visit our blog about common development pitfalls. For a guide covering iOS development, click here. For a guide on Android app development, click here.

Step 5: Testing

Create your test cases, which should be based on the user stories you came up with during step 2, requirements gathering. To efficiently test, lay out every step of your user stories in a spreadsheet, and identify the features that aren’t working properly. Take the time to make sure your app feels smooth and attentive to inputs as well. Users are likely to abandon slow apps in favor of faster ones.

Record every bug you discover while testing. Fix the issues, and test again. Repeat this step until testing is complete.

Step 6: Soft launch (quality assurance)

Sometimes referred to as a beta test, your soft launch will open up your app to a small segment of the public – one that you, or a marketing agency (or your developer) will find. They’ll use your app out in the field, so to speak. A soft launch can be thought of as the second step of testing, because it will inevitably uncover bugs and errors your first rounds of testing didn’t.

Optimally, you’ll have caught most of the bugs by this point, so your testers will have a high opinion about your app before it’s published (which gives you a significant boost to your app store rankings when they rate it after launch). They won’t be surprised, however, if they do find bugs – they understand that it’s a soft launch, after all.

You’ll bounce between steps five and six until all of your app’s bugs have been identified, fixed, and tested again. For more information and tips about running a beta test, visit our blog covering the topic.

Step 7: Deploy

Congratulations! It’s time to publish your app. Both the App Store and Google Play have different approval processes and standards for apps to pass before they can be published, as well as publishing fees.

If you’re looking for more information about the cost of publishing an app (and the other costs associated with development) visit our blog covering the topic. If you need help planning out your ASO campaign (which you should do before launch), visit our blog on the topic.

Step 8: Analytical review

Now it’s time to watch (and then react to) the data coming in. There are a lot of app analytics platforms, but we prefer Kumulos.

For a step-by-step, detailed guide to measuring your app’s success, visit our blog about measuring your app’s analytics.

For more information about coming up with ASO strategies, visit our blog on the topic.

Step 9: Enhancements

Based off of your analytics, it’s time to start updating your app with enhancements; enhancing your app’s UX by updating it’s design, security, and compatibility with other devices.

This is the step that glues the whole process together, and based upon the analytical data you’re receiving, you’ll ideate solutions for the aspects of your app that need to be enhanced.

The effects of not updating your app

Updating your app is the most important step you can take to ensure the time you spent developing your app (which in some cases can take years) doesn’t go to waste.

Updating your app is important for the following reasons:

App Trends

What’s cool is always changing, along with what’s possible. Updating how a feature looks or functions almost invariably results in a positive boost to your users’ experience using your app, which in turn leads to higher user retention, ratings, and reviews. Your update doesn’t always have to be centered around functionality either – sometimes it can be as simple as a background color change, which could be part of an A/B test you’re running.

Security

We all know there’s always someone looking for a vulnerability to exploit. Code that was once air-tight slowly loses it’s edge with time, and the longer your app goes without a security update, the more likely it is that someone with ill intentions will use that to their advantage.

This is an exceedingly important aspect to consider when updating your app. If a user is ever exposed to any security risk due to your app, they are virtually guaranteed to at least stop using your app, and are more likely to outright delete it from their device.

They’ll also be much more likely to give your app a bad review and rating, which can cause a huge dip in your conversion rates as your app plummets in its rankings on the App Store and Google Play. This can very quickly spiral into a downward trend that will be out of your control. Users who feel violated by your app will be sure to warn others about an app that is a security risk.

Bug Fixing

Even when you’ve tested your app throughly as outlined in the steps above, you’re bound to see bugs in your app over time. A major cause of these bugs popping up throughout the lifecycle of your app are due to new devices and updates to the OS your app runs on. As screen resolutions change, so to must your app – or at least, account for those changes.

In the same vein as security issues, bugs will also deter users from continuing to use your app. If you don’t care enough to update it, why should they care to use it?

Android development: What you need to know

Continuing from a previous installment of How to Build a Mobile App: The Ultimate Guide, we’re on to the next major player of the mobile market; Android!

If you own anything other than an iPhone, it most likely runs on the Android Platform. Mainly programmed using JAVA, Kotlin, and C++, Android boasted a global market share of 88% in 2018 (a growth of over 85% since 2009), and currently holds 36% of the US market. Just like our blog on iOS development, we’ll go over the information you need to know to make pragmatic decisions about Android development, and key terms to better communicate with developers.

Disclaimer: If you’re a developer or software engineer, there might not be any new information for you here. For a look into inventive strategies to boost your ASO, check out our featured piece on The Manifest.

If you’re a business owner, CTO, or marketing director, and you’re looking to hone your Android dev knowledge, or want to brush up on your developer jargon, you’ve come to the right place.

The Android platform has seen a meteoric rise in popularity since its inception – when Google Play first came on the scene in 2008 under the name “Android Market,” the platform was facing an uphill battle against tech giants Apple and Microsoft, who in 2009 both retained about 9% more market share than Android, which entered Q1 of 2009 with a market share of 1.6%, compared to the 88% it now holds globally.

Google Play now hosts over 2.6 million apps, and in 2016, Google Play announced users had downloaded over 65 billion apps in eight years.

The tools available to developers

Written using the programming languages JAVA, Kotlin, and C++ (among others), the Android Open Source Project (AOSP) is hosted on GitHub, and provides developers with access to 99 (and counting) open source repositories. A repository is like DropBox, but for code – it gives software developers remote access to different libraries of useful functionalities (which can also be called features). In the case of GitHub, these repositories are open and free to any member of the AOSP, but most developers will use their own private repositories as well.

A functionality is – in the simplest of terms – anything the app can accomplish. Does the app provide users with a map? That’s a feature. The map is GPS enabled? That’s another feature. The app provides users with next-step-directions in the form of push notifications when running in the background? That’s another feature.

If you’d like to learn more about feature sets and proper app ideation, check out our post on the topic.

Repositories are used to speed up the programming process by providing generic code structures that can be tweaked to fit an app’s specific branding and design.

A massive upside to Android development is its ease of access to software engineers – primarily due to JAVA acting as the flagship programming language when developing Android apps.

JAVA was first thought of in 1991, after all, and saw its first public release as JAVA 1.0 in 1996. As of 2016, it has been hailed as one of the most popular programming languages in use today, with 9 million developers reporting in, and is currently on its 11th version.

Kotlin, on the other hand, made its public debut in 2017, and is currently on version 1.3, which was released in October of 2018. Very new and relatively untested, Kotlin was designed to fully integrate with JAVA, and like JAVA, is an object-oriented language (meaning important information is stored in individual classes in the code itself), and seems to be a direct rebuttal to iOS’ Swift language. For an example of a class, check out our iOS development page.

With a new language emerging like Kotlin, it’s always fun to stay up to date on what’s coming down the pipeline; luckily, the Kotlin community makes it easy to stay in the loop.

Android developers, unlike those who work with iOS, have multiple compilers to choose from. A compiler is a program that software engineers use to write programs, and developers can choose from a number of compilers in which to write their code. For example, an Android developer could use Android Studio to write their code, or Intellij IDEA, or Eclipse (and many others).

The hierarchy of Android

There are four layers to the Android OS:

  1. Applications – This is where the native apps on your device, like your camera or text messenger, as well as any apps that have been download from Google Play, live in the OS. When an app is installed, it is stored in the aptly-named Application layer.
  2. Android Framework – This is layer that provides the tools developers use to make apps work – service functions live here: activity manager, package manager, NFC (near field communication) services, location services, windows manager, content providers, and view the system manager.
  3. Android Runtime – This is the layer that consists of the Android core libraries (the tools developers use to hook up JAVA with the Android OS), as well as the Dalvik Virtual Machine (DVM), a register-based virtual machine. For someone who speaks English, and not code, it’s basically a computer that lives in the OS itself, and ensures that the device the OS is on can run multiple instances simultaneously. Android Runtime is the foundation for the previous layer, Android Framework.
  4. Platform Libraries – Containing various C/C++ and JAVA libraries, this layer provides support for Android development. This layer contains functionalities like the media player, libraries for graphics, font support, and browser support – among many others (no one wants to read a list that long).
  5. Linux Kernel – This is the lizard brain of the Android OS. It manages drivers on the device, (think camera, audio, Bluetooth, memory), as well as memory management, power management, and other base-level management systems.

Those are the layers on the Android OS that provide the foundation, functions and space for your app to live and interact with. Now that we’ve got that out of the way, let’s move on to the building blocks of an Android app.

The building blocks of an Android App

There are five main components that make up an Android app:

  1. Activities
  2. Intents
  3. Services
  4. Broadcast receivers
  5. Content providers

Activities

Activities are how your users interact with your app. When a developer speaks about an activity in Android, they are usually referring to the multiple points of interaction on a single screen through the app’s UI (single screens in Android are referred to as view models, and they dictate the “box” that visual information fits into). Take, for instance, a device’s native phone app – there are separate activities to dial a number, view recent and missed calls, and voicemail. All of these activities are separate from each other, and are considered distinct activities unto themselves – but they all work together as a whole to help the user achieve their goal.

Activities in Android are designed to keep track of what the user is currently doing, the processes that keep track of the features users are engaging with, and “killing” the processes that are no longer necessary for the user at the moment.

When an activity is killed, its current state is saved, in case the user comes back to that activity. This ensures that memory is both freed up for current processes, but the processes in the background remain quickly accessible to the user.

Within activities are fragments, which can be thought of as sub-activities. Fragments can be interacted with just like an activity, but they are specialized – they give your app’s UI the ability to adapt to different device screen sizes, as well as the ability to produce a more dynamic layout. If you know HTML, it’s basically the same idea as building a responsive website.

Intents

Intents function as the messengers between the components that make apps work. They are used to take the necessary information from one component of an app to the next, in order for that component to do it’s job.

If that was a little confusing (which it is, I don’t blame you), think of them as an alarm clock. An alarm clock wakes you up and tells you what the current time is – the information you need in order to start acting to get out of bed and get on with your day. Intents “wake up” app components, and let them know it’s time to get out of bed.

The most important part of intents is making sure your code uses clear naming conventions – an intent needs to match with the names of components it needs to interact with, and if the names don’t match, it won’t be able to find the component it needs to deliver the message to.

For an example of naming conventions, let’s pretend there’s a turtle. The turtle sees a coyote. An intent is sent from TURTLE_CRAWL to TURTLE_HIDE. This changes the action the turtle is taking, just as an intent will change what action the app is taking in order to properly interact with the user.

There are two types of intents: implicit and explicit. Implicit intents are used to send information from one component of one app to another component of a separate app. Explicit intents are the direct opposite – and are used to take information from one component of an app and use it to invoke another component of that same app.

Services

Services are what keep the functions of apps running in the background, and are broken down into two categories: started services and bound services. A started service, for example, is used to run some sort of function in the background, until the user stops the function; this would be used to allow a user to listen to music from one app, while engaging another app at the same time.

A bound service is kind of like one app giving another app a helping hand – these basically tell the system to not kill the function the two apps are sharing, and as soon as the function has been completed, it can be killed.

Broadcast receivers

Broadcast receivers are aptly named, and serve as the proverbial loudspeaker for a device. Probably the most well-known (and dreaded) broadcast receiver is the “low battery” notification.

When a user downloads an app onto an Android device, the OS will assign that app a unique Linux user ID (Android’s foundation is a Linux kernel), and all apps run on a virtual machine (a simulated computer that exists as its own entity on the OS), so each app runs in an isolated environment from all other apps on the device.

This is called the principle of least privilege. This means that each app can only access the functionalities and data it needs to complete a task, and nothing more. This provides an extra layer of security, as apps are unable to share data with each other, and can only access the systems they need to work.

Broadcast receivers usually function with the help of the previously-mentioned intents.

Content providers

Just as the Android OS has libraries that help it function, so to does an individual app. The libraries, named content providers, house the information of that app, so other apps can access that information in order to function properly.

Think about how when someone texts you an address, you can click on that address to open it in Google Maps. In order for your map to display the address that was texted to you, your text messenger app stores that information in a content provider, which Google Maps can then access and display.

The manifest file

After you’ve made your app, all of the components of your app (activities, intents, services, broadcast receivers, and content providers) must be stored in what’s called the manifest file. The manifest file is the folder the Android OS searches through in order to find the components that make your app run. In short, for a device to know that an app component exists, that component must be stored in the manifest file.

Think of it as the roadmap the system uses to run an app – it tells the OS where to go and what to interact with. It also identifies permissions the user has set within the device, declares the hardware features an app needs to run, and the APIs it needs to be hooked up to.

Where to go from here?

The next steps to take are beta testing and then publishing, which comes with its own costs (a one time fee of $25 for Google Play) in addition to the other costs that can be expected while developing a mobile app.

We hope you’ve found this guide to Android development helpful! Below, you’ll find a glossary of commonly used words regarding app development.

Glossary of developer jargon:

  • Adaptive interface: An app that adapts to the available screen resolution. Essentially the same idea as a responsive web page.
  • API: An Application Programming Interface is a set of functions, classes, and protocols that define how pieces of software interact with each other. They facilitate code creation by providing tools and building blocks that help companies connect their software with another set of software, or even other companies’ code.
  • API calls: Sometimes referred to as an API request, an API call is essentially a piece of software in an app connecting to a server, and requesting a data transfer.
  • Back end development: This forms the logic and data structure of the app.
  • Back end integration: This allows an enterprise system to connect to an app – for example, connecting the database of a website to an app, in order for users to access the database through the app rather than the website. The information is hosted on the website’s server, but is still accessible through the app itself.
  • Front end: This is the layer of the app that users interact with.
  • Iterate: To perform a certain task or function repeatedly.
  • On demand app: These are apps that allow users to find, connect with, and book a professional service.
  • SDK: A Software Development Kit is a pre-made software tool that can be used for a variety of functions. Some SDKs help with analytics, others provide debugging and maintenance utilities, and a whole host of other functions.
  • Tokens: A token is a software based security tag that produces a single-use login password or PIN.
  • UI/UX: User Interface and User Experience are intrinsically tied to each other. UI is the layout and design of the front end of an app. UX is how the app flows, functions, and responds to the user’s inputs.