Edit June 19, 2013: Apple now allows transfer of apps between teams. Thankfully I haven’t initiated the process below. There are cases where Apple doesn’t let you transfer the app, so this post might still be relevant.
I recently took over the Tegoed app from my friends at Tupil and Zeker Waar. It’s an iPhone app that lets you check your phone balance and sends you push notifications when for example you’re about to run out of data.
I’ve developed my own apps and those for clients from scratch in the past, but this time I’m taking over an existing one. I recommend that you consider doing the same: take over an app that has already made money. There are lots of apps with early success and great potential out there that are no longer being maintained for all sorts of reasons. The owner might have a full time job, they might not charge enough for the app or do something completely wrong from a business point of view.
In this case, Tupil is too busy working on their wildly succesful Beamer app and Niels form Zeker Waar with his new startup Brainsley. The app was already making money, albeit a lot less than in it’s early days. The fact that people were evidently willing to pay for this app, puts it way ahead of earlier apps I developed and also gives it an advantage over any new – unproven – ideas I might have.
Best of all, it doesn’t have to take a ton of cash to buy an app; you can work out a revenue or profit sharing deal, offer X hours of free development time (there might be some tax caveats…) or perhaps they really don’t believe in it anymore and you get it for free.
You can probably draw up a contract without a lawyer – because a lawyer will cost you more than the app – but make sure the contract does not have any ambiguous clauses. Make sure it’s clear who owns the source code. If you have some sort of transition period, make sure their related clauses expire, meaning the contract becomes less complicated with time. It would be nice if there was a set of standard contracts for each country and a tool to tweak them based on your preferences and the kind of deal you want. I’ll let you know in a few years if this was good advice 🙂
Once the app is yours, you’ll need to take care of practical things.
Accounts (except Apple)
We had to transfer about a dozen accounts to my company: Twitter, Gmail, Airbrake, the domain, server, etc. Most of these accounts were registered with a @tegoedapp.nl email address. They would send me the password, which I would change and then I just changed my contact details and credit card info. The server and domain require a bit more paperwork, but those are standard procedures.
Moving the app
The first thing you should try is to ask Apple to move the app from the original developer’s account to your account. This way the users won’t notice a thing. There’s 99% chance that Apple won’t do this for you, but you should try anyway and be persistent (and polite of course). The more people who actually bother to ask, the more likely Apple will change their mind at some point in the future. It’s worth it because this would be a great user experience, lead to less unmaintained apps and be good for your business as well (you’re going to lose customers when you move the app).
If the app is the only app for that particular iTunes Connect account, there’s a second thing you can try. This was the case for Tegoed. It was owned by a company account beautifully named “Tegoed”. This looks a lot more professional than the personal name of a developer, which is especially important if you want your users to trust you with their phone company login credentials. Of course Apple wouldn’t do this either, but again, you should try.
What you most certainly should not do is the same thing you did for all the other accounts – namely to take over the existing account and just change your contact details. This will confuse the hell out of their systems and lead to some very concerned phone calls. 🙂
Assuming the developer you’re taking over from doesn’t mind if you use their account during a transitional period, that leaves just one option.
Tell your users to re-download the app
Last year the #1 Dutch news app nu.nl published an article and sent a push notification to at least a tenth of the Dutch population telling them to go and download their new app. Unfortunately the link opened in an in-app browser window and didn’t work in my case. When I went to the app store and searched for the new app, I coulnd’t find it (“Nu” means “now” in Dutch and does not make for a good search phrase).
What I’m trying to say here is that if you delete the app from the original account and release it again from your new account, it will be a terrible user experience. You’re also going to lose customers and lose the amazing reputation your predecessors built up from customer reviews (at least in my case; in your case it might be a good thing if they didn’t maintain the app for several years before you took over).
Let me help you ease the pain.
Note: this a work in progress, I will update this post if it works out fine or fails miserably. Use the following at your own risk.
I’m going to assume your app uses a server. You could even just put a text file with some magic words on a server somewhere if necessary.
The first thing you need is for your server to able to tell the app that the user needs to move. You could implement a dedicated method for this, e.g. http://yourapp.com/are_we_there_yet.json or just append the result to a commonly used server method. Once the new app is ready to go – and not before – it should return:
[gist id=5356032]
If your new app is free, then there’s no rush for people to move. If your new app is not free, one option is to make the new app free for a limited period of time and only letting your current users know. In that case the message should make it clear that they need to move quickly. Another solution is to make your app free and introduce subscription pricing. Assuming you have a server that keeps track of users, you can keep this functionality free for old users either for a limited period of time of indefinitely. The latter may be the topic of a future post.
Now either call the are_we_there_yet method in applicationDidBecomeActive in your app delegate or just append the following code to where your json result is normally processed:
[gist id=5356100]
Your app delegate listens for this notification and presents an alert. If the user dismisses it, he won’t be bothered for a week. Otherwise he’ll be taken to the App Store. Track the conversion using something like Mixpanel. This is also a good time to check out UIAlertView-Blocks, which of course you’ll install through Cocoapods.
[gist id=5356176]
Submit this update through the old account and make sure there’s enough time for your users to update before you remove it from sale.
App name and push notifications
Now it’s time to upload the app to your new account. Make sure you disable the moving code. Once the app is approved for your new account, you should remove the app from sale from the old account. This way when the user searches for your app, they’ll find only one instance.
You should not however completely delete the app. Correct me if I’m wrong, but if you actually delete the app you will lose push notifications, iCloud and perhaps other services. Also you won’t be able to update the old app if for any reason you need to do this. I recommend that you keep the old app alive and the Developer Account active for a while, probably until the next yearly payment is due.
There are two problems remaining: the name of the app and the continuation of push notifications during the transition phase.
You can’t have two apps with the same name in the App Store. The way I dealt with this is by renaming “Tegoed” to “Tegoed 1″ and then immediately claiming”Tegoed” for a new app on my own iTunes Connect account. Alternatively you could name the new version “2”, but I’m very conservative when it comes to version numbers. As far as I can tell, it’s not the app name that needs to be unique but the localized name(s) that are used in the store. You can only change the name of an app when you ship an update. The old name becomes available the second your new version is ready for sale. If you have enemies, be careful about your timing.
If your app uses push notifications, it’s important that those keep working on both the old and the new app. For that your server needs to know which cert file to use depending on the app the user has. The app should probably tell the server which version it is and you should store this in your server database.
Conclusion and work in progress
As I said before, I’m in the middle of this process myself. Any other things I should be aware of? Reply here or send me a message at sjors@purpledunes.com.