"Do it or don't. It's amazing how many things in life are that easy." — Henry Rollins
It seems that at one point or another in every person's career, we ask ourselves some questions that bring us to a halt — Is this what I want to do for the rest of my life? For the next 10 years? 5 years? For the next month? week?
At this moment, I cannot answer any of these questions. I tend to shake them off and continue on to some kind of destined path. I've always have been reluctant to recognize and be proud of my title at my current position—iOS Engineer. Honestly, it scares the shit out of me. I have been a designer for 90% of my career and when approached by clients and people in my network outside of my office, I tend to lean away from development speak. I've had this role for nearly 2 years and I still can't shake my impostor syndrome. I retract when asked about the Cocoa libraries, or lose focus when conversations become too technical. The thoughts running through my mind at the time are:
At the time I started writing this post, I couldn't answer any of these questions (or the questions below). I was confined to shaking them off and continuing on to some kind of destined path. I was always reluctant, back then, to recognize and be proud of my title at my current position—iOS Engineer. Honestly, it scared the shit out of me. I have been a designer for 90% of my career and when I was approached by clients and people in my network outside of my office, I always seemed to lean away from development speak.
I've had this role for nearly 3 years and I still can't shake my imposter syndrome. But I have grown to work with it—I have figured out, over time, what I excel at and what I need to spend more time on to catch up to those who were focused on computer science as early as college or even high school. I used to retract when asked about the Cocoa libraries, or lose focus when conversations became too technical. The thoughts that went through my head at the time were:
- What are they talking about?
- When will they pause so I can ask a question?
- Do they even realize I'm here?
- Why am I here?
is was a daily occurance for me—and, I have the feeling as the team grows and evolves, the revolutions of this cycle will occur faster and faster.
"As a solid rock is not shaken by a strong gale, so wise persons remain unaffected by praise or censure.” — Buddha
So today, I thought to myself, "What can I do to better my knowledge of the fundamentals in iOS development?". I figured I could come back to this post over time and fill in the gaps until I'm confident of what I've written. Here's what I came up with (please note that some of the questions are not yet answered, as this is still a work in progress):
1) What are the 4-10 most fundamental concepts in Objective-C? What are the 10-20% of ideas that produce the most results and must be mastered in order to write good code efficiently?
1) The design pattern of MVC (or more recently, MVVM) is essential for building a modular mobile app.
2) OOP, and modularity between classes, will make your objects self-sufficient, ensuring that no method is dependent upon another external class.
3) Method naming conventions, arguments and parameters should be explicit and well defined for the exact function being executed.
4) Implementing communication patterns like KVO and notifications, and also protocols, delegates and blocks.
5) Learn the frameworks! A lot of developers waste time writing code for something that is already provided.
6) Learn the LLVM and the compiler errors. Recognizing ambiguous messages will save you days in the long term!
7) Understand the concept of messaging and selectors.
8) Utilize literals, boxed expressions, boxed enums, and subscripting. They will save lines and lines of code.
9) Using preprocessor directives, macros, and global and/or static constants to properly architect a project.
10) The singleton pattern.
Apple has provided amazing documentation on 20,000+ API for iOS. Those methods have been created to provide assistance to developers to write more effective code. Using Apple's best practices will ensure that your own code will be legible and easily understood by anyone after you.
Play around with methods they have provided in Cocoa, CocoaTouch, UIKit & Foundation to see subtle differences in methods and compare the outcomes to learn why they were implemented in such a way.
2) What are the best resources/materials to learn Objective-C? Books? Tutorials? Websites? Is it best to have a mentor?
For documentation: Apple Documentation. Books: . Tutorials: . Websties: . A mentor would be nice, but, can be difficult to find one without the network—I would suggest following a few iOS/OSX engineers on Twitter, Quora, and LinkedIn, such as: .
3) If you had only six weeks to learn Objective-C, what would you use? What materials, and what path would you take?
I would definitely start with the Apple sample projects and templates. Get to know the default methodologies for table views and scroll views. Learn the MVC pattern, and understand why the Apple developers decided to implement certain methods.
Curiosity rules the programming world, and I feel that the only way to truly understand how something works is to get dirty and dig in as much as you can.
4) What small things can one create in beginning stages of learning Objective-C to apply their new knowledge (types of very basic apps)?
I would definitely start off understanding how table views work, including protocols (delegate/data source methods). Table views are a major part of most iOS application design scheme. Table views also conform to scroll view protocols as well. So it's a 2-for-1 learning experience.
5) What kind of things can one create at a more intermediate level of knowledge/skill in Objective-C? What is a typical progression like?
An intermediate engineer should be able to create an app that can handle multiple touch points, e.g., handle user authentication and server API calls and responses. They should also have a solid background in past (non-deprecated) APIs. Apple has been improving the SDK exponentially every release, so if the engineer doesn't keep up, their outdated habits will be a crutch.
Finally, they should be able to thoroughly understand blocks and operations (Grand Central Dispatch & NSOperation). Also would need to know which kind of logic belongs on the background thread (or its own thread) and what logic must be invoked on the main thread.
Typical progression really depends on the engineer's prior knowledge with programming. Apple's guidelines follow most MVC patterns as well as provide easy access to common algorithms which are fully-baked into Objective-C 2.0.
6) What is a test for proficiency of the fundamentals? What kind of application can one make when he or she has a firm grip on the basics? What is a test of advanced knowledge/skill? Very advanced? (Major milestones)
I would suggest having a lot of well-rounded experience with MapKit, UIKit, KVO, NSNotificationCenter and other communication patterns. Others I would include are from third party libraries such as: AFNetworking and SDWebImage for asynchronous networking and image caching.
7) What are the biggest sources of frustration or major roadblocks when learning Objective-C? How do you overcome them?
Definitely Apple's usage of private libraries. Of course, the engineers at Apple do a great job at documenting their code, SDK and frameworks, but it would be nice to see a little more of what actually happens under the hood. Frameworks such as Cocoa, UIKit and Foundation help out a lot for all levels of Objective-C engineers—no matter the skillset. But for beginners, it is very difficult to truly understand how some of these APIs are implemented and why they are the correct choice for your use case.
In the early months of Objective-C programming, I definitely was caught up in the magic of Apple's code. I would use a lot of their APIs without actually knowing what they did or even why I benefitted from it. Thankfully, with more time and experience, that is now a thing of the past. Now typing out Apple-provided messages is just as easy as writing in English (although Xcode's code completion does help out a lot!).
8) What skills make a great developer in Objective-C? Or in any language? What do the best have in common?
Curiosity. There are so many APIs that Apple has provided for developers, and with thousands more added and deprecated every release, you have to be curious to keep up with the latest practices. Most of the updates for iOS 8 were performance enhancements to private features used in native apps in iOS 7. If you don't have that curiousity to keep building and learn, you won't make any progress in any language you're working with. Also, reading the documentation goes hand-in-hand with everything I stated above, most initial questions and real world examples can be found in the iOS Developer Library.
9) This is more of a general programming question, but what are the best collegiate-level CS courses that help one write good code in real-world application development?
I didn't learn CS in school, I'm self taught. But for general programming, I would recommend MIT or Harvard's open source courses for 100-200 level intro cources. For courses specific to iOS development, Stanford has a lot of great iTunesU videos to watch and learn.
iOS Development Topics:
1) Experience in general, your background and (if they have rough idea of the project(s) at hand), if you've have worked on something similar in the past.
Before working at Marqeta, I had no experience of any kind with mobile development. I focused on mobile designs and responsive websites, but nothing in native code. I have a deep background in design and visual communication—I guess you can say I'm user centric to a fault.
This has enabled me to make the jump from visual layouts to actually coding iOS applications and understanding the frameworks I will eventually design for again. Before Xcode and Objective-C, our consumer app was built with CoffeeScript in Eclipse, which was an easy transition for me from front-end development to the small mobile team.
Since moving our app to native code, I've helped build, test, and ship four apps within the company and two personal side projects, and another in development.
2) What tools you typically use?
For code: Xcode is my main IDE, iOS Simulator is very helpful as well, although it is also good to have a real device around for UI testing in the final stages. I also use Atom text editor for merge conflicts and quick brain dumps.
For design: A mixture of Photoshop, Illustrator, Sketch, and Quartz Composer (w/ Origami from Facebook) for prototypes animations.
3) How much you charge on an hourly basis or how much you would charge for developing X project.
Of course, it would depend on the scope of the project, but my typical rate, because of my design expertise, would be in the $120 to $150 range per hour. An as I learn more, I'm sure the scale will inflate coincidently.
4) What's your policy in terms of communication hours, change of specs, bug fixing, etc.
I'm basically available to communicate at any time, as long as I'm not in a meeting or have any thing previously scheduled. I don't typically like specs to change drastically towards the end of a project so to prep myself for that, I have one simple request: only 3 major iterations in the planning stages of the project.
That way, the client and I can work on minor fixes and alternative onces the structure and architecture is in place. That allows me to focus on bug fixing throught the entire development process. I also typically have an exit period, like the entry period, where three changes or bug fixes can be executed before another contractual agreement is given.
This removes any liablity from a client who delays on communication or changes their minds often.
5) How did you design your apps? How did you implement certain views?
I usually start out with basic skeleton app, with nothing too visually appealing. This is typically made up of table views, collection view and scroll views to get the basic point across and to present user flows via segues. Once most of the functionality is put into code, I then move to finalizing the individual views themselves. Since I have a design background, I could waste away a lot of precious time if I focused on the aesthetics beforehand—which would typically lead to rewriting a bunch of code constantly.
6) Block vs Protocol-Delegate pattern? In what cases is one better than the other?
I really don't believe there is a right answer to this question, although there are a handful of wrong answers one could give. Let me explain:
Blocks: If your program needs a task to be asynchronous and only handles one or two extremely simple outcomes (i.e., success/failure, complete/incomplete, or data/no data), I would recommend going with the block route. This will inevitably keep the core logic of the function contained in a single scope.
Protocol-Delegates: However, if the task at hand requires many arguments or handles a myriad of outcomes, you may need to consider the Protocol-Delegate pattern. This will keep your core logic within the protocol itself, and and be subclassed within its delegates to provide their own implementations. This allows the delegate itself to essentially own the protocol without having to worry about what it has overridden in another class that uses these methods.
Also, a bonus to this particular design pattern is the addition of
@optional. If an implementation isn't configured as anticipated, the program will throw an exception or a Segmentation Fault, which is better than any false-positive a block may introduce and definitely easier to debug!
7) If you had to convince your friend to start developing on iOS, what would you tell him/her?
I would be ecstatic to have another friend join the iOS community! I have spoken with developers all over the world about issues, bugs, or just some friendly banter all because of this platform—it's been amazing.
I actually am asked quite frequently from friends how I got into doing iOS development and have steered them all to the same paths I've taken to get where I am today. I hope they continue on their journey, there's hardly a day where I'm not learning something new or improving my past work.
8) Automatic Reference Counting vs Manual Reference Counting?
I haven't coded in Objective-C long enough to have a strong opinion against ARC—I think it's a great improvement on using
retain/release for every object you implement.
However, I do regularly use MRC when I'm working with low-level C functions and APIs, like
Image IO or
GCD. It is very good to understand the differences and the enhancements that have been added because they will help you and your app grow (and perform).
I usually get into the habit, like most other developers, of writing my core logic out first, and then implementing performance enhancements later on (except for retain cycles of course!). This allows me to switch back and forth between C and Objective-C to save some overhead at runtime.
9) What is your opinion on the singleton pattern?
The singleton pattern has many use cases in modern Objective-C. Apple tends to reenforce this technique throughout its own documentation and libraries.
An alternative to this pattern would most likely be a static class, which would be great to implement if you explicitly do not need an instance of a class, but that would be difficult for OOP and for unit testing.
Also, using a singleton allows the instance to utilize KVO and NSNotifications because it has a valid reference and pointer to itself.
10) If you could improve one thing about Objective-C, what would it be?
11) What is main event loop?
The main event loop is a run loop that is executed on the main thread. This loop handles most user actions on the responder chain, i.e., keyboard inputs, view touches, etc. Additional event loops can be utilized, but must be configured manually within their own background thread.
12) Explain how message passing paradigm works and how it's used in Cocoa.
13) When does 'EXCBADACCESS' crash happen?
14) NSArray vs NSSet vs NSDictionary.
15) What is the advantage of using NSOperation over Grand Cental Dispatch?
16) What is a category?
17) What is method swizzling?
18) How does the responder chain work?
- Bucket sort
- Conting sort
- Heap sort
- Linked list
- Merge sort
- Quick sort
- Radix sort
- Random generation
- Randomized selection
- Binary search
Live iOS Apps:
- Webservice integration (AWS, Parse, etc.)
- Authentication integration
- MapKit integration
- CoreData integration
- Push notifications
- Geofencing integration
- Custom UI controls and views
- UI animations and dynamic visual effects
- Deep integration with popular APIs (Facebook, Twitter, Foursquare, Pinterest, etc.)
"I'm thankful to those who said no, because of them I did it myself." – Albert Einstein