Ita 2.0 Released to Customers Worldwide

ATHENS, Ohio—August 5, 2014—Nice Mohawk Limited today released the 2.0 edition of their flagship list-making application, Ita. The new release includes a complete modern redesign of the app and the addition of a new editing mode that allows for seamless in-line editing of multiple items. Ita is immediately available on the iOS App Store for $2.99.

“People love Ita because it lets you make lists and keep track of things,” said Robert Cantoni, Nice Mohawk’s co-founder. “Ita 2.0 is even better as it lets you edit items faster; also it looks nicer. We kept Ita’s price high so that we can fulfill a lifelong dream of swimming through money like Scrooge McDuck in his vault.”

Ita 2.0 still features list syncing over iCloud; it now requires iOS 7.0 or later. Ita’s icon has been redesigned to use an atom symbol, and settings have been moved into the app itself for easier access. Gone is the feature where lists would, like a paper list, show signs of age as they were used, which confused a few customers who thought their phones were dirty and/or that Nice Mohawk was attempting to hold their lists hostage. This release of Ita also adds a very nice editing feature: tapping list items while editing switches editing focus, making it possible to edit multiple items in quick succession. In addition to the new features, Ita 2.0 also improves its support for accessibility features and adds translations of the app into Traditional Chinese and Modern Greek.

Ita 2.0 for iPhone, iPad, and iPod Touch is available immediately and can be purchased from the App Store.

Ben Lachman and Robert Cantoni write iPhone and iPad apps with Nice Mohawk Limited. They also write an app called Ita. They sometimes have mohawks. They are very handsome.




  1. Android watches show what happens when Google and Samsung don’t have a product to copy.

  2. An Apple watch will initially be dismissed as derivative, then its sales will be dismissed because Apple’s a cult.

  3. The next version of competitors watches will look and behave a lot like Apple’s.

  4. The similarities will be dismissed as obvious, necessary features of wearables that Apple just happened to come up with first.

✍ Footnote: 5. Tim Cook won’t worry about any of the above.


Disk Caching with AFNetworking

✍ And we’re back, due to an overwhelming show of support from our reader.


Today’s quick tip: taking advantage of in-memory and on-disk caches when using AFNetworking. If you’re already using AFNetworking for your networking needs — and you probably are — you might be wondering whether you need to do anything special to use a cache for your objects. Specifically, we wanted to make sure we were getting all the advantages of both AFImageCache and NSURLCache — AFImageCache for in-memory caching, and NSURLCache as a disk cache.

It’s easy!

Step 1: Set up an NSURLCache, probably in AppDelegate. No memory capacity, as AFNetworking already has AFImageCache for a memory cache:

NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:0 diskCapacity:50 * 1024 * 1024 diskPath:nil];
[NSURLCache setSharedURLCache:URLCache];

Step 2: When you’re about to send off an NSURL request, check the AFImageCache first:

NSURLRequest *urlRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:URLString] cachePolicy:NSURLRequestReturnCacheDataElseLoad timeoutInterval:30.0f];
UIImage *image = [[UIImageView sharedImageCache] cachedImageForRequest:urlRequest];
if (image != nil) {

Step 3. If the return value is nil, let your request get processed normally. AFHTTPRequestOperation will use the NSURLCache automatically before going to the web:

AFHTTPRequestOperation *postOperation = [[AFHTTPRequestOperation alloc] initWithRequest:urlRequest];
postOperation.responseSerializer = [AFImageResponseSerializer serializer];
[postOperation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
	UIImage *image = responseObject;
	[[UIImageView sharedImageCache] cacheImage:image forRequest:urlRequest];
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
	NSLog(@"Image error: %@", error);
[postOperation start];

And that, like the man says, is that.


Animating Constraints


✍ Update: Talk notes posted here.

In doing some research for a talk on Auto Layout at CocoaConf Chicago. I ran across some great resources. I’ll be posting some of them in the form of talk notes in the near future. However, one thing stuck out at me. Animating layout constraints is mentioned pretty much every time people talk about Auto Layout. However, it’s often either glossed over or is a lot of ugly code. So here’s what I do. Hopefully it’s useful to someone.

    @interface MyViewController ()
    @property IBOutlet NSLayoutConstraint *animatedConstraint;


	self.animatedConstraint.constant = newValue;

	[UIView animateWithDuration:0.5 animations:^{
		[[self.animatedConstraint.fistItem superview] layoutIfNeeded];

Don't forget to connect your outlet in Interface Builder (or in code)!
codeAuto Layout

Iteration and iOS 7


iOS 7 changed a lot about the way iOS looks. I normally think of Apple as a company whose success is built on iteration — incremental improvements, building on each other year over year and maturing over time. A sudden, dramatic shift — like the one in iOS 7 — cuts against that grain.

The contradiction between Apple’s standard method of incremental changes and the sudden shift in iOS 7’s UI is a paradox worth exploring — paradox in the sense of an apparent contradiction which, on investigation, may turn out to be no contradiction at all. Apple, like any company, can innovate radically and/or incrementally, and it should shift its strategy depending on the product’s needs. The idea of Apple as a company whose product development is built on incremental improvements is an oft-recurring John Gruber theme that has become conventional wisdom to Apple insiders. Does iOS 7 mark a change in Apple’s strategy going forward?


While some Apple watchers feel concern at the sweeping changes introduced to the world’s most widely loved operating system, the question remains: is it an actual departure or something that fits within Apple’s understanding of product development? Looking back on Apple software, there are few design changes as large as the those introduced in iOS 7. The most similar was the transition from Classic Mac OS to Mac OS X. This was a clear and definite shift, but also coincided with Apple’s purchase of NEXTStep as a way to solve their inability to bring a next generation OS to market. As such, the changes had much more to do with switching to a new technology foundation while keeping existing users on the platform rather than a straight interface redesign like iOS 7.


I’ve hoped to see this sort of sweeping redesign happen to Mac OS X for years, but Apple’s never taken the time to complete one. Instead, we’ve had many piecemeal, incremental updates. Mountain Lion’s System Preferences > General > Appearance still has Blue and Graphite options — just one of maybe twenty or fifty odd relics in Mac OS that have either been completely abandoned or simply never developed into full features. (I’m hoping for Blue and Space Gray options in Mavericks.)

If iOS 7 is an interface redesign, rather than a change in underlying technology, then maybe the Mac OS 9 / Mac OS X transition isn’t the best analogy to what’s happened to iOS. Are there other products in Apple’s past that give us better examples?


I think that, looking back more carefully, we can see some places where Apple has re-envisioned products in a similar way to iOS 7. iMovie and more recently Final Cut have gone through a redesign from the ground up, in both cases more drastic than what has been done to iOS 7. On the hardware side, the Mac Pro recently finished the most drastic of redesigns. Even so, little of the Mac Pro’s core technology or hardware ability was changed. The iMac form factor has had radical refreshes from the iconic gum drop, to the desk lamp, to todays floating slab (with a touch of flower power in there as well).

✍ Bob: I miss desk lamp iMac.

✍ Ben: I do too. He was a chipper lad. I can still remember sitting in the Macworld Keynote when Steve unveiled it. It was killer—that is, until I read the comment by “iDisappointed” at the end of this article.


I miss the days of new iPod models every year, with new designs, and the changing iMac designs. I hope Apple keeps the iPhone on a tick-tock pattern with design changes every two years, but staggers those changes by redesigning one of the models every year.


I think you see that happening with the iPhone 5c. It’s an obvious new design direction while the 5s sticks to the normally understated iPhone look. The 5c seems to be taking a page out of the iPod Touch’s more playful design inspirations.


Quick reality check: is there anything actual powerful about Apple’s supposed pattern of iteration and incremental improvement? Or is it just a cliche about Apple that doesn’t have any real meaning? (Or is it something everyone does?)


The powerful thing that Apple has created is the mix of strong iteration based on smart technology choices (e.g., not adding NFC to iPhone, or moving to non-removable batteries in their laptops) while reserving the ability to throw away some or all of what you have and take a step back to re-envision a better way to interact with products. Having just one or the other makes your products boring or low quality, respectively. An important piece of this is making decidedly opinionated choices. Simply redesigning based on what people say you need or what users clamor for won’t result in a great product.


So sometimes Apple radically changes things, and sometimes they change things incrementally. Is there anything we can learn from that that will help us make better apps?


The takeaway here is that it is a bad idea to change things drastically just to please the market, or make your product feel “fresh.” Incremental change makes good products and iOS 7 doesn’t change that. The MacBook Pro is far and away the most solid laptop on the market and has been for years. In fact, it is probably farther out in front of other offerings than ever before and this is specifically because Apple has continually and incrementally decreased its thickness, increased its build quality refined each component and feature, rather than push for flashy redesigns.


Even the switch to solid aluminum blocks for the MacBook wasn’t really presented as a radical change, even though it seemed like a radical change in the manufacturing process — just not in the product itself. So incremental vs. radical doesn’t mean “underlying technology vs. gloss” — but rather about knowing your product’s strengths and refining them. Sometimes that means you have to concentrate on the underlying technology — the Snow Leopard update to Mac OS X is one example of that — while sometimes you have to concentrate on the interface itself.


But sometimes you need a redesign, a step back to look at the whole. A time to assess whether the product is meeting the needs it was originally built to meet. A product that has gone through revision cycle after revision cycle can include odd technology choices and incongruent user interface paradigms. iOS 6 wasn’t so much a poor user interface (it wasn’t) as it was incongruent with Apple’s hardware design direction and had grown into a smorgasbord of design choices when looked at as a whole. Tearing out all the old design languages and replacing them with a cleaner and more integrated language is a clear win, even if it makes some users weep for the loss of their shiny chat bubbles.


iOS 7 is a complete design statement. It presents a clear break with iOS 6 and gives us an aesthetic that will govern the way apps will be designed for the next five years. And that aesthetic will grow through iteration, as the technology gets better and as designers figure out the best ways to use elements like translucent layers and animated physics in apps.

The most amazing part of iOS 7 is that Apple has completely changed the look and feel of the OS without alienating their developers. In part, that’s because iOS 7’s unified, modern theme allays concerns about Android and Windows making iOS look old. It’s also because iOS 7’s underlying architecture isn’t radically innovative. The SDK has changed about the same amount in iOS 7 as it did in each previous incarnation of iOS. The tools Apple has added over the past few years — UIAppearance in iOS 5, attributed text additions in iOS 6 — have made it easy to use iOS 7’s default UI and to design new UI using most of the tricks of Apple’s own built-in apps. In other words, iOS 7’s radical new design is possible because of the slow, iterative improvements Apple’s made over the past five years.


WWDC 2013: What We Think Makes Sense

Unripe Fruit: What we don’t want to see

Things that would be weird to release without a major OS update: Apple’s music streaming service

Apple is expected to release their music streaming service next week — a strange announcement for a developer conference, and a strange announcement for the middle of a product cycle. It makes more sense for the streaming service launch to be a flagship feature of iOS 7 than to get released as a point-update to iOS 6 or as a stand-alone app. Our guess is that iRadio is a stand-alone app on iOS and a new feature in iTunes on OS X — maybe the only feature added to iTunes in the past five years that actually fits.

Things with limited actual benefit: UIKit for OS X

Allowing iOS apps to be ported directly to Mac seems like a good way to recreate the experience of the current dev tools simulator. iOS games that are ported to Mac already have issues with poor user experience due to the low quality porting done to bring them to the Mac. Making it easier for developers to port from one to the other would be nice, but a UIKit compatibility layer has all sorts of implications for low quality end products.

Things that just aren’t going to happen no matter how much you want them to: Apple TV SDK

A new way of interacting with the Apple TV is a necessary prerequisite to real Apple TV apps. It would be great for Apple to sell subscription-based “apps” that give users access to custom Apple TV channels from HBO, etc., but those custom channels, if they do someday exist, won’t be full apps. That would be an innovative way for Apple to get content providers to provide support for the Apple TV, but the prospect of paying 30% of subscription revenue to Apple probably can’t compete with a cable monopoly in the lizard-brains of network executives.

If you want to see the Apple TV SDK that Apple has, but hasn’t felt the need to make public, look no further than Matt Thompson’s excellent write up on Back Row, the internal SDK for Apple TV.

Things that don’t fit into the hardware release schedule and may not even exist: Low-cost iPhone

Jony Ive would never appear alongside a device primarily created out of an inferior material such as plastic.

Things that would be incredibly useful but just aren’t Apple’s bag: A custom web backend as part of iCloud a la Windows Azure

This might be controversial, but we don’t see Apple adding features like Parse, Deployd or Windows Azure to iCloud, as nice as they are. We hope they improve all sorts of things about iCloud, but we just don’t think adding developer-customizable server-side components is within Apple’s comfort zone.

Things that you don’t need to show to your competitors three months before launch: New UI Chrome for iOS 7

Showing off a new UI three months before it ships doesn’t fit Apple’s normal way of showing off their products, but the reportedly extensive UI changes planned for iOS 7 might be an exception. The changes will get revealed eventually in the developer betas — Apple can’t save all the UI changes for the iOS 7 release candidate, which generally coincides with their official hardware announcement. So some of the UI overhaul will be on display at WWDC, but expect to see more changes as the release gets closer. How much gets revealed at WWDC may be a test of how much Apple cares about a) increasing pre-release excitement for iOS 7 and b) Apple’s stock price over the next few months. And no matter how nice iOS 7 looks, pleased don’t install the first beta on your phone while 2000 miles from home.

✍ Ben: I did that once in the days of my youth… and lost the ability to receive voicemails for the balance of WWDC + traveling back home.

Things that we know will be released in the fall: The next normal-cost iPhone



Ready for Pickin’: What we want to see

Things that would be appropriate for a developer conference: New Mac Pro

Made in teh [sic] USA baby! An announcement regarding a radically new Mac Pro would definitely garner some positive press amidst low level negative coverage about the e-books lawsuit and congressional testimony on Apple’s tax avoidance schema.

Things Ben would like to buy: An updated Retina 13-inch Macbook Pro with Intel’s new Haswell processor

The update to Haswell will be great across the board for integrated GPU performance; that performance matters most in the 13-inch Macbook Pro, which is missing a dedicated GPU and a four-core Intel chip. If the rumors of an updated, slimmer form factor are accurate, this will be a sickeningly beautiful and fast Mac.

Things that build on iOS’s core features: Incremental API improvements that expand Apple’s strongest APIs

Expanded access to features from the iOS 6 Maps App via MapKit, SceneKit on iOS — here’s a nice Open Radar regarding SceneKit’s potential benefits — and more applications and flexibility for Passbook are three areas where iOS could expand existing Apple APIs to provide developers with more powerful tools.

Things that Apple actually needs to catch up on when compared to Android and Windows Phone: Expanded inter-app communication, hopefully via the UIActivity framework

Apart from iCloud Core Data, this may be the biggest missing functionality in the Cocoa Touch framework. We hope it gets strong enough to compete with Windows 8’s Contracts before Windows phones start [Windows phone market share joke removed out of empathy]. More robust inter-app communication in iOS will strengthen the network effect within the App Store ecosystem, and that’s a strong reason for iOS’s perceived dominance among developers. The shortcomings of iOS in this arena are a limitation that many users run up against on a frequent basis — at least, we do.

Things that happen every year at WWDC: Updates to Xcode and Interface Builder that are great to demo but sometimes are hard to get working for actual complicated apps and sometimes you wonder whether Apple really uses these tools for apps like iPhoto or even Find my Friends.

Ben: I’m thinking we’re going to look pretty silly on the iRadio one.

Bob: It will come out… but does it make sense?

Ben: They’ve had 10 years to think about it, so it had better.