This blog post is the sixth in a series, describing how app development works in a typical client-agency arrangement. The intended reader for these posts is someone who is looking to get an app made, who wants to know how the process works. This series covers how you might work with an agency to build an app and incorporates some of our learnings from our previous projects on what tends to work best.
You’re finally near the end of your app development journey. The code has been written, you’ve tested the app, and you’re happy for it to finally be released to your users. The next step is to navigate the release process, the handover of the project from your developers, and the ongoing support of your app.
Release & App Stores
If your project is a mobile app, it’ll generally be released on the iOS App Store and the Google Play store for users on iOS and Android to download and use it. To release the app, you’ll need to have developer accounts set up on the respective stores. It is possible to release your app from the developer account of the agency you are working with, though there are downsides such as having less control over your account and who the app is attributed to. If your app is a paid app or includes in-app purchases, you’ll most likely need to release the app on your own app store account to satisfy legal requirements
The actual process of setting up the app store account will need to happen well in advance of release, as both app stores have tools to distribute test versions of the app, which developers should be making use of during development. Once you get to release time, there is then work that needs to be done to get your app store listing in the shape you want it to be.
Your app store listing is – apart from any marketing website you make – the primary place where people will find out about your app and make a judgement of whether to download it. You’ll need to write all the marketing copy that the app stores require for their listings. These are similar for both platforms, but there are differences, including limits on text content length. You’ll want to make sure you understand the requirements for your app store listing before you spend too much time putting it together! There is a skill to writing successful app store listings, and there are companies that offer App Store Optimisation as a service, in much the same way Search Engine Optimisation is handled on the web.
One key part of the app store listing is the app screenshots. The screenshots demonstrate the contents of your app to a potential user. Basic screenshots can be simply taken by you of the app. Many apps choose to create designed screenshots instead. Designed screenshots are a way of creating marketing images that showcase the content of the app but also make use of annotations and graphic elements to visually enhance the image and highlight key features.
Both app stores have review processes when the app is finally submitted for release. Unfortunately, the exact criteria that apps need to follow is very specific and is often updated. The iOS review process is especially stringent, and it’s an unfortunate reality that there are often things brought up in the review process that require reworking an aspect of the app to be approved for release.
Handover & Warranty
Depending on the IP arrangements in your agreement with your developers, you may want all code for the project handed over at this point, so that you at least have a copy of all the source code in your control. This is important especially if you are not immediately continuing with a support arrangement with the developers, as you wouldn’t want to find yourself in a situation where you have no access to your source code, and you can’t get in touch with the developers.
Virtually all software projects have bugs, which will continue to be found even after your app is released. This is, unfortunately, a reality of software development – even projects with years of continuous improvement will find new issues appearing. Software does not exist in isolation: your app is running on an operating system which itself is constantly being updated, and it most likely uses external services which are constantly being updated too. These changes might require your app to be updated or else parts of your app might break, or bugs start appearing.
If an agency is charging a fixed price for a project, it will often offer a warranty period after project completion in which issues and bugs that are found will be completed for free. If a project is instead not fixed priced, and instead charged based on the time spent, then it’s unlikely for there to be a warranty period, as there is no real difference between fixing a bug prior to release or post-release.
Updates & Support
Once your app is released, you’ll need to continuously update it to some degree. These updates may just be to fix bugs, but you will most likely also want to change or add features as you work out how people use the app. Apart from bug fixes, which may be covered by a warranty period, you will need to have an arrangement in place for continued work on your app.
One common pattern for this ongoing work is to have a support agreement or retainer with your development agency. A support agreement can prove to be especially important in the case that a major bug or issue appears that needs immediate attention, so that there is a framework in place for that work to happen, rather than it having to be negotiated as a separate piece of work when hours might matter. A retainer, or support agreement, can be a great way of ensuring there is budget set aside for fixing any bugs that are found, while any left-over development capacity under the agreement that isn’t used for maintenance and bug fixing can also be put towards improvements and new features.
Hopefully, this series of posts has given you a helpful overview of the app development process. In the next post, I’ll outline a selection of technical terms that may be useful in discussing your project with your developers.
