Today I am launching No-Hitter Alerts, a new baseball app for iOS. Here are some screenshots.

About No-Hitter Alerts

For baseball fans, No-Hitter Alerts won’t need much explanation. The main premise of the app is simple – fast, reliable push notifications whenever a pitcher is close to completing a no-hitter. Notifications include TV, radio and online listings to catch the end of the game.

The app lets you configure how often the alerts are sent, and you can receive early warning for your favorite teams. It also includes a streaming live view for current no-hitter attempts, a hall of fame for the season’s closest efforts, and a few other bells and whistles.

Why I made No-Hitter Alerts

No-hitters are super cool. But there are 2,430 baseball games every year, or 4,860 possible no-hitters. Of these, only one or two will end up as complete no-hitters. News of a live no-hitter quickly spreads via Facebook and Twitter, but more often than not the game has ended before you hear about it.

I wanted a simple way to know – immediately and reliably – when to drop everything and find a TV.

Launch

No-Hitter Alerts is available now for $0.99 on the App Store. It supports iPhone, iPad and iPod touch.

I will also be presenting the app at CocoaConf DC tomorrow.

I’ve open sourced BENTagsView, a small control for adding tags to a UIView.

The tags can be customized in a few different ways – I’ve included an example project that demonstrates some of the options:

The control itself and the demo project are both available now on GitHub. BENTagsView should also be available as a CocoaPod shortly.

I’ve been playing around with the excellent weather app Dark Sky. I especially like the staggered slide-in animation the app uses when moving from page to page. Then I stumbled upon a StackOverflow question asking how this was accomplished (which also includes a nice gif of the original animation).

Here’s my crack at it:

There are likely multiple ways to achieve this effect but here’s my implementation.

As the user navigates, I capture the scroll position. I then convert this into a ‘scroll factor’ for each of the pages. Each page’s scroll factor is a number between -1 and 1, representing its distance from view. When a page’s scroll factor is 0, that page is front and center in the app. A scroll factor of -1 means that the page is at least one screen-width off to the left, and +1 means the same in the opposite direction.

Each page is constantly told its new scroll factor as the user moves through the app. In response, the page tweaks each of its labels. There is an autolayout constraint pinning each label to the left edge. This constraint’s constant is adjusted in proportion to its vertical position on the page – in other words, the top labels move around less that the bottom labels.

To round off the effect, the same scale factor can be used to adjust the transparency of each label as the page slides in and out of view.

There are a few limitations here but the general principle seems scalable, and the final result is fairly close to the original.

The source code can be found on Github.