You don't need to know git or cocoapods. In fact I had to just look up cocoapods as I've never heard of it. It seems it uses Ruby, which explains why I've never heard of it, as I don't use Ruby. I guess I'm incompetent (or perhaps just not cool :)
You should look into it. It will help you. You don't have to use it, just understand it's a tool available to you. Not trying to insult any one—just give them a framework for learning.
Git has become pretty synonymous with source control management, which is definitely valuable for a mobile dev, and a first class citizen of Xcode now. So, makes sense for it to be there.
Cocoapods is a great project -- basically makes it a _lot_ less painful to deal with 3rd party libraries.
However, in general I think junior developers rely way too heavily on 3rd party libraries.
Pretty neat to see a rouge map of iOS knowledge drawn up like this. Makes you realize you know more than you think. It's interesting when you compare all of this against someone who is first learning to develop for iOS (or anything software related). You gain an appreciation for all the hurdles a newbie coming to the field has that an experienced developer takes for granted.
I would have maybe brought design patterns higher up the tree and have the Apple Frameworks underneath them.
Reason being that it's more important to know how to use/approach the frameworks than it is to be completely versed in all of them. They often follow the same delegation patterns, etc. Knowing how to approach the documentation and look in the header files for help is -- to me -- primary to the details of the frameworks themselves.
11 comments
[ 2.1 ms ] story [ 30.7 ms ] threadCocoapods is a great project -- basically makes it a _lot_ less painful to deal with 3rd party libraries.
However, in general I think junior developers rely way too heavily on 3rd party libraries.
Xcode supports both, though git is enabled by default.
I would have maybe brought design patterns higher up the tree and have the Apple Frameworks underneath them.
Reason being that it's more important to know how to use/approach the frameworks than it is to be completely versed in all of them. They often follow the same delegation patterns, etc. Knowing how to approach the documentation and look in the header files for help is -- to me -- primary to the details of the frameworks themselves.