Tag Archives: uikit

Navigation controllers on the Mac

Brent Simmons has a good post about the pros and cons of bringing UIKit to the Mac. On the differences between iOS and Mac development, though, one point did stand out for me:

And there are things Macs don’t have at all — navigation controllers, for instance, since they don’t make sense in a context where you can just show the hierarchy via multiple panes.

Brent’s right that most Mac apps don’t need navigation controllers. I don’t think I’d have any use for them in my Mac app, Clipstart, for example. But navigation controllers are becoming more common in Mac apps, starting with Twitter apps especially. I expect an important part of Iconfactory’s work on the Chameleon framework to bring Twitterrific to the Mac was supporting navigation controllers.

I’ll always consider myself a Mac developer first, even though most of what I do these days is on iOS and for the web. I’d definitely welcome UIKit for Mac. I’m getting closer to announcing a new iPhone app and web platform, and while I have a Mac version in development too, I can’t justify the time right now to finish it. UIKit for Mac would make that decision much easier.

Developing for the iPad Pro

Let’s start with a quote from the MacStories review by Federico Viticci:

“For developers, it’s time to be bold with their iOS apps and understand that they can be more than single-purpose utilities. There are millions of people who aren’t buying PCs anymore because mobile devices are their only computers.”

I’ve been using the iPad Pro a lot in just the last two days. Apps that have taken advantage of the larger screen — and that support iPad multitasking well — are just much more useful. It’s great to have Slack or Tweetbot in the sidebar and a writing app in the main part of the screen. (Until Editorial is updated, like Seth Clifford I’ve switched to Byword.)

As a developer, going from an iPad Mini to an iPad Pro has opened my eyes to what Federico says above. You simply can’t have a great iPad app today if it doesn’t attempt to fit well on the iPad Pro. So although I said I would discontinue my app Tweet Library, I’ve actually been spending some time this week to update it to support iPad multitasking.

The key to iPad Pro support is actually less about auto layout (although that’s helpful too), and more about split views and size classes. For a modern app, this is an easy transition. But Tweet Library was written for iOS 4. Back then, UISplitViewController was extremely underpowered. I had used MGSplitViewController instead, which I’ve modified over the years to adapt to multiple screen sizes from the iPhone to the iPad. So the first step to real iPad multitasking was to rip out most of the split view code and start over with a clean foundation based on iOS 8/9 and UISplitViewController. Not exactly trivial work that I could knock out in a day, although I tried.

I remain very optimistic about the iPad Pro, especially when the Apple Pencil is actually available. From a business standpoint, it also seems like a better investment in time than either the Apple Watch or Apple TV. There are so many platforms and distractions now. If I can’t focus on a single platform, I want to at least be proactive in saving some attention for the iPad.

iOS 7 and UI debt

Jared Sinclair writes about iOS 7 as a squandered year for third-party developers:

“Fast-forwarding a year, the effect that iOS 7 has had on third party development is disheartening — which sounds like a fatuous thing to say, since there have been so many well-liked redesigns over the past year. But that’s the rub: the vast majority of third-party developers’ time has been spent redesigning and reimplementing apps to dress the part for iOS 7.”

I agree with Jared that it was a sort of lost year for app features, but Brent also has a point:

“Jared argues that iOS 7 wasn’t urgent, that evolution rather than revolution would have been fine, since customer satisfaction was extremely high with iOS 6. In retrospect I agree, but were I at Apple I would have argued that the situation is like tech debt — UI debt — and it’s best to deal with it quickly, completely, and early.”

They had to deal with it all at once because UIKit’s look and feel didn’t really evolve the same way Mac OS X usually does, a little each year. Even Aqua, the most dramatic change ever to the Mac’s UI, was fairly straightforward for developers to adopt; if you stuck with consistent Mac controls, you got a lot for free. There was very little of that kind of consistency on iOS because developers frequently built their own custom UIs which had to be thrown out when iOS 7 happened.