The Parse shutdown is approaching – and now that we’re in 2017, it’s getting closer every day.
Back in January 2016, Facebook announced that it was shutting down their Parse server application on January 28, 2017. And – if you haven’t changed your calendars yet – January 28 will be upon us in just a few short weeks. There were a lot of rumors and speculation about why Facebook decided to shut down Parse: as an “aquihire”, to add more functionality to Facebook login, because Parse wasn’t profitable – but, in the end, Parse just didn’t fit into Facebooks new revenue model.
So, come January 28, if you are still trying to run an app with Parse, you’ll find that the Parse API no longer works, databases can’t be accessed and Parse Hosting Services are kaput. Which is pretty much what Facebook has been warning developers since 2016.
To put it simply – as we like to do here – Kumulos is THE app build platform you’ve been dreaming of. But if you’re already happy with your current backend provider and just need to replace Parse push – no problem – we think you’ll find our UNLIMITED push notification service more than enough to fit your needs.
And we have a handy Parse Migration guide to help you step through moving over from Parse to Kumulos. Because that’s just how much we like you.
Don’t think of this as an end – think of it as a beginning. The beginning of a new and better way to build awesome apps for your clients, with Kumulos right there by your side.
Generating more downloads and attracting new users to your app can be (and generally is) an expensive business. It’s estimated that a 5% decrease in mobile app abandonment rates can actually increase overall app profitability from as little as 5% to as much as 95% (Bain and Company). While decreasing app abandonment rates can greatly improve profitability, it costs approximately 700% more to acquire a new mobile app user than to stimulate retention with existing users. If you’re running a mobile app development agency, it’s essential that you represent the best commercial and technical interests of your clients. Their success is your success and the best way to maximize the chances of a successful outcome is to focus on mobile app user retention.
Before we go further, here’s a great panel discussion on some of the issues that we’ll be writing about:
When it comes to developing mobile apps for your clients, your contribution won’t end when you deliver them their app. The days of being able to “drop-ship” an app to a client and walk away are over. Clients now expect you to be with them for the long haul, helping them make their app a success. They expect you to be their mobile marketing adviser. With any client’s app you have to ask yourself the question: how sticky is the app? In the same way that digital marketers are concerned with the engagement levels of blog content, videos and reviews (and a multitude of other types of content), app clients are concerned with one fundamental consideration: are my app users coming back for more? So serious mobile agencies are going beyond the design and development of great mobile apps. They are focused on how to leverage more value from those apps on behalf of your clients’. To do that they are increasingly thinking about how to measure retention.
Getting serious with mobile app retention
There’s a bunch of different ways to measure the retention performance of your clients mobile apps. Getting started with mobile app retention is all about understanding the needs of your app client, and each approach will possess its own merits and shortfalls in terms of selecting the right retention methodology. But the important thing is to focus on what matters. Bringing in new users at the top of the funnel via marketing efforts is totally superfluous if the bucket itself is full of holes and the UX of the app sucks. Mobile app retention is all about fixing the bucket, and making sure that the overall UX of your client’s app is adding genuine value to the experience of the user. So always start with the end in mind. It’s all too easy (and costly) bringing users in via paid channels, but getting them to hang around is a different ball game.
The purpose of mobile app user retention
The goal for each of your app clients is to convert each new app user into a paying customer or loyal advocate (depending on the industry sector and purpose of the app). Your job, as a mobile app agency owner, is to help take your clients on that journey. To to this it’s important to keep the purpose of what you’re trying to do clear: focus primarily on retaining the people you’ve already attracted and learn how to drive more engagement and revenue for your clients.
Here’s a short article to give you some ideas on how to improve app engagement.
If your client’s mobile app is churning too many users after a single use, you have a serious problem, purely due to the cost of attracting new users vs. the cost of retaining existing app users. This comes back to the leaky bucket analogy, because the economics of filling the bucket in order to patch it up are incredibly costly and damaging to your client’s commercial welfare. This is why the economics of mobile app marketing will always favor retention over acquisition. So with this in mind, consider very carefully how and where you invest your clients technical and commercial resources and always keep the end in mind: what does success look like? This is a difficult question to answer, but when it comes to industry benchmarks for mobile app retention, there are some guidelines, which will be covered later in the article. Based on the fact that you can only optimize what you already measure selecting the right retention methodology is the first step in the process.
Each mobile app client will view the science of retention from a slightly different perspective. If you’re developing a mobile game, you’ll live and die by the retention performance of the software on day one. If it sucks first time round post launch, you probably won’t get another chance to fix it. On the other hand, if your client has a B2B app where take-up will be slower, you might need to think about starting to track retention at a much later date, maybe month eighteen. The better you can understand their app, their commercial goals and the journey each of their users take through the app, the better positioned you’ll be to nurture it to success. In order to choose the right mobile app retention methodology to use, you’ll need to understand which options are available. This is where snapshot retention comes in.
What is snapshot retention for mobile app users?
Snapshot retention is a specific method of measuring the retention rates of mobile app users. It refers to a retention methodology that’s based on a snapshot of time of mobile app user activity. This is one of the best places to start if you’re trying to figure out the easiest and most basic way to measure retention rates for your app clients. Start off thinking about your client’s business goals and what they want to achieve. If the launch of the app is being run in parallel with an expensive marketing campaign, and the goal is to generate paying customers quickly, you’ll need to snapshot different time periods. The first day will be essential, but it won’t provide the full picture and help to identify if the app is sticky. This may only become clear after several days or weeks (or possibly months and years), so it’s essential that you work out the best way to measure each snapshot of app user retention in terms of time. But what matters, is that when you’ve decided on the right time frame, you’ll end up with one very concise way to express mobile app user retention as a single metric (or ratio).
The MAU vs DAU ratio for mobile app user retention
The MAU vs DAU ratio is a great example of a snapshot metric, whereby the DAU’s and MAU’s are simply the number of unique mobile app users who engaged with your client’s mobile software during a specific time period. A DAU, or daily active user, measures the number of unique app users in any given one day time period (often you’ll be referring to the performance of your client’s app for the previous day). An MAU, or monthly active user, measures the total volume of unique mobile app users, who are active in any given month or thirty day timeframe. This will typically be a rolling thirty-day time window whereby you can glean performance insight not just by each calendar month, but also by a fixed or ‘windowed’ thirty-day time period.
Once you have your MAU vs DAU metrics for a given timeframe, calculating mobile app retention rate is just a simple process of developing a ratio of DAU’s to MAU’s. Instinctively, when it comes to working with your app clients, this should represent the proportion of monthly app users that are active on a single day. Clearly, when it comes to enhancing the performance of your client’s app, the job is to increase the ratio, ensuring that you maximize the proportion of MAU’s who are liable to actively interact with their mobile app on a single day. Once you have the data, you’ll be in a position to make recommendations in terms of changes that can be made to the app, in order to cause a greater proportion of users to interact with the software on a regular basis. You can also update your push notifications or proximity marketing strategy. What you’re striving to achieve, is a ratio of one, because this means that every single mobile app user who engaged with the app in the last month, is active again on any chosen day.
Again, getting this part right will depend on the type of app your client has. Different apps will have different DAU/MAU benchmarks. It’s all to do with what the expected frequency of use should be. If it’s an app that is to do with something the user will do every day, then you’d expect the engaged user to be using the app daily. A diet tracking app for example. If it’s an app that you’d expect less frequent use, a restaurant booking app, then monthly may be the expected use frequency. It’s about setting the right benchmark use for the individual app. Irrespective, it’s essential to continually track the DAU/MAU ratio, to make sure its getting better and not worse. A falling ratio is a good lead indicator that things need addressing. Rule of thumb, for most mobile apps, 0.20 DAU/MAU is considered to represent decent level of engagement. So generally speaking, if 20% of MAU’s are interacting with the app on a daily basis, this is good. Another option is to consider using a DOD (or ‘day over day’) retention metric.
What is day-over-day (DOD) retention for measuring mobile app performance?
DOD retention is much like the MAU/DAU ratio, but provides a detailed snapshot metric. With DOD retention analysis of mobile app user behavior, you simply establish the ratio of the app users who are active today and yesterday, relative to the number of app users who were only active yesterday. This retention measurement ratio symbolizes the proportion of users who are liable to use your client’s app regularly in a short timeframe. In order to calculate this ratio, you establish the number of users who were active yesterday and today, and divide by the total number of users who were only active yesterday.
The constraints and limitations of snapshot retention for measuring mobile app performance
Helping your clients succeed and nurturing their apps to success, it’s going to be important establishing a mechanism for measuring mobile app users. Some of the methods detailed in this blog post represent a good starting position and will increase your client’s chances of success in mobile. As always, your ability to track the right data points will depend on your ability to garner the right information, and this means having a robust analytics platform. You must always ensure that this has been considered at the front end of your client’s project. You need to think about developing a clear and concise series of KPI’s and understand in detail how snapshot retention can bolster performance over time. But snapshot retention metrics are relatively simple in their nature, and do possess certain drawbacks and constraints:
These techniques will determine all mobile app users who are active only during a certain snapshot, regardless of when their first touch point was with your clients app
This provides very little or no distinction between mobile app users who are completely new to the software, and habitual mobile app users who could be considered as advocates or evangelists.
Determining the cause of why specific data patterns appear in the analytics can be extremely difficult and understanding how to improve mobile app performance and knowing what to do can be ever harder.
That said, having the data that helps you build insight into how the app is performing at least arms you to ask the right questions and dig for the solutions.
How to avoid an unhealthy DAU/MAU ratio
So you’ve spent months, designing, developing, testing and polishing your client’s mobile app and it’s now ready for launch. You’ve established your KPI’s and key measures of success. You’ve also integrated an analytics package that enables you to track mobile app retention performance. Now what?
The classic mistake to make when launching a new mobile app for your client is to focus on creating a bloated MAU ratio. If you accompany the launch of the app with an integrated marketing campaign, you’ll likely see a huge spike in activity in the first day or two after launch. Adopting this type of ‘Hollywood or bust’ approach, whereby you rely solely on the success of an initial marketing flurry, is liable to result in failure and an unhappy app client. Getting this process right requires time and making sure you know when to bring new users in at the top of the funnel. The best time to bring new users in at the top of the funnel, is when you know that your bucket is fixed, and you’ve maximized the probability that the greatest number of users possible will use the mobile app on a regular basis.
The problem is that all too often, an impressive MAU metric is viewed as being a positive thing. What tends to happen, is that users who were acquired as part of a ‘Hollywood or bust’ style marketing campaign, will possess a significantly higher churn rate than other mobile users. The fact of the matter is your client does need a large MAU metric. Your client wants the type of mobile app user who isn’t just a passer by. Your client wants the type of app user who discovers the software and sticks around because the features contained within the app are delivering something of value to them. The net effect of this type of marketing approach, is usually a weak DAU/MAU metric and the key to solving this problem lies in relentless and pragmatic approach to measuring and refining the onboarding and in-app experience. What’s more, an initial burst of marketing activity will impact the MAU metric within the first thirty days, but it wont explain what’s actually happened or why. So a good MAU metric on its own is a vanity measure and one that offers very little insight into whether the app is succeeding or not.
In conclusion, the best way to approach this problem on behalf of your app clients is to tread a careful line between mobile app user acquisition and retention. Yes, you need to bring users into the app in order to test if the bucket has holes, and this involves marketing be it paid or organic. But the trick here is not to over invest in marketing that is ultimately the equivalent of pouring water in a bucket full of holes. You need to pour in just enough water, without over investing; in order to get the right data to inform how you fix the UX issues associated with your client’s app.
If you’re a mobile app agency looking to bolster the retention performance of your client’s mobile app (or apps), Kumulos can help. Our Mobile App Agency Platform comes with integrated app Analytics to let you measure engagement and Push Notifications & In-App Messaging to manage engagement programs. This lets you offer your clients App Engagement Services that helps drive the right outcome for your clients and get apps on retainer, so you build reliable recurring revenue streams for your business.
We don’t care whether you’re building native apps on iOS and Android, or using your preferred hybrid platform, or a low-code / no-code platform, you can use Kumulos to help you deliver greater commercial success. We partner with a range of technology providers so you can have it your way.
A successful product, in pretty much any category, is not defined (just) by how many people are using it, but (also) how many people are using it – frequently.
Think about it – if you hear a really good song on the radio – you’ll probably want to hear it a hundred more times. If you find an awesome restaurant in a back alley somewhere, you’ll keep coming back for that teriyaki wok. So what do radio editors and restaurant managers do when they notice you like the song/food? Radio editors might keep playing the same song every day. Restaurant managers might send a glass of wine your way, on the house, to let you know they appreciate you coming every once in awhile.
The same thing as with apps – important as it is to have people downloading your app, that doesn’t mean you’ve completed your work. On the contrary, my dear Watson – only then is your true task just beginning.
Building the app is the easy part – now you need to focus on making people return to the app. In turn, transforming them to regular users and giving you various chances for monetization. That is the true challenge here – to get as big of a retention rate as possible, and to convert one-time users into regular returnees.
Analyzing user retention
The best way to measure how successful an app is to track retention. Some may argue that engagement is the best way to go – but not all apps are created equal. While some (for example, Shazam) might have fairly low engagement, others (Facebook) might have it high. That doesn’t mean both apps won’t be able to monetize properly, which is why it is best to focus on retention.
Retention is a metric allowing you to see how many people are returning to the app. As you try to engage with them, retention will help you understand which parts of your app are working and which are not. This will help you make tweaks in order to keep your users coming back for more. By constantly making improvements, you will keep your users and keep that conversion rate high.
If you want to measure retention, you need to understand how often users are returning in a set period of time. That is best done through cohort analysis, which groups together people who have started using your app at approximately the same time and shows you, in percentages, how many are returning.
Through cohort analysis, you can look for specific patterns in behavior, identifying your most loyal users, as well as those that were the first to quit. By looking at specific groups, cohort analysis can help you figure out if your retention strategies are bearing fruit or not.
Example of retention cohorts
Now, we won’t go in depth on what you need to do to keep your users engaged, and coming back for more – that’s a whole other post(s) in and of itself. Assuming you already know, and have devised a strategy, we will just focus on how to measure the success of that strategy: user retention. In particular, we’ll on that little extra you can do to improve that analysis.
Quantity craves quality
Quantitative analytics will tell you plenty about your app and its users – it can tell you the number of downloads over a specific timeframe. It can tell you how many active users your app has, how long they stick around, and how often they come back. You can get plenty of information about the time of day, week and month when your app is at its highest, and lowest points.
But all that information won’t help you improve the retention rate among cohorts, as it tells you very little about the experience users are having with your app. It doesn’t tell you what they’re doing when they open the app up, what they find most enjoyable, and what they’re struggling hardest with. The time of day when people use the app will tell you very little about the frustrations of a poor user interface, or if you have a non-working button, somewhere in the app.
For that, you’ll need that ‘little extra’ we mentioned earlier – qualitative analytics. All the engagement users have with the app, including tapping, swiping or pinching. Which parts of apps they interact with most, and which are just there to collect digital dust. All that information, which can prove invaluable to improving user experience, thus improving retention, is accessible through visual app analytics – something Appsee, for example, has to offer.
Now we will go through some the features visual mobile app analytics can offer, which can be a gamechanger when it comes to improving retention rates.
First up are touch heatmaps. This feature will place a visual layer over the entire app to show you exactly where people tap, pinch and swipe within the app. Using the same color-coding principle thermal goggles use, the feature will show you which parts of the app are used the most, and which are being neglected.
Here’s an example of how touch heatmaps can help you improve retention. Let’s say you have an app with a login screen. It allows your users to log into the app using either a custom account, or their Facebook and Google accounts. In that screen, you’ve noticed through touch heatmaps, that a lot of people are swiping across the bottom of the screen, looking to proceed without registering, or logging in at all. After they realize they can’t enter the app without registering, they quit, never to be seen again.
This might prompt you to create a ‘Enter as Guest’ feature, solving an important issue for a group of users, effectively improving on the overall user experience and beefing up that retention rate. That is exactly what touch heatmaps can do – the feature will give you more insight into user behavior, which is essential to understand if you want to improve the user experience, and ultimately – retention.
For more examples of how touch heatmaps can improve your mobile user interface, make sure to check out this infographic, as well.
Real-time, information sensitive session recordings of users interacting with your app can be crucial to your app’s success. This feature will let you see exactly how users engage with your app, what they do, if and where they get stuck, and which parts of your app cause frustrations.
For example, if you have a mobile game and you notice that many people reach level 10 and just quit there. You know that a lot of people quit there, but don’t really know why. By watching a replay of a user session, you could potentially find a design flaw which makes it close to impossible to finish the level, frustrating users and making them quit.
Or another example. Let’s say you have a shopping app. One of the biggest challenges for many shopping apps is that people tend to abandon their carts (shopping cart abandonment rate for mobile is at a stunning 97 percent). You see that they’re quitting, but can’t point a finger at a concrete issue. By watching user sessions, you realize that many users experience multiple issues before actually making the purchase.
Events like these happen all the time, and only by visualizing what your users are experiencing, you can optimize your user interface to keep your retention rates high, bring back old users and even onboard new ones. Session recording is the most powerful qualitative analytics tool, as it literally puts you into the shoes of the user and allows you to experience both good and bad sides of your app. Understanding your users’ troubles can help you build better future versions, and there is no better way for user retention than actually solving the problems they’re having.
Monitor, optimize, rinse and repeat
User retention is a process – not an event. You are never done optimizing your app. If you want to keep your users engaged and keep them coming back for more, you need to be engaged as well.
It all comes down to monitoring, optimizing, then repeating the process.
Every strategy, user retention included, needs to be based on solid, actionable data. Quantitative data can tell you a lot about who your users are and how much time they spend with your app, but it won’t tell you how they actually feel using it, and if they’re experiencing hair-pulling moments.
Through qualitative analytics, and tools such as touch heatmaps and session recordings, you will be able to understand exactly where the problems and nuisances lie within your app, and where your focus needs to be next. And that information is, without a doubt, essential to optimizing your retention strategies.
Hannah Levenson is the Content Marketing Manager at Appsee . A UX and mobile app enthusiast, she has a great affinity for discovering and sharing unique insights and resources with the mobile tech community. Hannah also loves photojournalism, classic rock, and pretending that she’s the only one with a “foodie” Instagram account. You can follow Hannah on Twitter @HannahLevenson.
Mobile apps are so ubiquitous nowadays that almost all companies can think of at least one way in which an app could enhance their business. On top of this, an increasingly large number of hugely successful companies have an app at their very heart – just think of Uber, Shazam and Flipboard if you need a few examples.
Whether you want to build an app to provide a better service to your customers, or build a whole new company around an app in the hope of becoming the next big thing, it’s important to consider certain things before you get started.
This article lists five steps for building a successful mobile app – don’t begin your app development without reading them!
1. Gain a clear idea of what you’re aiming for
This may sound really obvious, but it’s extremely common to hear of companies wanting an app (after all, “everyone else has got one”) without really having a clear idea of what it’s going to do. These unfocused people can land themselves in a whole range of undesirable situations; Unfocused thinking leads to an unfocused app – and modern technology users are a demanding bunch with a short attention span.
If you don’t have clear ideas, you are at risk of being provided with ideas by app developers who are often only trying to help. While it’s essential to work in partnership with your developers, it’s crucial to start out with a spec for what’s actually needed. The people who best know what your app needs to do are people within the business and, if the company is already in operation, the customers.
2. Be prepared to treat your app as an ongoing project or business
A HUGE misconception about apps is that they are a “job and finish” task. If this were remotely true, we’d never see software updates, and apps would all look the same as they did five years ago!
Even if you don’t think the core of your app will change much, there’s absolutely no way that you won’t have to treat your app almost as a living being.
Technology will move on, customers will demand new features, and sometimes something as simple as an operating system upgrade will require some coding for compatibility. So don’t think of an app as something that’s done once it’s built. This is merely the first step in the journey. This is even more relevant if the app is at the core of your business!
3. Keep an open mind on pricing
There’s no doubt that you’ll be able to find individuals who will build you an app “on the cheap,” such as students who’ve just learned objective C, or inexpensive off-shore freelancers.
Unless you’re happy to manage them extremely closely and shoulder some risk, think really carefully about taking this route and allowing a “race to the bottom” in terms of price. As per the previous tip, creating your app is not a one-off job if you want to take it seriously, and plenty of people come unstuck when they end up with an app that’s unsupportable because nobody really understands how it was put together in the first place. This was (and remains) the case with website and database projects too.
What you should pay for an app is a quintessential “how long’s a piece of string?” question. The answer is probably a little more than you’d hoped, but not as much as you’d feared! According to the folks at Dogtown Media, app development can run anywhere from $25,000 up to $500, 000 (and beyond). Finally, remember that you need to account for the ongoing development and support for your app, and not focus on a one-off headline price.
4. Get a prototype ready
Nothing puts the nails in the coffin of an app more than launching it without proper testing. Consumers can be savage when an app doesn’t provide instant gratification and will show no mercy in uninstalling and leaving a negative review – which (of course) will put off future customers.
For this reason, it’s essential to create a prototype and test it to within an inch of its life, perhaps with a select group of beta testers, before letting it anywhere near the public. Bear in mind too that, as discussed above, your first app release will be a 1.0 version!
This is widely known as a “Minimum Viable Product.” Within days (if not hours) of releasing this, you’ll probably start to think of new features that should be incorporated into version 1.1 and beyond!
5. Launch only when ready!
It’s really unwise to set a date to release your app and stick to it regardless of what happens. Do you want an app released on time to widespread negative reviews, or an app released several weeks late to widespread acclaim? Hopefully the answer is obvious.
Once you have launched, you’ll want to see how your app is performing – obviously the reviews will give you a broad picture, but you can go way beyond this by using mobile analytics to find out exactly how customers are using your app. Analytics will help you find which features are working and which your users are engaging with. From there you can go back, refine, improve, and move towards the next version – just as we discussed above.
What do you think? Any steps we left out for building a successful mobile app? Feel free to leave a comment below!
Kumulos gets the thumbs up from two leading mobile companies, listing us as the best mBaaS (mobile backend as a service) platform available today and the best alternative to Parse.
Here at Kumulos we are blown away to get two such strong endorsements from two great companies. Both companies are themselves recognized as thought leaders in the mobile technology space and they appreciate the value that Kumulos brings in helping mobile app development agencies grow their businesses. This further solidifies Kumulos position as an mBaaS market leader and in particular reinforces how much of a good a fit it is for Mobile App Development Businesses.
Waracle are one of the UK’s largest mobile app & IOT development agency working across a range of sectors from pharma and healthcare to banking and utility companies. You can read the Waracle story here.
“Kumulos has become our favourite mBaaS platform offering a wide variety of awesome features to help you develop, deploy and optimise your apps. What’s great about Kumulos is the fact it works well for indie mobile developers and big agencies alike.”
Carnival are a world leading push notification & marketing automation platform, working with huge global brands like Coke, CNN & Dreamworks. We’re pumped to be their top pick as the best mBaaS and best alternative to Parse. You can read the Carnival story here.
Guy Horrocks, CEO of Carnival says:
“Kumulos is an excellent solution for agencies looking to simplify the way they manage mobile data. Their flexibility, support and guidance is unmatched, especially when dealing with complex implementation questions, and their white label option is an elegant way to manage multiple projects. The team really cares about your success, which stands out in a category known for low-touch interactions and self-service.”
Kumulos is one of the longest established players in the mBaaS space. Over the years we have been highlighted by industry giants Gartner and numerous other technology blogs and review sites as one of the best mBaaS providers. We’re extremely thankful for all of the support.
Kumulos – The best alternative to Parse
In January 2016 Facebook announced it was pulling the shutters down on Parse. The Parse platform was acquired by Facebook and billed as an ‘unbundled’ platform-as-a-service for mobile development teams and agencies. Facebook closed the ‘as-a-service’ element of Parse in order to focus on developing and optimizing its own suite of mobile apps. Facebook had originally acquired Parse for $85 million in 2013 and became (to some extent) the focal point of the company’s developer offering. It made huge sense for Facebook to focus on their own suite of products rather than enabling other developers to build competing platforms. But the news sent shock-waves through the mobile app development community, and has forced developers and agencies to source new alternatives to host and manage their app projects via the cloud.
Fast forward and we’re delighted to be acknowledged as the world’s best alternative to Parse. Picking up where they have left off, we are now recognised as the best mobile backend as a service platform for Mobile App Development Businesses & App Agencies.
The App Build feature in Kumulos is a mobile Backend-as-a-Service (BaaS) on which you can very easily and quickly build and host your App Backend. App Build provides secure, scalable SQL based data storage in the cloud that can then be accessed and manipulated via a REST API and/or RPC API methods from one of our many client SDKs including iOS, Android, PHP, Windows, OSX and more. This leaves you free to focus on building the rich UI and UX that your clients crave, without having to worry about the hosting and availability of your app backend.
In part 1, we looked at how to design the relational data model for your app backend with Kumulos. Now, in part 2, we’re going to use these example data models to implement your app backend in Kumulos, showing how this then allows related data to be retrieved from a single API method.
Implementing one-to-many relationships in Kumulos
In part 1, we used the example of a mobile application that allowed users to upload and share photos to illustrate how the one-to-many relationship can be used to model related data. We also showed how this relationship can be implemented using a Belongs To field. We’re now going to look in detail at how to implement this data model for your app backend.
First off, we need to add a table to store a user’s name and the date of their birthday.
Next up, we need to create a photos table, containing a data field for the photo data, a title and a description.
A photo has a photographer who took the photo, and any given user has a collection of photos. The Belongs To field is used to express the one-to-many relationship as follows:
This record belongs to ‘Users’ as (their) ‘photos’. This record has a ‘photographer’.
When a user is deleted, any photos that they’ve taken will also be deleted.
We can extend our data model further and introduce the ability for users to comment on photos. To do this, we need to add a comments table to store comments on photographs.
This table used two Belongs To fields to implement two one-to-many relationships. First, we say that the comment has an associated photo, and the photo has a collection of comments.
Next, we say that the comment also has a creator (a user who posted it) and therefore each user has a collection of posted comments.
Because a comment belongs to both a user and a photograph, when either the owning user or photo are deleted, the comment will also be deleted.
“postedComments” is used instead of “commentsPosted” because Kumulos determines the relationship type from whether or not the word in the “as” section is singular or plural. So, you must use phrases ending with either a plural (for one-to-many relationships) or singular (for one-to-one relationships) noun.
Implementing many-to-many relationships in Kumulos
In part 1, we used the example of a mobile application that allowed users to share their favourite meals to illustrate how a many-to-many relationship can be created using two one-to-many relationships. Lets look in more detail at how to implement such a data model for your app backend.
Lets add a table to store information about people. Essentially we want to know their name and why they like food.
We’ll now add another simple table storing a title, description, and the name of a chef who is famous for the meal.
Now, here’s where the magic of this data model happens. We add a favorite meals table to store the link between a person and a meal. It also stores what the person likes most about the meal.
The many-to-many relationship between people and meals has been captured by these two one-to-many relationships:
One person has many favorite meals (through connoisseur)
One meal is the favorite dish of many connoisseurs
So, to select a person’s favorite meals, you should select from favorite meals (including the meal record) and filter the select by the person’s ID. Similarly if you want to know who likes a particular meal, select from the favorite meals table (including the connoisseur) and filter by the meal ID.
Because a favorite meal belongs to both a person and a meal, if you delete a person then the entries for their favorites will be deleted but the meal itself wont. The same is true if you delete a meal. Any people who like that meal will stay put but any trace of them ever liking it will disappear.
Fetching related data from your app backend
Having added Belongs To fields above to implement the one-to-many and many-to-many relationships in your app backend, you can now exploit these relationships to fetch related data from your app backend with a single API method. When you create a new API method with a select action, the API editor will allow you to include records linked by “Belongs To” in your result from select actions.
Using our mobile application for sharing photos as an example, we can add a new API method on the photos table.
Then, we can check the comments box to say that we want the related row(s) from the comments table returned with each row from the photos table. Neat huh!
In Part 3, we will look at how we can go a step further and filter the data you fetch from or update in your app backend based on the data it is related to. But again, if you cannot wait until then, further information can be found in the docs.
Well… Facebook made the Parse closing announcment. I for one am more than happy to admit that, along with everyone else on the planet barring a few executives inside Facebook, I did not see that coming! The furious activity on the Kumulos Slack channel at 11pm the night the news broke is testament to that!
Watching the reaction to the unexpected announcement that Facebook was shutting down its Parse mBaaS has been interesting. #parseshutsdown #lifeafterparse – I even saw one company offering “Counselling” but I’m going to give them the benefit of the doubt and assume they meant “Consultancy”.
I know Parse had its fans but it’s not like when 90’s band Take That split up!! (Our digital marketing coordinator wanted me to change this to One Direction, but I’m keeping it real, “Never Forget”).
Who is saying what about the Parse closing announcement?
Social Media has been dominated by three main personas:
Developers who rely on Parse to host their app’s data and are now, understandably “Concerned” (okay, okay, some do need counselling).
Industry commentators rightly speculating on what this means for other mBaaS vendors and the mobile app developers who rely on them.
mBaaS vendors, old and new, offering either migrations or hosted Parse-as-a-service (hmmnn – “PaaS” is already used, so is this “hPaaS”?)
The only notable absentees are the poor startups who were building SaaS products for developers on top of Parse – an indication of just how big the Parse community was becoming – spare a thought for them!!
However, this post is primarily for the #1s, and I know there are a lot of you out there. I think I am somewhere in between #2 and #3 on the above list – I’ll let you decide which side of #2.5 I am after you’ve read this! Oh, and from now on, if you could read this in your best Liam Neeson accent, that would help out a lot.
The next part is very important.
You are going to have to rebuild your app.
That’s the bad news, which in itself is not actually all that bad – regularly updating an app is one of the best ways to ensure that app ranks highly in the App Stores. However, the really good news is that you have a year to ensure that when you do rebuild your app, you choose the right platform for you.
Oh, and I do have a very particular set of skills. Skills that I have acquired over a very long career (sorry, couldn’t resist). There is an element of truth in that (bear with me). Kumulos has been around since before Parse and in that time we have seen many different mBaaS vendors (remember StackMob for example) come and in some cases surprisingly go?
Will Parse live on?
Parse have announced they are open sourcing their server so you might be tempted to host it yourself or switch to one of the new vendors offering hosted Parse-as-a-Service. However, before you do, look carefully at what is included so far. There is no analytics, no key/value store for config, no UI to browse your data, no scheduled jobs etc. There are also (last time I checked) over 40 open issues. I am sure that Parse will open source more of their platform and that the not-insignificant community will address issues as they arise and maintain SDK compatibility with new iOS and Android versions for the foreseeable future. However, if Facebook can’t make a commercially viable business out of Parse, can anyone?
Indeed, while I am sure Facebook wanted to retain the very talented team behind Parse, I am equally sure that if it was making money, they would look to sell the Parse business rather than shut it down.
When choosing a platform, you need to consider will it be around as long as you, your business and importantly your clients’ business will need? Sure, Microsoft Azure, AWS and Google Compute are unlikely to ever go away. However, I bet if I asked that same question a week ago, Parse would be in the same list!
So, why did Parse shut down? Well, Parse was free up to 30 API requests per second (that’s over 75 million API requests per month). How many of the 1.5 million apps in the App Stores do over 30 API requests per second and would therefore pay for Parse? And, as I’m sure we have all done, you’ll have seen how scary Parse pricing became when you move that API requests slider up! So, how many of the apps that do make over 30 API requests per second would then immediately start looking at a more cost-effective platform?
The Freemium model where a small number of power users cover the costs of the larger number of free users, can be highly effective. However, I think it is difficult to make this work when you are effectively just reselling server capacity. And if the rumors that Parse were hosted on AWS are true? Ouch!
A sustainable model
Here at Kumulos, we favor a much simpler model. When you get paid, we get paid. Revolutionary, huh! Kumulos is free while the app is in development, but when you submit the app to the store and start to get recurring revenue from either your app or your client (for hosting their data), you pay us a small, fixed fee at the end of each month. If you don’t want to use our new App Grow feature to provide an App Store Optimization service to your clients, you don’t have to pay for it. If you do provide a monthly App Store Optimization service to your clients, then again, you pay us a fraction of what clients will pay you each month for such a service. This model has served our customers and our business well for many years and looks set to continue to do so for many more years to come.
If you’ve not yet launched, then now is the time to switch
If you’re still in development, then while it will be a bit of a setback to your schedule, it will never be easier to switch platforms than it is now so my advice to you would be to switch vendors now. If you want to move to Kumulos, then you will find this is as easy as:
Create an app, give it a name
Create some tables and define your schema
Name your API methods
Deploy your API to our load-balanced servers
Download our SDK and integrate into your project
Remember, Kumulos is free while your app is in development.
For existing apps – an opportunity to talk to your clients
If you have apps that are already on the store, then you are going to need to plan and schedule updates to move them to a new platform. If you are in the app development business, then while this is obviously a decision that impacts your client, they will look to you as their trusted advisor for a recommendation – use this as an opportunity to talk to them about ongoing services you can provide. If you are not charging your clients for hosting their app data – why not? Do you think their web developer hosts their website for free?
So, over the course of the coming weeks, look at the different vendors out there, what features they offer your business and how likely they are to be around as long as you and your clients need. We will shortly be publishing a Parse migration guide, special pricing for those impacted by the shutdown and, should you want to move to Kumulos, some limited development services to help with migrations. See our website for more details on what we have to offer.
In the meantime, do have a conversation with your clients around the additional services you can offer them. Think about Care packages to host and backup your clients data (in case your new mBaaS vendor does a Parse), monitor upstream service availability and average API response time or how about a Grow service to increase downloads with app store optimization?
In our experience you might be surprised by what they say. You could find that you first thought was a threat to your relationship with your clients and your business becomes an opportunity to add monthly recurring revenue and grow.
I read this and my first reaction (probably a bit like yours) was…Huh?
An iPad App grounds an Airline? What’s a mobile App doing as part of an airlines critical business systems?
Dig further and it gets interesting. It makes sound business sense for AA (and others) to use mobile technology. Here its a $1.2m in savings a year – through weight reduction. I did notice on recent travels that you rarely see aircrews lugging those huge pilot cases any more – and this is why. Its all gone into Apps; light, flexible easy to use. It shows just how central mobile app technology is. Some smart people say that we are just at the start of this revolution, and errors like this show the technology has a way to go to fully mature. What it makes clear is the big business impact that a simple App crash can have even on even the most trad of businesses.
(OK, so maybe impact and crash aren’t the best words to use here) – But you get my drift.
What happened and why shouldn’t it have happened
OK, so hindsight is great, isn’t it? Makes us all feel really smart. But it has to be said that you’d really think airline IT boffin somewhere would have thought this through and done a risk assessment.
So it appears that the App (called FliteDeck – made by Boeing business Jeppesen) crashed when it tried to access charts stored in a back-end database. Somehow the DB had duplicate files that the App couldnt resolve so errored and crashed. The App was used to manage the fight plan, no flight plan = no flight. The only way to fix it was to connect to Wi-Fi and reinstall the app. I’m guessing it’s probably not that easy at 35,000 ft.
This did make us Kumulites scratch our heads and think though. It shows again how important back-end infrastructure is when Apps are critical business tools. If they had been using a mobile back-end as a service like our mBaaS and running kScripts to check for file duplication in the database, then this just wouldn’t have happened. Even better would be to ensure they are using hook-ups to pull data from other (reliable, tested and trusted) sources rather than replicating sources, because that’s how mistakes get made, isn’t it.
There’s a lot of chat in Kumulos HQ about this. The conclusion is what happened here was a good thing (because no one got hurt) and may jolt techs to realise that a 4 tier architecture with a mBaaS (with kScripts and hookups) as a consolidation layer is the way to go.
Enterprise mobility and utility Apps are here and here to stay but right now the DIY back-ends still feels a bit flabby – firm back-ends run by those who know their stuff is the future.