SY, a fan of our password manager STRIP for iOS sent us one of the funnier complements we’ve ever gotten:

Overall I love the app, the interface is clean and simple but doesn’t look cheap and nasty like XXXX and others.

Thanks, SY!

Updated, Update II, below

Thanks to direct reports from our customers, and some crash logs we’ve received via iTunes Connect, it appears that the new version of Codebook that we published in the App Store (version 1.4.0) had a start-up bug in certain circumstances, on certain iOS versions and hardware. Basically, the app was crashing immediately on iOS 3, and crashing on some instances of iOS 4 during the application start-up sequence. We’ve since pulled Codebook from the store to prevent anyone else from downloading this update.

No one’s data is lost, but anybody who’s run into this problem will find their data inaccessible, simply because they can’t start the application. To that regard, we are hustling to deliver a fix through the App Store (we’ve already got the bugs solved, and thoroughly tested). We realize that if you’re a serious user of Codebook, you depend on being able to access your data, and we’re on it.

For all future releases of Codebook, we’ll be testing on more devices, iOS 3 and 4, to make sure this doesn’t bite us again. I should note that we had done extensive testing of Codebook, but it was limited to iOS 4 on an iPhone 4, and iOS 4 on an iPhone 3G. Clearly, we need to be testing this on the iPod Touch, on iOS 3, etc, and that’s what we’ll be doing from now on.

We do have some good news: Codebook 1.5 is already undergoing testing and should be ready for release soon. The main reason for the version bump, aside from a ton of user interface and usability improvements, is the new feature: Sync with Dropbox!

Thanks again for your patience and feedback.

Update, Nov 23rd, Codebook 1.4.1, which fixes the issues outlined here, was submitted to Apple on Sunday (Nov 21) with a request for expedited approval due to the situation at hand. We’re waiting to hear back, hopefully it will be approved and posted to the App Store within the week.

Update II, Dec 2nd, Codebook 1.4.1 is now available from the iTunes App Store. All users of Codebook should upgrade as soon as possible. Release notes (and sneak peaks).

Updated: 6/6/2012 Strip for Windows and Strip for OS X are now for sale.

It’s about time we came out and said it: we are in fact working on Strip Desktop. Long requested by fans of our popular private data management app for iOS (and previously for Palm OS), Strip Desktop will provide a means for users to manage their Strip data on their desktop computer, in addition to the features we’ve already made available in Strip Sync.

As you can hopefully tell from the screen clip above (click to enlarge), we are working hard to maintain the same simple and elegant style used in Strip for iOS, by borrowing some of our design choices from Apple’s Address Book. We expect this interface to change and mature quite a bit over the next few months, but this is a reasonable approximation of our intended product. You can’t tell from that lone screenshot, but all the basic features of the data editor in Strip for Mac OS X are complete at this point.

Strip Desktop is a bit of a misnomer, as it actually describes two distinct, native applications: Strip for Windows, and Strip for Mac OS X. We’ve been making great progress recently on the Mac version, but we’ve fallen a bit behind on the Windows version and expect to pick up the slack soon. We are considering publishing Strip for Mac OS X in the new Mac App Store recently announced by Apple, and expect to have it ready for release by the time the Mac App Store opens for business, whether or not we decide to go that route (Apple estimates this will be around Jan 26th, 2011, so that’s our target).

Online Backup & Strip

We’ve reconsidered our previous stance on providing an online-backup feature. We’ve found that supporting Sync over local WiFi networks is particularly difficult. With so many different types of home networking hardware out there — with all the infinite variations of network configurations, combinations, pitfalls, and firewalls — it’s no wonder Apple does sync over the Dock cable. It’s time for us to find ways to make this easier, too.

We’re not getting rid of Sync over WiFi, but we are going to begin experimenting with an online backup & sync feature for Codebook, and if all goes well, we’ll port it back to Strip. The basic gist of the feature is that a copy of your encrypted db will be placed in your Dropbox account. When it’s time to sync, any one of your copies of Strip can download the master copy in your Dropbox, and sync against it locally. Your unencrypted data will never be stored on Dropbox, and your password/key will never be sent over the wire. This feature will have the happy side-effect of providing you with the same multi-device replication you get now with Strip Sync.

Discontinuing Strip Sync

Relatedly, we have one maintenance update in the pipe for Strip Sync, and we plan to discontinue development of the application once Strip Desktop is released. Once we have Strip Desktop and the Online Backup feature in place, there won’t be a need for the software anymore — whether or not you choose to use Strip Desktop. The forthcoming maintenance update of Strip Sync will coincide with the release of Strip 1.5 for iOS, a rather handy set of small productivity enhancements and bug fixes. Users who upgrade to Strip 1.5 will need the latest version of Strip Sync, as well. We’ll publish a notice to the mailing list as soon as this next release is ready.

Android

We really appreciate the requests you’ve been sending in for an Android port of Strip! At the moment we need to focus on the desktop applications. Once we’ve brought them to market, we will take another look at building a port for Android.

There’s a really telling thread active on the cocoa-unbound mailing list right now, regarding the difficulty in grasping how to structure applications in Mac OS X, especially as compared to its sibling iOS, and the materials that are available, a subject with which I’ve become quite familiar as I hack on STRIP for Mac OS X:

When I create a new Rails application or Ruby Gem, there’s a clear, predefined application structure. Its obvious what things go where. It’s the same structure every time,

When I first created new iPhone projects, picking a “Navigation-based app” or such like gave you all the structure you’d really need for that type of app. You could see exactly where the VCs lived, how they hooked up to NIBs and how they talked to each other. I don’t need the templates now, but they were very instructive in the beginning.

I’m missing the same thing for Mac applications.

Exactly. List users are starting to add their suggestions for reference material and tutorials, some good resources there. But really, we could use some better, more comprehensive materials from The Source for Mac OS X. The WWDC video sessions are invaluable, the small app examples are great, the API documentation is fantastic, but we devs really could use some beefier, more complex, real-world reference materials.

Update: It’s not really a how-to document, but I did get a lot out of Matt Gallagher’s article, The design of every Mac application.

In working on Strip for Mac OS X, I came across a scenario in which I wanted to get the bottom bar buttons on an NSWindow to follow the left-margin of panes about them in an NSSplitView with which they are associated. That sounds like a mouth full, so I’ll use a picture to illustrate, it’s an idea I’m looking to borrow from Apple’s Address Book application (click image to embiggen):

What I’m trying to suggest with the annotations I’ve made on the image is that the [+] button under that middle pane (highlighted in green) will move as the left margin of the pane is moved, either by the user, or by the window being resized—which cascades down to the subview being resized, since the split view is basically the entirety of the window’s contents.

In any event, I wasn’t sure how to hack this out and didn’t see any examples out there, so I put one together. There might be a better, faster way of handling this, perhaps by responding to NSView notifications about a change in frame, but here I just used an NSSplitViewDelegate method that fires every time subviews are resized (thus, every time the margins of the panes might have been adjusted by a resize or a divider moving). Sample project is here on Github, but this is the meat of it, in the NSSplitView’s delegate:

// gets call after the NSSplitView is resized OR after the divider(s) are moved
- (void)splitViewDidResizeSubviews:(NSNotification *)aNotification
{
    [self repositionBottomBarButtons];
}

- (void)repositionBottomBarButtons
{
    // we don't actually have to do anything for the left-most button and the left pane
    // because we've got it pegged in IB to maintain it's position in relation to the
    // window's bottom and left bounds

    // first tell the superview that it will need to redraw the frame we'll be moving
    NSRect oldFrame = [rightButton frame];
    [[rightButton superview] setNeedsDisplayInRect:oldFrame];

    NSPoint newOrigin = rightView.frame.origin;

    NSRect newFrame = NSMakeRect(newOrigin.x, oldFrame.origin.y, oldFrame.size.width, oldFrame.size.height);
    [rightButton setFrame:newFrame];
    [rightButton setNeedsDisplay:YES];
}

And there we go, button now follows the pane’s margin, moves nice and smooth.