Mobile and social media apps – a couple of war stories

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.

iPhone Apps

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.

Facebook apps

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”.

For example, under the Facebook Platform Policies, all apps need to have a privacy policy. Notwithstanding the fact that this may well be necessary anyway from a data protection perspective, it’s also a requirement of Facebook’s T&Cs. Most people may think that Facebook would never actually enforce these types of terms against app providers.

However, we had a client contact us a few months ago because it had received a message from Facebook about its app – the message from Facebook said that the client’s app violated Facebook’s Platform Policy (Section II.3) because it didn’t have a privacy policy (which it didn’t) – Facebook said that unless the issue was addressed by 5pm on Tuesday they would take the app down. The message was sent at 8pm on the previous Thursday, so that gave 3 working days to draft a privacy policy and get it live on the app – stressful.

What often happens is that, because the app is designed by an agency, liaising with a marketing person customer-side, the legal team are then brought in at the last stage and there’s some confusion about whether the app needs T&Cs and a privacy policy and, if so, who should draft them – either the developer (who probably won’t have the legal expertise) or the customer (who was expecting to have outsourced the whole project to the developer and hasn’t given its in-house legal time enough notice).

Another issue is whether the developer even factored in the display of T&Cs and a privacy policy into the app itself – or whether this would require some post-acceptance development / design work which the customer will most probably have to pay for grudgingly. This could have been addressed up front in the contract, i.e. by agreeing that the developer will provide the T&Cs/privacy policy as an additional deliverable or that the customer will just draft them itself (which is probably sensible given that the customer is usually the larger party with legal support). In either case, the developer should ensure the T&Cs/privacy policy are incorporated into the app and that users are required to accept them – definitely as part of any registration process.