Becoming an iOS Developer

This blog post describes my experience of learning how to write iOS software, after having spent many years exclusively in the world of .NET development. It provides warnings, suggestions, and tips for others who are interested in learning iOS development. The post ends with a qualitative comparison of programming in WPF and iOS.

[UPDATE: July 17, 2012] I self-published a book that explains iOS to .NET devs. It is titled iOS Programming for .NET Developers. Learn more about it here http://iosfordotnetdevs.com

Why iOS

About a year and a half ago, I realized the world had changed. Apple was dominating the mobile market, a computing space rapidly gaining importance and relevance in the business world. Microsoft wasn’t even close to catching up. In fact, they aren’t even close yet, as far as I can tell.

Despite my years of investment in becoming a Windows desktop software developer, and my four years as a Microsoft MVP, I decided to branch out into totally foreign territory. I bought a MacBook Pro, a heap of books for iOS noobs, and started from scratch. This was not an easy or comfortable decision, by any means, but it was the logical thing to do. So, I did it.

What I have accomplished so far

So far in my voyage as an iOS developer I have worked on three apps successfully launched and used in production. Two of them are iPhone apps that I wrote and published to the iTunes App Store: Master WPF and Two Letters.

Where I gained the most experience with iOS was working as Technical Lead on an iPad project for Trane. The app assists salespeople in selling residential HVAC systems to homeowners. You can watch a brief video about the app on my employer’s Web site here (scroll down the page a bit to watch the video).

Words of warning

I have had quite a few people ask me how I went about becoming a competent iOS programmer, usually because they want to become one, too. I warn that it will take a considerable amount of time, effort, and patience to get over the learning curve. If you think that going from WinForms to WPF requires a major mental adjustment, you ain’t seen nothin’ yet.

When you move to iOS, you will need to leave behind most of what you know about UI programming from the .NET world. Fundamental things like object-oriented programming, virtual methods, properties, and loops are still relevant, and having knowledge of those things is essential. But knowledge alone won’t be enough to get you up and writing an iOS app.

You will need to re-map your existing concepts and knowledge onto a new programming language, UI platform, APIs, operating system, IDE, keyboard shortcuts, debugger, error messages, etc. This takes time, and can be frustrating for people who are accustomed to being competent and productive in another environment.

Lastly, if you are a closed-minded person, don’t even bother. I found that switching from .NET to iOS programming required me to learn a very different way to think about writing software. I’m not saying it’s better or worse than what I already knew, just different. If you can’t admit that your technology of choice isn’t superior to all others, just stick with what you know and avoid the frustration. Successful, productive learning requires acceptance and humility.

The Eightfold Path

Once you decide to take the plunge into iOS programming, it might help to have a roadmap to follow. What follows is a high-level overview of the eight things I suggest doing and learning, to become competent at iOS development. Some of these steps overlap each other, but the overall progression of topics is the key takeaway.

Step 1: Pay Apple
You need to buy an Apple computer, an iDevice (iPhone, iPad, iPod Touch), and pay $99 per year to be in the iOS Developer program. Joining the iOS Developer program is necessary so that you can run your apps on your iDevice. It also grants you access to a large number of useful developer resources on Apple’s site.

Step 2: Objective-C
If you were to move to a foreign country, the first thing you would probably want to do is learn the native language. The same applies here. Objective-C is the language of iOS. There are others, such as Objective-C++, but almost all iOS developers use Objective-C.

Step 3: Xcode
Xcode is the Visual Studio for iOS developers. Apple gives Xcode away for free, even if you don’t join the iOS Developer program you can get it. Xcode is where you write your code, design your screens, debug issues, configure provisioning files, analyze memory leaks, etc. You will spend a lot of time in Xcode, so it pays to spend some time learning how to use it.

Step 4: Memory Management
iOS does not have a garbage collector. Instead, it provides you with a very simple API that implements reference counting. This means that an object is immediately removed from memory when all “owners” of that object relinquish ownership. Before iOS 5 you needed to write all of that memory management code into your apps. Now, with iOS 5, there is a wonderful new compiler service called Automatic Reference Counting (ARC) which inserts the memory management code for you.

ARC is awesome, but I highly suggest that you don’t use it until you can manage memory yourself. In other words, don’t rely on ARC until you understand what it’s doing. There are many reasons for this; one of the most practical of which is the fact that most iOS sample code is pre-ARC.

My memory management bible, which I returned to many times until I finally “got it,” can be found here. You’ll probably need to read more in-depth explanations of memory management before that blog post will make sense and be useful.

Step 5: Interface Builder
Interface Builder, normally referred to as IB, is an excellent tool that allows you to build user interfaces via drag-and-drop. Before Xcode 4 came out, IB was a separate stand-alone tool that was loosely integrated with Xcode. Starting in Xcode 4 it was moved into Xcode, enabling a more familiar design-time experience for .NET developers.

IB rocks. It’s so good that I have never once needed to look at the XML it generates to serialize UIs. Imagine using Cider or Expression Blend and never needing to look at and edit XAML by hand!

Step 6: CocoaTouch
CocoaTouch is to iOS as WPF is to Windows. It’s what you use to create beautiful user interfaces that do real work. CocoaTouch is a high level library, built on top of several lower level libraries, such as Core Graphics and Foundation. It is a library with many frameworks and APIs, ranging from touchable Buttons, to customizable maps, to video players, to device-level notifications. It also has deep and rich support for the Model-View-Controller design pattern baked in, including a full navigation system based on view controllers.

The best book I know of for learning CocoaTouch is the one from the Big Nerd Ranch.

Step 7: Core Data
Once you are comfortable with the language, IDE, and UI platform there is still one more topic you need to wrap your head around. It’s called Core Data. It’s a framework, by Apple, that simplifies working with an application’s data. It does a lot of things for you, including mapping entity classes to SQLite tables (or other backing stores) and translating high-level queries into low-level queries and executing them for you.

The book that I read to learn Core Data is called “Pro Core Data for iOS”. Apple also provides a lot of great documentation about Core Data.

Step 8: Publish Apps
Don’t just write apps. Publish them to the App Store. Apple can reject your app, and prevent it from being available in their App Store, for many reasons. Professional iOS developers need to know how to create iOS software that will be approved by Apple. Plus, these days, companies looking for iOS developers require that you can demonstrate your skills by having published apps. If you don’t have apps in the App Store, you’ll be at a huge disadvantage when applying for iOS jobs.

Apple recently published their own roadmap for getting started with iOS development here. I haven’t checked it out in depth, but it is getting rave reviews so far.

Comparing Apples and Microsofts

The last topic I would like to touch on, which is also the most difficult to communicate, is a qualitative comparison of WPF and iOS programming. This is inevitably subjective and circumstantial. I hope it conveys an impression of what one can expect when developing iOS software.

Apple expects developers to be smarter than Microsoft does. Microsoft works hard to ensure that programming technologies are usable by as broad a range of people as possible. Their tooling and documentation assume you aren’t quite sure what you’re doing. Apple, on the other hand, is not nearly as helpful and pandering. I’m not saying either approach is intrinsically better or worse, but as a reasonably intelligent developer I prefer not being handled with kid gloves.

Visual Studio has way better visual debugging tools than Xcode. Apple has been improving their debugging tools in each release of Xcode, but the debugging experience for a WPF developer exceeds that of an iOS developer any day of the week.

Objective-C is very weird at first. It takes some getting used to. Once you become accustomed to the odd-looking syntax, however, it’s actually rather simple and pleasant to work with. Compared to C# it is much less feature-rich, but that hasn’t been a problem for me. I have enjoyed writing Obj-C quite a bit.

iOS apps run lightning fast. Not having the overhead of a managed runtime environment, a garbage collector, code-access security, etc. really helps keep iOS apps fast and easy on the battery. Remember, when writing mobile software, battery is king and speed is a close second. Objective-C is basically plain old C with some extra keywords that support object-orientation, and a very lightweight runtime also written in C. It’s really, really fast.

In iOS you don’t decorate user interfaces with renderings created and styled in markup. Instead, you use bitmap images (typically, PNG images) or, in more demanding scenarios, draw to the screen in code. Since iOS apps exist in a fixed size window, you generally don’t need to worry as much about having resizable graphics, so using images is easier, assuming you have a way to get the images in the first place.

The primary design pattern used for structuring UIs is Model-View-Controller (MVC), not Model-View-ViewModel (MVVM) like in the WPF and Silverlight worlds. As I mentioned above, CocoaTouch has full support for MVC baked in. It’s quite nice to have that in the platform, because it’s less code you need to write and maintain. In my Master WPF app, I actually used ViewModels in one screen, but that’s a topic for another post.

Abort()

This blog post was not intended to persuade or dissuade you to or from iOS. I don’t care what kind of programming you decide to do. Hopefully this has given you some insight into what it has been like for a .NET guy to try out something new and different. Maybe you learned a thing or two along the way.

Have a great day!

Share this:

Like this:

LikeLoading...

Related

This entry was posted on Sunday, February 19th, 2012 at 4:43 pm and is filed under iOS. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

@hybrid – I tried MonoTouch about a year and a half ago, when I first got into iOS. I thought it would be a way to write iOS apps without needing to learn Obj-C and Xcode. I didn’t like it, way too many bugs in the platform and the IDE (MonoDevelop) crashed all the time. It might be better now, but I have no intention to return to it. Native is the way to go.

@ross – Yeah, it’s not cheap to get started, but it’s not like getting into .NET programming on a Windows box is free either. Regarding UI styling, there’s more to it than the brief description I gave in this post. There are many options depending on what you need to do, ranging from static images, to Core Animation, Core Graphics, and UI View layers. I don’t find UI customization in iOS to be as open as in WPF, where control templating is everywhere, but that’s not usually necessary. The standard iOS controls already adhere to the iOS style, which is what most apps should stick with anyways.

“iOS apps run lightning fast. Not having the overhead of a managed runtime environment, a garbage collector, code-access security, etc. really helps keep iOS apps fast and easy on the battery. Remember, when writing mobile software, battery is king and speed is a close second. ”

Well said! I totally subscribe to this line of thought.

I’m wondering how C++ apps will measure up against its .NET counterpart in Windows 8. Im hedging bets on native code to build apps that shine…but at this point I think I may need to do obj-c to make apps that really sell😉

It seems to me it make more sense to compare programming for WP7 and iOS than WPF and iOS. I see many things that are similar:
99$/year membership, to post an app on the market place the app should be approved, fixed sized window and etc.

@dima – since WPF and Silverlight are essentially the same now, a WPF/iOS comparison is valid.

I think the big blocker for non Apple devs is having to buy a Mac in order to develop. Many of us, myself included, already have Windows PCs and have a hard time swallowing the “Apple tax”, especially if it’s just to play around.

Can you say a few more words about why you decided to pursue iOS? I am also a WPF desktop programmer, and it does seem that Microsoft is way behind in the mobile space, so I’m struggling with the same sort of questions that you answered (apparently) over a year ago. Why iOS and not Android? Are you seeing less jobs for WPF and more for iOS. How about jobs for Android? Is the pay the same, less, or more for iOS? Did you manage to convince your work to let you do an iOS project or did you just “go it alone”. I saw that you’ve already produced something for the Apple store. Congratulations!

@spivonious – You could pick up a used Mac Mini for relatively cheap, but I agree that it’s a lot of money if you only intend on playing around with it. I invested in a new MacBook Pro because I wanted to take my career in this direction.

@Dave – Those are great questions. I’ll do my best to answer each of them.

Q) Why iOS and not Android?
A) Several reasons. I prefer iOS over Android (I have had both phones and definitely prefer my iPhone). I have friends who are iOS devs, and they loved the platform, which influenced my thinking. Also, getting into iOS represented a more significant challenge than Android, because the language, OS, IDE, etc are so different than what I knew at the time. I figured it’s better to tackle the harder challenge first, not only for the sense of accomplishment, but because I assume that fewer people can/will do it and succeed.

Q) Are you seeing less jobs for WPF and more for iOS. How about jobs for Android? Is the pay the same, less, or more for iOS?
A) There are plenty of WPF jobs out there. I assume the relative number of jobs, and how much they pay, between iOS and WPF is based on where you are looking for a job. I wasn’t getting into mobile because of the immediate impact it would have on my career, more for the longer term impact. Get in before the masses, and you will be the expert when demand is high later on.

Q) Did you manage to convince your work to let you do an iOS project or did you just “go it alone”?
A) I work for consulting firms, so I rarely get to influence what type of projects I work on. My previous employer had a client that needed two iOS apps, and they wanted it developed using MonoTouch. That was around the time I had already begun learning iOS on my own. I think the only way to get work doing what you want to do is to first learn it in your free time. Otherwise, why would someone hire you to do it, and not someone else who already has experience with that tech?

RE: Android. The thing is, and what you touched on, is that while it may only take you a couple of weeks to learn something like Java, you need to ask yourself, do I want to devote all the effort of learning the Android framework and API’s? Is this the future? Is it my definition of fun? etc…

I think too many people ‘language’ hop and never delve meaningfully further.

Wow, this sounds like the same thing I went through towards the end of the year, I bought a second hand MacBook Pro, pay that $99 tax, download XCode, and throw myself into the deep end, now I can proudly call myself an iOS developer, since I have an app, on the AppStore.

I have been developing for Windows most of my career.
When it came time to buy a smart phone a few years back, the major factor in my mind was market share (where do I have the best chance to sell my apps), and thus I purchased an iPhone. I did this not realizing I would need some kind of Mac and 99$ a year. I was not happy to say the least. Out of principle I refused and after a year of hard work, I finally got OSX to run in a virtual machine on top of Windows 2003. Although I proved a point to my self, this method was just too slow and hacky. Earlier this month was my birthday and my wife got me a Mac Mini. I still refuse to pay 99$ until I am ready to push my apps to the App Store. With that said, I jailbroke my phone, installed AppSync and whala. I can now build and deploy from XCode to my device for testing.

I do have to give Apple props for giving away their development tools!

I will be following your suggestions to become proficient with IOS development

Great write up Josh. I appreciate your frankness in regards to the frustration of going from a high level of proficiency in one language to struggling as a beginner with a new language. I’m going through that right now and your article is good encouragement to put my head down, soldier on and trust that in time I’ll attain the same level of speed and proficiency and I’m used to.

Can you add a little time context to your experience? How long did it take to get through the initial learning process before you officially started writing your first app? (I assume you did a lot of demo work beforehand?) How long did each app take to develop? What do you think the time frame is for becoming functional at iOS programming? Anything that adds a little form to the nebulous and intimidating “deep end” of learning a new language would be helpful for those of us considering taking the plunge.

@Trent – That’s a good question, and it’s hard to answer. My iOS learning was a casual, after-hours activity that I did while working a full-time job. I would say it took me a couple of months to read about Obj-C, write little demo apps, learn Xcode, etc. before I felt like I knew enough to realize how little I knew. Probably 4-6 months of tinkering and further reading before I started gaining enough confidence to publish my first app (Two Letters). Once I had an app in the App Store, I was able to get a full-time job writing iOS apps, which then rapidly increased my exposure and experience with the platform. All told, I’d say it took me a year to become competent enough at iOS that I would honestly call myself an iOS developer.

Thanks, nice share!
Do you have any experience/opinion on whether Objective C’s “nativeness” can be a disadvantage regarding taking advantage of multiple cores and async programming? It seems to me that MS, especially with F# but also with the upcoming version of C# may get a non-trivial advantage with respect to this later this year, but I don’t know Objective C nor iOS, so it would be interesting to get some thoughts on this. Users are craving multi-core phones and tablets, but it is not obvious to me that many developers are ready/able to take advantage of those extra cores yet.

@Jarle Stabell – iOS has full support for leveraging multiple cores, as found in their iPhone 4S and iPad 2 hardware. If you are interested, take a look at the Grand Central Dispatch API. Here is Apple’s documentation on GCD (it applies to Mac OS X as well as iOS).

@Dan M – I do and I don’t miss LINQ. I really missed LINQ to Objects when I first started doing iOS work. Then I found that the Foundation classes (such as NSArray) have a lot of the LINQ-ish functionality that I sorely needed, just called by a different name. This is the kind of mental re-mapping that I referred to in my blog post.

Since I use Core Data in my apps, I can leverage this awesome free library that adds even more LINQ-like goodness to my toolbox…

@ross – Phew, that’s a long list. You’re not going to get exact parity on most of those, but there are, in many cases, things that somewhat resemble the things from your list. Also keep in mind that Obj-C is not as strongly typed as C#, it’s based on message passing, and the Obj-C runtime is open for your code to fully access and manipulate it, so it’s a different world from .NET.

Anonymous Types: Structs can be declared in a function, which I believe is something Obj-C gets from the standard C language. It’s somewhat similar to anonymous types.

Anonymous Delegates: Yes, they are called blocks.

Generics: No.

Reflection: Sort of. You can get runtime info from the obj-c runtime, and there is basic support for introspection (asking an object what type it is, etc). If you use Core Data for your data model, those objects can leverage the rich type information in a “managed” object. Also, the Obj-C runtime makes it easy to create types, and modify types, dynamically.

Closures: Yes, blocks support capturing variables from their declaration site.

Attributes: No.

Aspect Oriented (postSharp): Not sure.

TDD: Yes

BDD: Not sure

Continuous Integration: Yes, I’ve seen tools for that, but haven’t used them.

I don’t understand why many developers think that things created by a company should be free. Businesses deserve compensation from the consumers of their products. If you don’t want to pay, use open source technologies. There’s no sense complaining that companies charge for their products and services.

Josh – Great post. I suspect many .NET developers are making the jump to iOS. I took the plunge several months ago and was a little hesitant with the Objective-C language and new IDE. I like learning new things so hopefully the change won’t take too long!

Regarding data access though (haven’t gotten that far). Would you recommend creating a WCF web service to provide the data needed for the iOS (iPad) app? We use SQL Server as a backend so wasn’t sure if that is the best approach.

@Jason – Thanks, I appreciate the kind words. The large, line-of-business iPad app I worked on talks to a set of WCF services. The server-side technology doesn’t really matter from the mobile device’s point of view, as long as it accepts and emits properly formatted data.

Josh, Great post – thanks! Much like you, I am a .NET developer who is diving into iOS. Your numerous articles and posts on WPF and MVVM have been immensely helpful to me on the .NET side, so I am happy to see you venturing into iOS as well. Anyway, thanks for all the contributions you make to the developer community.

Josh, it happend several times that I was in need for help and your article saved my time. Thank you for this and wish you success in Apple’s world.

To lower initial costs one could consider installing iOS on PC. Since later versions of iOS are compiled to x86 it is not a big deal. Snow Leopard could be installed on PC with full GPU hardware accelleration (I tested EP35 Gigabyte mb, Intel E8200 cpu, Ati 4850 gpu). Windows 7 still could sit next to iOS as dual boot. I recommend searching for hackint0sh. It might not be 100% legal though.

I have two concerns about iOS development:
– The increasing restrictiveness of apps that are to go into the app store
– Private commercial application that are not intended to be sold through the app store

I have heard that some iOS developers have decided not to submit new app updates to the app store because of the increasing amount of sand boxing limitations

@David Roh – I am not familiar with the increasing restrictiveness that you’re referring to, so I can’t speak to that. For apps that you want distributed to your users, but not via the App Store, you can use Apple’s Enterprise deployment system. It removes the restrictions that are placed on apps in the App Store, such as adhering to Apple’s UI guidelines, download file size, etc.

Found your blog through google+ but I just wanted comment on something strange about the timing of this post.

I come from a world of Flash and Actionscript programing, and I’m happy with android and it’s development. That being said, I’ve been really impressed so far with Microsoft’s Windows Phone, and the comparison of windows 8 to Ipad makes me actually think about getting a windows 8 tablet rather than an Android one.

I would expect .net developers to be a bit more happy about the recent shift in technology and their prospects for the future.

Would it be possible to use a “New iPad” iPad 3 for development of iPad 3 and iPhone apps – that is, install all the development tools on the iPad 3 (I am obviously an iOS newbie). A second choice would be to buy a Mac Mini and add a high resolution display, keyboard, and mouse.

Air Book and Mac Pro laptops are nice but they are way over priced for what one gets.

@David Roh – The development tools for making iOS apps all run on the OS X operating system, not iOS. This precludes doing iOS development on an iPad.

I suppose the value of hardware is subjective, but I don’t think Apple hardware is overpriced. It’s very well designed, well constructed, and durable, which I cannot say for most PCs I have owned in the past. Most Mac users I know end up buying a new Mac because they want the latest hardware and software, not because the machine craps out like a cheaper Dell/HP/etc would. It’s not uncommon to hear of Apple machines lasting for 7 or 8 years, with regular daily use. Spend more now to spend less later, that’s how I see it.

I did a lot of hardcore iOS development on a Mac Mini with an HP monitor, before my employer upgraded me to a MacBook Pro. It worked just fine.

@Dave – I can’t say from experience, but based on what I’ve heard and read online, the Air can run Xcode just fine. They already come with SSD instead of an old-school hard disk. My MacBook Pro has SSD and 8 GB RAM and it is smoking fast. I read that 4GB RAM in an Air is enough.

Josh,
Thank you very much for a very informative post about iOS development from a .NET perspective. I am finishing a Silverlight app and planing on porting it to iOS using MonoTouch(it seems like the path of least resistance), but your experience with the platform is convincing me to bite the bullet and go native. With Microsoft’s recent WPF/Silverlight future fiasco, iOS development looks more and more attractive.

I’m surprised that you’ve moved to iOS with Windows 8 around the corner and Metro recently announced. It would seem logical to take your XAML and C# experience in to the new Windows 8 world, wouldn’t you agree? I can only assume you think that platform is going to bomb.

I too am interested in tablets from the perspective of a field device for LOB applications. Being a WPF developer I’d obviously favour Metro over iOS but I can’t deny the lure of the iPad. However, I do ask why I’d bother learning that platform when all I write are LOB applications.

@Andy J – I am already seeing lots of interest in LOB apps for iPads, amongst other mobile devices, at the consulting firm where I work. I believe that we are at the forefront of a new era for LOB software. It will no longer be the exclusive dominion of desktop and web apps targeting a large monitor. Regarding my shift away from Microsoft technologies, it’s more based on my recognition of Apple’s success than a prediction of Microsoft’s pending failure. That’s not to say that I think Windows 8 will be a success.

Well, I have my Mac mini up and working with 8 gig RAM, XCode installed, and just bought a “New iPad” (really bad marketing name – what are they going to call the next one the Newer iPad).

However, there are a lot of things that a Windows developer is use to that must be learned about the Mac (OS X) and iPad (iOS) such as
– File structure
– What to use instead of Windows Explorer (I would like to see the real file structure, get to root, etc)
– How to do a network connection
– How to download compressed data and uncompress
– How to create a database and read and write data to it
– What website are good for developers (is the a CodeProject for iOS and OS X?)

Anyway, I think you get the idea – so were do I go to get developer type info?

– You can view the file structure of an App by right clicking the app and selecting ‘show package contents’

– Finder (on the mac) is the stuff you use on the mac for browsing the file system ( and ofcourse terminal). Note that apps on iOS are sandboxed and normally you can only read/write from its own directories. So there’s no easy way to browse the files on your iOS device

– See examples of NSUrlConnection in the apple documentation to get you started with the networking stuff.

– For database you can use sqlite directly (pre-installed on each iOS device) or core data (more orm like)

– Apple provides lots of examples on their developer website (also the video’s of WWDC are available there). There’s nothing like codeproject for iOS AFAIK.

Josh – Thanks for the overview. I do have a question that I thought you could answer. When you created an app for Trane and distributed it to their salespeople, did you put that app on the iTunes App Store where everyone could download it? Or did you use the developer account and use the unique device identifier to specifically identify the target devices and thus bypass the App Store? Or is there another way to distribute apps to a specific group of people?

Okay, so I have been working my way through the Stanford videos. I have created a test app and I can run it on by iPad using XCode; however, I would like to permanently install the test app on the iPad so that I do not need XCode to run it – how do I do that?