Panel

Josh Abernathy (twitter github blog)
Rod Schmidt (twitter github infiniteNIL)
Ben Scheirman (twitter github blog NSSreencast)
Pete Hodgson (twitter github blog)
Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion
 01:25 - Josh Abernathy Introduction

GitHub
GitHub for Mac
GitHub Issues App
GitHub Jobs App
Lua
Corona SDK

03:48 - Differences between writing an app for Mac and writing an app for iOS

AppKit
UIKit
Chameleon
twui

05:37 - Model View Controller

Model View ViewModel
Knockout.js
013 JSJ Knockout.js with Steven Sanderson (JavaScript Jabber)

11:51 - Testing

specta
expecta
OCMock

15:04 - NSTableView

Cocoa Programming for Mac OS X (4th Edition) by Aaron Hillegass

17:28 - iOS vs Mac

The Rude Awakening for iOS Devs: Josh Abernathy

22:05 - Memory Management

002 iPhreaks Show - Memory Management
Garbage Collection
ARC

24:32 - Binding
 27:23 - Fixing AppKit
 32:09 - APIs
 33:18 - App Store

Sandboxing

36:34 - Resources

Cocoa Controls
Tweetbot
Twitter Mac App
The Hit List
Things
Cocoa Programming for Mac OS X (4th Edition) by Aaron Hillegass

40:47 - Sharing Code

Xamarin
cheddar-mac
cheddar-ios
ReactiveCocoa

Picks

MOO (Ben)
Kaleidoscope (Ben)
Briefs (Ben)
clojurem (Rod)
Oblivion Soundtrack (Rod)
CloudApp (Pete)
MindNode (Pete)
LimeChat: IRC Client for Mac (Pete)
People are not resources - The Philosophical Developer (Pete)
Downton Abbey (Chuck)
Downton Abbey at 54 Below - Season 4, Episode 1 Sneak Peek (Chuck)
GitHub (Chuck)
Daring Fireball Linked List: Using Quartz Composer to Recreate Facebook Home (Josh)

Next Week
 Xcode
 Transcript
 BEN: Have you seen that app "Little Inferno" by the guys who created World of Goo?

PETE: Mm-mm

BEN: It's a great game. It's on MacHeist right now; I think that's still going on. So if you --

CHUCK: Oh, I saw that!

BEN: Anyway, so my son is 3 and he's really adept at using the iPad, but he's never really used the computer before so like the whole mouse thing is totally foreign to him. But, he was watching me play this game and he gave it a shot. He's actually learning the click and drag stuff, which is pretty awesome.

PETE: Awesome.

BEN: I guess the downside is just learning to burn things...

[laughter]

CHUCK: Nice!

BEN: It's just kind of the point of the game. So...I don't know [laughs].

PETE: Yeah. It's a tradeoff, right?

BEN: Yes.

PETE: Dragging, clicking, burning...

CHUCK: Hey everybody and welcome to Episode 4 of iPhreaks! This week on our show we have, Rod Schimdt.

ROD: Hello, hello!

CHUCK: Ben Scheirman.

BEN: Hello from Houston!

CHUCK: Pete Hodgson.

PETE: Hello from [inaudible], San Francisco!

CHUCK: I'm Charles Max Wood from devchat.tv. This week we have a special guest, and that is Josh Abernathy. Did I say that right?

JOSH: Yeah! Yeah, you said it right.

CHUCK: If that's more than 2 syllables, I'm going to screw it up.

JOSH: [laughs] People always get turn off because it's long, but it's just like it looks.

CHUCK: Oh, I see. So, do you want to introduce yourself really quickly?

JOSH: Yeah! I'm Josh Abernathy. I work at GitHub on the GitHub for Mac App, and various other side things. And yeah, I've been doing Mac and iOS stuff for quite a while now. So hopefully, I'll have something interesting to say about the topic.

CHUCK: So is there a GitHub app for iOS?

JOSH: We have a couple different iOS Apps. There's an Issues App and there's a Jobs App, neither of them are particularly well-maintained at the moment. So, we kind of try to pretend we don't have any iOS Apps.

CHUCK: I see.

PETE: I actually tried to use the Issues App the other day...

[Josh laughs]

PETE: And then I went and look...Is it open source? Is it available kind of the code --

JOSH: No...

 

Have you seen that app "Little Inferno" by the guys who created World of Goo?

Mm-mm

It's a great game. It's on MacHeist right now; I think that's still going on. So if you --

Oh, I saw that!

Anyway, so my son is 3 and he's really adept at using the iPad, but he's never really used the computer before so like the whole mouse thing is totally foreign to him. But, he was watching me play this game and he gave it a shot. He's actually learning the click and drag stuff, which is pretty awesome.

Awesome.

I guess the downside is just learning to burn things... [Laughter]

Nice!

It's just kind of the point of the game. So...I don't know [Laughs].

Yeah. It's a tradeoff, right?

Yes.

Dragging, clicking, burning...

Hey everybody and welcome to Episode 4 of iPhreaks! This week on our show we have, Rod Schimdt.

Hello, hello!

Ben Scheirman.

Hello from Houston!

Pete Hodgson.

Hello from [inaudible], San Francisco!

I'm Charles Max Wood from devchat.tv. This week we have a special guest, and that is Josh Abernathy. Did I say that right?

Yeah! Yeah, you said it right.

If that's more than 2 syllables, I'm going to screw it up.

[Laughs] People always get turn off because it's long, but it's just like it looks.

Oh, I see. So, do you want to introduce yourself really quickly?

Yeah! I'm Josh Abernathy. I work at GitHub on the GitHub for Mac App, and various other side things. And yeah, I've been doing Mac and iOS stuff for quite a while now. So hopefully, I'll have something interesting to say about the topic.

So is there a GitHub app for iOS?

We have a couple different iOS Apps. There's an Issues App and there's a Jobs App, neither of them are particularly well-maintained at the moment. So, we kind of try to pretend we don't have any iOS Apps.

I see.

I actually tried to use the Issues App the other day...

And then I went and look...Is it open source? Is it available kind of the code --

No...

You guys should have been sourced it...

Yeah, there are a lot of internal discussions about what we need to be doing with our iOS Apps and Mac thereof. Yeah, the Issues App is kind of interesting in particular because it was written in Lua, and so a lot of the -- like we could open source it, but probably most people wouldn't be terribly interested in the source because it's all Lua.

Wow! So, what framework did you guys use to interface with Objective C?

I wasn't involved in that. It was Corey Johnson who did that, and he wrote (I don't know) some kind of a Lua Bridge to Objective C --

Oh really? It makes me want you guys to open source. [Laughter]

I think its framework is open source.

Oh, yeah?

I honestly don't know, it was like 2 years ago maybe even longer ago, that he did that. So, it might be open source; I don't know his framework. Yeah. It's interesting.

There was a kid out here in Utah, he wrote a game in Lua for the iPhone.

Yeah! There are a lot of people who really liked the language for its, I guess, its simplicity.

It's really common in the game industry. I know one framework for writing iOS Apps in Lua, it's called the "Corona"...

Oh, yeah...

But, I think it's more geared for writing games because the UI code I've seen like under demo pages and stuff, it looks totally non-native.

Yeah, that's a bummer.

I think Angry Birds is written in Lua, right? [Josh Laughs]

No, seriously. I think --

Well, there you go.

Yeah. I think if they can do Angry Birds, you could do anything.

Yeah, yeah. No kidding...That's the secret to making billions of dollars on the App Store; just regular app in Lua and you're golden.

Anyway, we're little off-topic. I'm just curious, what are the major differences -- I'm going to just go right to it -- what are the major differences between writing an app for the Mac and writing an app for iOS?

Oh, man! You would think they would be kind of similar, but frameworks are just worlds apart. Because AppKit's from, I don't know the 80's probably, and then UIKit was made for iOS. And so UIKit was kind of like their chance to go back and redo all this stuff from AppKit; UIKit is much nicer to work but has a consequence of that, whereas, AppKit has years and years of hacks and fixes than what not thrown on top of it. And so, you have all this craft that comes with a framework that exist for years. Whereas, UIKit gets kind of this clean-break-nice-clean-framework feel to it. So, it's just very very different and could as much more rough around the edges, I would say.

So you can't just replace the UI with NS and make your app to it?

[Laughs] Yeah, if only...[Laughs]. There've been a couple of attempts at that, though. The Iconfactory guy has created the Chameleon framework, which is kind of like this being UIKit on the Mac field to it; and that's what Twitterrific for Mac has written then. Then there's also TwUI from Twitter, which has let Twitter for Mac was written then, which kind of tries to be similarly UIKit like for Mac. But, both have their own downsides, and at the end of the day, you still have to deal with AppKit; you're not skipping it. And, it's sadly not just replacing NS with UI or UI for NS.

Yup. So, I know that the iOS Apps are kind of Model-View-Controller-ish, are Mac Apps kind of the same way? Do you structure them the same way and you just use different parts of the different frameworks? Or, is there more to it than that?

Yeah, it's still generally Model-View-Controller. The difference being that, in Mac OS X land, you have to deal Windows, too, and so you have ViewControllers, but then you also have WindowControllers. And those can, how exactly, those relate; you have your ViewControllers inside your WindowControllers, obviously. And then, you can have like a document controller if you're a document-based app. So, it's very similar in the structure just with one higher level in the Window.

Do you end up like nesting those ViewControllers arbitrarily? Or, was it was --

Yeah.

Okay. Because I've always had a hard time with that with like test -- I guess in my dark past, I did some Flex Development...don't tell anyone... [Laughter]

You can edit this out, right? [Laughter]

Hey, I keep hearing that you can write iOS Apps in Flex.

Oh, man...Let's ask a different topic.. [Laughter]

Yeah, and the thing that we always find really challenging with Flex Development was this kind of like how to structure like MVC UI patterns when you want to kind of compose stuff together. I guess, the JavaScript development community is kind of going through this at the moment with things like that, burning Ember as well, but yeah, is it just that you kind of arbitrarily nest these things inside themselves? Or, how's that work?

Yeah, definitely. We'd probably go crazy if we tried to fit all that in one --

Model-View-Controller...

Model-View-Controller, right, exactly; it'd be terrible. Yeah, we try to break it down as much as we can by conceptual view. So in the GitHub for Mac App there's like, the historyViewController, and then when you go into a specific commit, there's a commitViewController, a changeViewController, and kind of these high-level architectural pieces, and not to go down like too many [crashing]...oops...too many rabbit trails. But in GitHub for Mac and some of our other stuff, we've been working with a different paradigm; we've been talking about Model-View-Controller. We've been trying out a paradigm called "Model-View-ViewModel", which you might be familiar with if you have any exposure to the Microsoft world since what they do --

I was going to say Knockout.js, I believe, is Model-View-ViewModel.

Oh, okay! I didn't realize that it gone to JavaScript world now, that's interesting.

I think the guy that wrote Knockout was a Microsoft, he works at Microsoft now, I think that he was a Microsoft guy and he wanted to bring that kind of MVVM thing to JavaScript because there wasn't anything that was doing a little time.

Yeah. If you're curious and want to know more about it, we actually interviewed him on JavaScript Jabber; I'll put a link to that in the show notes as well.

Yeah, that’s interesting. I had no idea he'd made the jump there, too.

So, how was that working out for you? The MVVM thing...

It's been really really helpful for us. The big one for us has been that we can break down bits of the app into these pieces that are more easily unit testable. Because for Model-View-Controller, you often end up with this big ViewControllers and you just kind of like throw everything in the ViewController. But then, you can't really test it very easily because now, all of that logic of the View is so dependent on the View and dependent on how they like a noob instantiated in having a TextField on the screen and all that stuff; it's really hard to unit test. And so, people try to do like Automated UI Testing through using Accessibility APIs or that sort of thing, which works pretty well, but it still kind of a hack on the fact that all this logic lives like in your TextField or in your nib. But, it's been great for us because it lets us really unit test a lot of these like behavior and logic of a View without having to instantiate this whole View hierarchy thing.

So you can kind of fraud the ViewController and then check the ViewModels that look right, is that about it?

It's kind of; it's more that like the ViewModel -- you make a ViewModel out like the same kind of level of granularity as you have a ViewController so might have, like Frost, you might have a HistoryViewModel, and that would provide us with like all of the data that we we're displaying in that View. So, that will give us all of the commits that we want to display for repository or something, and so then we can unit test that and be like "Alright, given this repository, does the HistoryViewModel give us the right list of history? The right list of commits?" And so you can test that logic without having to be like "Okay, is it in the TableView and does it have a TableViewCell with a title label of this: blah, blah...?"

So the ViewModel actually has behavior in it as well and you're kind of unit testing that behavior inside the ViewModel?

Yeah. The goal is that you can kind of like separate that apperance, which is in your View from the behavior and logic of the data, which is in the ViewModel. And so hopefully, in that way, you can get much more unit test coverage. In Frost, we've had a lot of success with it.

That's awesome.

So the ViewModel is kind of like a DataSource?

Yeah. You could definitely think of it like the DataSource in the behavior guide, behavior source, behavior controller, or whatever.

And you guys, did you kind of build a framework around this? Or, is this more like kind of a conceptual panel not just you think about when you're building the code?

Yeah, it really doesn't require much of like any kind of framework or infrastructure support per se. We have lika a super class, but it really doesn't do anything at all. They're basically just plain objects, plain NSObjects.

Oh!

You need like some kind of data-binding between your View and your ViewModel, and that's where you could have some kind of framework that helps you with that. But, that's kind of a different topic.

So you mentioned automated testing, are you guys -- I know that GitHub are really big on CI or at least [inaudible], well-known for having lots of good CI projects -- so, are you guys using kind of Automated Testing in the CI for the Mac App as well?

Yeah, we have a CI Server, I think it's just a Mac mini at the office now, and it builds on every push. So, it runs the unit test or through all the unit tests and gives us adult.

Awesome.

Yeah.

So we talked about testing last week, what are the testing tools for Mac Apps?

Well, we just do unit testing; we don't do any kind of Automated UI Testing because it tends to be fragile and it's not clear what exactly the winds would be for us compared to unit testing. So for unit testing, we use two frameworks called "specta" and "expecta", which are kind of behavior-driven design sort of test things; we don't really follow any like strong pattern. But, it lets us write unit test that are really fluent so you can say "It should give us the top 10 commits (and then say), the top 10 commits should equal this". And so, it illuminates a lot of the Broiler play, that you're typically have to write for like OCUnit tests, and those sort of frameworks.

That sounds like kind of similar to Kiwi on iOS.

Yeah, very similar. I think the only big difference between the two is the syntax because I think Kiwi is kind of more message passing syntax, Objective C message passing. Expecta is more dot syntax.

Oh, okay.

Yeah. Expecta matches better with the Rspec's new style, where you say "Everything expect", and then you've wrap that. And I think that's probably more readable than the message passing style because you end up having a lot of nested square brackets in the key rematcher syntax.

Yeah.

They do.

And I think Kiwi does some -- I think expecta does a better job with the, I guess you call it type in for NS, but kind of more generically, you can just say expect(1).to=2 or whatever, and you don't have to worry about what the types of those things --

Ah, right...Because you're already wrapping everything...

Yeah. So it's --

Oh, that's a definite reason to switch.

Yeah, that is. Yeah.

The value wrappers...

Yeah.

Oh, man! Oh! [inaudible]

Is that available for iOS as well?

Yeah. Yeah.

I'm definitely going to look into that.

Yeah, they're really nice. Specta is like the framework, and then expecta is all the matchers.

Cool!

Oh, okay.

Does it do mocking as well? Or, do you need to signout for the mocking?

No, it doesn't do mocking. We use OCMock, or whatever that thing is called.

I don't see any reason why you couldn't embed this in Kiwi, though, because all it does is raise an exception just like Kiwi would.

I have no idea. I have seen they're basically the same thing under the hood; it seem that's all like OCUnit under the hood.

Right. So, I wonder if we could like step back for a minute. I remember trying out my first mockup, I was reading Aaron Hillegass' book "Cocoa Programming for Mac OS X" --

Yeah, that's a classic.

Yeah. It was so different because I was reading it for the purposes of writing an iPhone app and it was just so different. But I did go through the tutorials and take a look. However, the things that you would end up using like NSTableView and some of the other things just seem so, I guess, basic or bland that all of Mac Apps that I know and love don't look like that. So I'm wondering, do the top apps just end up rolling their own stuff? Or, it's just like heavy subclassing customization?

Yeah, it's probably a lot of both. I think that there's, well up until Mac OS 10.7 I think (pretty sure it's 10.7), all NSTableViews, they had cells, which -- in UIKit you have cells, but there are UIViews and so it's a pretty standard thing -- but for NSTableViews, cells are not Views; cells are these things that they kind of treat them like stamps. And these cells, you just kind of stamp out of your View. This comes from back in the day when you can have all kinds of memory to keep Views in; you want it to your TableView to scroll quickly, and so you needed this really lightweight object that you kind of draw a cell for a TableView. And it couldn't be even a View; it had to just be an object. And so, these NSCells were really kind of a pain in the butt to use and a pain in the butt to customize because they're not Views. So, you can't add things to their hierarchy. That was really really annoying for a really really long time. And so, a lot of people wrote their own like view-based NSTableView replacements. So, I wouldn't be surprised if a lot of TableViews and a lot of Apps are really their own custom TableView replacements based on View cells. But then in 10.7, I think it was, we got NSTableView now can handle view-based cells and it might just a little bit better. It's still a little bit of a ghetto, but a little bit better. [Ben Laughs]

I have a question for you. It seems like most of the Apple events and announcements, they seem to spend a lot more time on iOS than they do on Mac.

Yeah.

I'm just kind of curious, do Mac developers feel like they're kind of being pushed to the side? Or, [Laughs]...

Oh, man! I'm not the guy that ask about this. I'm fairly cynical anymore about Mac Development or, I don't know, Apple Development generally. Obviously, Apple's focus right now is iOS, and that makes a lot of sense; that's where their money is. So, why would that not be where their focus is? That's where the future is. So, it makes sense that that's where they were focused. It does suck that it feels like so little attention is paid to the Mac, especially in terms of APIs, like I talked about earlier. In many ways, AppKit is still stuck in the past; stuck in the way we did things 10 years ago, and it hasn't changed much. It's changed a little, but not nearly enough. That bothers me, but at the same time, I understand why Apple wouldn't want to pour any more time or money into Mac than they really have to; doesn't make any sense, just business wise.

What about the influx of Mac users that, I think for a lot of people and I think, I'm probably in this category where I came to Mac via iOS. I wanted to get a Mac because I wanted to write for iOS, so like just a regular people non-techies who get an iPhone and they just love the way it looks and feels, and the way it just works, and they hear the hype at the Apple Store, or whatever. And so, I wonder if there's just all this new Mac users that should be paid attention, too, right?

Yeah, I would agree with that! In my frustration, I don't know, a couple of years back I wrote a blog post about why Apple should care because there's all these iOS Developers who now want to make Mac counterparts to their apps. And they come to AppKit, and they come to Mac Development and it's the stone ages! And Apple should care about that because the Mac is still where people get a lot of work done. Like, we're developers, and so we probably spend more time on our Mac than maybe a lot of people. But, the Mac is still where people do a lot of work, and so they should care. They should care that developers are coming to Mac, and throwing up their hands and disgusting leaving, or writing their own UI Frameworks, or jumping through all kinds of hoops like they should care. But at the same time, you look at some of the fires they have in iOS land with iCloud and Core Data syncing. They have enough other fires burning that I'm sure are much more important to them than Mac Development is. Even though that, I agree. I think there's a business case for Karen; it's still relatively weak, I think.

I wonder if their kind of long-term strategy is just to merge the two and then they'll just kind of ever not just use UIKit for everything.

Yeah. It'll be interesting to see what happens with 10.9, if 10.9 is a much more obvious merging of the two worlds.

Because it feels like with, especially the last few releases, because they've been kind of figuring out the extra stuff you need for iPad for like bigger real estate. Stuff like CollectionView makes it kind of fadely feasible that you could use the same frameworks for building like a desktop app rather than just a tiny little TableView within --[Josh Laughs]

Yeah, it has been interesting to see in with the ViewController containment stuff; it's been interesting to see how they try to scale up some of those UIKit paradigms.

Yeah, because I was really painful for a while. When the iPad first came out and everyone was rolling their own, I remember like no end of frustration trying to figure out how to put a ViewController inside of ViewController, and then "Oh wait, we're not supposed to do that" --Yeah...

[Laughs] Yeah...

Good times...

We do that on Mac, but a ViewController isn't nearly as central on Mac development as it is in iOS, and so, it's much less of a big deal to kind of embed them within each other.

Right. On the Mac, there's the NSViewController Class. Do you guys use that much? JOSH: We have a subclass to that we use because NSViewController itself doesn't really do much for you. It'll load like a View or a nib, but --

But has a view property... [Laughter]

Yeah! That's basically it! It's like "Yeah, we have a View, we're controlling it. What more do you want from me?" [Laughter]

So, do you run into any -- we talked a couple of weeks ago about Memory Management. Is Memory Management terribly difficult on the Mac?

No! It's even easier...relatively easier than on iOS. Because on iOS, you actually have to kind of worry about how much memory you're using that maybe that's less on these days. But on Mac, as long as you're not using exorbitant amount of memory, doesn't especially matter. Obviously, you still want to keep a handle on how much you're using at any one time, but it's now like iOS where the OS will just kill you if you ask for too much.

An OS like has garbage collection right now, but they're taking it away. Is that right?

It's been officially deprecated. So, it's...I don't know. We use garbage collection in GitHub for Mac and then switch to ARC pretty quickly because, as much as I like the idea of garbage collection, it was really buggy with respect to some other Apple frameworks. So, it was an, option but never a terribly great option.

And switching over to ARC, was that painful? Or, was that like pretty straightful?

I was fairly painful for a little bit; less painful than going to Manual Memory Management, but there are stuff like 'notifications'. In garbage collection, you didn't have to remove the observer for notifications. And so, then we went to ARC and suddenly, everyone is trying to message deallocated observers. So, it is a little bit of a pain in the butt, but what can you do? [Chuck Laughs]

I wasn't really surprised when they deprecated garbage collection, but then I guess, I haven't done that much OS X development, so I didn't know that it was buggy. And I guess, hearing that it's kind of buggy makes me understand, but [inaudible], why would you get rid of garbage collection? [Laughs]

It broke my heart; I wish they would have...I don't know. It was really buggy especially back in the day with 10.6 and Core Animation; it was extremely buggy. I wish they would have fixed it, but it's hard to know if -- given that they have to be a superset of C -- it's hard to know how much fixing it would have really done for it.

Yeah.

I wish we at least have garbage collection, though, still. I really wish we have garbage collection. Every time I do the stupid weak/strong dance for blocks, I wish we had garbage collection. [Laughter]

Another concept that I learned when learning from that book was the "Concept of Binding", which we just don't have on iOS. I'm wondering if anybody really uses that. Or, if that's a set of the technology that's going away.

Yeah. Binding was a weird one. I feel like Mac OS X has this funny history of Apple being really excited about new APIs for what like one OS release, and then they drop it, and they're like "Ah, that never really happened; pretend that never happened". And binding is in that category, where they were like "This is great! It eliminates all this boilerplate! Just let you glue your two components together!" then they just never really talked about it ever again. For us, we use it in a few places. The idea of binding I think is sound, but the implementation of Cocoa Bindings was hard to debug, really awkward to use for a lot of controls, and the way it plays with, actually, with Memory Management semantics is really goofy, too. And so for a lot of those reasons, I think a lot of people don't use them; we use them pretty sparingly.

Yeah. I have this healthy fear of things like that where some critical part of your application's logic is a setting in a property pain somewhere in interface builder. [Laughter]

And if you accidentally fat-finger it, like you'll never going to look at the diff and know what you did.

Yeah. Yeah.

And you can't set a breakpoint on that. So, I just kind of wholeheartedly dismissed the whole binding system just from pain and during that same sort of thing in Windows Forms back in like .NET2.0 days.

Yeah.

But it was curious to know, does anybody really use it? It sounds like it's still there, but --

I think there are still some people who really like bindings for simple things like User Defaults. It's pretty straightforward to bind, and I think a fair amount of Mac Developers do it for that. But yeah, having your application's stability and logic being tied to a random string in an Id field is pretty terrifying.

So, are there any frameworks or any libraries that you use in Mac development that we don't have in iOS that you wish we did?

Hah! Nothing immediately comes to mind. I think that maybe some of like the Core Image stuff might not be on iOS. But honestly, I don't know! I've never done enough of that stuff to feel the pain of missing framework. Mostly, I find myself wishing I had iOS frameworks on Mac. CHUCK: Which ones would you?

Well, I would love that UIKit on Mac [Laughs]...Just throw AppKit out the window. But, yeah…

Do you think that if Apple does decide, perhaps at WWDC this year, that AppKit needs, are we thinking, kind of like UIKit got from a fresh start; and as a result, it's so much better or more modern usable framework. Do you think that they might just deprecate AppKit entirely and create something new? Or, do they want a fresh code of pain on AppKit?

[Laughs] I would love to see them just deprecate AppKit and give us a new way forward. It feels like they keep trying to kind of fix AppKit like in Core Animation support for AppKit, which they introduced in like 10.5 or something. They're still trying to fix AppKit to support Core Animation layers. And that's kind of what it feels like, that they're kind of trying to put bandaids over these things; trying to plug every hole. But, I don't think that works because AppKit is just from a different era - it's from a completely different era. It might have been awesome 20 years ago, but it's not awesome now. UIKit is like the example for that. They threw out AppKit; they could've used AppKit. But they threw it out, they made UIKit, it was a completely clean break, and AppKit is mostly really nice to work with. And so, I would love to see them do that with AppKit; just throw it out, deprecate it, and start something new. And then now, like they have a fear of deprecating things, right?

Yeah. [Laughs]

Which makes me think that they just won't.

I wonder if this has any kind of corollary with the switch from Carbon to Cocoa?

Yeah, definitely.

That was before my time, before when I understand Carbon Apps and C++, or something. I don't even know. But, it was just a totally different architecture, completely different environment. And switching to Cocoa was kind of a huge thing for these like really long-standing Mac Apps.

Yeah. I think that's a great example. Apple has a long history of deprecating things aggressively, and it's usually for the better. And so, I would love for them to deprecate AppKit and give us something new. It's a huge undertaking, though, right? Writing a new UI Framework is ridiculously huge task to get all those little things right; it's a big deal. So, I feel for them, but I think it should be done.

Are there any reasons why they couldn't just adapt UIKit to work on the Mac?

Well, it works on the Mac because dissimulator is running UIKit presumably. I don’t know…and sure there are like paradigm problems with just giving us UIKit.

I bet the graphic performance is horrible like relatively. I'm sure there's loads of stuff under the covers that's really optimized for the purses around the GPU on iPhone like, I would guess, it's really really optimized for an ARM purses.

But they are in control of the hardware, too. So, this is a problem that they could address. ROD:

Yeah.

[inaudible] PCWorld, where the guts could be anything; any combination of parts. I could understand why they would be hesitant. But, when they own the entire ecosystem, they can kind of do whatever they want.

I think, pretty much all they'd have to do is add support for multiple windows; an overlapping windows.

Yeah. ROD: Unless you change the whole UI paradigm.

Yeah, that brings up an interesting point. Why I like iOS? I think it's a lot easier just in terms of it's all Hypermodel; you have way less things that you can do so it sort of focuses your attention to things that "Okay, I only have 5 places for buttons". [Laughter]

So, that's a good thing. This is why I think I'm really bad at iPad app design because there's just too many places I could put things --

And, the number of choices on Mac are even greater than that. So, I would have a hard time designing a Mac App, I think.

[Laughs] Yeah.

I'm going to have to find an image of an iPad app that's like all buttons...

[Laughs] Why would you do that to yourself?

Ben's app on the iPad... [Josh Laughs]

Yeah.

I think that's true with the APIs as well. I guess that's partly what just you've been saying, that with UIKit or with Cocoa Touch, there's pretty much one way to do most things and there's not that much to look around for. But I remember when I was writing this [inaudible] OS X app, they're just the size of the API that's kind of accumulated every time is pretty intimidating. It was like, "I just want to open a dialogue, how do I do that?" [Laughs]

There's like sheets, and there's [inaudible], and there's activities --

Do you ever done Win32 programming?

Yeah!

Oh, god! It's horrible. [Laughter]

Are there any tips for like how to know which bits of the API are the bits that people should still be using? And, which bits are just like the crafty corners that you should just avoid at all cost? JOSH:

Well, drawers; drawers are write-off.

I wish I've known that.

They were so big in like maybe 10.1, and they're still there; you can still make drawers on your windows. But drawers, yeah don't use drawers...I don't know...it probably just comes from having experience on the APIs. It really is kind of overwhelming, especially compared to iOS.

Yeah.

You look at a TableView; NSTableView has a clickView and a scrollView. And, what do both of those things do? And, why do you need both of those things in addition to a TableView? It's more complex, that's for sure. And a lot more customization requires subclassing, which is terrible. It really comes to a day where you didn't do things custom, you only did the straightforward thing because probably custom would be slower and much more expensive.

So, you guys in the App Store with the Mac App?

No, we're not in App Store.

Is there a reason for that?

Sandboxing would be pretty difficult for us.

Oh, okay.

It's not impossible, but some of the things we would have to give up for sandboxing would really suck. So for right now, there's no real reason we need to be in the APP Store, and so we don't jump through the hoops necessary.

I wonder how much for success the App Store has been overall. I'm not sure that Apple release numbers on how many people are using it, but --

Yeah, I don't know. And for a little bit there, it seemed like there were a lot of stories about prominent developer leaves Mac App Store because sandboxing, or whatever. I don't know if that's changed at all recently.

I know, in my experience, it takes a lot less sales of your Mac app to get into the top charts than it does on iOS.

Yeah. I'm sure the amount of people using it is ministerial [inaudible] of the iOS App Store. I actually kind of like that because one of the arguments that people always make against web apps is all people won't be able to discover it and you need an App Store so people can find your application. The kind of example I always give to them is like "Oh, is that why everyone uses the App Store for their apps on Mac?" It was like "No, they don't actually." Turns out the web has this search functionality that people use quite a lot. [crosstalk]

Yeah. Well, it's interesting, too. I think all of us use Macs in our daily usage, and just think about the number of apps that you get out of the App Store versus the number of apps that you download off the web and just install or copy over to your application folder or something.

Yeah. It'll be interesting to see if Apple makes any changes in 10.9 to kind of encourage more Mac App Store usage.

Well, you already have to go in and check the box that says "Allow third-party programs".

Yeah. Our nightmare is when it becomes much more difficult.

Yeah, that's true. Hopefully they never do that [Laughs].

Yeah, let's hope so.

But, you never know. It is a business and they definitely make money when you buy stuff out of the App Store.

Yeah. It'd be very interesting to see what 10.9 gives us, or we continue to merge with iOS, or if it's still a pretty separate deal.

Are we expecting 10.9 at WWDC sometime this summer?

I think they said they were going to go to a yearly release schedule, didn't they?

Yeah, I remember John Siracusa is lamenting like, because he has his epic review that he does in the old time -[Laughter]

And he's like "Oh, this sucks!"

There's rumors that Mac developers have been pulled on to iOS 7 so Mac 10.9 will be delayed. So, maybe we'll get it this summer, or late summer, something like that.

Yeah.

I wonder if anyone at Apple has ever read 'The Mythical Man-Month'. [Laughter]

So, Josh, I was wondering if there are any like resources online like it's got to be hard to kind of weed out like all of the iPhone specific stuff. I know some resources that I look out like 'Cocoa Controls', does iOS and Mac like third-party libraries or whatever. I'm just wondering if there's any kind of specific to Mac that you look at or maybe books or something that are still relevant today.

Not really; it's pretty few or far between. I usually just search, Google search, or search on GitHub to see if I can find something that I'm looking for. With UI stuff, it's usually a completely lost cons; you're not going to find whatever kind of custom UI you're looking for for Mac probably. Whereas, on iOS if you wanted like a custom progress indicator or something, there's like ten different custom progress indicators you can find. But on Mac, you probably had it luck. When it comes to kind of more generic libraries like networking or data storage or that sort of thing, you can usually bring it to Mac without that much work if you need to.

Do you have any like -- I don't know, like when I download iOS Apps, I'm always kind of like visually picking the apparent to and figure how they did certain things and try to learn from that -- are there any like Mac Apps that you look at and be like "How do they do that?"

Yeah, sure. These days, Mac Apps -- I mean really, what was the last Mac App that came out that you were really excited about?

Tweetbot.

That's what I was going to say...

Yeah! It's like one a year, maybe. And so, it's definitely interesting when those things come out because it's I'm super excited like "Whoa! Someone made a Mac App! Can you believe that? Isn't that cute?" [Laughter]

And so, yeah, we thought it's interesting. I really like the Twitter for Mac App despite the fact that it's not really starting to show its AHI, it's really well-done.

I kept with it for a long time; it's still like I write in the MacBook Pro and then I was like "Oh, I couldn't get off of the [inaudible]" [Laughter]

That's why I can't upgrade to a MacBook Pro; it's because I can't give it up. But yeah, it's exciting when those things come out and I love to see what people are doing with the UI; Reader for Mac was interesting when it came out. But, these things are just so few and far between; I get excited when it happens. Man! It's like an event!

Have you ever looked at the Hit List, it's a To-Do application?

Yeah!

I really love this app, it's one of my favorite; just well-designed apps. It's got tons of features that looks great. But when I look at this, I'm like "I don't even know the first step to building something like this". It's inspirational to look at, but man!

I can't imagine the amount of custom work that went into that app.

And it's one guy...

Some people are just disgustingly talented. [Ben laughs]

'Things' app is really great, still, in the UI. It's not as customed, but it's really just well-polished, much like their iOS App.

Yup. So, are there any books or other resources that you would recommend?

For Mac development...

For Mac development...I mean we talked about differentiating between Mac and iOS stuff, but if somebody wanted to make the transition, what would you tell them to do?

The Hillegass because probably the kind of seminal work on Cocoa development on the Mac so, I would certainly recommend that. I don't know that there are any extremely modern resources anymore for Mac. Back in the day, you used to have the great bloggers of old who are Mac developers, but no one really blogs much anymore and especially not about Mac stuff. So, resources are pretty sparse; they are always sparse for Mac development. Not many people were ever doing Mac development, but by comparison to iOS development, they're extremely sparse. So, it involves a lot of experimentation especially when you're trying to figure out a custom control; a lot of experimenting and Googling and crossing your fingers hoping someone else has stumbled across the same thing.

Yup.

Do you have any sort of guidance or recommendation for creating an app that is on both platforms, iOS and Mac, and sharing code between them?

I don't really, I haven't done it. And so, I can't really make any concrete recommendations. Chameleon, that I talked about earlier that the Iconfactory made, that was kind of their goal with Chameleon; to be able to share a lot of the UI code between Twitterrific on iOS and Twitterrific on Mac. And so, that's why that exists - to be able to share a lot of that code. I'm not sure if that's really a great way forward, but they seem to do alright with it.

That's really interesting to me because I've built apps that share code, but is usually at the business logic data layer, not the other way around.

Yeah. We've had some interesting discussions internal on the GitHub team to how we would share things between the GitHub for Mac and GitHub for Windows Apps. Because there's a lot of things that we do that are basically the same but in different languages and APIs and what not, which is a whole different problem, but kind of similar and that you can end up saying "Well, we'll share a lot of the data access code or a lot of the model code, but everything else has to be fairly custom for the platform".

You just have to rewrite it all in Lua. [Laughter]

Exactly! Well, now there's Xamarin, so you can just write it all on C# and be done with it.

There's also a bunch of different cross-platform desktop before that's, I guess, what people do is use something like --

Titanium has a cross-platform desktop version. But, it's kind of the same stories all across platform things. You really need to be an expert on those things, those frameworks, and that comes at the expense of you learning like the proper AppKit way or the proper Windows way, or whatever.

Example of an app that does do iOS and Mac on the same codebase, [inaudible] Cheddar, which is this To-Do App that Sam Soffes, I think that's how he say his last name, he made that and he said that it was the same codebase. I think he open sourced...I know he open sourced the iOS codebase, so that means he open sourced the whole thing.

Yeah, Ratio, the Mac app is open source now, too.

Yeah. So, if people are looking for examples of apps, that's one to look at.

Well, you can even run into it a little bit in the model there, like if you have an image property on an object. I mean on iOS, it's UIImage and in Mac it's NSImage, so you got to do a typedef or ifdef, or something.

Yeah. Interestingly, this is also where Model-View-ViewModel can kind of help you out because, at least in theory, you could share a lot of the ViewModel logic as well between platforms. I guess it depends on how much of the actual View design is the same. But conceptually, at least, you could end up sharing more of that.

Yeah. Well, if they're using the same data or mostly the same data, then your ViewModel will look mostly the same.

I would think so, yeah.

Yeah. If you're not familiar with the concept of ViewModels, I highly recommend that you go check it out because it is an interesting way of thinking of things. It's kind of like a presenter, but not quite the same thing.

Yeah.

I'm not going to go into the differences, but it is an interesting concept, and I really like the way that it applies to some of things that I've seen it do it in JavaScript.

I think its biggest enemy is its own name because you have like Model-View-Presenter, ModelView-Controller, and then Model-View-ViewModel, and you just get kind of seemed like "Okay, now you're just trolling me..."

Yeah. I just had a stroke or something...

It's also weird to apply that in the web. And I think it makes a lot more sense in rich-client experience where you can have like actual binding or actual like interaction that changes state rather than like a paid refresh or whatever. So, I think it maps better than that environment.

I think if you're doing -- you can do rich-client web apps, they're like single-page JavaScript; it just happens to be using HTML as a presentation. I think I've heard that with people who've had success with like Knockout and the data binding stuff, it's when it's a single-page app and you're really pretty close to where rich-client at that point.

Yeah! And it has been interesting to see how the web has kind of try to reinvent or has had to reinvent some of these like rich client...I don't know, I guess design paradigms.

Yeah. So the MVVM stuff that you guys are using, does that have data binding in it? Or, you kind of manually moving different stuff between?

No, it would be terrible if we're manually keeping it all. We use ReactiveCocoa to do the binding...

Oh, right. Right.

The View to the ViewModel, which under the hood is Key-Value Observing. So, not Cocoa Binding is like kind of similar, and that make sure everything is kept in safe between the different layers.

Cool. I really want us to do a show on ReactiveCocoas thing, it's really really interesting.

Yeah, I think it's fantastic! But, I might be a bit biased. [Laughter]

Alright, is there anything else that we've missed as far as Mac development goes before we get into the picks?

If you're doing Mac development, may God have mercy on your soul. [Laughter]

It's a small group, but it's a small proud group of Mac developers. And, you'll make me extremely happy if you ever make a Mac app anyone. I'm so pumped when someone releases a Mac app.

Alright, cool! Well, let's get into the picks! Ben, what are your picks?

Okay, so I am less prepared this time than before -[Laughter]

Shame!

Yeah. So, I will pick 3 things. The first one is, I like this little cards that people have that like really good cards doc, whatever there. They're kind of like half-sized business cards, and I recently got a bunch of those for NSScreencast. I got them from "moo.com". Every time I hand one out, it comes with a little cardholder and they just kind of slick and everybody's always commenting about those. I usually take those at conferences and hand them out; just really good quality cards. So, that's moo.com. Another app I use on my -- I guess it's just kind of continuing on my developer tools pick list -- is "Kaleidoscope for Diffs", which is like by far the sexiest Diff Tool you've ever seen. That's at kaleidoscopeapp.com. I actually use that for just diffing, back when it was own by Sofa (We Are Sofa), and then it got acquired by Black Pixel, and they basically answered my prayer to add merging support to that. So, it's got the 3-way merge support in it. And then, I'd also like to pick the "Briefs App", which is actually the release date was just announced on Twitter while we were on the call; it's going to be May 1st. And this is a Mac App and iOS App for doing like --

I'm so happy right now!

Yeah [Laughs]. If you don't know the history of Briefs -- it'll like maybe 2 1/2 years ago, could have been even 3 years ago -- I remember we were using Briefs and they were trying to get it in the iOS App Store. It got rejected time and time again and their creator, Rob Rhyne from MartianCraft, he just kind of gave up on it and he was like "I spent a year of my life on this, and they'll never going to approve it". And, when I was talking to one of the developers sets at CocoaConf in Dallas, it seemed like they were nearing completion of a version that was sort of blessed by Apple. And, both apps have been approved and they'll be coming out May 1st. So, you can find that at giveabrief.com, and that will probably be released by the time this episode is out!

Nice.

I saw a really cool demo of that at CocoaConf in San Jose just this weekend, and it looked really really cool. Very incredible how fast you can like put together a price tag.

Awesome! Rod, what are your picks?

Oh, yeah! Josh, just so you know, I have a Mac App, too, [inaudible].

Oh, good! Good! [Laughter]

You guys are making me so happy!

I actually have two!

Oh, my gosh!

My first pick will be one of Josh's projects; I like to study compilers, and someday, I hope to write my own language. But he has a project called "clojurem", that is a clojure to Objective C compiler that I thought looked interesting. So, I'd like to check that out. I also have a fantasy about writing stuff in the Lisps... [Josh Laughs] ROD: So, that goes in with that. And also, my second pick is the "Oblivion Soundtrack", someone post a link up to it on rdio, and I get a list, and it's a good soundtrack; written by the same guys that did the Tron Legacy Soundtrack.

Oh, cool! Yeah, band called Daft Punk; it's kind of cool stuff. Alright, Pete, what are your picks?

Actually, I was thinking about picking my own Mac App just because I can do that. And then I realized that my developer license expired, and I was too lazy to update it, so it's now not in the App Store. But I did write a Mac App, so Josh should be happy. [Laughter]

Ahh, there's so much amazing about that symptom. [Laughter]

Kind of sums up for a lot of things, maybe.

It really does, yeah.

Yeah. It was actually making some money as well...I wasn't going to put my kid for college, but --

It's not like forgetting to renew your SSL Certificate?

Something like that...

[Laughs] Yeah, they can never trust you.

There might be someone who's like really mad at me because they can't get an update for their Mac. I'm going to pick 3 -- I actually just like find at the App Store and look for apps that I've actually installed to see, trying to find some useful apps. So the 3 apps I'm going to pick is, an app called "Cloud", which is just like a really redonkulously easy way to take a screenshot and share it with someone. So, it's a little thing that runs in your tool bar, and whenever you take a screenshot, it notices and uploads it to URL and post the URL in your clipboard, so you literally hit like command-shift-4 to take a screenshot. And then, there's a little ding noise that URL for that screenshot is in your clipboard, so it's great when you want to share what's on your screen if you found the [inaudible], something like that. Another app is "MindNode", which is like a mind-mapping application. I really like mind-mapping, feel like doing kind of brainstorming and also taking notes during conferences. I try to do it, when I'm at conferences, I try to close my laptop and use a notepad to sort of do that stuff, but in general, MindNode is a good thing. And, "LimeChat", which is an IRC client if you're an IRC person. My other pick is a blog from an ex-coworker of mine, Dan Tao, philosopherdeveloper.com. I picked this because he had like a quite relevant post about good people are not resources. And he mentions in that the whole thing of like Apple shipping OS X developers to iOS and referencing The Mythical Man-Month, so I recommend that blog.

Nice. Alright, I'll go next. So, I'm a fan of Downtown Abbey, so I'm going to pick "Downtown Abbey" even though it's not on TV right now. It was kind of interesting because my wife really likes those period pieces and I just can't get into them. But for some reason, this one really did. It was fun to just watch and see how the interaction see like technology move forward. So, they got these electric lights in the house, and the old lady's like "I can't deal with them! They're too bright!" And they get a telephone, so they're not quite sure how to deal with it. Anyway, it's just fascinating show. Related to that, if you're a fan of Downtown Abbey, there is a video on YouTube. It is season 4 episode one sneak peek, it's a spoof, it is hilarious! I'll put links to both of those in the show notes. I'll put a link to the Downtown Abbey on Amazon; if you have Amazon Prime, you can watch them for free. And then, my last pick is something that I think Josh might know a little bit about, and that is "GitHub".

[Laughs] A little something...It's pretty cool [inaudible]...

Yeah! It's kind of useful...Anyway, I'm not sure if it's been picked on the show before. But, if you're looking for a way to share open source apps, or just a place to provide some source control management, then GitHub's a great place to go. And they have all kinds of features in there like a wiki for your project and issues, how the track problems with your app, you can do poll request or people can send you poll requests. So, it's just a terrific place and a terrific way to purchase a paid in open source. Anyway, those are my picks. And, we'll hear what Josh has to pick.

I have a just one pick. So a few weeks ago, Facebook announced the Facebook Home, or whatever it's called, which I could give or take. But, it was interesting to me that conversation that kind of started after that about Quartz Composer and how Facebook uses Quartz Composer to design some of the things involved in Facebook Home. There was a guy who put together, David O'Brien, he put together some great YouTube tutorials in using Quartz Composer to create this kind of interactable prototypes of some of the great animations in Facebook Home. For me, at least, it's always inspiring to see these really well-designed products that are just really human and really alive-feeling, like Facebook Home seems to be. And then to be auto recreate that, Quartz Composer just amazing to me. It was really really inspiring to see how much you can do in Quartz Composer. And, if you wonder why we don't have tools like Quartz Composer that can actually turn that into like an app if you can design so much within it. So, that is my pick. You can download Quartz Composer and download the videos on YouTube, or Vimeo, or wherever. There are also a branch thread in a core question, asking questions about having this Quartz Composer to prototype software and a couple of the designers from Facebook, actually, chime in on the branch thread talking about how to do some things in Quartz Composer. So, that was really interesting and pretty inspiring to me.

Awesome! Alright, well, thanks for coming Josh, it was an interesting conversation.

Yeah, my pleasure! Thanks for having me!

Alright! Well, thank you for listening and we will catch you all next week!