I wrote a 30+ page guide/book called Building iOS Apps From Scratch a few months ago, here's a link if anyone is interested. http://designthencode.com/scratch/
Your design tutorials look awesome, I will be picking them up. Do you have any recommendations for similar books, blogs, etc, that focus on low-level technique for creating user interface elements for iOS? I really like your technique of using layer styles, etc, and have always wondered what are some other tricks of the trade are ways to create realistic UI elements. (I am proficient in Photoshop as a tool, but not really proficient in applying it to the end of creating UI elements.)
Thanks! There really aren't many, which was a key reason why I put some together. There are lots of free PSD sites, but obviously they don't include any instructional material. However they are great to poke through to see how things are constructed so I'd recommend heading to Dribbble and 365psd and poke around for some free PSDs. They're great to learn from.
-track down an example app to hack around with. this was the single biggest thing that got me from the hurdle from a Hello World app to a production full featured thing
-learn objective-c yes there is no way around it! try rewriting your favorite python or C example to get your head around some of the translation
-stackoverflow is your friend
-it's easier to get started working without Interface builder, so you can do that just to learn a thing or two with a sample app but then do the same thing using IB; it will be quicker and cleaner in the end. this may be the hardest thing to start to wrap your mind around as it involves lots of clicking and less hacking
-design is everything. if you really want a quality app it's key to go from the bare bones to something a designer put skill into. once you get the hang of IB this can be a quick and amazing makeover. find a good designer to collaborate with.
What I did was make a simple app highlighting each skill I wanted to learn (Tables, Pickers, etc.).
Realize that a lot more time than you think will go into submitting to the store, provisioning, and getting your ducks in order there. Don't leave one hour to do this the first time. Also don't asume because it was easy the first time it will be the next. XCode gets very confused with multiple provisioning profiles sometimes. Things expire. etc.
I read the O'Reilly iOS book and Tapworthy along the way. And an Objective-C book or two; but I don't remember which.
Just watch out - as with every language, there is a lot of bad code out there. While I agree with the notion of reading others' code (personally that helps me a lot to learn a new language), I'd go through the Apple-provided sample code before venturing into code of random apps.
Yeah, I meant things like sample code for plain C frameworks, where the author has just decided "hey, why not do this in Obj-C++ instead of Obj-C." As I recall, many of the AudioToolbox examples are like this.
Didn't mean to imply that there's no place for Obj-C++, just that it's not good style if you don't actually need it (like to wrap a C++ lib).
For those of you thinking about making an iOS app for your startup or for profit, make a note of this:
Making the app is the easy part, it's the marketing that you really need to be working on and it's the marketing that will make or break your startup. It's the critical joint.
This is a very important point. I've got an incredibly simple app on the market, but because of some good publicity, it's gotten some good download numbers. On the flip side, I'll see great apps that've gotten < 1000 downloads simply because the author didn't get out there and write to every blog in sight.
I just threw email darts at the dartboard that is Android blogs. A few of them stuck, and people started to download. That got me some decent ratings, and it's kept going from there.
As I said in another comment, emailing Android blogs got me a couple of app of the day type things. I also stumbled across my app being the top comment in a fairly popular Reddit thread which I responded to (as the developer) which got me a spike of good ratings and activity. To be quite honest, it was a fair amount of luck.
It's so much easier when you already know how to program anything.
I was a Perl dev and dabbled in Java. I was forced at my job to learn iOS and produce a specific app in less than 3 weeks.
Wasn't pretty, but working under pressure can be good motivation too.
Pretty similar situation here. Was told to experiment with mobile apps first, but after deciding to use my own computer went native instead. From a background in PHP and only very limited knowledge of how Obj-C works, I managed to get an app mostly finished in the best part of a fortnight.
The biggest hurdle was actually trying to create a native form; something which is remarkably difficult to find good resources for compared to other things.
Had I tried to learn in my own time, without the pressure of having to get something working at all, I would have spent months reading textbooks and learning how to write basic hello world apps.
Instead, I made more progress than I could ever have imagined just by being given a challenge and an idea of what to make. And that's sometimes the best learning experience you can get.
Thanks for this submission. I'm currently learning iOS development for the specific purpose of building an application. Ironically, my biggest obstacle has been choosing a path from the numerous options that can be found online. I've decided to pick a path that I find credible and stick with it regardless of its optimality. Your path is the way.
So what path have you chosen? I am a Ruby programmer and want to make an iOS app. I'm planning to use the Stanford course on iTunes to get started. Do you know if that's any good?
The Standford course is really great, really well-recorded. They always make sure to repeat questions students ask for the sake of people who are watching them on iTunesU.
Also a Ruby programmer, and I'm currently on lecture 5 and assignment 2 of the Stanford course, and I'm finding it very good. I've dabbled here and there with various Obj-C tutorials, but this course takes you from knowing nothing about Obj-C, Cocoa Touch, and XCode, right into building apps. Because it is targeted at Computer Science majors who already know other languages there is no basic-level stuff like, "This is a loop", "This is what object orientation means", etc.
I don't think of myself as a visual learner and I tend to avoid screencasts in favour of reading, experimenting, and hands-on learning, but the difference between web development with Ruby and mobile development on iOS is so big that the methodical, step-by-step nature of this course is helping me.
I learn best by immersion and example, so I just picked a project and started building. I looked at prominent open source iOS apps and constantly referred to Apple iOS SDK docs, Apple example code, and several prominent books on iOS development (Hillegass, et al).
If you're more of a methodical or visual learner, use the iTunes U course videos.
My biggest piece of advice is to just do it. Jump right in and start writing some apps. You'll never get good if you don't actually build anything, for the most part, so just jump in and build something.
Between stackoverflow and all of the iOS blogs, google actually makes this approach ("I'll just hack until I have a question") totally reasonable. The modern Internet has very much changed the experience of picking up a new platform.
One of the biggest things that I stumbled over was whether or not I should code straight objective-c or use Interface Builder. In the end, I feel IB just gets in the way of being able to do cool things. I think if you're serious about making cool apps then stick exclusively to building apps with objective-c and avoid IB. (imho)
For normal interfaces XIBs are way easier to maintain and handle then a bunch of addSubView calls.
The only things that should be hard coded are interfaces that are too unique or exotic. Even then, XIBs allow you to place arbitrary UIView elements wherever you wish and you can get the best of both worlds.
How do you accomodate merging changes to XIB files within your VCS? It's already pain enough to deal with the Xcode project file. I ended up tearing out all use of IB in my large project after spending too many hours manually merging XIBs.
If I'm "doing it wrong" and there's a way to materially speed up my dev flow, please enlighten me. I can't wait. :)
Are you running into merge conflicts with other people?
Generally, we avoid any merge conflicts with XIB files. We have a small team so basically anyone who is dealing with it has an 'exclusive' lock until they are done.
That includes avoiding having a feature branch that makes changes to XIB files that might change in the main branch. Merging XIB file changes isn't for the faint hearted - and the likelihood of having a working XIB file at the end of a merge is not 100%.
Same as @wallflower.
Our team is really small (2) so we never really run into that.
I wouldn't want two devs working on the UI at the same time. It's kind of an unspoken rule because just merging anything UI related is a big pain.
Like from the web world, one dev would do the UI html and js, while the other would do the server logic and API.
I try to use the MVC model in my projects, where the XIBs and their accompanying .m files just have basic getters/setters and the xibs are rarely changed.
Indeed this is precisely how I do things as well. If I have a custom UIView subclass then I still lay it out in a xib in relation within it's superview. Doing it this way makes refactoring so much easier.
If you did this then in IOS 5+ you'll be missing out on storyboards which are a great productivity improvement. Not a good idea. Indeed you don't want to use IB all the time, but you should learn when to use it.
After a year of iOS dev, I have slowly moved away from IB as well. You'll start off implementig everything in IB and putting any sort of layout logic in your view controller. But eventually, you'll start doing more complex views, you'll find it difficult to handle rotation, youll find it difficult to create reusable modules which are expected to handle different environments correctly (ie, status bar bs no status bar, etc).
Then one day you'll strip all of the layout logic out of your view controller, delete your xib files, and instead create a set of uiview subclasses and override their layoutSubviews method. On that day you will be happy.
In almost every case I've encountered so far, doing this has cleaned up my code (removed kludges) as well as made my layout "just work" in all the situations where previously it was glitchy. viewDidLoad, viewWillAppear etc are a poor substitute for layoutSubviews.
I did this and deeply regret it. There isn't a good way to manually size and position elements in code. Doable, but not in a pleasant way. The real pain is doing all of that manual labor a second time over for an ipad version.
I've looked at reverse-engineering xib files in order to be able to produce my own, thinking it would make a pretty neat tool to use. It's a nightmare.
Monotouch seems to have pulled this off somehow.
For some reason, the boss insists we do everything using xibs. :(
iOS app development was a steep learning curve for me, coming from a C#/.NET background. After 3 years of professional iOS hacking, I created a video course a month ago, targeted to programmers. I think Stanford is a great place to start as well as the book route. The goal I had with making these tutorials was to create a see-and-do way of learning iOS. If you take the course for a spin, let me know what could be improved. http://www.learnapps.org/?page_id=66
