Every nib you use is a boatload of code you don't have to maintain. Use nibs. Can they solve every problem? Goodness no. But they're a great way to get the basics of your views laid out. They give you an easy way to preview the behavior of your view when layout changes.
And they're very forgiving when you change your mind. Changing text alignment? One click. Want to change the balance or padding of some elements? Nudge them around with a real time preview until you're happy. Mess with different color combinations in your UI to your heart's contentment.
Doing all your view layout in code gets damn tedious when you have to compile and run each time to check your results.
Every now and then some crackpot will come along and tell you never to use nibs. Ignore them. Use nibs when they make sense for your workflow. End sermon.
You all have been warned! ;)
Nibs are handy if you're sticking to stock UI and stock behavior. Programmatic layout takes longer to setup the boilerplate, but once it's in place, I find it about as easy to work in code as nibs. With complex designs, I find it significantly easier to work programmatically.
Very few beginner iOS developers will have a design team at their beck and call.
Since I used Cocos2d (which doesn't use nibs) in one of my games, I was able to update it very easily for the iPhone 5 (despite using some magic numbers) by simply using a multiplier based on the screen size.
- If developing a trivial utility app you're expecting to release quickly, target iOS version N-1. Any user who is more that one major iOS version behind won't be the type of user who will download your app (or any app really).
If developing anything more ambitious, target the latest iOS version only and take full advantage its new APIs. By the time you're ready to go mainstream (a few iterations of the app under your belt, nailed your marketing strategy, etc), there will have been at least one new major iOS version released and any time and effort you spent writing code for older iOS versions will have been wasted.
(talking from experience here :)
- Before writing a single line of code, sort out your logging. At the very least, use a handful of macros like [0] to print the class, message name and line number when logging and to exclude debug log statements from release builds. Or check out something like CocoaLumberjack (haven't tried myself yet but writing this made me realize I need to sort out my own logging system so will give it a shot).
[0] http://stackoverflow.com/questions/969130/how-to-print-out-t...
Once you've published your app as universal, there is no way back. You can't decide in a subsequent update to revert to an iPhone-only or iPad-only app - Apple won't let you.
So if you start with an iPhone app, and then put together an iPad version of the UI just to try out and publish it as a universal app, you'll be stuck with having to provide an iPad version of your app for the rest of times. Even if you realize that the iPad version isn't worth it for your app and that nobody uses it, you won't be able to discontinue it.
So think very carefully before flicking that switch.
You also won't be able to charge different prices for the iPad and iPhone versions either. Although you probably could make separate in-app purchases that get offered based on device type.
The only people I still know that avoid heavy utilization of these do not understand how to properly use them. Go learn!
I also agree that the lack of "diffability" for XIBs, despite them being XML, is a pain.
Maybe I was missing something, but my experience matches the OP.
If you're just talking about some buttons in a toolbar, go nuts, but otherwise it's worth the time investment to learn.
I've dealt with far too many bugs involving Interface Builder and it's random changes and "upgrading" the second I touch a nib that it's more of a liability now.
People who say it's less "code" are just delusional. Setting the font in IB versus a single line in viewDidLoad: doesn't save you anything. At some point in time that line of code is getting executed and you will at some point have to maintain it.
I actually consider this a big liability for Apple going forward. The explosion of "phablets" and other form factors spells the end of their pixel-perfect design approach and their tools and APIs for managing dynamic, variable layouts are stone age compared to Android's.
Sure, you can control all your code, but there is so much time that is lost until the UI is finally ready, and than the marketing department wants it redone in one day.
Another tip: try both Xcode and AppCode: http://www.jetbrains.com/objc/. It's a subjective thing but for myself AppCode is far better (it helps that I also use IDEA for Java, including Android).
Anyhow as we're contributing top tips, my one is 'Always run your app on target hardware.'
Don't rely on the emulators, especially if your're doing OpenGL work. You will only know your framerate by running your app/game on the real hardware.
Running on the emulator is good if you haven't paid the $100 to put it on device yet. After that, you better be running on your device every time. There's so much to be said for actually holding the device and using your app like your normally would, instead of pointing and clicking with a mouse. Even the pixels and text-size/color are WAY different when on the device. Seriously, do this if you aren't already.
I don't think you ALWAYS have to run on your device. Emulators are much faster at launching and getting to it. I use the emulator for a majority of quick fixes, layout changes, API debugging, etc. I move over to the device when things are nearing a point where I need to test real-world things.
Using the emulator is fine, just be sure to test on the device before you deploy.
I wish Google provided tidy tools with their style guides, or Apple did something with Xcode.
(I haven't but their RoR-tailored IDE RubyMine is the only IDE I've enjoyed using after it for less than a week.)
I actually do most of my iOS development by running emacs on my Linux box and using sshfs to access the files on the Mac. I use command line tools for compilation/running/debug. I did originally start out using Xcode but it gets in the way of the coding. (My work involves a library that functions in the background and has no user interface.)
AppCode hasn't seemed worth the effort to investigate and $200 is rather a lot to spend on a code reformatter. (Also only running on MacOS makes it significantly less useful to me.)
The 15 hours of video is the best investment of your time if you want to jump start into iOS development.
1. Make an app that looks awesome as a reference (and don't expect anyone to ever, ever use it)
2. Get a job as an iOS contractor
3. If you have enough experience and a good idea, make your decision between a reliable cash flow and becoming an App Store cowboy. But only then.
I would absolutely try to write one or two "Hello World" apps without ARC first. CMIIW but Xcode will highlight any instance where you do things differently than ARC would, there is plenty of feedback on what you are doing. And once you feel confident enough, upgrading the project just takes a few clicks.
And I found ARC to be super easy not in spite, but because I came from C++ :) it is shared_ptr vs weak_ptr all over again. Don't memcpy() them, don't create cyclic references, beware race conditions when testing if a weak_ptr is still there ...
RegexKitLite - Powerful regular expression support
Use NSRegularExpression instead. It's built into the OS (in Foundation) as of iOS 4, which is below the minimum target you have (if you support the iPhone 5).
w/r/t using the visual XIB/Storyboard interface vs. coding the views, I've found early on that while the nibs and storyboards make it easy to prototype and visually hook stuff up, looking at some of the apps I admire (apps like Clear, Rise, etc.), makes it pretty clear that I will need to code these views up myself to achieve some of those interactions. Unless I'm missing something (which of course I am, I'm a NOOB) I don't see how most of those can be done right from the nibs.
edit: also, if anyone has any other recommended links/resources, I'd love any recommendations. Thanks.
-XIBs are awesome and you should strive to use them, falling back to layout in code when the XIB fails to meet your requirements. Though I'm also finding storyboards hard to swallow for complex projects. -Blocks and GCD are great tools but with great power comes a lot of complexity and consideration, they could easily get beginners in trouble. I ain't saying don't use em, but There Be Dragons Here.
Bravo on bringing up Singletons, thats something I only recently discovered and wish I had sooner. Also, I feel like a primer on delegates, protocols, notifications and selectors: when to use what and why, would also go a long way in the beginning.
Don't know how things are with Testflight right now but when we worked with them last year we had to right our own script to upload the dSYM. Also Testflight does a lot more than just crash reporting so it might be too big a hammer if you just want automated crash reports.
Here are the resources I’m using:
Started with: https://developer.apple.com/library/ios/#referencelibrary/Ge...
Then, plan to get a feel of the language will read http://developer.apple.com/library/mac/#documentation/Cocoa/...
Then I was thinking to go watch https://itunes.apple.com/il/course/coding-together-apps-for-...
Also, a book that seems good to read https://www.bignerdranch.com/book/ios_programming_the_big_ne...
Other suggestions and insights are appreciated.
Otherwise you can just use git submodules.
I wish I had something to suggest as a replacement. We're still trying to figure that one out ourselves. We just know we won't use submodules again. For now, we're manually managing disjoint repositories.
It has been super easy compared to git submodules.
Also, you can only remove a submodule manually. There's no option to have git do it for you.
Compare this:
+ (MyClass *)sharedClass {
static MyClass *_shared = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
_shared = [[MyClass alloc] init];
});
return _shared;
}
+ (MyClass *)sharedClass {
static MyClass *_shared = nil;
if (!_shared)
_shared = [[MyClass alloc] init];
return _shared;
}
Just use the -fno-objc-arc flag (http://stackoverflow.com/questions/6646052/how-can-i-disable...)
I'm currently using this switch to gradually migrate a non-ARC project to ARC.
I think we need a few programmer generations until everyone is fine with some form of automatic memory management in all programming languages.