How to deal vendor lock-in in mobile applications
The effort of most suppliers is to bind a client to further cooperation. Some try this through the quality of provided services (e.g. us), some by selecting the technologies that do not allow switching to another supplier, some by strict contractual terms. What to be careful about in the case of mobile applications?
1) Applications under your own account
The basic measure against vendor lock-in (proprietary lock-up) is to have your own iTunes, Google Play and Windows store account and publish applications under it. While opening an account takes time and it is necessary to demonstrate the various certificates of incorporation, you will also pay an annual fee (iTunes $99, Google Play $25 one-time, Windows Store $99), but otherwise the advantages prevail.
The application can be withdrawn from sale anytime, the pricing policy changed (free/paid app), but mainly to replace with a newer version. After sending the new application version (which might as well be from another manufacturer), the old version ceases to be offered, and only the new version can be installed. It is more important, however, that the operating system will offer an update to the new version to all users who have installed the old version on their phone. This update is also automatic in several versions of mobile OS, i.e. the application is updated in the background, without any user interaction.
It is also suitable to built a mechanism that refuses to run the application if it is on the old version right into the application – this is a measure for the (now) smaller group of users who have automatic updates turned off.
In the event that the application supplier is replaced, the migration to a new solution is almost unnoticeable for users.
Ackee offers a publication under the Ackee account to clients (for those who do not need to set up their own account, e.g. single events), but also under the client account without any additional conditions or charges.
2) Access to the database
Most applications need a server-side to run, with the requirement to own user data. The application layer on the supplier's server (which may be a closed solution) uses the data or directly updates them; however, in the case of the supplier’s replacement, it is not a problem to exchange the application layer and build it again on top of the database (controlled by the client).
3) Source codes
As regards the source codes of mobile applications, it is not common to supply these codes to the client. It is for this reason that a lot of solutions represent the company's know-how. At Ackee we have, for example, our own written chat module, or augmented reality technology. Thanks to the re-use of these components, we are able to significantly reduce costs and the application's price. However, some clients require source codes; in this case they agree to a higher price due to the need to develop some customized components.
Reasonable compromise
If the procedures in Points 1 and 2 are properly followed, or the application users are not regarded as hostages, it is no longer necessary to require Point 3 and thus make the application costs higher – here the final price could climb above what any mobile application rewrite from another supplier would cost (who also has prepared pieces of code and know-how).
