How to Learn to Write iOS Apps
ashfurrow.com
ashfurrow.com
Will be picking up Texture soon. Thanks again.
-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.
Here's one heuristic: if you see any Objective C++ files (*.mm) in the project, you can probably ignore it as an example of good style.
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).
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.
However, it did have in-app purchasing and that was tedious to implement.
Not code-wise, but fiddling with xcode/apple dev center to generate ad-hoc profiles and signing and transferring to the device.
That sucked up more time than the code, at least for the first prototype build.
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.
Many of the how-to ebooks just add a code change here and there in the Apple Examples and publish it as their own.
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.
Maybe also links to their repos?
Thanks
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.
Monotouch seems to have pulled this off somehow.
For some reason, the boss insists we do everything using xibs. :(
Xcode's a shining example of an IDE that knows how to do one thing and do it really well.
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.
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. :)
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%.
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.
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 think the reason this makes my code feel cleaner is due to allowing me to implement "separation of concerns" http://c2.com/cgi/wiki?SeparationOfConcerns