I am currently working for a small startup. I was previously under contract, now I am working for equity (no pay). The thing is, there is not yet a signed agreement in place as the details are being worked out. I may finish development before the contract is ready.
I’m not currently under any contract or agreement, so the other party doesn’t have any legal claim (that I know of) to the code I’m writing now, other than NDA (which just precludes me from cutting him out and releasing on my own). He already has the old code that I wrote under contract. I’ve made it clear to the other party that I won’t submit the app or turn over the code until there’s something signed to protect my interests. I’ve stopped pushing commits to the company repo (I’m now the only developer actively working on the project).
However, I would still like to send builds over TestFlight for feedback and testing purposes. The other party has access to the developer portal and iTunes Connect for code signing, etc. Things are amicable and I don’t foresee getting burnt on this, but I’m not going to put myself in that position. My concern is that if I send a finished build via TestFlight, it could be extracted and submitted to the app store without my participation. They wouldn’t have the source for future maintenance and updates, of course, but it could be reverse-engineered by another developer later working from the old code base.
Is this technically feasible at all? If so, is there a way I can send builds for testing while protecting my interests?
2
If you are concerned about the binary, and other assets, within an Ad Hoc distributed app being repackaged and submitted to the App store before it is reversed engineered, then including one or more checks for an expiration date a few days out may be suitable. Perhaps have the expiration send the user back to TestFlight to encourage them to test only your latest builds. Another possibility is for the Ad Hoc deployed test version to include incidental use of several private or disallowed APIs (UDID, etc.) that may cause Apple to reject a submitted app.
You might also consider the appearance of an Easter-egg copyright notice (suitably obfuscated in code) to which the other party is not legally entitled to display.
But after any reverse engineering of an app’s binary, all bets are off.
1