Offline Mobile App Performance: The Forgotten User Experience Ingredient

Last week we took an in-depth look at why mobile app performance matters. The key takeaway is that great performance is an essential part of great mobile experiences. Today I’d like to focus on one specific, often neglected piece of the app performance puzzle: offline capability.

Most of today’s mobile applications treat offline as an error state. All functionality breaks; the app is essentially useless. This is true even for otherwise great apps by companies with massive amounts of resources at their disposal. And this poses a problem, because an app that doesn’t function offline provides a bad user experience in a fairly common situation. Yet most app developers ignore offline functionality, and punish users for a variable which is, in most cases, completely out of the users’ control.

For example, take Slack’s mobile app, which I absolutely love using when connected. If I am offline, the app will let me compose a message, warn me that I’m offline, and tell me that a message wasn’t sent. But if I reconnect, the message will still be waiting with an error:

Slack Offline

Bank of America’s mobile banking app – again, usually a joy to use with a network connection – just bounces me out of the app entirely if it can’t connect to a network. I’d love to be able to access some basic account information, but I can’t even get to a login screen:

Bank of America offline

So why is it, then, that companies like these, with millions of dollars and dedicated mobile teams allocated to supporting mobile user experiences, can’t get offline right? Simple: it’s really hard to do.

In “The Offline Mobile Challenge,” Forrester Research claims that “offline support is the mobile app feature continually underscoped by developers and oversimplified by stakeholders,” and that “the pain (and associated cost) of developing and testing the various facets of offline service causes this mid-project de-scoping phenomenon.” Yet the value for the user cannot be understated: in addition to providing offline functionality, a local cache supports sub-second app performance, since the frontend can display local data instead of having to query a remote database or file server.

Facemire, M. and Hammond, J.. (2014, September 26). The Offline Mobile Challenge. Retrieved from Forrester Research database.

Facemire, M. and Hammond, J.. (2014, September 26). The Offline Mobile Challenge. Retrieved from Forrester Research database.

3 different approaches to offline capability

One of the contributing factors to offline’s complexity is that there is no standard way to implement it. Different use cases call for different approaches, ranging from fairly simple to incredibly nuanced. Let’s take a look at what these are:

Local read-only

The easiest solution to the offline challenge is to simply create a read-only cache on the client device. This allows users to access content while offline, and the app can check in on the backend when it is connected to ensure all data is up to date.

I’m actually surprised how infrequently I see this implemented. It would be a perfect solution to my problem with the Bank of America app I pointed out above. Similarly, a sales enablement app that allows a salesperson to access pricing models, product catalogues, and other supplemental information on the road and in the absence of a network connection would be a great use case for this offline model.

The limitation, of course, is the read-only bit. While relatively simple to design and build, a read-only offline model only works if you’re delivering static content. It can’t support more complex use cases where users manipulate data on the client side – for that, you need a more robust architecture with sync capabilities.

Last write wins

In use cases where users need to be able to perform the full set of client-side CRUD (create, read, update, delete) operations, the simplest sync policy is “last write wins,” whereby the most recent update to data ultimately becomes the master record. This allows a user to make updates to data on the client while offline, and those changes get pushed to the backend once a network connection is reestablished.

This approach is well-suited for use cases with a low frequency of concurrent updates, or when changes come from a small set of predictable endpoints. Slack could benefit from this offline capability, for example, allowing my most recent sent messages to sync with the backend once my network connection is restored. And a Kinvey customer has actually launched an eDetailing app with this functionality, allowing sales reps to indicate that they had provided FDA-mandated information to clients while deep inside hospitals where network connections can’t be guaranteed.

The catch with last write wins is that it lacks any conflict resolution policies when making writes. If the use case requires that the application can prioritize concurrent writes based on a given set of criteria, last write wins will fall short.

Policy-based conflict resolution

This is the most comprehensive approach to offline cachning and sync, and predictably the most complex. An organization-defined set of rules determines through business logic which endpoints have write priority in certain cases; these rules can be as complex as required to support any use case.

This approach is required for omnichannel apps where data is manipulated from a large number of endpoints, and for just about any application that deals with physical goods. A field sales order placement app, for example, wouldn’t operate effectively with a last-write-wins sync system – if there are inventory changes or pricing updates while the salesperson’s app is offline, you would need a complex, custom approach to conflict resolution to ensure orders can be placed and the right people can be notified of any changes.

The drawback with policy-based conflict resolution for offline capability is simply the time and cost associated with creating it.

The auth problem

Authorization is a major pitfall in offline capability, often realized too late in the development process to fix. If your app accesses sensitive business data, it will inevitably connect to an enterprise authentication source. But those sources assume network connectivity in order to handshake with the client and grant authentication. No matter how robust your caching architecture is, if you’re still using standard enterprise auth your app won’t work offline, period.

The solution is to treat in-app authentication in a similar manner as MDM vendors. Require an initial authorization, and then grant a user cache access for n hours before an authentication handshake is required again. This ensures a level of security adequate for most use-cases without crippling offline capability.

Tying it all together

As I’ve said many times in this post, creating robust and functional offline caching and sync functionality is one of the most difficult pieces of app development. A quick GitHub search will net you myriad approaches to the problem, each one more nuanced and complex than the last. It is imperative that during your scope process you determine which of the three approaches best fit your needs and allocate resources accordingly.

Alternatively, you can turn to a managed service to do most of the heavy lifting for you. Kinvey’s client libraries allow you to add caching and sync to your app – with the specific policy tailored to your exact use case – with just a few lines of code: check out the dev center to learn more.

Why Mobile App Performance Matters

appperformanceBuilding mobile apps is hard. Building a successful mobile app, on the other hand, isn’t just hard — it requires a tremendous amount of skill and likely a bit of luck as well. In this post, I’m going to spend some time exploring why this is so, make a case for app performance as a key driver of app success, and talk about a few of the ways you can set yourself up for success by ensuring your app performs as well as possible.

It’s harder than ever to get our attention – especially on mobile

Note: I will be using some mobile web statistics in this post because there is a surprising lack of statistics and benchmark information for mobile app engagement, but I think you’ll agree that the data are still valid.

A recent study by Microsoft suggests that, with news being delivered in soundbytes and 140 character tweets and online entertainment (particularly video) becoming shorter and shorter, we now have an average attention span of 8 seconds when interacting with digital content. An anecdote released by Chartbeat – that 55% of pageviews get less than 15 seconds of attention – would seem to support this.

And lest you think that we’re somehow more engaged on our mobile devices than when we’re at our desks, that’s not the case. Have a look at our own engagement metrics below: mobile users viewed 28% fewer pages per visit, spent a staggering 55% less time on the site, and were 12% more likely to bounce in October.


timeonsite bouncerate

It’s difficult enough to get app downloads, but it’s even harder to keep users around

The Google Play store may have upwards of 1.8 million apps, but app downloads are heavily skewed towards a select few top-performing applications. According to AppBrain, 64% of apps in the Play Store have fewer than 1,000 downloads; 35% have fewer than 100.


Apple doesn’t make download data for apps in the App Store publicly available, but app analytics firm adjust claims that 83% of apps in the App Store are “zombies” – that is, they don’t appear in any local or global category rankings and can only be found by direct search. This is compelling evidence that the state of download distribution in the App Store is similar to that in the Play Store.

It’s a bleak outlook indeed if your endgame is app downloads, but smart publishers will be more concerned with making sure those downloads result in sustained app usage. Unfortunately, the news here is even worse. Andrew Chen, working with mobile intelligence platform Quettra, uncovered data that suggests an Android app’s daily active users will drop by 77% within the first 3 days after installing, 90% within 30 days, and 95% within 90. So while it can be tough enough to hit the 100 download threshold, you’ll actually need to get to the 2,000 mark if you want 100 meaningful users.


Our neighbors over at Localytics have an awesome annual report that tells the same story: 55% of your users are likely to use your app five times or less. In case you’re not sick of the bad news yet, Localytics also has data suggesting retention rates are getting worse in their App Stickiness Index, where loyal users seem to be on the decline year over year.


Performance is a huge factor in the critical first impression

In a Google survey, 63% of respondents said they use apps to make their lives easier. And the top reason they abandoned apps is because they “lost interest.” That’s a broad category, but given the short attention spans we’ve highlighted above, it’s clear that you need a high performant app in order to maintain interest and stave off app abandonment.

Mobile web statistics support this assumption. According to a report by Akamai, 39% of users have dissatisfying experiences using their mobile device for web browsing, with the top two reasons being slow load times and freezes or crashes. A separate Akamai report shows just how quick mobile consumers expect things to be and the consequences if they’re not: 57% will abandon a request after waiting 3 seconds, and 8 of 10 people won’t return after a disappointing experience.

Even more evidence that performance is key: in a study conducted by AppDynamics, they found that 86% of people in the US had deleted or uninstalled an app because of performance issues. And what do they do instead? 38% jump ship to another app while 34% just give up on whatever they were trying to do entirely. There are no second chances, and performance issues can have word-of-mouth implications too: AppDynamics found that 19% of those disappointed by their experiences complain to friends and family about the app.

Don’t forget about the revenue implications of performance, either. According to Aberdeen Group, a 1-second delay in web application load times equals 11% fewer page views, a 16% decrease in customer satisfaction, and a 7% decrease in conversions. Amazon famously reported that every 100ms delay in page performance costs them 1% of sales. Going by their Q3 earnings, that’d be about $10 billion lost per year if their pages took just one second longer to load.

One bright spot: it goes the other way, too. That same AppDynamics survey found that 1 in 3 respondents would spend more money with an organization if they had a good mobile app.

Fine, you convinced me. Now how do I make sure my app performs well?

Easier said than done, but the good news is that technology is doing its best to keep up with consumers’ performance demands. It really boils down to three things: ensuring your infrastructure can scale with demand, enabling sub-second data delivery, and providing the same experience when users can’t connect to a network.

In the old days (read: 10 years ago), scaling was a huge challenge. It takes a lot of time and money to purchase, install, and provision backend infrastructure, so companies had to guess what sort of load to support and either overspend or suffer angry users if they got it wrong. But with today’s cloud infrastructure, you can ensure your application scales gracefully and you’re only paying for what you need, when you need it. Case in point: when NBCUniversal launched their 50 Shades of Grey app in anticipation of the movie release it exploded in popularity; Kinvey was able to scale to support hundreds of thousands of users and nearly 3 million daily API calls almost immediately with no performance issues (check out our case study to read more).

Additionally, many backend systems of record an app may need to access will have been created years ago, when data access was measured in tens of seconds. But as we’ve seen, for today’s mobile consumers seconds don’t cut it — you need to deliver data within milliseconds. Having that data cached in a high-performant cloud layer, closer to the user and capable of delivering information at mobile speed, is critical.

If you can put the data even closer to the user and cache it on their device, even better. As a bonus, the app is now able to function without a consistent network connection. Regarding the importance of offline functionality, I love this quote from Forrester Research:

Developers … cannot make assumptions about the constancy, quality, or even existence of an individual’s network connection. Therefore offline support will be a crucial consideration for nearly every future modern application. Unfortunately, our experience shows that offline support is the mobile app feature continually underscoped by developers and over-simplified by stakeholders.

And as far as caching and sync goes, Kinvey has you covered here as well. Now go out and build a great app!

mBaaS in the Wild: a Mobile Game Built on Kinvey

spelldomI recently had the chance to connect with Tyler Bandy, cofounder of mobile game development studio HangZone and creator of the awesome iOS game Spelldom, which combines the best elements of Words With Friends and Clash of Clans. Spelldom is backed by Kinvey, and Tyler was kind enough to share with us his experiences using our platform.

Be sure to check out Spelldom and the other HangZone games in the Apple App Store!

What’s the premise of this game? How do the mechanics work?

Spelldom is a town building strategy word game. Each player has their own town, which they strategically layout with new and upgraded defenses to try to protect their Castle from attack. The attacking isn’t with your typical mindless barbarians that like to disrupt virtual civilizations though. No, these are word-based attacks where you must spell your way to victory. Players play their first word on the opponent’s Portal, the entrance to the town, and artfully work their way around defenses by connecting words with each other to move. Complete the town’s objective (something like play 18 words), steal the opponent’s gold, score enough points, and then take their Castle to earn 3 stars! The game is complete with teams, chat, tournaments, and leaderboards to add even more fun!

What inspired you to create the game?

We came up with the idea for Spelldom in 2013. We were playing a good bit of Clash of Clans and Words With Friends, and we started to think about what would happen if we made a cross between the two games. One of our biggest gripes with Clash of Clans was the lack of skill, as your attacking could only be as good as the troops and the spells that you had unlocked. We were also frustrated with how Words With Friends games lasted so long, and you were always at the mercy of your opponent to play back before you could do anything. With Spelldom, we looked to fix those areas with a skillful fast-paced attacking system all set in a quaint little magical forest.

Why did you end up deciding on Kinvey for your backend? Did you look at any other alternatives or think about doing it all yourself?

When we started working on Spelldom, we didn’t have much experience working with backends. Our previous games were single player titles, so we didn’t need servers to handle multiplayer interaction. Spelldom is a different beast, though. We have to save each user’s town layout, resources, and achievements. We need to save team information, and quickly update individual and team leaderboards. Spelldom also has team chat and gem gifting between teammates. This all takes a ton of server calls per user. Kinvey charges on a per user basis, unlike many BaaS competitors who charge per server call. Consequently, Kinvey’s pricing structure was a good fit for us. We also didn’t want to deal with a small BaaS company that might go bankrupt, leaving us with no way to run our game. As one of the larger BaaS players, we felt good about Kinvey.

Did you use any tools other than Kinvey to help you build the app (IDEs, SDKs, Testing/QA tools, etc.)?

We built Spelldom in Xcode, using the Cocos2D-X game engine. We’ve integrated the Facebook SDK so people can check out their friends’ towns, and our new update will include the Everyplay SDK, so people can share videos of their attacks.

Can you explain how you are using Kinvey data store/auth/business logic?

When a user opens up Spelldom, we attempt to login the user to Kinvey in the background, so we can load his town and let him know about any raids that happened while he was gone. If it’s a new user, we create a new user entry on Kinvey, and create a fresh new town. We do all of this without the user having to choose a user name and password, so it’s all a pretty smooth experience.


We save a ton of information for each user—hundreds of columns to handle their town layouts. We also save each multiplayer attack, for a limited time, so that defenders can see what happened to their town while they were away—and so attackers can relive their glorious pillaging.


We use business logic pretty extensively to handle more complicated operations. If a user joins a team, we can’t just make a simple save on the user. We have to make sure there is still space available on the team, update the team’s scroll total for the new member, and carefully handle a few other moving parts. We have to do these sort of operations in the business logic instead of making individual calls from the app, because things would go awry if we lost a connection after handling only some of the actions. We also use scheduled business logic to check the rankings at the end of our two weekly tournaments and then to dispense the rewards.


This really just scratches the surface of the different ways we use Kinvey’s data store and business logic. There’s chat, the team invitation system, shifting resources between users after an attack…there’s too much to cover.

Are you connecting to any data/auth/biz logic sources outside of Kinvey? If so, how did that go?

Users can log into Facebook and Everyplay to view their friends’ towns, check-out their friends’ teams, and share attack videos. Those login processes are quite simple for the user, and don’t take much more than a button press.

Were there any features of the Kinvey iOS library that you found especially compelling?

The business logic is really helpful for us to do whatever sort of custom actions we want. There have been some game oriented BaaS companies that have shown up since we started developing Spelldom, that aim to speed up the development process with canned team and chat functionality. The downside is that they don’t seem to offer as much flexibility as we have with Kinvey’s business logic.

How long did it take you to develop the app? How long do you think it would have taken had you not used Kinvey?

Spelldom took about a year and a half to develop. If we hadn’t used a BaaS provider, I’m honestly not sure how long it would have taken. We don’t have experience building that sort of functionality from scratch.

Were there any benefits to using Kinvey that you didn’t expect from the start?

Using separate backend environments for the development and release versions of the app is pretty much necessary for testing new features without disrupting the live version of the game. It’s been easy to toggle between the two environments, so that’s been a plus.

Do you plan on using Kinvey for any future projects? We’d love to have you!

We’re still focused on making Spelldom as fun as possible for our users right now, so we don’t have a new app in the works yet. We’re quite comfortable with Kinvey now, so it would be a natural choice for any project that requires a backend.

Any plans on an Android version? I don’t have an iOS device and I want to play :)

We built Spelldom using Cocos2D-X, so the majority of our code base could translate to Android. There’s still a ton of code that we would have to rewrite for Android, though, so we’re not planning an Android release anytime soon. If the game does well on iOS, we’re certainly interested in porting it to Android. In the meantime, you can checkout our previous title, Fizzy Factory, on Android.

How Mobile can Save your Life in the Zombie Apocalypse

We all know that mobile apps have a lot of value in our day to day lives, but what about in extreme survival circumstances? After seeing the Boston streets crawling with Halloween zombies this past weekend, we undertook a bit of a creative writing exercise to show you how mobile could help save your life in a zombie apocalypse.


Day One

I was at the office this afternoon and everything went dark. Our internet connection was down so I grabbed my phone to try and figure out what was going on. That’s when the twitter statuses started streaming in.

Zombies. They were everywhere.

Decision time. Run for the hills, or stay and fortify?

I check quickly to find out how likely it is that Boston can survive a zombie apocalypse. Luckily, one of the first links to come up under #zombieapocalypse is an article that links to this map. Looks like I’ve got a good shot in Boston. I knew living this close to all the biotech companies would be good for something!

The Kinvey Marketing team here in the office today is a pretty good bet to stick with– Jacqueline and Justin are both black belts, Margaret and Rob have a mean golf swing, and I’ve got a lot of armor and swords. We may just survive this thing…

Stay and fortify it is.

Day Two

The building apparently has a backup generator, because the power is back on. 4G networks are up, so we’ve still got time to prep. Half the team has iOS phones and half have Android, so we start to load up on survival apps and manuals.

Survival Apps

It seems pretty obvious to us that we’ll need to download some useful apps for easy reference. Who can be bothered to lug around books during an apocalypse? I’ve already got the Amazon Kindle app on my iPhone, so I start with the Max Brooks classic The Zombie Survival Guide.

Next up we all download the American Red Cross First Aid App. With ratings that high, it’s got to be useful!

Food and water are going to be important, and everyone will be hitting up the stores, so we have to think clever. Luckily, I enjoy urban foraging, but I’m still not an expert. I get the Wild Edibles Forage app, and the Android users on the team get the Edible and Medicinal Plants app.

We all download and install the Life360 app. This will let us keep track of where we all are, map out where zombie nests are cropping up, communicate in team chat, and let us check in at various safe houses we set up.

We’re off to a good start.

Day Three


We decide to try and make it to the Department of Public Health to see if there’s any news.

We map out the route.

Easy peasy, we’ll be in and out!

We head out, get there and find the place empty. There’s a link written on the windows though in dry-erase marker.

It’s a way to sign up for alerts from the CDC via email or text! Great, this means we’ll know as soon as information is available.

We start to head back, but get overrun by a zombie swarm on our way back. We need to hide!

We run into the closest parking structure at 33 Arch Street. The zombies are hot on our trail. There’s nowhere to go, we’re trapped!

That’s when we see the fleet of Zipcars.


Rob thinks quickly, pulling out his phone. He opens his Zipcar app, books a car, and unlocks it right from the app. We dive into the car and drive out, crushing zombies under us.

That was a close call!

Day Four

We’re running pretty low on food. We had a Halloween party the day before the zombie outbreak, so we had lots of chips, candy and chicken wings, but now we need to go on a rood run. There’s a Roche Brothers that opened up down the street from us, but getting there is going to be hard, there’s a zombie swarm right between our building and the grocery store.

Margaret comes up with a plan! She has an Apple Watch, which will let her control her iPhone remotely. We’ll use it as a distraction to draw the zombies away while we run by.

We set up the iPhone in the opposite direction that we want to run, then hide around the corner. Margaret taps her Apple Watch a few times and viola– the phone starts blasting music. The zombies are distracted and we’re able to run by! We’ve got all the canned goods we need for a couple weeks now.

I remember that there’s a pretty extensive garden not far from the Fed building, too. Our edible plants app comes in handy as we gather up some vegetables that are still in season.

Day Five

We’re holding strong, it’s time to start collecting survivors.

We’ve zombie-proofed the office by setting up a simple mobile authentication app, modified from our MIC Sample App. It lets the survivors authenticate with the service of their choice, which gives them a secure login screen as a QR code.


Anytime we find a new survivor, we just add a new user.

Authenticated users can swipe in with their mobile phones, and we can keep zombies out.

We’ve also got motion-sensing IoT cameras set up everywhere to detect zombies. Thanks to Matt’s most recent Hackathon Project!

Day Six

We got an SMS Alert from the CDC today! A cure has been found, and we’re all going to be okay! Thanks to mobile tech, we survived the zombie apocalypse.

Migration and Cloning Now a Part of the Kinvey Console

As part of our efforts to continuously improve our product, we’ve been developing new features to make the lives of Kinvey developers and administrators easier. Recently, we heard from some customers that they needed a simple way to migrate changes back and forth between different Kinvey environements within an application, and to create new clones of existing environments.

These features are important during testing, debugging, and any time app updates need to be done — they ensure that the changes won’t break any part of the app in production. Isolating specific code and figuring out potential problem areas is critical, and app administratiors don’t always have the technical skill to use a command line interface.

That’s why we built Migration and Cloning into the console, and made it as easy as a press of a button. See how it works:

Migration is meant for pushing changes between environments, while Cloning is for creating entirely new environments. Both are part of the Lifecycle Management features that Kinvey provides for app development.

We’re very excited about these and other improvements coming down the line, making Kinvey the go-to product of choice for enterprises that want an easy-to-use, secure, and scalable application platform.

Hackathon @ Kinvey: Building the Next Generation of Awesome mBaaS Features

HackathonIt has been a while since our last hackathon. So when it came time last week for our engineering team to demo what they had built over the span of just a few days, I was expecting to see some awesome stuff.

Every hackathon I’ve witnessed at Kinvey has been better than the last — I expect to be blown away. After all, Mike’s Kinvey Auth Service hackathon project back in April of 2014 set the foundation for our Mobile Identity Connect feature that makes any enterprise identity or auth service look and feel like an OAuth flow for frontend developers. And when Ed built ANY-dlc in our previous hackathon, he took the first step towards what is now our RAPID no-code utility for connecting your Kinvey app to REST-based services (RAPID is still in beta but should see general availability soon).

But I really wasn’t expecting to see the level of innovation I saw last week. While we do judge a “winner” and “runners-up,” I want to stress that each and every project demoed was a) outstanding, b) way more polished than I could ever think possible with just a few days’ worth of work, and c) absolutely viable as a future addition to the Kinvey platform. I asked the engineering team to send me screenshots (hint: click on the thumbnails to see the full-res versions) and summaries of their projects, so the below is straight from the horse’s mouth, so to speak.

The Winners: Ivan, Thomas, and Patrick – Load Testing on Kinvey

From Ivan:

Our idea is to solve the “load testing” problem we’ve repeatedly seen with our customers. We noticed, over and over again, that usually right before a launch target date, customers scramble to perform a load test. They spend a bunch of time scripting it together, based on existing practices they are used to, and often end up doing it “the wrong way.” Frequently, customers had unrealistic expectations without realizing why that’s the case – inadvertently they would test for twitter-level scale. Then they would run into problems, spend a bunch of time with us supporting them, tweak their script, and run it again. The whole thing takes weeks and frustration.


We thought that the Kinvey platform is actually well suited to help and provide this feature out of the box. Our goal was to a) make it extremely user friendly – in fact, business-user friendly, so with buttons, not code – and with pretty charts as output, b) have load testing done “the right way,” and c) accomplish this without having to spin up brand new services and existing infrastructure.
Our solution is completely out of the box, can be run by a non-coder, and re-run over and over again at any time. It saves weeks across both customers’ time and Kinvey’s time.

Load Testing 1

Load Testing 2

The Runners-Up, Part 1: Mark – kinvey-tools

From Mark:

kinvey-tools is a command line tool for the engineering team which automates boring and repetitive tasks, like scaffolding a new project, or creating a list of third-party licenses for the legal department.

Sidenote: our engineering team owes Mark a beer for this one. You should have heard how excited they were to have something like this!


kinvey-tools Update Licenses

The Runners-Up, Part 2: Kurt, Paras, and Matthew – Kinvey Partner Portal

From Kurt:

The Kinvey Partner portal allows referral partners to log in, submit leads, and view their opportunity information. Fully integrated into Salesforce via Kinvey’s RAPID REST API integration, now Kinvey’s sales reps can work with our partners more effectively, sharing data without having to rely on disorganized emails.

Kinvey Partner Portal 1 Kinvey Partner Portal 2 Kinvey Partner Portal 3

Dave, Gal, and Mike – Kinvey Atoms

From Dave:

Our project allows non-technical users to build and manage contextual apps – apps that use dynamic data in an intelligent fashion to react to changes without requiring a developer to write code for each interaction.

Another sidenote: this one had my jaw on the floor. We talk a lot about the importance of context in mobile apps (in fact, we have been doing so since 2012), and this makes it super easy to create apps that display the information a user wants, when the user wants it, based on their behaviors.

Kinvey Atoms

Ed – the Kinvey Kitchen

From Ed:

The Kinvey Kitchen allows developers to share easy-to-consume code snippets, which can be used across any application. There are snippets for every platform supported by Kinvey, and with github-integration it is easy to start sharing!

The Kinvey Kitchen

Matthew – An IoT Use Case on Kinvey

From Matthew:

My project was a detection system. I used cheap $20 Android devices and quasi-IoT devices. They were set up to take pictures on some interval (default: 5 seconds). The pictures were uploaded to Kinvey. Then, there was a monitoring app, where someone could go and look at the latest picture in real time taken for any of the deployed cameras. There was a mechanism for motion detection, and when it was triggered, an email was sent showing which camera had motion, and the degree of difference. All of the deployed cameras were also notified that the other camera(s) detected motion, the idea being that they could be set up on a one minute interval, but if one camera detected motion, nearby cameras could be alerted to take pictures more frequently.

Intrusion Detection 1 Intrusion Detection 2 Intrusion Detection 3

Tejas and Patrick – Kinvey Diagnostics

From Tejas:

Kinvey Diagnostics is a tool that allows developers to quickly find and troubleshoot issues with their data links. Developers can run a health check on their data links and see a diagnostic report that provides details and suggestions to fix issues.

Kinvey Diagnostics 1 Kinvey Diagnostics 2

Introducing the mBaas Savings Calculator

mBaaS Savings CalculatorLast year, we showed people the value of creating applications using mobile Backend as a Service (mBaaS) with our App Cost Estimator. Since then, we’ve discovered a lot of ways that we could improve our calculator, and we have been hard at work adding in all the features you find in Kinvey in order to help people understand the real value of mBaaS.

That’s why we are excited to unveil the mBaaS Savings Calculator. The Calculator asks a series of questions about the application you are trying to build, and uses the answers to those questions to plug into assumptions that we have tested with developers about how long it takes to build out different features from frontend, backend, infrastructure, and maintenance perspectives.

Notably, the new calculator includes infrastructure costs. This is a big update to the App Cost Estimator, because it allows you to specify what kind of infrastructure you would need to build out in order to run an application if you weren’t using an mBaaS, and compare the price. Infrastructure costs are often overlooked when people think about building apps, but they serve a critical function when it comes to creating secure, reliable, and scalable applications.

The mBaaS Savings Calculator also takes into account updates to the Kinvey platform, such as our RAPID REST-to-REST connectors that cut down development time from weeks to hours.

Finally, the mBaaS Savings Calculator is now responsive, so you can get estimates on your mobile phone!

Give our mBaaS Savings Calculator a spin and see how much you could be saving!