Motion::Project::App.setup do |app|
  env = if ENV['dev'] == '1'
          'dev'
        elsif ENV['adhoc'] == '1'
          'adhoc'
        else
          'dev' #default
        end

  #...

  if env == 'dev'
    #...
  elsif env == 'adhoc'
    #...
  end
end

task :set_adhoc do
  ENV['adhoc'] = '1'
end

task :tf => [
  :set_adhoc,
  :testflight
]

Use the :tf task instead of :testflight and everything will work as expected:

rake retina=4   #This will default to dev=1, but it doesn't matter
rake device debug   #This will default to dev=1
rake tf notes="//"  #This will run testflight with adhoc=1

Note: Updated based on feedback from Ben Sheldon.

Interested? Visit iOS Dev Tips Weekly to subscribe.

Feel free to send me feedback via email.

• Newark: 9ms
• Atlanta: 16-19ms
• Dallas: 34-35ms
• Fremont: 72ms

Recently, I've started making it a habit to continously try out new tools, evaluate them against old ones, as well as enhancing my learning and use of existing tools. For example, I am continuously on the lookout to learning more about MacVim, my primary editor, or otherwise playing around with different configurations, like switching to a different font. I'm recently testing fishfish alongside bash. And I'm always evaluating open-source software libraries I can tap on.

I keep a text file open im MacVim all the time. It acts as my TODO list and worklog. For each piece of software that I am evaluating or want to get used to using, I just add a line that acts as a recurring TODO, to be reminded of it, as well as to add notes to.

Here's some of the other tools I have been evaluating recently:

• Flint - Campfire chat client
• Path Finder - Finder replacement
• DragonDrop - utility to help with drag and drops

Some gems I found a while back:

• Xscope - several utilities in 1 for designers and developers, especially nice if you need to work at pixel-perfect levels
• Alfred - app launch
• App Code - I still use MacVim, but that's just me
• Crashlytics - Crash detection/reporting tool for iOS and OS X apps
• Divvy - Window management
• Trello - a flexible project management/TODO list software

Have you been improving your toolset recently?

I don't know how well Paper did in sales, but I thought to myself, if an app makes you feel like getting an accessory (a stylus) for it, it is already a successful app.

I told my wife, "hey, wouldn't it be fun if we skip over our usual work and work on a little side project over the weekend?"

When dealing with apps and services that deal with visual content, I'm a great fan of chromeless displays. Since the content is pictorial, we decided to just show them in a grid. I have been toying with Parse and thought this would be a good chance to build something with it, leaning on its datastore functionality. We pulled the shared drawings from Twitter's Streaming API and stored them into Parse, then wrote a web app that pulls the latest drawings from the database and display them. We did a quick wireframe and she went off to do the design while I coded.

This became Paper Board, the website.

When we were finally done with it, she said, "Why don't we build an iPhone app?" You can see where this is going (and using Parse was brilliant foresight!) So we did. We wanted to keep a similar, simple user experience where the content was front and center (and because we didn't want to spend too much time on it).

After more coding, using and testing the app, we submitted it and waited. And waited. The app was rejected.[1] After appealing and more waiting, it was finally approved yesterday.

Here it is: Paper Board, the iPhone app.

And this is how a geek couple spent a weekend (and a few more days) together :)

PS: I just learned about this while I was writing up this post.

[1] Rejected for the reason: "Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected", while apps that con users into thinking they offer lock-screen functionality is approved and floating in the top 10 continues to amaze me.

John Feminella's answer is very interesting. I thought many apps will benefit from this so I implemented this proof-of-concept - guessIdentity.

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.