I’ve been asked the following question quite a lot recently: “Do you have a template app development agreement”. That question often gets followed by: “Is it just a standard software development deal or is there anything else I need to worry about?”. The answer is “yes” – there are a few extra things you need to worry about, in particular, because of the nature of the third party platforms that mobile and social media apps are made available on – the two most obvious being Facebook and Apple.
The vast majority of app development contracts I’ve worked on have involved the app being developed by a small agency (usually in Shoreditch) and commissioned by a large company with a desperate need to launch the app asap. As a result things often get overlooked in the initial discussions and it can be too late when it comes to papering the deal. There are a couple of issues I’ve experienced recently from working on social media / mobile app development projects which I thought I’d share in this blog post.
Who’s going to submit the app to Apple? Us or them?
If the customer’s going to do this (i.e. using its own iTunes developer account) then the customer will still need some assistance from the developer if, for example, the app gets rejected – i.e. the developer’s obligations shouldn’t end on satisfactory delivery to the customer because there’s the additional hurdle of acceptance by Apple (over which neither party has any control).
Certain customers may not have the resources or expertise to submit the app to Apple and may therefore want the developer to submit the app on the customer’s behalf. If so, there should be an obligation on the developer to keep the customer updated as to the status of the submission to Apple.
Whether the customer or the developer is going to submit the app becomes particularly relevant when it comes to payment. In software development deals, you generally expect to see acceptance testing provisions, with payment obligations linked to completion of the acceptance tests.
The developer will obviously want to get paid as soon as possible. If the customer’s going to submit the app to Apple – then this could create issues because the customer won’t want to pay the developer until the app’s been accepted by Apple, whereas from the developer’s perspective, once it’s handed over the app to the customer, it has no visibility over the acceptance testing process and therefore the timeframes for payment. Split payments are a good compromise along with an acknowledgement that the customer has no control over the Apple acceptance process.
If the developer is managing the submission process, the customer will need satisfactory evidence from the developer that Apple has accepted the app before it hands over any cash – if the customer has a strong bargaining position it could agree with the developer that it won’t hand over any cash (or the final instalment) until the app’s actually live on iTunes.
Given that the app will be sitting on a third party platform – there’s also the issue of the app’s compliance with the relevant third party platform operator’s T&Cs – e.g. Apple’s notorious “iPhone Developer Program License Agreement” or the Facebook “Platform Policies”.