We see a lot of customers choosing to use Mendix as a MBaaS. Some customers choose to use Mendix purely as a back end data layer, which doesn't even have any customer facing pages. This is because of the platforms strong integration capabilities. The data is then serviced to users of the mobile app using exposed services in Mendix either as REST, SOAP or OData. This is very easy to set up in Mendix and allows for very quick data exchange between the two. Customers often choose to take this method over developing the mobile apps in Mendix, due to the fact they already have mobile app development tool or they need a high level of device interaction.
In terms of back-end services, we already have connectors for sending and receiving push notifications, SMS, Email and Machine Learning. Allowing you to build smart connected applications. Cloud Storage can also be provided either storing these in Mendix or on something like AWS S3.
Our platform has an added advantage over mobile backend as a service tools, which is that we can build cross platform apps as well as the back-end logic. We also have the added benefit of being able to help customers with speeding up the whole application life-cycle.
Interesting question Prachi.
Presumably you’re thinking in terms of writing the same app in iOS, Android, Blackberry, etc. (mainly to maximise local performance) and developing a Mendix app as a “concentrator” of backend services such as cloud storage, social media services, push notifications, user management et al.
From your question, I guess you’re aware that there are already products available that focus on offering SDKs / APIs to achieve exactly this.
While it probably could be done using Mendix, a significant issue would be that Mendix was fundamentally designed and optimised to be something else.
Using Mendix as an intermediate layer would almost certainly negate any performance gain you might have from developing a pure native app.
The standard licencing model would work against you too.
Better to look elsewhere.