As a software developer, I often encounter the issue of fixing up (having to add new features and/or fix bugs in) an already existing mobile app. If the appropriate tools are unavailable, I often face obstacles when taking on this task.
As a client, you must know that during development, there will be byproducts arising parallel to your app. These will play a crucial role in the life of your app later on. In this post, I will introduce you to the most important ones of these elements in iOS and Android mobile application development.
As developers, we often face a problem: in order to actively work on a mobile application, we need access to various online systems. App shops are the most basic example: whether you have an iOS or an Android app, you will either need a Play Store or an Apple Store account. These systems make it possible to organize the development teams. As a client, it is extremely important for you to have access to these accounts, then to give access to the developers. Luckily, both the Google and the Apple systems allow you to handle permissions as you wish. Therefore, you can hand out only the necessary permissions to the developers, so they won’t be able to access your financial information, for example.
You can handle teams not only in the stores, but also in online analytics, and crash reporter systems. When deciding which specific tools to use, it is important to check whether they can handle teams. If they can’t, it might be time for you to reconsider.
All in all, it’s extremely important for you as the client to have the direct access usernames / codes / passwords to all of these accounts.
The most substantial part of development. If you do not have the source code, then no further development can be done on your mobile app. In this case, we have to start everything from scratch.
It depends on your agreement, whether you have the source code from the beginning of development or only get it at the finish line. Either way, I advise you to place the code in a version management system (Git, svn); there are free and paid solutions available. Again, we can manage teams and organizations. The important part is that you, the client, should be the owner of the account, giving the developers permissions only.
As important as the source code. However, developers seem to disregard it.
Commenting on the code belongs to the documentation as well. I would only advise requiring commenting from your dev team if your app is extremely complex, containing non-evident logical structures. And if you decide for commenting, you should also keep in mind that this might cost you extra dollars, as proper commenting might take extra time.
There is one, critical piece needed: more general than commenting on the code, but detailed enough for a new member or an entirely new team to join in the development. You can picture this as a comprehensive specification capable of briefing a new developer regarding the technicalities.
Most of the time, mobile applications communicate with some sort of a server, where for example, users’ data are stored. A detailed report of this communication will always be needed later! We, developers, must know what to expect as a result from each URL by sending parameters through them to the server.
Both platforms use certificate signatures as a security solution.
Apple manages these centrally, so even if you lose your certificates, Apple will let you make new ones, therefore allowing you to release new versions of your app. This is a fairly comfortable solution, however, Apple might seem a bit too complex in its restrictions sometimes.
Whereas, signing an app at Google takes place with a locally generated key. If you lose this key and its password, there is no going back, you won’t be able to release new versions; you will only be able to upload a completely different application. Your already existing users won’t be able to update the old app, but will have to download the new one.
It is evident from all the above that you need to have all documents, source code, and all internal and external account keys in order to later have the capability of releasing new versions of your app (even involving a new development team).
Editor’s note: Whether you are working with a freelancer or a company’s team, we would advise you to set the scene straight from the very beginning of development. If they don’t bring it up, let them know you are aware of these materials and that you want to have/own them. This will protect you in a few ways;