From my understanding Apple effectively owns your entire output when you're employed full-time (at least as an engineer). At a recent interview I mentioned I like tinkering with code on the side and was told I'd have to give that up and stop contributing to open source. I imagine that extends to participation in the "outside world" at least to some extent.
The fact that Apple developers I've spoken to spend their personal coding time (on the rare occasion it exists) on work projects only reinforces all of this.
(All that said, my sample size is seven people, so I could be quite wrong in the end.)
From my understanding, it's effectively impossible for Apple employees to have any apps listed in the App Store through personal accounts. Which, no doubt, accounts for a lot of the reason why the Xcode -> iTunes Connect -> App Store experience is so miserable.
I have specific knowledge of several instances where this is, indeed, true.
Your article:
Is five years old, and never claims about that the person mentioned in article was still developing apps after being hired by Apple. In fact:
The picture displayed is from a now-defunct Seattle-centric business social networking website, and Phillip is mentioned as being part of the "Seattle Community," but a resident of "San Jose California."
It seems totally sensible that Apple would want to hire someone with experience building iOS apps, and would then make them give all of those up as soon as they're hired. Which would be identical to the experience that the people I know have had.
I did some more digging, and:
“Apple employees are generally prohibited
[from publishing apps in the App Store],”
[Evan] Doll told Wired.com. “You have to
get a special exception from a VP.
Otherwise, big no-no. If he was doing it
pre-Apple then he’d have an easier time
getting an exception,” he added.
But both of these things also apply to Google employees without special permission to 'moonlight.' And yes, it's possible to get it, and people do, but it's going to be scrutinized.
>At a recent interview I mentioned I like tinkering with code on the side and was told I'd have to give that up and stop contributing to open source.
I faced similar in my last company (not with Apple). Now find it very difficult to get working on a side project or similar at home after having not done anything in that regard in a few years.
IBM had us sign something that said we couldn't work on outside projects without permission. It seems like it's not that difficult to get permission. Most people just ignore it.
When we got notice of the acquisition a group of devs had a lawyer come in and from what I hear the lawyer basically said "don't sign this if you want to do anything outside of work ever".
I just thought this was common for these megacorps. Is that not the case? I also wonder if they can actually enforce something like that in California.
Check out California code 2870 which basically says anything you work on at home, on your own time, using your own equipment, and not related to your employers line of business, is yours. The company can still fire you for your side business though.
When checking out California Labor Code section 2870, also remember to check out California Labor Code section 2871, which expressly states that the restriction in 2870 does not limit the employer's right to require the employee to provide confidential disclosure of inventions during the employee's term of employment, and also to require a review process by the employer to "determine such issues as may arise" related to the disclosed inventions.
The "not related to your employer's line of business" is the tricky clause. With a large diversified tech conglomerate like IBM, Apple, or Google, they could conceivably argue that anything tech-related was in their line of business. They may not win, but you don't really want to fight one of their legal teams in court, and so it had a chilling effect regardless.
The fact that Apple developers I've spoken to spend their personal coding time (on the rare occasion it exists) on work projects only reinforces all of this.
(All that said, my sample size is seven people, so I could be quite wrong in the end.)