Paul Scott shares some cool insights on MXit API. For developers looking to build for MXit (one of the world’s largest mobile chat firms), read this:
The “API” as it turns out, is really an SDK. A Microsoft .Net C# SDK at that. There is no API (well not counting the standard XMPP “API” which we have been using for years anyway) at all, but a Windows DLL that contains an interface to the MXit currency functions (they call it Moola) and some basic messaging options. They have also introduced a simple markup language that allows some simple graphical elements to be cached client side for performance. The markup would be really useful IMO, but that seems to be secondary to MXit themselves.
Essentially the DLL is only useful to Microsoft Visual Studio coders as it uses the Net.TCP function to do the bidirectional API calls. That basically means that you cannot even hack this thing onto Mono and still use a Free Software stack to run your apps. There is a WCF service that runs on top of the API to handle the requests to handle the HTTP requests from client apps.
This could all have been achieved in a much easier way by sticking to pure old XMPP plus a basic API to handle some non-standard XMPP stanzas for the transactions etc. I do not know why they approached it in this way at all.
Basically the MXit API is Yet Another Walled Garden (YAWG) that I do not need to think about again.
For those that are interested in doing something with the “API” the approach would be:
1. They are very interested in games, so make a simple text based multiplayer game.
2. Get in real early. I suspect that the apps will quickly become saturated and lose novelty fast, so start coding immediately if you think that you may want to make money from this thing
3. Be aware that your revenue stream is based on MXit Moola, which means a Premium Rated SMS service via MXit. That means that for every Rand you charge your clients, you will get 50c
One vector that I can think of for one person to make an absolute fortune from this would be to buy the infrastructure and software and create an Open API around it for 3rd party devs to use. You will essentially become the middle middleman and create value for everyone in the world that does NOT want to fiddle with Windows DLL’s and such. You could then charge a small transaction fee on that service.