Guest blog: Google Analytics for mobile apps is shutting down. Users move to Kumulos Analytics.

This is a guest blog written by our good friends at Kumulos, specifically Caroline McClelland, Kumulos’ Marketing Manager.

With 17 years of marketing management experience in global organizations including information technology, financial services and retail, Caroline has great passion for mobile marketing and building high performing digital teams to work creatively in all areas of marketing.

The topic of this piece will undoubtably be a problem for lots of developers – but not so for us (NS804). We have always used Kumulos, our preferred mobile analytics platform, for the majority of our projects because of the quality of the service their platform provides.

Google Analytics for Mobile Apps is shutting down. If you use the free version of Google Analytics, and if you have a free Google Analytics property collecting data exclusively from the Google Analytics Services SDK (Android or iOS), you should already have been notified. So, if you are one of the many that are using GA for mobile analytics, now would be a good time to step back and think about which app analytics service is the best fit for your mobile app development business.

Join the many, many app developers making the move away from Google to Kumulos ahead of the shut-down. Developers with apps of all shapes and sizes across a broad range of industry verticals are choosing to move from Google Analytics for Mobile to Kumulos. They tell us it’s because we are the analytics platform that gives greater clarity on how the apps are performing both technically AND commercially.

Which is nice to hear, because that’s precisely what we’ve set out to deliver. The Kumulos single pane of glass means we make it easier to understand app download trends, user engagement, user retention and user behavior, alongside the technical performance of the app, and any API dependencies impacting on users. So, past Google Analytics customers now get a more comprehensive view on how the app is performing.

If you’ve yet to select an alternative app analytics tool, the mobile app performance team here at Kumulos, will tell you everything you need to know about moving along the well beaten path transitioning from Google Analytics for Mobile, to Kumulos.


Many in the mobile app development industry are not surprised at Google’s decision. For a long time, the mobile version of Google Analytics has been considered to be slightly flawed. So is it a good thing that they are finally shutting it down.

Well, according to trusted sources such as Simo Ahava, Google is wanting all GA users to migrate to Firebase Analytics. So that will mean a new system to learn, a new system to set up and from those in the know, Firebase Analytics falls short of what many serious mobile app publishers need. So for some, this will be a backward step.

And, it’s not just Google Analytics that’s impacted here. Google is now starting the process of deprecating the legacy Google Analytics for Mobile Apps. This covers all data collection SDKs that do not have the word Firebase included. Also, take note, the Google Analytics tags in Google Tag Manager for mobile apps will be impacted.


Now that Google has started the process of deprecating their Google Analytics for Mobile Apps you need to take action. In fact, Google has already started to decommission properties that receive data exclusively from the Google Analytics Services SDK. Data collection and processing for such properties will stop on October 31, 2019.

However, reporting access through Google UI and API access will remain available for properties’ historical data until January 31, 2020.

After this though, the service will be fully shut down. These properties will no longer be accessible via Google Analytics UI or API, and data will be removed from Google Analytics servers.


Moving from Google Analytics to Firebase isn’t an easy switch. If you’ve already taken a look at Firebase you will see why!  Hopefully you’ve started to look at other players in the analytics field.

Despite the Firebase team making the user interface a little more intuitive it’s still not the easiest platform to understand. Firebase is known for having a very different approach to analytics, as it revolves around the duality of users and events. Yes, it’s a free app measurement solution that provides data on app usage and app user engagement, but it’s far from comprehensive, isn’t easy to understand and difficult to build actionable insights into how app performance can be improved.

However, you should use this time before October 31, 2019 to think carefully about what’s the best analytics tool for your mobile apps. Then, based on this, look around and see if there are alternative app reporting and analytics tools that better fit your needs.


Kumulos is used by a broad range of different organizations, from large multi-national enterprises to the software developers that build enterprise grade apps for their customers. If you build apps for your own customers then we can offer you something very different.

Kumulos App Performance Management platform comes with a comprehensive range of services covering the entire life cycle of the app. Its 5 integrated services include app store optimization, analytics & reporting, backend hosting, crash reporting & endpoint monitoring and its award winning push notifications service, which received awards from Business of Apps, Mobile App Daily and The Tool. It provides a management console for mobile app developers, like NS804, to gain comprehensive visibility on how all client apps are performing technically and commercially.

How much does it cost to implement wearables?

Just how much does it cost to implement wearable technology with your app? We have the answer, but before we get into it, let’s look into where the wearable market is today, and how it got there.

A brief history of the future

If there’s one burgeoning technology that has “future” written all over it, it’s wearable tech. From 2010 to about 2015, there seemed to be a contraction in the evolution of different types of consumer-facing hardware – sure, there were many different devices being created, but they all generally fit into the category of “thing with a screen.”

A smartphone is a smaller tablet. A tablet is a laptop without a keyboard (unless you’re talking about Microsoft’s Surface), and a laptop is a portable desktop computer. All of these devices were made to basically function (other than inputs) in the same manner – and during this time, innovation was based around making devices smaller, and more portable.

Mp3 players were abandoned in favor of iPods. iPods were abandoned and replaced with iPhones or Android devices.

The first wearable devices, like the FitBit, were a continuation of this trend – take a screen, make it smaller, and put it on a device. There was one important distinction with this device, however – unlike smartphones, tablets, and laptops (which all accomplish the same tasks), the original FitBit only did two things – it kept track of your daily steps, and how much time you spent sleeping.

This was in 2009 – two years after the first iPhone was released, and during the time period mobile devices were focused on adding features, not purposely limiting them.

The power of wearables isn’t their ability to do everything, however – it’s their ability to do a small range of things very well. When it comes to keeping track of steps, wearing an unobtrusive device that you don’t need to interact with is a much better user experience than taking out a phone, opening an app, waiting for it to load, starting your step counter…

What’s less distracting when you go for a run – a smartphone bigger than your hand, or a device you can wear on your wrist?

So what does a watch that keeps track of your heartbeat, steps, and sleep cycle have to do with the future? It’s because this is just the beginning.

The wearable hardware market

Smartwatches and fitness trackers – the two types of devices that immediately come to mind when the subject of wearable tech is brought up.

For good reason to – the vast majority of wearable devices sold have been Apple’s AppleWatch, which sold 1 million units in one day on its initial launch in 2014. Since then, there’s been steady, incremental improvements to smartwatches, like battery life and screen resolution. When WatchOS 2.0 came out, and apps began to run natively on AppleWatches without the help of a companion smart phone, the benefit of smartwatches began to come apparent.

Wearable tech’s association with fitness isn’t unfounded either – the fitness and sport segment of the wearable market accounts for 39% of the market share. Speaking of market share – the wearable market, while new, isn’t small at all – in the U.S. alone, there were 38 million users of wearable tech by 2018.

The truly exciting aspect of these numbers is their potential – with AR-specific products already on their way to market this year, like Microsoft’s HoloLens2, the growth and innovation the wearables market will experience will most likely be staggering – in both economic growth, and impact on society. In the U.S. market, 21% of consumers have stated they are “very likely” to purchase a piece of wearable tech like a smartwatch. With AR, VR, and MxR on the horizon, this statistic will only increase.

Just take a look at this piece from TIME about the future of wearable tech – smart clothes that provide tactile feedback paired with GPS navigation, shoes that charge your other wearable devices by utilizing the energy from your movements, and GPS enabled shirt buttons that can call 911 when you’re in danger.

The wearable software market

There are three main industries focused on expanding their markets via wearable devices:

  • Fitness and Wellness
  • Healthcare
  • Defense

Both the fitness and healthcare industries are expanding into wearables for obvious reasons – defense contractors and the DOD, however, are more interested in the application of VR and AR technology.

The healthcare industry is expected to monitor the health of an estimated 5 million patients by 2023, driving $60 billion in spending on wearable tech. The Department of Defense is expected to spend nearly $11 billion on VR wearable tech by 2022 – while that’s a hefty price tag, the amount of time and money saved in training soldiers is a much higher number.

While wearable tech will most likely never fully replace smartphones and laptops, they will undoubtably enhance the experiences they provide to users. That’s why it’s important to make sure the pain point your wearable app solves is even more targeted than a standard mobile app.

Despite many pieces of wearable tech providing the hardware layer for native, standalone apps that run independently without the help of the cloud or another piece of technology, most apps that live on wearables (especially smartwatches) are supplemental additions to an already existing app.

So, how much does it cost to implement wearables?

Luckily, developing a wearable app isn’t much different than developing for iOS or Android – there’s just a few tweaks here and there. AppleWatch apps are programmed using Xcode and Swift, just like all iOS apps, and Android Wear apps are programmed using the usual suspects – JAVA and C++.

Let’s pretend that we were going to make a wearable app for Brew Trader – it’s an app that gives users the ability to find and trade craft beer with other beer enthusiasts nearby, which they can find on a map, or through searching for a specific beer.

Let’s say the wearable app we’re developing is going to be used to supplement the process of communicating with other users – currently, users are sent a notification when they have a trade request. In order to optimize the interpersonal communication between users, and lessen the time a request spends in limbo, we decided to build out a wearable app that alerts the user about any trade requests, or responses to their own requests.

What would this require?

First, we would need to build out the UI for the wearable app – the parameters of which rely on a set of factors such as the screen shape (for smartwatches: rectangular, or circular) and model of wearable device (AppleWatch vs. Android Wear). If we wanted Brew Trader to be available for both Apple’s and Android’s wearable devices, we’d need to develop native apps for both.

The interfaces of smartwatches use different inputs and design hierarchy than mobile apps, so while it’s important to keep the styles of your app similar, it’s just as important to not reuse UI elements – you’ll end up going back to re-design them anyway.

Second, we’d connect the wearable app to the mobile app using the cloud, as well as connecting the wearable app itself to the backend database Brew Trader uses to keep track of trade requests, user profiles, and user DMs.

Third, we’d use an analytics platform like Kumulos to create segmented push notifications that alert users to trade requests, responses, and DMs.

Fourth, we’d implement the new code into Brew Trader’s code base, and add the new smartwatch functionality as an update to the already existing app.

And when it comes to implementing a wearable app into an already existing app, that’s really all there is to it. Something that’s very much worth noting – if the only thing you want to achieve by implementing a wearable app into your already existent app are push notifications (and the push notifications don’t rely on data from the mobile version), there’s virtually no extra cost. All smartwatches can display the push notifications of an app, regardless if it’s a mobile or wearable app in question.

If you want to build a wearable app from the ground up, it’ll largely be the same cost and process as normally developing a mobile app. One thing we will recommend here is to directly contact the company that designs the hardware you’re planning to develop for. The wearable industry is still very plastic, so UI/UX standards aren’t set in stone, and users are still very willing to learn new ways to interact with wearable devices. As a developer, you can actually influence the development of hardware to include physical features or processing capabilities your app would need to function. This isn’t an opportunity developers have very often, and the window to do so will soon be coming to a close.

Stories from the office – subverted expectations

When I got into work this morning, right after the first two sips of coffee, I saw an inspirational video posted by one of my LinkedIn contacts. It was a challenge he sent out – to make today the most productive we can.

I had been on a productivity hot streak – I had written and posted eight blogs in seven business days, and I was ready to blast out another piece today. After seeing the LinkedIn video, I challenged myself to write two.

Unfortunately (fortunate for the tendons in my wrist, however), the hot streak came to a close.

Our CEO is a big believer in letting us carve our own path, discover the dead ends, and learn from them. There’s never been any pressure to not make a mistake – the expectation isn’t perfection, but rather the ability to pivot quickly and make the most from (and fix) said mistake.

Mistake #1

Not talking to any devs about the content wheels the content department came up with.

Believe it or not (but it’s very believable), before I started with NS804 I had about as little knowledge about app development as possible. The first smartphone I ever got was a hand-me-down iPhone 5c in 2015. I still use it – all five available gigabytes.

I’m pretty okay at learning new things, however, which is the reason I’m here. I’ve learned a lot in these past eight months, and I hadn’t hit a snag since January when I first tried to wrap my head around writing a layperson’s guide to Android development. I’ve gotten to that point where if a developer is talking about what they’re working on, I can glean about 70% of what they’re getting at – it’s like when you can understand the words of another language when it’s spoken to you, but you can’t form them in your head to respond. In my case, it usually means I spend about 70% of the conversation nodding my head up and down, because that’s the universal way to communicate “I understood what you said, I just have nothing important to add.”

So anyway, the title of the story I planned to write today was this: “How to migrate your users when updating your app.”

If you’re a developer, you most likely just blinked from the… ridiculousness of that title.

You see, I’m a writer, not a developer. I have a degree in creative advertising, not computer science or information technology. The last marketing department I worked in was for a reclaimed wood shop.

But don’t worry – our blogs and guides aren’t pulled out of a hat and vetted by someone who doesn’t have enough technical knowledge to understand when they’re on a wild goose chase (like the situation I’m currently writing about). There’s our dev’s expert review backing our content.

Mistake #2

“If you can’t find it on Google, it might be because the thing you’re looking for doesn’t actually exist.” – Future Kate, hindsight-ing past Kate.

I mean, yes, there are better resources out there, like Stack Overflow or Exchange for the answers to detailed or technical questions. But when you’re writing a piece that needs to be understood by everyone, it’s better to start with resources that were meant to be consumed by non-tech people. You know, don’t reinvent the wheel, work smarter, not harder sort of deal.

All that I could find were how-to’s on migrating your app to the cloud – all well and good, but it wasn’t what I was looking for. I’m not one who gives up all that easily, however, so I kept refining my queries, digging deeper.

For a while I was a little excited by the thought of writing a blog on a subject no one had touched yet – the fabled nascent piece of content. Now, if you are a developer, you might be shaking your head at your screen right now, thinking to yourself, “yeah, you couldn’t find anything because it’s a literal non-issue.”

But, dear developer, to someone who has worked on re-branding campaigns, it was a natural, completely rational subject to tackle.

The funny part is that I totally understood you could update an app’s code base with anything. Sure, if it’s on the App Store, you need to get your update approved by Apple first, but you can switch out a build that was made in React Native with true Native, or vice versa.

Unfortunately for my productivity, I had to be bashed in the face with this information before it really sunk in.

I finally found the answer as to why I couldn’t find any pertinent info about user migration on Google – from, you guessed it, Stack Exchange:


“Oh,” I found myself thinking. “Duh.”

Just to be sure, I walked down the hall to our senior Swift dev’s cubicle. She was talking to our CEO, who was sitting on the comfy red couch we like to gather around, their conversation about some company growth we’ve experienced recently.

“Sorry for interrupting,” I began. “but I have a question…”

We shared a laugh, them laughing at the situation, me laughing at my own expense. If you can’t laugh at yourself, you’ll never laugh again, after all.

They quickly responded with the exact reasons listed in the Stack Exchange answer, while I nodded along.

As if the universe wanted to ensure that user migration was a non-issue, our CEO reminded me of another fact – DIY app builders like Appy Pie (again, I don’t hate you Appy Pie) retain the rights to the entirety of the code of your app – so if you outgrow their services and want to make a new app, you’re starting from scratch anyway. Because the law.

Luckily, the best part about a content wheel is you have the next six months of your professional life planned out, so I told our CEO I’d just move on to the next blog topic we had strategized on.

“Write something about this,” he said.

What are the steps to creating an app?

Do you want to create an app, but have no idea where to start? That’s okay! It’s actually not that complicated, as long as you have a roadmap to guide you.

Naturally, just like any idea or business venture, the first step is:


Whether your idea comes from inspiration from your daily life, or from finding a need due to market research, or even because your business needs an app; the strength of an idea isn’t based off of color schemes, names, or packing in trending feature sets to impress investors.

It’s all about how well your app helps solve the pain point your intended users face. It doesn’t matter what your app does, or what type of app it is – your app’s value will be judged by the solution it provides.

Gaming apps solve boredom, fitness apps help solve either lack of motivation or help keep track of goals, navigation apps help users find their way, banking apps help users answer the important questions like “Do I have enough money in my checking account for this coffee?”

You get the idea.

At this point, don’t sweat the small stuff – don’t even worry about what your app will look like. Only focus on the solution it can provide, and the most logical and practical way to facilitate that solution.

Market research

If you didn’t initially start with this step, you’ll want to do it now. You don’t even need a prototype of your app by this point – all that you need is your idea. Take that idea, and bring it to your target market. Talk with them about what they want. Go to networking events, conventions, local businesses, check out blogs, google “your idea + problems,” and most importantly, research your competition.

There’s 2 million apps on the App Store, and 2.6 million on Google Play – mathematically, it’s pretty likely someone has built an app that at least touches on the basis of your idea.

Your job isn’t to come up with an original idea – it’s coming up with the most optimal solution to that idea. If you’re worried about originality, don’t be – Homer’s The Iliad and The Odyssey covered every narrative trope imaginable – writers today just come up with ways to repackage those ideas.

Uber wasn’t an original idea – people had been flagging down taxis for a hundred years by the time Uber came along. When you boil Uber down to its core idea, all that it is is replacing a hand wave with an app – everything else is secondary. Instagram didn’t invent filters, it just made it easier to use filters to make your photos look better.

When you’re researching your competition, pay close attention to three things:

  • The UI/UX
  • The features it uses to solve the problem
  • The app’s ASO

Take from those three things the aspects you do like, and keep them. Replace what you don’t like with your own spin on things. Then, come up with how you can create a unique package for your branding. Remember – your idea, and even the features used to facilitate your idea, don’t need to be original. If you’re making an app that requires GPS and mapping, you’re inevitably going to implement location services during development – coding languages (and the methods for building app functionalities) were designed to be systematic and logical – not unique.

One more important aspect concerning market research – this is when you’ll want to decide what platform(s) you’ll use to build your app. Knowing which platform you’re building for will dictate every following step in the process of creating an app – and if you are building both an Android and iOS app version, you’ll need two dedicated development teams.

More about deciding which platform is best for your app:

Gather your resources

For you, this means finalizing your concept and your market research, and then finding a developer. Once you’ve settled on a developer, it’s their responsibility to determine your app’s feature set and the SDKs and APIs it utilizes to achieve your desired functionality.

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.

This is when it’s time to start planning out the design of your app. Some dev shops have their own UI/UX designers, some don’t. If they don’t you’ll need to do it yourself, or find a freelance designer.

App design usually begins with wireframes and color options (usually starting with the home screen and moving on from there), as well as planning out the UX of the main functionalities your app provides. Think of the inverted pyramid – start with the overarching themes, and slowly work your way down to the nitty gritty details. 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).

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

From these designs, you can build out a prototype, which is actually much easier than you’d expect, via help from different prototyping applications:

Once you’ve signed off on a prototype, your development team can get down to actually building your app. A good developer will be able to take your plan and run with it from here – they’ll obviously check in to provide you with updates, and to make sure you’re happy with what they’re producing, but they won’t be asking you technical questions – that’s why you hired them, after all.


This is a step that begins after the first lines of code of your app are implemented, and after that, testing never ends. It might sound disheartening, but that’s the nature of the beast.

To efficiently test, lay out every step of your user stories (which you and your development team came up with in the previous step) 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.

Then, it’s time for testing round two… beta testing!

Beta testing will open up your app to a small segment of the public – one that you, or a marketing agency (or your developer) will find. The purpose of a beta test is to increase the likelihood of catching bugs due to increased entropy. Beta testers, while not as detail oriented as a dedicated internal testing team, will use your app in the way they expect it to work – not the use case you have imagined. You’ll find out during this step if the two align, and iron out the kinks if they don’t.

Beta tests are important for another reason – it opens up your app to more devices and usage environments. Your app needs to work the same in a cornfield as it does on the subway. The text and font you used in your app may be legible in an office environment, but the sun’s glare might make it difficult to read. These are the kinds of details beta testing will pick up on, and improve upon.

For more information and tips about running a beta test, visit our blog covering the topic.


Before you launch your app, you’ll want to plan out your ASO. There are two fronts to your ASO campaign: user acquisition, and user retention, in that order. These can be broken down into sub-categories:

User acquisition:

  • Keywords
  • The app’s build and compatibility
  • The app’s actual page on the App Store (you can think of this as your app’s storefront)

User retention:

  • User reviews and ratings
  • Time users actually engage with the app
  • In-app purchases (if applicable)

Keywords are the bread-and-butter of any ASO campaign. The App Store’s search option functions in largely the same manner as a search engine like Google: users input a phrase or word, and the App Store displays apps based upon relevance and ranking.

Keywords are the foundation from which to build your ASO efforts, and effectively implementing them is crucial to your app’s success on the App Store. The most important steps you can take to ensure your keywords are working for you is to:

  1. Know your competition and
  2. Start with 2-3 keywords (as your campaign matures, consider utilizing up to five main keywords)

For more information about ASO, visit our blog on the topic. For more information about keyword research, check out our guide on the topic.


Congratulations! You’re almost there. The next steps are publishing your app, which will mean different things depending on what platform you want to release on. 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.

Apple has strict guidelines that must be met for your app to be approved – Android does not.

To publish an App on the App Store, you must pay a yearly fee of $99, and Apple takes 30% of profits from downloads (that 30% is only applied to paid app and in-app purchases). In order to publish to Google Play, you must pay a one-time fee of $25, and Android also takes 30% of profits from paid an in-app purchases.


As soon as your app is launched, you’ll want to start analyzing your user data. In order to do this, you’ll need to find an analytics platform. This is a very detailed and intricate process, so for accessibility, we won’t include that information on this particular blog – but you can find all the information you need about measuring analytics here.

Based off of your analytics, user reviews, and user ratings, you’ll want to start coming up with ideas for how to enhance your app. From here, you’ll begin again at step one: ideation.

Android or iOS – which is the better MVP platform?

If you’re planning on making a MVP (minimum viable product) app, there’s a good chance your reasoning fits one or both of these criteria – time is of the essence, and/or you have a limited budget. No matter what your reasoning is, however, the benefits of a MVP app’s model of development boil down to one thing: efficiency.

So, other than the generalized buzzword of “efficiency,” what makes a successful MVP app?

  • Lower development cost
  • Shortened development time
  • Consistent, user-driven, and targeted updates
  • Reduced business development cost
  • Streamlined market release
  • Discovering and refining your revenue model through user engagement

Something to keep in mind when developing a MVP app – a MVP is not a prototype. A prototype, by definition, is a preliminary model of something; a MVP is everything (nothing more, and nothing less) that a product needs to both achieve the solution to a pain point, and simultaneously satisfy customers.

Or you can think of it this way; a prototype is what it will do. A MVP is what it does.

Now that we’ve got that out of the way, let’s get to the main question of this blog post – which is the better platform for a MVP app: Android, or iOS? It stands to reason that if you’re developing a MVP, you want to make sure the development and release of your product are as efficient as possible – and with that comes the need to know which market will be the most efficient for your MVP to live in.

Which is the better MVP platform – Android, or iOS?

When it comes to overall development costs, iOS wins every category other than publication costs and investment in infrastructure – the latter of the two categories is determined by your extant infrastructure (if you already own Apple products, iOS will cost less, and vice versa). While both Google Play and the App Store will skim 30% of profits made from paid app and in-app purchases, the App Store’s publishing fee is annual, whereas Google Play’s is a one time deal.

But there’s much more to efficiency than just reducing costs – this is about the best platform for a MVP after all – not the cheapest.

Development time

Development time is determined by two factors: ease of programming, and ease of testing. Again, when it comes to the time it takes to develop an app, iOS wins the round. Why?

Android is mainly programmed using JAVA – a computer language that saw its release in 1996. While this does mean there are more Android programmers available to hire, it doesn’t equate to faster development. JAVA was written to build websites, and was later adopted by the Android platform as its de facto programming language. Due to this, Android is highly customizable – but leaves room for development inconsistencies that tend to pop up because there aren’t strict standards.

iOS apps, on the other hand, are written with Swift. Swift was made specifically for the development of apps, as well as being designed to run on Apple products only. While this does limit apps built using Swift to devices that start with the letter “i,” it does ensure a much more stable development environment. With Swift, there’s usually a right way and a wrong way to implement a functionality – meaning there’s a lot less time spent trying out different iterations of code.

The same is also true for the time it takes to successfully test your app – again, iOS comes out ahead of Android. This is for two reasons: it is simpler to produce robust code with Swift, and there are less iOS devices than Android devices (this is the main reason for the discrepancy in testing time between the two platforms).

Between the currently used iPhone, iPad, and even Apple Watch and TV, there are about ten iOS devices to test your app on (and that’s if it’s used on their entire range of products). To achieve the same level of quality assurance for an Android app, you’d have to test on 24,000 different devices.

With easier to write and more robust code, paired with a smaller number of available devices to test on, iOS apps will almost invariably take less time to develop than Android.

User engagement

While user engagement is an important metric for any app, when it comes to the development of a MVP, high quality user engagement is essential to your success. This is because MVP apps are basically a shortened version of classic app lifecycle management – rather than building out every feature, testing, and then releasing, a MVPs necessary features are implemented, then the bare bones (minimal, but still very much functional) app is sent to market. After users begin using the app and asking for extra features, the development team then works to implement the requested additions to the app.

It makes sense as to why this method of development is so cost effective and efficient – rather than guessing what features your intended audience will expect from your app, you build the main idea, and give your users the power to fill in the cracks. This saves money and time on two different fronts: you don’t waste resources implementing unwanted features, and you spend less time and money conducting market research. Your users act as both your focus group and your test bed.

The caveat here is that in order for that to happen, your user base must be highly engaged with your app – much more so than the average app user. And this is where, hands down, iOS is the stand-out platform:

  • iOS users engage apps for nearly twice as long as their Android counterparts
  • iOS apps have a higher retention rate than Android apps
  • iOS users download more purchasable apps than Android users and spend more money on in-app purchases:

  • Gaming app average revenue per user: $1.99 (iOS) versus $1.56 (Android)
  • Shopping app average revenue per user: $19.64 (iOS) versus $11.49 (Android)
  • Travel app average revenue per user: $32.29 (iOS) versus $20.47 (Android)

It’s metrics like these that put iOS ahead of Android for the best MVP platform. Without high quality, consistent user engagement (as well as two-way communication between your development team and your users), your MVP will face a much longer road to achieving your goals. This isn’t to say MVP apps don’t work on Android, just rather that iOS lends itself better to MVP development.

We hope you’ve found this guide useful. If you’d like more information about deciding between Android or iOS, check out our blogs about how to decided which platform is best for your app, and which platform costs more to develop for.

Improving inventory and supply chain management with an internal business app

Inventory management and supply chain management aren’t the flashiest of a company’s operations, nor do they seem like their efficiency could be improved by an app. But just as inventory and supply chain management are crucial to the success of a small, medium, or large business, so to are these core operations the perfect area for innovation – facilitated by an internal business app.

Ever had to search for a barcode scanner? Ever had to run off the floor to check inventory levels on a desktop computer? Is your team constantly playing catch-up at the end of the week to figure out just exactly how much of a product is left in your inventory?

An internal business app can solve these supply problems, and much more. Let’s go over how.

Common inventory management problems

What are the most common challenges inventory managers face in today’s market?

  1. Low product turnover
  2. Excess inventory
  3. Failure to keep track of stock
  4. Poor service levels
  5. Difficult identifying demand patterns
  6. Lack of visibility

Many of these challenges are amplified by the multi-channel marketplace, and the disruption of buying patterns and behaviors fueled by mobile shoppers. While these changes of scale and expected turn-around times can potentially dramatically increase a business’ profits, the rapid changes of today’s market can be difficult to keep up with, or even keep track of. It’s somewhat ironic that the mobile devices that brought about these changes are also the answer to the problems they created.

Shoppers are more efficient now than ever before – it’s time for the companies that supply the products to catch up. If a customer can see how many of a certain product remain in Amazon’s inventory, why can’t you?

You really don’t have to be Amazon to achieve that level of efficiency and inter-connectedness.

Low product turnover

Let’s face it – not everyone has the access to the amount of warehouse space that Amazon can brag about – which means warehouse space is a precious commodity, especially in a fast-paced, on-demand economy. If you’re not properly keeping track of demand, you run the risk of either running out of stock, or wasting space housing a product with little demand that could be used to hold a more popular product.

An internal business app can help here – by integrating your mobile app with your customer facing website and POS system, as well as your own internal database, every transaction is immediately tracked and reported on all of your systems. This gives multiple departments the ability to analyze customer purchasing trends more effectively and in real time – and when enhanced with analytical tracking capabilities, your system can warn you about poorly performing (or over-performing) products before they cause a speed bump in your operations.

Excess inventory

Ever order too much product? We don’t even have a warehouse, and we’re constantly dealing with the problem of finding space for all the extra water cooler refill jugs. It seems like we’re constantly bouncing between two extremes – either at the verge of an inter-office drought, or it’s monsoon season (albeit in the form of large bottle of water).

An internal app helps mitigate the risk of ordering too much product – analytics are very good at recognizing trends that wouldn’t normally be noticed. They can also even help warehouse managers find extra or unused space that could be used to store excess product.

Failure to keep track of stock

It may be a meme by this point, but modern problems do require modern solutions. With the growth of the on-demand economy, keeping track of stock with manual checks isn’t time efficient, nor as reliable as it needs to be to stay on top of fluctuating product demand.

This is a problem that’s compounded by the fact that many sales happen out in the field. Just because it’s called an internal business app doesn’t mean it’s limited to the four walls of your warehouse, showroom, or sales floor. Your sales people out connecting with and selling to clients can update your operations and inventory manager with sales they’ve made in real time.

Accounting errors add to costs – an internal app can cross-reference and compare numbers from all of your departments in real time, so when your crews are counting, you can be sure the numbers they come up with are correct.

Poor service levels

Every business knows customer satisfaction is the number one key to success, and failure to meet customers’ expectations will spell the doom of any company. Knowledge is power – and in this case, knowledgable employees means happy customers.

Internal business apps means everyone is on the same page – from your head of operations to your warehouse associates. Delivery and lead times vary depending on the product in question, and delays can lead to dissatisfied customers. An app helps optimize your inventory management operations so you don’t have to worry about a product showing up a day after it was scheduled to arrive.

Difficulty identifying demand patterns

Keeping track of demand can be made extremely difficult by continuously growing and morphing product portfolios. Product uncertainty is a very real problem these days, especially when some products have short lifecycles.

In order to stay on top of these ever-changing product portfolios, you need to use analytics tools. With an app, you can keep these tools in the warehouse rather than an office, therefore bringing more efficiency to your operations.

Lack of visibility

With a global market, accurate supply chain management is crucial to your success. An internal business app can help with that facet of your business’s operations as well. Let’s look into how.

Common supply chain management problems

Getting the right product to the right place at the right time is – to put it mildly – complicated.

Cost control

The most successful method for reducing operating costs is to make those operations more efficient. Shaving a second here or there can have a huge and lasting impact on your overall expenses.

We’ve used it as an example before, but it’s a well-used example for a reason: consider the decision of UPS to not make left turns; they invested in a software that mapped the United States (as well as most of the world), in order to nearly eradicate left turns from their parcel delivery truck routes. This decision ended up saving the company over 20 million gallons of fuel every year – those seconds it takes to make a left turn add up – and in the same manner as UPS, shaving off seconds from your warehouse operations can save your business a significant amount of capital.

When your entire team are receiving real time updates to incoming and outgoing product deliveries, and collectively can work together to achieve the same goal faster – they are no longer forced to carry a clipboard around to manually keep track of products.

With rising fuel, energy, and freight costs, compounded by a much larger International customer base, having a system that can plan efficient routes is essential to cutting expenditures.

Labor rates are also on the rise (which is a good thing!) – but that means every second spent keeping track of inventory is precious – and those seconds could be better utilized in other areas of the warehouse. With an internal business app, your employees have more time to do what they were hired to do, rather than keep track of shipments and product numbers.

Supplier and partner relationship management

Miscommunication can be a major roadblock to efficient operations. In order for your supply chain to effectively get a product from point A to point B to point C, everyone in every step of the process needs to adhere to mutually agreed standards of operations. This is especially important when assessing your operations in order to understand current performance levels, as well as finding room for improvement in your operations.

When every employee is in the know, and literally on the same page, this standard is simple to stick to. While this can be achieved through a mixture of communication methods, such as web portals, cloud storage, and email, having more than one form of communication results in wasted time and effort on everyone’s parts.

An internal app keeps all communication and analysis in the same place.

Finding talent

Like we stated at the beginning of this blog, inventory and supply chain management aren’t the flashiest of business operations. This is a big reason many employers find it hard to find and identify interested and qualified talent.

An internal app helps solve this issue via two different fronts: making the job more attractive, and lowering the acceptable knowledge threshold.

Any supply chain manager worth their salt needs an extensive understanding of every facet of your supply chain. With an internal inventory and supply chain management app, the burden of knowledge is reduced because it’s so much simpler to keep track of data – analytics can identify demand patterns before even seasoned supply chain managers would, and products are automatically tracked and updated throughout every system simultaneously.

This also helps to make positions more attractive. 70% of the workforce in the U.S. is disengaged – and one of the major reasons for this is lack of direction. An internal business app gives new employees the direction and knowledge they want, therefore increasing your employee retention and acquisition.

Apps aren’t just for consumers

We hope this blog gave you some ideas as to how an internal business app can improve your inventory and supply chain management. If so, keep an eye out for more ideas on how your business can improve its efficiency and bottom line with an internal business app!

How much does it cost to implement push notifications? – with Kumulos

Push notifications are a fantastic and proven strategy used to increase both user engagement and user retention – but are they worth the cost?

The short answer: most of the time. But let’s get into the reasons why.

The cost of implementing push notifications

Let’s start with the lowest cost option first – sending out push notifications on your own. In order to do this (at least for iOS), you’ll need to:

  1. Sign up for an Apple Developer Program Membership ($99)
  2. Set up a push notification certificate for your app ID (which you’ll get when you sign up for an ADPM)
  3. Download a push notification app from the App Store
  4. Set up a server from which to send push notifications to your users’ devices (costs for servers vary, and largely depend on your data loads)
  5. Use callbacks in the app to receive and handle push notifications

You should note that for iOS users to receive your push notifications, they must opt-in. For Android, it’s the opposite – users are automatically set up to receive push notifications when they download an app. Because of this, Android apps see a much higher opt-in rate than iOS – 91% compared to 43%.

Keep in mind, however, that iOS users tend to engage with apps more than Android users do. In addition to this, users who opt-in to push notifications engage with apps 88% more than those who don’t.

Also remember that just because you’re sending out push notifications yourself doesn’t mean that it’s free – if you’re the CEO of your company, you’re using your own time. If an employee of yours is sending them out, they’re using their own time – and time is money.

Sending a push notification, no matter if you’re supplying the backend infrastructure, is never truly free of cost. There’s also one glaring issue with sending out push notifications yourself – you lack the ability to study your push notification analytics.

Implementing push notifications through an analytics platform

If you’re invested in making a successful app, you’re most likely going to use an analytics platform in order to, well, analyze how users engage with your app. If you use these types of services, they might just have their own push notification service.

While this does cost more than sending out the push notifications on your own, successfully running an app without the support of an analytics platform is nigh impossible. So if you’re already utilizing a service like this, you might as well make the most of it.

There are a lot of analytics platforms, but we prefer Kumulos. A major reason for this is because through their platform, you can schedule, send out, and analyze your push notifications – as well as create segmented campaigns.

Bringing your analytical capabilities and your push notification campaigns together has an extra bonus – you’re able to study patterns of user behavior (like the day of the week, or hour of the day) that a user is most likely to open up your app. If they didn’t open up your app at their usual time yesterday, send them a push notification with a message that serves as a gentle reminder for them to engage with your app.

Now, we’ve stated this before, but we’ll say it again: it’s incredibly important to keep one fact in mind when sending out a push notification – you are interrupting your users’ daily lives. It’s the digital version of being handed a flier while you walk down the sidewalk – or being asked to write down your signature for a cause.

That’s why there are four key factors behind successful push notifications:

  1. Targeted
  2. Immediately beneficial to your users
  3. Attention-grabbing
  4. Billboard rule (less than ten words, ideally 7)

If your push notifications fall into the realm of “sales-y,” you actually run the risk of decreasing your app’s user engagement, and increase the chances of users abandoning your app in favor of one that doesn’t annoy them.

Bob Lawson, Founder, Kumulos says, “We 100% agree that push notifications are worth it, when done correctly. It’s far less expensive to retain existing app users than work on acquiring additional users. Having the ability to analyze the results of push notification campaigns is key to driving successful outcomes for any app.”

If you’re using a platform like Kumulos to both analyze user behavior and send out push notifications, you’re more likely to find the sweet spot between grabbing your users’ attention (for their own benefit), and interrupting them (for the benefit of your metrics). Users can easily tell which category your message falls into – and they’ll react accordingly.

This is why, even though it costs more (at least initially) to subscribe to an analytics platform with push notifications capabilities, it’s ultimately more economical to do so than going the “free” route.

Targeting the needs of your users, and providing them with a pertinent CTA is how you increase your user engagement. Shouting into the void, or asking your users to do something for your app while providing no benefit in return is how you lose users.

Here’s an example of a bad push notification:

Hi! This is _______! We’d love it if you could review and rate ______, the app you love, in the app store! Here’s a link to share us on social media: [link]

And here’s an example of a push notification that accomplishes the same thing, but in a way that’s beneficial for both your app and your users:

One month free for rating ______: [Link]

Now, that might seem like a low effort sales pitch, but what’s less of an interruption? “Here’s the thing,” versus “Hi! Here’s this great thing we’d like you to know about! If you want to act upon this thing, visit here!”

The second example also provides users with an immediate benefit: “one month free.” Don’t bury the lead.

There are other strategies for getting the most from push notifications, namely Proximity Marketing. If you’d like to learn more about that, check out our guest blog from Kumulos’ Caroline McClelland.

The last thing we want to cover is that sometimes push notifications aren’t the best way to go about increasing your user engagement and retention. Like anything in this world, context is key to success.

Understand how your users’ interact with your app, and if that interaction could receive benefit from push notifications. If there’s no benefit they could provide your app, don’t use them.

So, how much do push notifications cost?

As much as you want them to. Just remember; the more investment you put into analyzing your users’ needs and usage patterns, the more targeted (and segmented) of a push notification campaign you can make – which in turn results in better responses to your push notifications.

Don’t be the seedy car sales representative. Be the friend who wants their friend group to know about the cool thing.

Android or iOS development – which costs more?

Developing an app is never an inexpensive endeavor, which is why it’s always important to cut any unnecessary costs. What’s the most significant variable to the cost of developing your app?

Android, or iOS?

After identifying your targeted pain point, the next question you should always ask yourself is this: which platform do I launch on? Answering this question will dictate your UI, your marketing, your development, your testing – the entire strategy behind building your app, basically.

Quite often, however, the most important aspect of developing an app isn’t which platform to develop for, but which platform costs more. So, which platform does cost more to develop for? Well, by now you’ve probably noticed a pattern – it depends.

For the time-pressed reader, the more affordable option is usually iOS. But there are factors that can alter this answer, and it’s important to know why and how these factors impact the cost of developing an app.

Let’s get into it.

The two wrestling giants

Both Android and iOS boast an almost unprecedented number devices sold, available apps, and total app conversions:

  • In 2017, over 1 billion Android devices were sold, while Apple sold over 200 million iOS devices
  • As of 2018, Google Play has 2.6 million apps available for download, while the App Store comes in a relatively close second with 2 million
  • In 2018, App Annie released a report stating that the total number of app downloads between Google Play and the App Store was 28.4 billion conversions – of that number, Google Play accounted for 20 billion downloads

Android owns significant percentages of the marketplace, while iOS apps see higher user retention:

  • In the U.S., Android owns 54.6% of the market, and iOS owns 44.4% (Android is the top performer globally)
  • More iOS users download purchasable apps than Android users (11.82% vs. 5.76%)
  • iOS apps have a higher retention rate than Android (1% to 3% higher)

Something to keep in mind: While Android does account for a larger share of the mobile market than iOS (at least in terms of devices sold), this figure is likely skewed by the fact that Android comes with many pre-paid phone options, and there are no iPhone counterparts. While this larger presence seems to indicate apps available for both platforms would see more downloads from Android, we have witnessed the opposite from the data of apps we have published.

Out of these three apps, one has an audience centered in the U.S., one is centered internationally, and one has an audience split almost evenly between the U.S. and international markets.

  • For the U.S. centric app, 76% of downloads are from the App Store.
  • For the internationally centric app, 46% of downloads are from the App Store.
  • For the app evenly split between U.S. and international markets, 65% of downloads have come from the App Store.

Purchasing power and user profiles

When you compare the average revenue per user between app categories on Google Play and the App Store, despite iOS accounting for less devices and downloads, iOS apps see higher average earnings than Android.

  • Gaming app average revenue per user: $1.99 (iOS) versus $1.56 (Android)
  • Shopping app average revenue per user: $19.64 (iOS) versus $11.49 (Android)
  • Travel app average revenue per user: $32.29 (iOS) versus $20.47 (Android)

What’s the reason behind these differences? While it’s important to keep in mind that the following findings are generalizations of markets, and not indicative of every user profile, there are noticeable trends that arise when comparing Android and iOS users:

Again, these are generalizations, and should be treated as such.

Some other interesting stats on user profiles:

  • iPhone users are more likely to engage in m-commerce
  • Apple customers are loyal; 80% of iPhone users have perviously owned another iPhone
  • iOS users tend to favor social media and retail apps, while Android users favor utility and productivity apps
  • iPhone users tend to identify as extroverts, and Android users as introverts

The cost of development

Development costs, no matter what platform you’re developing for, come down to three factors: time, hourly rate, and investment in infrastructure (like the computers used for development, or the servers that house your app’s backend).

The time it takes to develop an app can be further broken down into three determining factors: ease of programming, testing, and publishing (specifically the review of your app before it is officially launched).

Swift, the coding language all iOS apps are programmed with, is robust, streamlined, and was written expressly for the purpose of building apps for Apple’s devices. On the other hand, Android apps can be built by JAVA, C++, Kotlin, and Go (among others).

While the latter two of these languages were written with the same purpose as Swift (app development), JAVA and C++ have been around long before the idea of what an app is today had come to fruition. JAVA saw its public release in 1996, and C++ was released over a decade before that.

Since these languages are old enough to order a beer and not get carded, there are more programmers who can code for Android than iOS. While this does usually translate into a cheaper hourly rate when hiring Android developers, it doesn’t always ensure you end up with a smaller bill to pay.

There are conventions that no Android developer will break – but while there might be two, or possibly even three ways to write a feature in Swift, there’s a multitude of ways to code that same feature with JAVA (the most popular Android programming language). Due to this, when comparing the two platforms based on ease of programming, Swift tends to come out on top.

If you’re being incredibly thorough with testing your iOS app, you’re going to need about ten different devices (ranging from the iPhone 5s to the Xr, to the different iPad generations, and possibly Apple Watch). To achieve the same level of quality assurance for Android, you’d need 24,000 different devices (and there were that many in 2015!).

Realistically, a good batch of Android devices to test with are all the popular and currently used devices, plus as many others as you can get your hands on. But even when accounting for ignoring 23,970 devices, those thirty remaining Android devices still add up to at least three times the amount of devices that need to be tested against. Again, when it comes to testing, and the time necessary to properly do so, iOS comes out on top.

With so many devices necessary in order to properly test your app, Android apps can require a significant investment in infrastructure. It is definitely worth noting, however, that iOS app development requires Apple products, which means if you don’t already have iMacs or MacBooks, you’ll need to find a developer that does, or foot the bill yourself.

When comparing the cost of investment in infrastructure for both platforms, it really depends on what infrastructure you already have in place – if you already own Macs, iOS would be the cheaper option. If you already own a bunch of Android devices, Android will be the cheaper option.

Publishing an app on the App Store or Google Play is a drastically different process – Apple has strict guidelines apps must meet before they are published (such as security, transparency concerning private data, benefit it provides, and uniqueness), while Android has an automated approval process. To publish an App on the App Store, you must pay a yearly fee of $99, and Apple takes 30% of profits from downloads (that 30% is only applied to paid app and in-app purchases). In order to publish to Google Play, you must pay a one-time fee of $25, and Android also takes 30% of profits from paid an in-app purchases.

It is also worth noting that for every update you provide for an iOS app, Apple must approve that update before it can go live.

When comparing the two platforms based on time and cost to publish, Android is the winner. These differences do, however, influence other aspects of your app’s lifecycle, which we’ll cover a little bit later in this blog.

The cost of marketing

This is probably the aspect of launching an app that is least influenced by which platform you’re building for – but due to the centralized nature of Apple products and customers, iOS app marketing usually comes out cheaper.

This isn’t due to Android app marketing relying on different marketing channels than iOS, but rather the scale at which Android apps must market themselves. Because Android has such a large presence in international markets (one of the main attractors to the platform), you’ll inevitably spend more time and money marketing to those extra markets than the mainly U.S., Canadian, and western European markets iOS users usually reside in.

This is also influenced by the need to market your app in the native languages of those respective markets.


Remember those strict Apple publishing guidelines? When it comes to getting the most out of the lifecycle of your app, those rules and regulations will actually work to your benefit. iOS apps are more secure, therefore they can be used for a longer period of time before being confronted with a vulnerability.

iOS apps are required to notify users of data collection, as well as receive their permission in order to do so. Because every update is reviewed by Apple before it can go live, users can always expect an update to provide meaningful, tangible improvements.

While these rules might seem strict initially, they’re powerful user retention tools. Privacy and data security are at the forefront of your users’ minds all the time, and generally speaking, iOS users can expect a higher degree of security from their apps.

One aspect of app lifecycle management where Android comes out on top is its open source nature. Because the platform itself is based around open source releases, and its core libraries are available to everyone for free, Android does have the benefit of unlimited potential for growth and innovation. In addition to this, because iOS is only available on the iPhone, iPad, or Apple Watch or TV, there is always a potential that Apple products will fall out of favor with the market.

If Samsung fails, Android remains strong. If Apple fails, iOS is gone. There is no indication that this is going to happen anytime soon, but it is worth noting.

There’s a time and place for everything

Generally speaking, if you want to access users in western markets, iOS development will be the cheapest option. If you’re looking towards international markets, Android will take the lead – at least when it comes to lifetime profits. But when accounting for time to develop and test an app, iOS will almost invariably come out on top.

How much does it cost to add a GPS & mapping API?

How much does it cost to include a GPS and mapping API in your app?

Depending on what you want your app to achieve, the answer can vary drastically. It also depends on the API you want to use, the type of app you’re making, and the functionality you want your map to provide.

Let’s go over the cost of some of the more popular GPS and mapping APIs, starting with the most well-known of all:

Google Maps

First of all, if your app is free (as in no cost to download, no ad revenue, and no subscription fee) Google Maps is free to use. This includes all of their API’s functionality – directions, routing, street view, and all the other functionalities.

Google Maps also provides developers with the ability to customize their map – this includes colors, information presented, and much more. The customized map can then be copied as simple Javascript to be implemented into your app – this works with both Android and iOS platforms.

Google Maps’ costs are as follows:

  • Embed Advance: $14 per month
  • Static Maps: $2.00 per month
  • Dynamic Maps: $7.00 per month
  • Static Street View: $7.00 per month
  • Dynamic Street View: $14.00 per month

For more information, visit Google Map’s pricing page.

Keep in mind that even if you’re on a free plan for Google’s API (or any API for that matter), it still takes time and costs money for developers to implement that API into your app. Most APIs also require a backend through which they access data, which adds to your costs. Backend service pricing varies wildly.


Another GPS and mapping API, Mapbox is free-to-implement as long as you stay below the magic number of 50,000 views/requests/users a month. Mapbox gives developers the ability to provide users with real-time navigation, augmented reality, and data visualization. Their API is customizable, and their tools for visualizing data can be used on the web, mobile, and desktop.

If you go over that magic number of 50,000, the price moves up to fifty cents per 1,000 map views, geocoding requests, directions requests, matrix elements, and Tilequery requests. If you’re building an enterprise app, you can get a volume discount if your numbers are over 5 million for the same categories.

Mapbox can be implemented for both Android and iOS apps.

For more information, visit Mapbox’s pricing page.

Tom Tom

Tom Tom is yet another mapping API – rather than providing a pricing plan based on interactions per month, Tom Tom offers you 2,500 API transactions on a daily basis. This number is reset each day. Keep in mind that a transaction isn’t a user opening your app, using the map functionality, and then closing it. For their maps API and traffic tiles, one transaction is equal to fifteen requests.

If you’re going to go above those 2,500 free transactions per day, you can check out Tom Tom’s pricing page here. For 50,000 transactions, the price is $25.00, and for ten million the price is $4,199.00 – as you can see, depending on how many users you expect, your costs can vary significantly.

So just what are GPS and mapping APIs?

First, let’s cover the basics – API, just in case you aren’t familiar with the acronym, stands for Application Programming Interface. Basically, an API provides a developer with set of functionalities and protocols that define how pieces of software interact with each other.

In regards to an what an API call (also referred to as an API request) is, it’s essentially a piece of software in an app connecting to a server in order to transmit data between the server and the app. This is all made possible by backend integration.

This is how GPS and mapping APIs are able to update users with directions, or can display (and react to) traffic conditions. Every time your users interact with the mapping API your app uses (for instance, finding the nearest gas station) they are guided by directions that are provided by multiple API calls.

The app communicates to the server where it is, and the server uses that data to correctly display the next step in their route. This process is continued until the user has reached their destination.

This is why most GPS and mapping APIs offer different options from which to mix and match – and why you should choose which features you want to include carefully. While mapping APIs are designed to scale with your usage volume, they do become more expensive as your user base grows.

It’s always easier to add functionalities than it is to take them away – your users will be disappointed and dissatisfied if they notice a feature that was available to them is no longer there.

That’s why we recommend starting out your app as an MVP.

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:


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.


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?