Why I Chose to Learn iOS Instead of Web Development
I write the curriculum for DevMountain's part time iOS development course. Our first cohort was extremely successful. If you are considering learning to code or become a developer, you should consider our iOS course. This post is a response to the number of students that ask me if they should do web or iOS, or even web then iOS.
Funny they ask me what I think. Is it not obvious what I think? I chose iOS. Here is why:
What makes iOS the best choice?
There are at least 4 reasons 1 why you should learn iOS development over web development:
- Higher income
- Scratching my itch
- Stronger platform
- Residual income
The best senior web and mobile developers make very high salaries. But pre-course students are not asking about talented senior developers; they are asking what they should expect coming out of a 12 week program (I should point out that some students are brilliantly talented after only 12 weeks).
Both iOS and web cohort graduates will interview for positions paying 1/2 or even 1/3 of what the top senior developers are making, and will be happy to do so. To use real numbers, I'm talking about $45k-70k for the students compared to the $100k-140k that senior developers make in similar markets.
Thanks to the small mobile developer pool and the current demand of companies to develop in-house and App Store applications, the best iOS graduates will end up on the higher end of that $45k-65k number. In my experience, iOS developers often are offered 15-20% more for a comparable development position. There are a lot more web developers than iOS developers.
There are also a lot more iOS development jobs than there are iOS developers.
Think of it as simple supply and demand: there are less iOS developers than are needed so employers have to pay more for iOS developers. The inverse is also true: because employers are paying a higher rate for iOS developers more students will begin to choose iOS development.
The market is currently bullish on iOS development. The cohort fills up quickly and we receive more applicants each day. The best time to become an iOS developer is right now; this is a wave that you don't want to miss.
Scratching my Itch
It has to be frustrating that when you have an app idea you have to convince a developer to build it for you.
I do not have that problem. My problem is that I have too many ideas and not enough time to build them all. How would you like to have that problem?
The apps of which I am most proud are the ones I built for myself 5. When a friend had an idea for a sunrise sunset calendar I wanted one so I helped build Rise. I wanted my daughter to learn letter sounds so I built Alphabet Sounds.
These were weekend projects. Neither of those examples took more than 50 hours to build. But they are on my phone, on the App Store, and are making a small residual income.
It gets better. As my daughter grows I can build apps specifically targeted for her learning needs. I can watch her trying to learn math and find tools and concepts that work for her. Then I can build them into an iPad app that she will want to use.
Many pre-class students pick the web class because it is a broader platform. I chose iOS because of the platform depth, and chose not to do web because of its breadth.
When you develop on a platform it shapes the way you see what you are building. Communities are formed around platforms. Typically libraries (third pary code bases you might add to yours) are built for a specific framework or platform.
- iOS development is one platform and countless libraries limited to the iOS platform. 2
- Web development is countless frameworks and libraries limited to the framework you choose.
Mobile development moves quickly, but the frameworks remain steady. At DevMountain we do not teach a language, we teach the frameworks. This means that what you learn in your 12 weeks will still be usable in 3 years. Of course there will be new features and APIs; there will even be a new language (Swift). But the frameworks remain the same.
You gain an enormous command over a deep platform rather than a broad set of skills related to web development.
You need to know: the gold rush is over. You are not going to make millions of dollars in the App Store. But that is probably old news to you. Most people I talk to would love $100-300 of residual income each month.
The fact is that once you learn how to build iOS applications you are hours away from submitting software to a store that can return to you a residual income. The experience is life changing.
The iOS platform is a powerful and active software marketplace. If you spend the time and energy making a product (even on the side) that meets a market need, and find a good way to bring people to that product 3, you will make money 4.
"Life changing" does not always come in the form of 6 figures. I have a simple application that makes enough each month to pay my family's phone bill and over the course of the year save up to buy a new iPad and iPhone when they come out.
I have another application that makes enough to pay for our family's health coverage. When we had a baby last year it was not the insurance from my full-time job that paid the bill; it was the insurance paid for by one of my apps.
Neither of these make a ton of money. But, I have not touched them in years and the income makes a tangible difference.
Ultimately any senior developer will want to learn more than just one language and one platform. If you pick web first, come over and learn iOS next. If you choose to learn iOS first, eventually go learn web development.
If you are considering becoming a developer; do it! Learning to develop is a life changing experience. Whether you focus on iOS or the web, it will be exhilarating. We are excited for you. Software development is a mentorship driven industry.6 There are millions of experienced developers on the other side, and they are ready to put their arm over your shoulder and welcome you to the party.
In the end, the best I can offer is my experience.
I left my corporate stooge job. I quadrupled my annual income. I obtained the freedom to work on whatever I want, and only on products in which I believe. I get to decide how much money I make.
I get to wake up in the morning and spend time with my little girls. I get to take a day off when my wife feels overwhelmed. My best friends work and build with me everyday.
Learning iOS development is one of the best decisions I have ever made.
The platform is bursting with users and powerful APIs and the products we are building are fun and exciting. Developing on a native platform means you can take advantage of hardware, and provide your users with better experiences. The list goes on and on. ↩
This is not true if you select a gaming platform like Cocos2d or Unity. Those will also limit the libraries available to you as you are building an application. ↩
Making significant money from iOS applications on the app store takes a full business. You will need to focus on market fit, marketing, keeping your app up-to-date, and maintaining relationships with your customers. It is not simple. But it is also not a pipe dream. I have multiple friends (not flukes) that make or have made 6 figure incomes from the app store. It takes work and dedication. And it is very real. ↩
Especially in iOS. I am always amazed by how much developers love and assist one another. Just look at Marco Arment's latest product Overcast. It is an iOS podcast application, and he received help and guidance on how to build it and what to watch out for from PocketCast and Castor developers - other independent competitors. ↩
Are you excited to start using Swift? Do you hate Storyboards? Did you notice that Apple pulled the "Empty" template from the latest version of Xcode 6?
Do I have a treat for you: The Empty Swift Project Template
Using it is simple:
- Download the file
- Unzip the template
- Move the template ~/Library/Developer/Xcode/Templates/Project Templates/ note: you may need to create the directory
- Restart Xcode and attempt to create a new project
Steve Freeman wrote an excellent article on "Bad Code":
Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.
The analogy is especially poignant because we've all been in the situation where our time is spent fixing expensive bugs in old code. He is exactly right. Bad code is like a call option: an infinitely risky choice.
Why would you ever sell a call option?
So then, why do some people sell call options? Or to carry over the analogy, when would you write bad code?
Selling an option is like entering into a contract with someone that dictates they can buy two super bowl tickets from you in 2 years for $3000 (tickets often sell for around $2000 each). If you can get the tickets for less than $1500 then you'll make a profit. If however, the tickets skyrocket to $5000 a piece when they decide to buy you would lose $7000.
You sell a call option when you know (or expect) the value of the product will go down. 1 Meaning you SELL the contract now for a price because you believe you can BUY the product for a lower price at a later time. (You sell Super Bowl ticket contract for $3000 when you are very confident you will be able to get them for less than $1500 a piece.)
We pay for our code with time and the lost opportunity of additional features. If you have to spend time fixing buggy code you can't add new features.
If you are writing code that is crappy, it means you think you’ll have more (cheaper) time later to write better code. You are selling your product now because you are confident you won't be spending time on new features later. Is that true? Or are you making a bad judgement call?
Are you unintentionally betting against the future of your product?
Some contractors may be working on a one-off product. In that case, it doesn't make sense for them to invest heavily in well written code. They sell their unwritten work for a set price, and then build it for as little as possible.
However, if it's a product for which you have long term plans, and future features to add, bad code is the wrong side of the table. When we bring on users then our time will be more expensive, not less expensive. When we our product has paying customers we'll have stricter requirements on how we spend our time, not looser requirements. If you believe in the future of the product, you shouldn't write bad code.
There is, however, a place for technical debt.
Debt as a tool is simple. Imagine you could buy an app for $20,000 that makes $10,000 a year. Would you do it? Maybe not for cash. But what if you could buy it with a bank loan? If the terms of the loan allowed you to pay off the loan in 5 years, you could grow the business and get a reasonable return on a very low up-front cost. If you believe that the business will grow, you're willing to take on the $20,000 risk with the expectation that paying off that debt will be feasible.
You incur debt when you expect the value of what you're buying to go up. Meaning you BUY the contract now because you believe you can SELL the product for a higher price later (over time). It’s important to note that the technical debt I’m referring to isn’t going back and rewriting old code. You may have a little bit of refactoring later, but true debt is something you don't pay for now.
It's entirely possible to fake out or leave features unfinished without writing bad code. For example, management may want to include "delete user" in the minimum viable product. You may buy that feature with debt (not actually paying for it) by including an email concierge service to delete a user. (The app enables the user to send an email requesting to remove a user and you manually delete the user rather than writing code to automate it). You are selling the feature for a premium because you didn't pay for it yet, and you can write code that accomplishes the feature later using the profit you captured in the period the feature was manual (i.e. hiring more developers).
You may look at your product and find features that you can purchase with debt (meaning you don't actually pay for it today, but offset it to the future). If you believe that in the future your team will grow and you will have a greater ability to spend time on features and performance, you may consider faked or manual solutions that come with very little up-front code cost. Be cautious: too much debt can eventually bankrupt a product. However, when used wisely debt may allow you to move faster than you could otherwise.
Steve Freeman was right, we don't know the future, so we should be far more careful with the code we write. Bad code is a blank check to be cashed in the future.
However, true "Technical Debt" actually is a valuable tool that developers and product managers can use in order to work around implausible delivery dates2.
I'm aware, and maybe you should be too, that most investors that sell naked call options simultaneously hedge their bets by protecting some of their downside with another call option at a higher price. This may carry over into where you may write better code in another area of the app, or you may hire another developer to go back through and write tests or fix bugs in a second pass. ↩
That's actually Freeman's term, not mine. ↩
If we're honest code style (like the famous 'nested else') is silly little problem that we all care way too much about. Objective Clean is a Mac app makes it super easy to fix. My development team decided to take a stab at keeping style rules using the app and we're loving it.
The simple purpose of the app is to set and enforce rules for code style.
On my last team we spent hours every week making each other go back and fix code style faux pas. With Objective Clean my team was able to go through all of the rules (you do it on their site) and make sure we could agree. The app doesn't change your code for you. It simply nudges you in the right direction with either compiler warnings or errors (you decide which). One of our developers went through the code and, thanks to the app, cleaned it all pretty quickly.