Somewhere between going through the iPhone to iPad display transition, supporting both portrait and landscape orientation and building screens that are dynamic and parts of it animated, I discovered that life without IB is much sweeter.

Why IB?

IB lets you lay out your user interface visually, with inspectors to tweak the controls' properties. If you work with a designer who is not into programming, it is supposed to let you send the XIBs/NIBs to them and who can tweak it directly without requiring additional work from the developer.

If you have custom built components or do even a little bit of layout in code, your designer wouldn't be able to see how the UI looks like in IB. Also, tweaks could mean animate this button for 0.1 seconds longer which requires changes in the code to see the result.

UI Reuse

You need to keep 2 set of NIBs, 1 for iPhone and 1 for iPad. Controls may need to be laid out differently in different screens, or you might have more functionality when running on the iPad due to the additional screen real estate available.

But often, there is UI that is re-usable across the two screen sizes. Creating your view programmatically makes it much easier to share them. For example, you can detect or pass in the actual screen size.

When you have your views written in code, you can decompose them into functions, methods, classes. Much better than in IB which pretty much can't be reused.

Portrait and Landscape Orientation

Let's face it: the layout system in IB is quite primitive. It lacks the layout managers provided in systems such as Java and Smalltalk. If you use IB, you often do up the portrait mode screen in NIBs and then run code to adjust them when changing to landscape orientation. This mixing of IB and code makes things more confusing and hard to architect.

Fine. So How Do We Do It in Code Instead?

For each screen, I have a controller class and view class pair. Here's the controller class:

@interface MyViewController : UIViewController

@property (nonatomic,retain) UIView* mainView;

@end

@implementation MyViewController

@synthesize mainView;

- (void)loadView {
    self.view = [[[UIView alloc] initWithFrame:
        [UIScreen mainScreen].bounds] autorelease];
    self.view.autoresizingMask = UIViewAutoresizingFlexibleWidth |
        UIViewAutoresizingFlexibleHeight;
    self.view.backgroundColor = [UIColor whiteColor];
}

- (void)viewDidLoad {
    [super viewDidLoad];

    self.mainView.autoresizingMask = UIViewAutoresizingFlexibleWidth |
        UIViewAutoresizingFlexibleHeight;
    //self.mainView.delegate = self;  //good to have
    [self.view addSubview:self.mainView];

    /* TODO: controller is displayed for the first time, do things like
        load data, etc */
}

- (void)viewDidUnload {
    [super viewDidUnload];

    self.mainView = nil;
}

- (void)dealloc {
    /* Call -viewDidUnload here so all releasing of view resources is
        only done at 1 place. */
    [self viewDidUnload];
    //TODO: Release other owned ivars here

    [super dealloc];
}

- (MainView*)mainView {
    if (!mainView) {
        /* We use [UIScreen mainScreen].bounds instead of
            self.view.bounds so we don't create self.view as a
            side-effect. It's messy because creating self.view will
            trigger creation of self.mainView itself */
        self.mainView = [[[MyView alloc] initWithFrame:
            CGRectMake(0, 0, [UIScreen mainScreen].bounds.size.width,
            [UIScreen mainScreen].bounds.size.height)] autorelease];
    }

    return mainView;
}

@end

And here's the corresponding view class:

@interface MyView: UIView

@end

@implementation MyView

- (id)initWithFrame:(CGRect)frame {
    if (self = [super initWithFrame:frame]) {
        //TODO: assemble your subview and add them to self.view
    }

    return self;
}

@end

I often build a UIViewController and UIView subclass containing common code which serves as the base class for most view controllers and views in an application.

Straits Times app on the iPad

• EULA should go into the EULA accessible in the App store instead. There's a least 1 mistake in the EULA, referring to the "I Do not Accept Button" as the "Cancel" button.
• UI is jerky, it doesn't respond immediately to finger dragging the screen.
• Sometimes when you swipe to a new page, the images flashes.
• Get rid of the animation for unrolling the paper after tapping on the "iPad Edition", "PDF Edition" or "Breakign News" buttons. It's unintuitive, especially as there's a pause before the animation to reveal the article starts.
• The "Breaking News" UI seems quite different from the "iPad Edition", e.g. you can scroll articles up and down in "Breaking News" and website-like tabs are used for sections, but you swipe left-right in "iPad Edition" and tab buttons at the bottom are used for sections.
• There isn't a clear visual response when you tap on the screen (especially articles) to indicate what you have tapped on. The articles suddenly pop up fullscreen.
• Crashes within 1 minute of initial use, crashes again within the next few minutes.
• I like that tapping on the photo thumbnails bring up a fullsize image with the caption. I wonder if there is something interesting that can be done along the lines of The Big Picture.

Straits Times app on the iPhone

• EULA (see comment for EULA for app running on iPad).
• Has an irritating ad that animates after each refresh. Perhaps move it to the top or bottom, but either way, just keep it stationary and don't flash it?
• App slows down while reloading.
• In a few minutes testing, seems more stable than running on the iPad.

What I missed from Chrome

• Multiple undo of tabs closed and the restored tab(s) preserves history
• Opening a link in a new tab goes to the right of the current tab (Update: Safari 5.1 does this now)
• It's still faster
• Omnisearch bar
• The way tabs are displayed

What I hate about Safari

• Safari has this annoying behavoir where when you open a new window, press Cmd+L quickly to go to location bar, start typing and it suddenly loses focus. Everytime. Annoys me to no end. (Update: finally gotten down to it. It's the Handoff extension. Removed it and the problem is gone)

What's good about Safari

• It's a much better Mac citizen, e.g. QuickCursor support which I think requires using the accessibility API.

Other than that, they aren't that different for day-to-day web browsing.

PS: Creating the .ctags file is so convoluted because I can't figure out how to put a multiliner without ruining the formatting in the instructions.

From the README:

Uses public APIs to create native-looking glass buttons. No image files used. Buttons can be created in IB (and configured programmatically) or fully by code.

• Include Quartz Core framework.
• Add Global.h, MOButton.h/.m, MOGlassButton.h/.m
• See demo project.

It shows the relative number of commits (rough equivalents of changes if you are consistent) performed across the duration of the project. You can see that

1. I am most productive (again, commit-wise) the few hours around 12am and 12pm.
2. I am least productive on Fridays.
3. I seem to be slightly more productive during midnight than noon.
4. I work on Saturday nights.
5. I work on Sunday nights
6. I work everyday.

Does anyone else has Punch Card graphs they like to share?

Here's what as a user, how you can help us:

1. Let us know what you were doing when you saw the bug. Is there a way to reproduce the bug reliably? It's always easier to fix if you can help the developer see the bug for himself/herself. This is the single most important thing you can do for the developer to help fix a bug.
2. If it's something that can be seen on the screen, a screenshot helps.
3. State which version of the software are you running on.
4. State which version of the operating system are you running on.