Parse shutting down is an old story now, but ...
It may be the final mile (final deadline for Parse is January 28th 2017) but we’ve realized a large percentage of developers have, in fact, been patiently evaluating their options since the shutdown announcement.
So after what was only a short February rush, it’s now obvious that most developers waited for the smoke to clear and the best options to arise. And that most of them (most of you) will be migrating over Q4 and early Q1 2017.
So having migrated over 1000+ developers from Parse to Batch (we’ll call them early adopters!) over the course of the past 6 months, we thought we’d share a couple important learnings for your perusal, because who’d want to perform such sensitive a migration in a rush, or even worse, uninformed?
(By the way is it difficult to migrate to Batch? Nope, are saying developers).
But first off quick reminder:
Parse Core was an mBaaS (Mobile backend-as-a-service) platform that facilitated data and user data user by providing a cloud-based suite of tools to host storage for photos, gifs, user information, user location etc. It was the perfect alternative to having to maintain those yourself, plus it was tailored for mobile. Parse Core also enabled apps to let their users sign up through their Facebook, Twitter and other Social network accounts. Batch doesn’t do this for you but there are plenty of options out there.
Apps used Parse Push to send push notifications to their users. This is what Batch does, and much more. Our platform comes with the same basic push capabilities Parse had and goes way beyond with marketing automation features, advanced In-App Messaging features, APIs and of course we’ve added everything new since iOS10 and Android 7.
Now, to the stuff we learned:
Careful with your Parse Android Push Tokens
Just like Batch, Parse also used Google Cloud Messaging service to send push notifications to Android users.
BUT when we started importing Android push tokens from developers migrating to Batch, we realized that Parse default integration pushed developers to use the same generic Publisher's SenderID: theirs! Thus, irremediably tying those tokens to the main Parse account and making it impossible for developers to reuse their tokens elsewhere.
You may be in that situation too. Maybe without knowing it. And if you are, you'll need to start recollecting tokens from the start ASAP if you want to be able to keep messaging your users in the future.
Time to investigate.
Parse offered their users a targeting feature called channels: a simple way to create segments of users to bulk send push notifications to specific user groups. While not very advanced the feature was easy to implement and a crowd-pleaser.
That's why at Batch we worked to make it really simple to replace Channels with our Custom segments, while providing what we call Native segments—something Parse also offered.
For more information, have a look at User Targeting.
App-to-App Messaging Service
Countless developers have asked us for that specific feature.
Parse users were using Parse to send direct App to App Messages which is considered a bit insecure as an easy decompilation of your app would render your API Key accessible. In simple words, malicious people could start sending messages to your user base with little efforts and even Parse, while providing a way to so, warned against such implementation.
At, Batch we value your security and therefore for developers wanting to implement such protocol we strongly recommend you use our asynchronous Transactional API for that, where API keys & certificates going to be stored on your servers, and not in your app.
We also found a weird security vulnerability with the Users object, on Parse, which is public by default. Parse offered a webservice route where you can request a complete list of all users and user-infos. Any malicious person using a web proxy or who whould decompile your app could get access to very sensitive informations, if you had stored physical address, phone number, email, etc.
On the service side, developers have been positively surprised with the level of customer support Batch is able to offer, where Parse was relying on user-generated tech support through forums, we thrive on real-time, 1-to-1 chat support using our ubiquitous chat bubble at the bottom-right of all pages of the Batch.com website & dashboard.
So no more searching an answer on forums for ages, no more endless waiting after “a ticket has been opened”.
We get you technical and marketing answers, fast.
Ultimately Parse was mostly free. So how does Batch compare?
Well heard developers, and we’ve kept our BASIC service entirely free through a couple of pricing upgrades, since our 2014 launch. In fact today, more than 80% of the 4,000+ developers using Batch are using our free service and of course for bigger, more demanding corporations, we're able to offer Enterprise-level service with according rates.
Interested to learn more?