Ashley Kleynhans

Building Your First Mxit Application


I have had quite a large number of people asking me advice about building Mxit applications, so decided to share some of that information here.

This information relates to building Mobi Portal applications, and probably won’t be useful if you’re using the .NET SDK.

Before you start building your application, you should refer to all the various different Mxit terms to ensure that you won’t be in violation of those terms. You should also start off by reading the Mobi Portal API Specification.

Mxit Mobi Portal applications use a very small subset of HTML, so you won’t currently be able to access GPS, Compass, Accelerometers, etc.

An Idea

Obviously the very first thing that you will need to do when building a Mxit Application for the first time, is to come up with an idea.

Although Mxit is an Open Platform, and you can clone existing applications, I have much more respect for people who come up with an original idea instead of cloning applications that already exist.

It will also be difficult for you to try to compete with an existing application that has already been around for several months and has an established user base.

If you are struggling to come up with an idea, you should consider browsing the Programmable Web API Directory which lists almost 9,000 APIs at the time that I am writing this article, for some inspiration.


You can use whichever hosting provider you like.

South African hosting solutions tend to have lower latency since Mxit is also hosted within South Africa, but unfortunately decent South African hosting can be very expensive, and the cheaper hosting providers aren’t really an option. I know of people who have tried to host their Mxit Applications at Afrihost and Cybersmart and ended up having to move them over to international hosting due to their local hosting providers not being able to cope.

I am a big fan of Amazon AWS, but their hosting can become very costly very quickly. Although I don’t use Amazon EC2 for my server hosting, their S3 service isn’t very expensive, so I highly recommend using it to store things like images.

My preferred hosting provider is Hetzner in Germany. I have a few Dedicated Servers hosted with Hetzner Germany. I don’t recommend local Hetzner hosting in South Africa because they have too many outages and their service is also not as good as Hetzner in Germany.


You don’t need a database to have a Mxit Application, but I think your application will generally be pretty pointless without some sort of database. In the very least I recommend storing the userid of each user that interacts with your application, so that you can engage with them using the Mxit Messaging API.

I’ve found that running a single MySQL database server can cause high CPU load during peak times, so I generally prefer using MongoDB to store my data. MongoDB is schemaless, so adding new fields doesn’t involve updating millions of records. If you find querying MongoDB difficult, Stripe recently launched MoSQL which live replicates MongoDB to PostgreSQL, so that you an benefit from NoSQL in the form of MongoDB, but also be able to query your data using SQL.

Tracking and Analytics

I recommend implementing Google Analytics tracking in your applications. Nic Malan has written a PHP Wrapper for Google Analytics which I use in most of my applications. Nic’s wrapper requires the curl executable to be installed on your server.

In addition to Google Analytics, I also record custom analytics in Redis and have a CMS that displays those analytics.

These analytics are useful for finding trends in your applications and have also helped me in noticing that things were not functioning correctly, so that I could either fix those things myself, or raise them with Mxit where applicable.

Ensure that you keep track of the userid of each of your users if you plan on Improving User Engagement with the Messsaging API.


You should ensure that your application is scalable by implementing caching for resources that will be frequently required. Various different options are available such as Memcache, Redis, Couchbase, etc.

I typically develop my Mxit applications in PHP, so I use APC (Alternative PHP Cache) as an op-cache, and generally use either Redis or Couchbase for caching data. The main reason why I choose Redis or Couchbase rather than Memcache is because both Redis and Couchbase persist to disk, but Memcache does not, so if you have to reboot or restart your Memcache server for whatever reason, there will be a large amount of load while data starts to get cached. I have had some bad experiences where I was caching user agent strings in Memcache and had to restart the Memcache server, which brought the entire application to its knees.

Using External APIs

If you’re going to call external APIs in your applications, I strongly recommend caching the data that you retrieve.

Many external API services have implemented rate limiting, and if your application becomes successful, there is a very good chance that you will exceed those rate limits, which could potentially cause your application to generate errors and become inaccessible.

I experienced outages in one of my applications less than 3 months after launching it, due to rate limiting imposed by the third party API that I was using.


When I built my first application, I was much less experienced than I am now, and made the mistake of neglecting to use pagination. If ever pagination was important, it is within the Mxit environment.

Most Mxit users have older phones which don’t have much memory, so spewing out massive amounts of data on a single page will most likely cause the Mxit client to crash on those phones.

The number of items per page depends on how much data is contained within each of those items, but generally somewhere between 5 to 10 items per page is my recommendation.


Remember that many Mxit users are using devices with extremely limited memory, so you should try to keep the number of images that are displayed on a single page to an absolute minimum to avoid the Mxit client from crashing.

You should also bear in mind that different users have different devices which have different screen widths, so you should resize your images to at least 2 or 3 common widths to ensure that the images are correctly displayed across all devices.

In my first Mxit application I made the mistake of using an image as a separator between each item on the page, but obviously this caused the devices with limited memory to crash, so I received plenty of complaints from my users, and changed the image to a text separator instead.


Mxit provide a feature where your users can invite their friends to your application. In order to use this functionality, you will need the Referral ID for your application. Unfortunately the referral ID is not yet available from the dashboard, so you will have to manually request it from the Mxit Developer Centre.

Once you have your referral ID, you can allow users to invite their friends to your application by adding a link as follows:

<a href="mxit://[communityportal]/RecommendPage?ItemId=00000000" type="mxit/service-navigation">Invite Friends</a>

Or, alternatively, you can link to other Mxit applications as follows:

<a href="mxit://[communityportal:Refresh]/ReferralPage?ItemId=00000000" type="mxit/service-navigation">Another Awesome Application</a>

In both cases, the ItemId is the Referral ID that Mxit will provide you with.