Live data from Hacker News

Your First iOS App – 100% Programmatically

blog.austinlouden.com

61–70 of 111 posts

Re: Your First iOS App – 100% Programmatically

#61
I came from a electrical and computer engineering background and so I am more used to procedural programming. When I started with iOS development, I tried IB but then I cannot figure out the magic and decided to create my UI mostly from code. Then, I started doing more and more software and adding more code, and managing it becomes painful. Since this is a personal project, I do not want to spend too much time and want to follow Apple's way of doing things. Since then, I started using XIB file and adding them slowly. It is important to realize that it is NOT an all or nothing approach. You can mix and match XIB and code with what you are comfortable with.

Some comments say that using UI will eventually restrict you. That might be true and I can totally see that. However, at that time, it is a good idea to step back and look at the overall design and figure out if you over design something. I like functional apps that work with little effort. It does not mean that it have to look ugly but you can customize and beautify the UI within the constraints of Apple's framework. Yes, there will be limits but is it worth the extra complexity of rolling it out on your own?

I have not tried storyboard but I would like to try it out soon.

In general, my philosophy has changed to use good, solid, reliable frameworks and keep the design (UI) and features (code) simpler. You will be able to get 90% of what you really want with less work (coding and maintaining).

Re: Your First iOS App – 100% Programmatically

#62
Having made a few iOS apps in team/solo environments, I now stick to the following:

Large team - don't use Interface Builder. Synchronizing it is too difficult and any productivity gains will be lost. Layout in code is best here, but really is time consuming for complex UIs. However, pixel-perfect match for designers is a great benefit since you're specifying everything in pixels that you can copy right out of the designer's graphic.

Solo dev on a small app - Storyboards. In this case, 99% of the time the budget is fairly low and getting out something that works is the most important. Storyboards can speed things along and make it quick for matching a design to an outside designer's Photoshop.

Small team with only a couple of developers - either way is fine, but you need to manage it correctly. If going for Interface Builder, you need to have a list of devs who 'own' each screen, and only they make changes to it. This prevents any kind of conflicts when merging. If going for in-code layout, make sure the design is set in stone and won't change. Moving things around to meet designer's goals for a small team can kill productivity fast.

Also if you like TDD (it's not really popular at all in iOS dev circles, probably because TDD for ObjC/UiKit is not that great), then 100% stay away from IB. IB and TDD are very incompatible in my opinion.

Re: Your First iOS App – 100% Programmatically

#63

Earlier quoted context omitted.

Perhaps the worst, most insidious, damning thing about IB is it keeps novice iOS developers novices. You end up with programmers who don't know what they don't know. I can write UI code faster than any developer I've ever met who uses IB, and that's doubly true for class hierarchies I have subclassed for multiple apps, and triply true when it comes time to change those subclassed hierarchies. You note that IB is for…

> Maybe it's a matter of how you think, but I can "see" the changes when I adjust the frames, colors, padding, resizing masks, and that's basically all IB will do for you. I know what you mean. I'm not an iOS/Cocoa dev by any means, but when I write CSS I typically know what the outcome is going to be in my head because I've done it so many times.

I can see it in both code and interface builder. Doing it in code on iOS is like using CSS where the only selector is `#id` and there are no child selectors. Would you write CSS if you had to do this?

    #username-label { text-align:right }
    #first-name-label { text-align:right }
    ...
    #last-name-label { text-align:right }
    #address-label { text-align:right }
With CSS, you get nice things like:

    #user-form label { text-align: right }
iOS code looks more like the first example but it goes on for hundreds of lines. You can create something like classes by creating real classes, but then you end up with inheritance hell.

I find IB's WYSIWYG to be a lesser evil.

Re: Your First iOS App – 100% Programmatically

#64
post #43

This is exactly how you should build your first app. Using Interface Builder will make you a permanent novice.

Do you really think that reinvent the wheel is better than using technology that a vendor gives you? Do you really think that folks at Apple make all their interfaces in code? Tip: Probably every feature that was added in Xcode was added because Apple engineers benefited from it.

[deleted]

Re: Your First iOS App – 100% Programmatically

#65
post #27

So, a word of advice to new folks trying out iOS land: Interface Builder is most emphatically your friend. The compile/debug cycle in iOS is sufficiently lengthy that laying out views programmatically gets very tedious very fast. Besides realtime previewing of exactly how your view is going to look , IB also helps you understand how your layout is affected by rotations to landscape and differences in view height betw…

I've been a Cocoa developer for close to a decade now, and I've gone back and forth on this many times, but by now I've settled 100% in the nibs-are-evil camps. There are several reasons for that: - Nibs are a nightmare when working with version control and merge tools. Now, at least, they are XML instead of a proprietary binary format, but it's still a joke… - Auto-layout in IB is provably the worst GUI I have ever…

Since you seem to be catching some flak for your post, I'll elaborate a bit further.

AutoLayout is a constraint solver, and as such it's very easy to either over-specify or under-specify your constraints in a way where it no longer evaluates.

On top of this, AutoLayout also has a priority for each constraint such that if/when such a conflict occurs AutoLayout has some ordering as to which constraints get abandoned first.

When you run into cases where AutoLayout breaks, debugging is a chore. You have to go through your entire view hierarchy and query each view for its hasAmbiguousLayout flag, which will give you some pointers as to what views are breaking your whole layout.

Interface Builder makes this somewhat worse because it doesn't give you an easily understood 1:1 match between what you do in the UI vs. the code that gets generated out of the other end. The opacity makes it hard to triage AutoLayout failures.

We use AutoLayout in small parts of the app, and we've found that doing it in code has been preferable - for a system that is as easy to break as AutoLayout you really don't want to be poking buttons on the top of a black box in the hopes that whatever comes out the bottom is sane. If there was a more transparent mapping of Interface Builder -> NSLayoutConstraint this would be less of an issue.

Also, yes, XIB merges are one of the Prime Evils of Hell, second only to pbxproj merges.

Re: Your First iOS App – 100% Programmatically

#66

So, a word of advice to new folks trying out iOS land: Interface Builder is most emphatically your friend. The compile/debug cycle in iOS is sufficiently lengthy that laying out views programmatically gets very tedious very fast. Besides realtime previewing of exactly how your view is going to look , IB also helps you understand how your layout is affected by rotations to landscape and differences in view height betw…

I jumped into iOS dev after storyboards so, I fear nibs... I've never used one. If I started with a storyboard, should I throw in nibs every now and then for certain tasks??

I like to think of Nibs like classes. A lot of times I'll have a certain design I want reused throughout the app, and this works perfectly. For instance, in an app I'm working on now, I have a few different views that have scroll-views inside of them, with each object of the scroll-view being a view itself. In the last of the chain of views, I use a nib because there's a solid amount of data there, and visually designing it in IB is easier to iterate and make it look exactly like I want it to. I have a .m/.h attached to the view (just a subclassed UIView) with a custom init method, returning what is basically a custom object (that happens to be that .xib). It's super efficient to make changes and keep things looking good when the data or the feature-set needs to change.

Re: Your First iOS App – 100% Programmatically

#67
I find IB (and storyboards in particular) to be amazing for rapid prototyping (MVP anyone?). I can put together a basic app with 5 views, buttons, maps, whatever I want (as long as its a standard iOS control) in like an hour.

HOWEVER, in the long run storyboards can get annoying, because you're constantly switching between code and a visualizer. The first time you can't find what exactly is making that button do what its doing is quite frustrating, to say the least.

Re: Your First iOS App – 100% Programmatically

#68
post #21

I've finally arrived at the fascination with learning something by just starting with nothing and building onto it one step at a time. My first two to three years of programming were spent jumping into random tech (like Rails, SQL, jQuery) and faking it til I made it (although we all still fake it with jQuery). I didn't necessarily understand my tools but it let me rapidly gain a feeling for how tools come together.…

we all still fake it with jQuery

this

Re: Your First iOS App – 100% Programmatically

#69
post #54
post #30

This article, although still great for beginners to get started, is using dated techniques that should be avoided. In the past, developers would have resorted to starting with interface builder to do their designs. As they continued the development process, theyd notice that more and more of their views had to be done in code because Interface Builder wasn't powerful enough to do what they wanted. It could then be un…

http://en.wikipedia.org/wiki/Irregardless

Your parent meant "disirregardless" of couse :)

Re: Your First iOS App – 100% Programmatically

#70
post #29
post #24

Earlier quoted context omitted.

How would you know if a production app was using Storyboards? I just submitted my first "Storyboard App" . It was a little uncomfortable for me seeing as I have gotten used to using NIBs, but I did it because I assumed Apple was moving away from NIBs.. I wonder how other people who use Storyboards do it..I pretty much had to sit at a desk with my MBP connected to external monitors anytime I wanted to do any work, jus…

> How would you know if a production app was using Storyboards? Because just like NIBs, Storyboards exist as part of an app's resource bundle, which is easily viewable. It is usually fairly straightforward to examine an IPA from the store and determine whether it's using NIBs and the like.

I think the most likely explanation is that the grandparent commenter was referring to their own experience with projects they've worked on.
Post reply on HN