The Right Things to Think About Before Migrating from Parse

parse-to-kinveyParse’s announcement that it is shutting down was a bitter day for all of us at Kinvey – Parse and Kinvey were the first two viable Backend as a Service platforms in 2011, and for the first two years of our existence, we fought head-to-head against them.  At the same time, there was a whole lot of mutual respect between our team and theirs. Our CEO, Sravish, summed it up pretty well:

While Parse has planned their sunset strategy the right way (the platform will be available for another year), many developers are understandably beginning to look for alternatives already.

Instead of just telling you, “Hey, migrate to Kinvey,” we felt it was far more responsible for us to tell you why you should consider Kinvey (or any other service) as an option for your Parse apps.

A product ethos you know and love

Kinvey – like Parse – was built to dramatically improve developer productivity. We have not taken any shortcuts. We spent a lot of time and effort understanding the hard problems developers encounter and don’t want to deal with while building apps — standing up and scaling data services, file services, push services, making apps work offline, storing data securely, etc. — and we provide you all this capabilities (and more) as part of our service. You can read more here.

Kinvey – like Parse – has spent an enormous amount of time delivering SDKs and documentation developers love.  Take a tour of our docs and SDKs.

Single line of code to do common tasks via our SDKs: User login/logout, changing password, moving data, storing data for offline use, encrypting data, etc. — it’s a single line of code.

A complete backend stack: You get a data store, a file store, engagement features like push notifications, email and SMS, analytics, a Node.js PaaS to run custom code, an API console to test your backend, and much more. We’ve built it, so you don’t have to.

Built-in, end-to-end security lets you focus on building your app instead of securing it.

Cloning your backends and migrating data from one to another is easy and simple. This lets you iterate on your app without having to worry about complex migrations.

Scale and a track record of powering numerous successful apps like yours

With a global developer community and 10s of 1000s of apps powered by Kinvey, whatever use case you can think of has already been built on Kinvey. Whether you’re an enterprise building internal and external apps for your digital business, an agency looking for a way to get better apps built faster for your clients, or an indie developer trying to create the next game-changing app, we’ve got you covered.

Delivered at scale — an important thing to ask your new vendor is “Can you match Parse’s scale?” As a long-time Parse user, you know that they’ve hardened their platform over time and had various uptime issues while they went through the hardening process. Well, Kinvey went through a similar journey.  No other vendor can match the scale that Parse and Kinvey can give you.

A fair and transparent pricing model (with a generous free tier!)

At Kinvey, we decided to implement a pricing model that was not API or data based. We didn’t want you to have to think about architecting your app to fit a pricing model. If you are building a chatty app, do it. Don’t let a pricing model stop you.  Instead, Kinvey has a simple app-based pricing model.  

We’ve simplified our pricing into tiers to make it simple. At a glance, our tiers are:

For developers and prototypes:

Development (FREE)

  • All core BaaS features
  • Unlimited API calls
  • Business logic
  • 1 environment
  • Up to 1,000 active users per month (MAU)

Indie ($200/month) – everything in Development PLUS

  • Up to 100k active users per month
  • 2 environments
  • Team collaboration

For business and and enterprises:

Business launch (starting at $24k/year) – everything in Indie PLUS

  • Unlimited users
  • 3 environments
  • Prebuilt connectors to Enterprise data and auth systems
  • Data backup and disaster recovery
  • Uptime SLAs
  • Standard support
  • Dedicated account manager

Enterprise (custom pricing) – everything in Business PLUS

  • Single-tenant instance
  • Unlimited apps
  • 6 environments
  • CDN acceleration
  • 24×7 support

A compatible architecture stack

Kinvey’s architecture is very similar to Parse, which allows your apps to work the same way as they did before.

  • Complete SDKs in Objective-C, Swift, Android, JavaScript, Angular.js, Backbone.js, Xamarin, Node.js, Java, etc.
  • A NoSQL based data store (powered by MongoDB)
  • A file store to store large files
  • A node.js based PaaS for you to write and run custom code on the server
  • Push, SMS, Email made easy
  • Analytics to track how your apps are used
  • and much more

At the end of the day, changing platforms is a hard pill to swallow. We get that. We think you should do take your time and do it the right way. Good luck!

Kinvey Makes SharePoint Cloud-First and Mobile-First

sharepoint-heroHave you tried to mobilize your enterprise Microsoft systems? It’s not easy. Microsoft wants you to migrate to the cloud with SharePoint Online, spending a bunch of time and money on new Microsoft products (surprise!). Though Microsoft has reluctantly backpedaled and now say they will support SharePoint 2016 on-premise, customers are stuck waiting for it to be released in the spring (and cautious businesses will likely wait longer for release-date issues to be resolved). Few can afford to wait that long to launch mobility projects.

Even then, SharePoint is planted firmly in the web world. It’s not optimized for sub-second mobile speeds, assumes the user always has a data connection, and requires developers to have deep knowledge of proprietary Microsoft data access methods and languages. Building mobile apps that use SharePoint is a terrible experience for developers, and this often gets passed on to the end user as a sub-optimal UX.

Which is why today we are thrilled to announce the launch of our out-of-the-box RAPID connector for SharePoint. By extending your existing cloud or on-premise SharePoint deployment with Kinvey, businesses can build performant, secure mobile apps with SharePoint data, using whatever tools or languages their developers prefer. Setup takes just minutes and requires no code – just configure and go!

 

Kinvey’s RAPID SharePoint connector:

  • Caches SharePoint data in the cloud for sub-second mobile experiences
  • Can provide offline access to SharePoint data
  • Integrates seamlessly with Mobile Identity Connect for superior identity and access management
  • Requires no management or maintenance overhead
  • Has built-in, end-to-end encryption for secure and compliant data access
  • Can be set up with no code in less than three minutes (seriously – check out the demo above)

In short: we’re making SharePoint cloud-first and mobile-first without any expensive migrations or upgrades. If you’re interested in extending your existing SharePoint deployment to mobile developers, let us know.

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 Kinvey.com 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.

pagespervisit

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.

appbrain

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.

quettraretention

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.

localyticsstickiness

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.


zombies

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

map

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.

zipcar

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.

qrcode

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.