038 iPhreaks Show – OS X
Panel Jaim Zuber (twitter Sharp Five Software) Ben Scheirman (twitter github blog NSSreencast) Andrew Madsen (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:45 - iOS vs OS X UIViewController NSViewController 06:09 - NSWindowController 08:18 - Layered Views 09:48 - Bindings Cocoa Programming for Mac OS X by Aaron Hillegass Debugging 14:51 - Navigation NSPathView NSTableView NSScrollView NSCell 18:52 - Auto Layout 19:44 - Carbon 22:32 - Objective-C 24:44 - NS Classes Next Step 25:54 - Customization The Hit List Things NSOutlineView NSSplitView NSTabView 30:12 - Mac vs iOS Development Picks Mastering Modern Payments Using Stripe with Rails (Ben) The Doomsday Key: A Sigma Force Novel by James Rollins (Ben) The Art of the Screenshake (Ben) objc.io Issue #7: Communication Patterns (Jaim) The Snow Shark (Jaim) FastSpring (Andrew) objc-run (Andrew) Andrew's CocoaSlopes2013 Slides (Andrew) Disneyland (Chuck) New Media Expo (Chuck) Next Week Subscription APIs for Recurring Revenue with Manton Reece Transcript CHUCK: I’ll turn this podcast right around. CHUCK: Hey everybody and welcome to episode 38 of the iPhreaks Show. This week on our panel we have Jaim Zuber. JAIM: It’s 10 below, my car won’t start, and I'm not even mad. CHUCK: Ben Scheirman. BEN: It’s 35° and I'm also cold, but not quite as cold. [Chuckles] CHUCK: Andrew Madsen. ANDREW: 25° in Salt Lake City. CHUCK: I'm Charles Max Wood from DevChat.tv. Last week it was like 70-something degrees where I was at, so, very nice. This week we’re gonna be talking to Andrew; he’s kind of our guest, I guess. We’re gonna be talking about OSX programming. It’s kind of interesting after learning some of the techniques and tools for building things for iOS, I haven’t really looked at what's different with OSX. Do you want to kind of get us started on some of the things we have to know or do differently? ANDREW: Sure. Well I think the first thing to know is that iOS and OSX are sort of siblings, or you might even say that iOS is OSX’s kid, but iOS was obviously Apple’s chance to sort of do-over things that they wanted to do differently without the whole legacy baggage that kept them from doing that on OSX. In many ways, iOS is the more modern of the two – I wouldn’t say ‘operating systems,’ but the APIs are certainly more modern in a lot of places. There are things on OSX that are just more difficult if your coming from an iOS background you're sometimes left thinking, “Man, if I were in iOS this would be super easy, but it’s not so easy on OSX.” Fortunately there are also a few places where the opposite is true. OSX still makes things easier than they are on iOS. I'm not exactly sure where to start ‘cause there are quite a few differences. BEN: How about just the, maybe the [inaudible] example. The first thing I notice when I create a new Mac app is I'm used to just getting a view controller for free and that is kind of absent. You got a .NIB and that gives you a main window but there's really nothing else it gives you, right? ANDREW: Right. Well that's actually a great place to start. So on iOS, if you’ve done iOS programming, you know that UIViewControllers are sort of like the main class, almost, in iOS. Every single time you have a view onscreen, it has a UIViewController controlling it. On OSX, there is actually an NSViewController class, but that was introduced in 10.5, so relatively recently in the history of OSX, and what that means is that you can write an entire app without using NSViewController. It’s not sort of the vital class the UIViewController is on iOS, and that sort of gives you a lot more flexibility in terms of how you structure your application, but these days I've actually started using NSViewController more like UIViewControllers used on iOS.
CHUCK: I’ll turn this podcast right around. CHUCK: Hey everybody and welcome to episode 38 of the iPhreaks Show. This week on our panel we have Jaim Zuber. JAIM: It’s 10 below, my car won’t start, and I'm not even mad. CHUCK: Ben Scheirman. BEN: It’s 35° and I'm also cold, but not quite as cold. [Chuckles] CHUCK: Andrew Madsen. ANDREW: 25° in Salt Lake City. CHUCK: I'm Charles Max Wood from DevChat.tv. Last week it was like 70-something degrees where I was at, so, very nice. This week we’re gonna be talking to Andrew; he’s kind of our guest, I guess. We’re gonna be talking about OSX programming. It’s kind of interesting after learning some of the techniques and tools for building things for iOS, I haven’t really looked at what's different with OSX. Do you want to kind of get us started on some of the things we have to know or do differently? ANDREW: Sure. Well I think the first thing to know is that iOS and OSX are sort of siblings, or you might even say that iOS is OSX’s kid, but iOS was obviously Apple’s chance to sort of do-over things that they wanted to do differently without the whole legacy baggage that kept them from doing that on OSX. In many ways, iOS is the more modern of the two – I wouldn’t say ‘operating systems,’ but the APIs are certainly more modern in a lot of places. There are things on OSX that are just more difficult if your coming from an iOS background you're sometimes left thinking, “Man, if I were in iOS this would be super easy, but it’s not so easy on OSX.” Fortunately there are also a few places where the opposite is true. OSX still makes things easier than they are on iOS. I'm not exactly sure where to start ‘cause there are quite a few differences. BEN: How about just the, maybe the [inaudible] example. The first thing I notice when I create a new Mac app is I'm used to just getting a view controller for free and that is kind of absent. You got a .NIB and that gives you a main window but there's really nothing else it gives you, right? ANDREW: Right. Well that's actually a great place to start. So on iOS, if you’ve done iOS programming, you know that UIViewControllers are sort of like the main class, almost, in iOS. Every single time you have a view onscreen, it has a UIViewController controlling it. On OSX, there is actually an NSViewController class, but that was introduced in 10.5, so relatively recently in the history of OSX, and what that means is that you can write an entire app without using NSViewController. It’s not sort of the vital class the UIViewController is on iOS, and that sort of gives you a lot more flexibility in terms of how you structure your application, but these days I've actually started using NSViewController more like UIViewControllers used on iOS. So I do tend to have an NSViewController – not for every window on-screen, but for every sort of logically-grouped major view in my window. An NSViewController does do the same sort of thing as UIViewController but it’s not nearly as full-featured, so really, it knows how to load a view from a NIB and do the memory management of outlets and that’s kind of about it. It doesn’t have all the convenience methods that you can override for view; it doesn’t even have ViewDidLoad but like ViewDidAppear, and obviously rotation methods don’t apply. Another thing to know about NSViewController is that it’s not in the responder chain. So unlike UIViewController you can’t implement a responder chain or methods that you expect to just be called by the responder chain being walked there. BEN: So if you wanted to have, say, a blue box that you – I don’t know if that would just itself be an NSView or whatever – and you click and drag on it, you'd actually have to put the mouse handling code in the view? ANDREW: That’s correct. BEN: And decide to bubble it up to the controller via some sort of event or delegate system? ANDREW: Yeah, that’s exactly right. In NSView, you have the same kind of event handling method you'd find in UIView. Of course, there are mouse and keyboard handling methods; they are more important than the touch handling methods, although there are also touch handling methods because we have these multi-touch track pads and such on modern Macs. But you're exactly right – those have to be implemented in NSView and if you want a responsibility for those to be taken over by the controller, it’s completely up to you to figure out how you wanna pass those up. Typically, I do that by making an NSView controller the delegate of its view. You create a custom view, a custom delegate protocol to pass those backup and do whatever it is that needs to be done with them. BEN: I think that’s not necessarily a bad thing and I think it was kind of a point of confusion when I was learning iOS that a few controllers would just magically get touch events. ANDREW: Right, and you have to – I mean, it’s not magic of course, but I'm sure it makes a lot of sense conceptually unless you understand the responder chain because the touch of course is happening conceptually on the view, on the screen, right? That’s the way it’s always been on OSX and in fact, like I said earlier, you don’t actually have to use NSViewController at all, if you don’t want to. The sort of the old way things were done was to have views handle all of their touch handling logic and user interface stuff all in the NSView subclass. You’ll still find a lot of code that’s written that way. And in fact, like you said, if you just create a basic Mac app from the xcode template, you don’t get a view controller at all. And actually that kind of annoys me, because they stuff everything into the app delegate, which we’ve all heard talked about before even on iOS, but it kind of encourages especially new people to fill up their app delegate with all of their program logic and factoring all that out is completely up to you. The template doesn’t even sort of guide you towards a better approach. So I think a discussion of NSViewController leads to another class that is pretty important on OSX that doesn’t really have an exact counterpart in iOS but that’s NSWindowController. I guess, in some ways, NSWindowController’s sort of more like UIViewController than NSViewController. It’s like UIViewController because typically, again, you don’t actually have to do it this way but it is fairly common because NSWindowController has been around for a long time. But you'll typically have an NSWindowController that controls each window on the screen, and a window on the screen is kind of like UI window except that you can have as many as you want – your application is not limited to one window at a time. But NSWindowController handles loading from a nib and memory management and has windowDidLoad that you can override and it has methods to close the window and show the window, that kind of thing. So that actually becomes a good place to put normal controller kinds of code that are relevant to an entire window. BEN: And so a window would be composed of views, and would you have the same sort of window controller containing a child NSViewController? ANDREW: Yeah, that’s up to you again, because there's a lot more flexibility, but that’s typically how I do it. Typically I’ll have an NSWindowController and then it has a single content view that contains all the subviews for that window. I generally actually break – depending on the application of course – but if it’s a fairly complex application, I’ll often break the main window’s UI into multiple NSViewController managed views. OSX does not have the parent-child ViewController stuff that iOS has, so if you're gonna – I like that paradigm, but you have to do that yourself. So it’s your job to manage adding the child ViewController managed views to your main content view and removing them as appropriate and all that. You don’t have any of that parent-child hierarchy management stuff built in [inaudible]. BEN: Got it. What about – I know that NSViews are not layerbacks like UIViews are and in iPhone you can change which layer class you are and you can just assume that there is always a layer. How is that different in Mac programming? ANDREW: By default, an NSView is not layerbacked at all. Unlike the UIView where they always have a layerback [inaudible] doing their drawing, NSView by default does not have a layer but you do have the option to make an NSView layerbacked. There's also a second kind of layered view that is not on iOS at all and that’s called a layer hosting view. I can talk about that in a minute, but a layerbacked NSView is a lot like a UIView and that it always has a layer and you can change the class of that layer and set the same sorts of properties on the layer that you would set on UIView. Of course, the methods to do that are not on NSView, so you have to access the layer directly. There's no setBackgroundColor on an NSView, for example; but otherwise, that’s fairly similar. It is important to keep in mind, though, that core animation was tacked onto OSX, in 10.5. Unlike iOS where it was there from the very beginning and a lot of the very foundation, a lot of the UIKit stuff, it depends on core animation – that’s not really true in AppKit, so it’s a little more of an afterthought; not quite as extensively used as you would use it on iOS. BEN: Another thing I remember reading about, I started off learning objective-C through Aaron Hillegass’ Cocoa Programming for Mac OSX, I think the third edition book, which is really excellent, but at some point I realized I was learning – I sort of [inaudible] off that book and start practicing iOS because the two were so different. I remember the biggest difference that I first noticed was the book used bindings a lot. I don’t know if this is just my experience with doing this sort of thing with visual studio in the past and my utter hatred of, sort of, magical connections that make forms over data really easy, but a complicated app’s a lot harder. And so I wasn’t sure if anybody really used bindings, and I was kinda glad that they weren’t on iOS because it meant that things were a little bit more explicit. What I mean by that is if you have something like if you have a converter or application that converts units from one format to another, so you have °F to °C, and when you change one text box then it automatically changes the other one – things like that. Is that something that people use? ANDREW: Right, well I can only kinda speak for myself, but I really like bindings. I've been using them since I started doing OSX programming when 10.3 was the current version and that was also the version that introduced bindings. They’ve always been around, but they were certainly new when I started and I really liked them; I used them quite extensively. I know there are people who don’t like them for various reasons, but they are certainly one of those things that has a learning curve associated with them like core data or something. But to me, the effort to learn pays off in much faster development – in certain cases. I mean, you're right that if you do anything too crazy, you end up hitting into their limitations but – something like a unit converter like you described is certainly possible with bindings and I might very well do that with bindings, if I were doing that. BEN: One of the things that I don’t like with that type of system – not that I necessarily don’t like but certainly is a drawback is when you're debugging something that is going wrong, you can’t necessarily put a break point on that. Or maybe you can, but there's just no code to look at. It’s very difficult to see like what is happening in here. It may very well be that you're just opening up a NIB and you accidentally fat finger a checkbox somewhere, or one of the keypads somewhere and just – stuff doesn’t work, you know? It just seems like that is a less favorable debugging scenario than a compile error, for instance, or something where you can actually set a break point that’ll be like “what is the value at this point?” ANDREW: Yeah, I think you're right. I think maybe for the benefit of our listeners we should explain what bindings is because if you’ve never used, if you’ve never done OSX programming, there's a good chance you haven’t hit into them. The whole idea of bindings is that you can have something in your model and something in your view. Say, you have a string property in your model class and you have a textbox in your view. And you just want, any time somebody types something into the textbox, that gets set in the string property and any time the string property changes, you wanna update the textbox, its contents. In iOS, everybody kinda knows how to do that; it’s not that complicated, but you do have to write some code in your controller to take updates from the property and send them to the textbox and vice versa. With bindings, you can set that entire thing up in interface builder and you don’t have to write any controller code at all. In fact, you don’t have to write any code if you have the string property in this textbox, you can hook them up with bindings and updates to one or the other will be reflected in the other magically. I think it’s important to know when you're dealing with bindings that they're actually not magic even though they seem that way. They're built on top of Key Value Observing and Key Value Coding, just like you'd expect. And in fact, those technologies were introduced when bindings came out to support bindings. And I think you're right though, that it can be more difficult to debug when you don’t have code to look at, that you wrote. But on the other hand, bindings, as long as you understand that it’s really not much more complicated than when you set up a binding, a KVO observance is being set up, if you look at error messages that you get out of bindings and know that you can often track the problem down fairly quickly. Because a lot of times the problem is, you enter, you mistype the property name, and so you're trying to set a property that doesn’t exist on Model Object or something. And you'll get an error message that tells you pretty clearly that that’s what's going on. So with a little bit of experience, I actually think debugging is usually not that big of a deal. There are, of course, trickier cases and you can get part of the way towards debugging those by doing things like creating a custom getter for your property or a custom setter and overriding that, seeing what the – when that’s being called or what's being passed into your setter, because those property methods do get called by the bindings machinery. JAIM: So what are some of the methods used for navigation throughout the application? Do you have something like a navigation controller? ANDREW: That’s another good question. No, a lot of those built-in UIViewController subclasses that are part of iOS that are used very heavily for creating your application’s user interface structure don’t exist on OSX. But there are some other ones or some counterparts that do exist. For example, you do have an NSTabView, which sort of serves the same function as the UITabViewController. It just has a bunch of child views that it can switch in and out of the TabControl at the top where you can make the TabControl invisible and do that programmatically. That’s actually sort of a big one for – if you want to do other kinds of navigation, like if you wanted to mimic iOS’s navigation controller, you would have to write that yourself or find a project on GetHub. There's nothing built-in quite like that. There are a lot of the other kinds of – I mean, there's an NSTableView, which is broad, which is similar to the UITableView, although it’s actually quite a bit more sophisticated in certain ways. NSScrollView is like UIScrollView, it’s hard to rattle them off the top of my head, but there are a number of those kind of classes that have pretty close counterparts and the APIs are actually fairly similar. If you work with UITableView a lot, you won’t be shocked to see how NSTableView works. BEN: I've heard that NSTableView creates cells like UITableView does, but these are laid out like a grid, correct? ANDREW: Yeah, that’s true. So NSTableView doesn’t just have rows; it also has columns and those columns are optionally re-orderable and you can sort by them and all that. So that’s why I say in some ways it’s more powerful. One more thing to mention about NSTableView that will sort of lead us into another discussion about one of the big differences between iOS and OSX is that there are actually two kinds of NSTableView: there are cell-based NSTableViews and view-based NSTableViews. Cell-based NSTableViews, which are the original kind, have been around forever. Those using NSCell to draw their contents, there's not a separate view for each row and column like you would expect if you were coming from iOS. And then there's a view-based NSTableView, which was introduced in 10.7, and that does use NSViews or they're actually NSTableCellView instances and there's one per row, and they’re handled there. There's a queue just like on UITableView where when they go off-screen, they're taken out of the view hierarchy and put it in this reuse queue --. Anyway, it works very similarly to UITableView if you're using a view-based NSTableView. BEN: When did that get introduced? ‘Cause I remember reading about the whole conundrum of ‘cells aren’t views’ and it’s kind of a pain in the neck. ANDREW: The view-based NSTableViews came out with Lion in 2011, so they're actually still reasonably new and with the slower adoption rates of OSX updates, there are still a fair amount of code out there that targets 10.6. But that’s kind of an important thing to note and that is, that NSTableView got this view-based TableView to get rid of its use of NSCells, ‘cause they're kind of annoying. But NSCell is still used pretty heavily in a lot of other places in OSX. For example, NSButton uses an NSButtonCell, which is an NSCell subclass, to draw itself. And if you're coming from iOS and you're used to making a custom button super easily like you can on iOS, you're in for kind of a bit of pain when you try to do that on OSX, because to create a custom button on OSX you actually have to subclass NSButton and NSButtonCell and override the drawing method. It’s a little bit of a pain, and I think especially when you’ve never seen NSCell before. It’s kind of hard to figure out what the thing’s for and why it’s there, and why not just have NSButtons be regular views that draw themselves. Anyway, NSCell is kind of a thing that a lot of Mac programmers will complain about a little bit. BEN: I know auto layout was available on OSX long before it was – or I guess maybe a year before it was on iOS. Is that something that you take advantage of as well? ANDREW: Actually, I have to admit that I've started the last five Mac projects I've worked on using auto layout and the problems that were in interface builder with using all the layout just annoyed me too much and I ended up turning it off. But as with iOS, they’ve improved that a lot on xcode5 so for the next project I start I do plan to use it. It’s essentially identical to iOS; there's really not any major differences. I think it’s a good thing, I just – well, everybody’s heard about the problems that existed with using auto layout and interface builder and how frustrating an experience that was before xcode5, so that’s why I haven’t used it. CHUCK: So Andrew, help us get a little bearing about the kind of ecosystem for the kind of developing on a Mac. So we’re talking Cocoa, right? Cocoa libraries? ANDREW: Absolutely. Yep. CHUCK: I talked to a lot of people who had been doing Mac development for decades, and a lot of what they're doing is C++. What are some older frameworks that people might run into? ANDREW: Well, I’ll get a little bit out of my depth here because I'm definitely a Cocoa programmer, but I think the biggest one to know about is when OSX first came out and they needed to maintain compatibility with these code bases people had that were for the classic Mac OS, they created a thing called Carbon. I believe it’s just a pure C API that could be used to quickly and easily pour apps over from OS9 to OSX and still maintain compatibility with OS9. And Carbon sort of lives on; it’s getting less and less important but it’s still not unheard of to run into some API that’s not really available in Cocoa and that you'd end up having to drop down the Carbon to use, but typically those are really small, like you might write five lines of code that use a Carbon API. In my experience it’s always ‘cause I'm running into a problem and I find a stack overflow answer or something that tells me to do that. I don’t know Carbon well enough to find those solutions myself, so it’s really not something that you have to worry about a lot anymore. Carbon is still around but it’s deprecated essentially; they never made it 64-bit compatible, which does not mean you can’t write 64-bit apps that use little snippets of Carbon, but you can’t write an entire Carbon app that’s 64-bit. Other than that, I think you're not likely to run into a lot of stuff that’s unfamiliar. Core foundation is around, of course, and that’s a C API but same is true on iOS, so you're not really anymore likely to use core foundation on OSX than on iOS and it has exactly the same API as it does on iOS. BEN: Okay. Now I’d heard that Carbon was not supported with the newest version of OSX is that – the kind of big thing, you can’t do a lot of it, but there's little parts that’s still supported? ANDREW: Yeah, I can’t really say exactly the whole scope of what's there and what works and what doesn’t anymore, but I know there are parts of Carbon that are still around and still used in a lot of apps and definitely still work. I think one thing that kind of points to whether Carbon should be used or not is if you try to go looking for documentation for Carbon, it’s actually really quite hard to find. Like if I wanted to learn for some crazy reason how to write a whole app in Carbon, I'm not even sure where I would start. I’d probably go install OS10.1 or something and play around on that. So, it’s really not something to worry about. BEN: Okay, so the objective-C, Cocoa stuff – that started with OSX? ANDREW: Yeah, well that’s actually interesting. I don’t know how many people are interested in this kind of thing, but I find the whole history – well I don’t find the history of things I use interesting, in general – but objective-C actually started a long, long time ago, in computer terms back in the early ‘80s and early to mid-‘80s and Next adopted it and that was Steve Jobs’ company after he was forced out of Apple. When Apple bought Next and decided to make their next operating system based on Next Step, they got objective-C that way. So, objective-C and the Cocoa frameworks actually have a 25-year history. The first Next machines came out in 1988, I think – that’s when Next Step came out, so we’re coming up on 26 years of those APIs. And they’ve changed a lot and matured even before Apple got them, but some of the fundamentals came from that long ago, and so that kind of helps explain why there are some of these legacy things like NSCell, for example, that really don’t make sense now or we’d figure out better ways to do them, but in the Next days they made sense for one reason or another. Often that can be explained by – a Next machine can be 25MHz with 16 [inaudible] ram or something, so performance was a huge bottleneck, even compared to the first iPhone, these machines were really slow. BEN: I remember reading a discussion about how terrible it’d be for performance if we had a 10x10 TableView and we had to create 100 views. We’d never going to be able to do that. ANDREW: Yeah, well that’s exactly why NSCell exists. That is a complete way of optimization so that you could draw what conceptually were a lot of views on-screen without hitting into a huge performance bottleneck. So when NSCell is used, especially in an NSTableView, there's only one NSCell that draws the entire TableView’s contents so you're not having to create an NSView which is relatively heavy and add that to the View hierarchy, then draw it. NSCell is a lightweight, quite simple class. CHUCK: Okay, so the NS classes, those come way back from Next Step --. ANDREW: Yeah, right. CHUCK: -- and introduced into kind of Apple world in OSX? ANDREW: Yeah, that’s absolutely right. NS is abbreviation for Next Step. JAIM: It’s like the Next Step developers were like, “Hey, we know what's going on here” and the Apple developers were like, “What is this? Madness!” ANDREW: Yeah, absolutely. BEN: I thought it stood for New Shiny. ANDREW: Yeah, right. No, it’s the opposite. JAIM: It’s old. ANDREW: Yeah, you're right. And there are some of those Next Step guys they're still kind of around. Wil Shipley comes to mind – he’s still a pretty prominent developer in the Mac and iOS, although he’s still mostly a Mac developer in the community. He started all the way back in the early ‘90s on Next and wrote some software that really was successful, and Omni group, which is a company that he founded – they were Next developers that came over and started doing Mac software after transition, but they’ve been around doing it for a long, long time. Even Keynote – I can’t remember the name of the app but Keynote really is an evolution of an app that started as a Next app. BEN: So I have a sort of a tutorial-type question. There are apps that I've seen that are highly, highly customized and there are apps that sort of take the traditional OSX look and feel. One app that comes to mind is The Hit List – have you ever played with this app? ANDREW: No, I don’t think so. BEN: It’s at potionfactory.com and I really, really love this app. It is similar to Things as a to-do list manager, but it just has such an attention to detail, I really, really like it. One of the things it does is it has this kind of – and this is pretty standard nowadays but there was like the left hand, I don’t know what you call it, like a TreeView? And then there's no actual slider, there's just a line in between the two, like the main content pane and the left side bar. I'm wondering how much of this type of application is custom. Is it starting from scratch, or can you take like the – I don’t even know what you call it – like UISplitter or something, where you have some notion of custom drawing. You know what I'm saying? I don’t know if my question is clear. I'm just wondering like, how would you build something like this or like Things, if you are more familiar with that app? ANDREW: So I pulled up a screenshot of The Hit List; I haven’t seen this app, but potionfactory has been around for a long time and I know about them; they're a great company. Anyway, looking at the screenshot – so over on the left you’ve got, you called it a TreeView, I think? That’s actually called an OutlineView in Cocoa terms, but there is actually a built-in class that does that and just by the look of this, it’s not heavily customized. That’s pretty much – what you see here is pretty much available with that built-in class. So NSOutlineView is actually a subclass of NSTABVIEW and has a very similar API but the difference is that it lets you have a hierarchy with collapsible folders and that sort of thing and it also does not have multiple columns. It might be possible to have multiple columns, I'm not sure; I've never actually tried that. Anyway, so that part is all basically built-in and as far as the splitter goes, that’s also a built-in class called NSSplitView. So the part of the UI that you talked about is not custom – you don’t really have to write a lot of custom code. You can get pretty much what you see there with just the standard built-in stuff. Looking at the app, there are some things in here that are definitely custom-code like the tabs at the top – there's certainly no fancy TabView like that. There is an NSTabView but it won’t draw tabs to look like that, so you're certainly gonna be doing a custom control for those. BEN: So would you be starting with NSTabView and then taking over drawing, or would you end up just writing it yourself? I mean, these tabs are kinda like Chrome, you can drag them, so I'm guessing that that’s just its own control. ANDREW: Yeah, absolutely. NSTabView is actually pretty limited. It actually brings up an experience that I had which is, the app that [inaudible] just launched a couple of weeks ago. It’s sort of main UI, there’s some tabs and we made a custom tab bar at the top that doesn’t look like the built-in one and that turned out to be – it’s not difficult but it’s a lot of custom code. If you wanted to do any of the fancy stuff like dragging tabs and being able to create new windows and reordering them, NSTabView doesn’t even sort of get you on the way to that, so you really will be just writing your own. And it’s actually something we’re thinking about doing for the next [inaudible] is writing completely our own core animation–based tab view that can do custom transition animation, all that kind of stuff, just because the built-in one is actually quite limited. Of course, as with iOS you'd look around on GetHub and Cocoa controls and see if you can find something somebody else has done that’s good, and oftentimes you can, but maybe not as often as with iOS ‘cause there just really aren’t as many Mac developers out there as there are iOS developers these days. CHUCK: Alright, well are there any other differences or gotches to writing Mac apps that we haven’t discussed, that somebody who’s familiar with iOS would run into? ANDREW: I think we’ve actually covered a lot of the biggest things. I think something that we didn’t mention that is not really a difference in the APIs, but it’s a difference in mindset is that when you're writing a Mac app, you should keep in mind that iOS has always been touch-driven, for very good reasons, and OSX is not touch-driven – it’s mouse-driven and always has been. You should keep those differences in mind when you design, say, you want to make a Mac version of an app you already have on iOS. Unless there's a really good reason or it really lends itself well, you really ought to rethink the UI when you do an OSX version and support the kinds of interactions that people are used to on a Mac instead of just directly coding your UI over. The reason people use Macs when iOS is still around because there are things that are still easier on a Mac with a mouse and keyboard, and you ought to make it so that your app takes advantage of that. You can make things smaller; you can make controls smaller than you can on iOS, since you’ve got a more precise input device; you can put a lot more on the screen at one time, and then of course, I think it’s really quite nice in a lot of ways that OSX runs on machines that are still much faster than the typical iOS device, so you can get away with really CPU or GPU-intensive things that still are really difficult on iOS. So I work on audio apps and it’s still true that for the CPU, I mean, the stuff that we do regarding audio – it’s just way easier for us to get that to work well on a Mac than on iOS, which is nice, but take advantage of that. JAIM: Yeah, developing for keyboard in mouse, it’s becoming a dying art. It’s not yet, but it’s on its way. You know, a very specialized app to doing it. Kids are coming up and having no idea why they can’t touch your desktop screen and do stuff. ANDREW: Yeah. BEN: That’s true. When you think about the minimum level of dexterity you would need in your fingers to operate a mouse and keyboard, kids probably don’t start getting interested in computers until probably three or four years old, because watching a two year old trying to use a mouse, it’s tough. My kids are four now, they’ve been using an iPad since they were under a year old. My son was able to figure out how to unlock the iPhone at about 11 months. To me, that’s amazing. He’s never known a non-touch interface, and so when he gets on a computer, it’s just a little bit foreign to him. It’s almost like looking at a telephone with a cord these days. Or a phone booth. JAIM: [Inaudible] interface. BEN: Yeah. Well, he sees that on my screen all the time so that’s not quite so foreign. But yeah, I mean, to me it is kind of amazing. The other thing that probably keeps me on iOS more than anything else, and this is true of iPad as well, is that [inaudible] way more choices and way more things to do and way more rope to hang yourself with. I know what good Mac apps look like, but I don’t think I'm good at creating them, or at least, in my head, just because there's so many things you could do. The way you lay things out, you have this ultimate flexibility, but unless you have a clear picture in your mind or maybe a solid designer who knows what they're doing – to me, it’s so much more difficult to design for than a phone that’s 320 points wide. There are only four places for buttons, so if you have six buttons in mind, you gotta start thinking of better ideas and those constraints, I find, are comfortable for me because it allows me to try to simplify in order to fit in that sort of screen real estate that we have. ANDREW: I think you're right. And there's also a lot more heavily enforced UI paradigms on iOS, so TableViews and NavigationViews and those things are so much more enforced by the frameworks that it’s easier to figure out. Well I basically know how this application’s going to look. And it fits into these paradigms, and I know how to do that, and it’s true, you have a lot more to come up with on your own on OSX, but I like the extra flexibility. Maybe it’s just because I started as a Mac developer before iOS and still do more Mac development than iOS development, but I feel much less limited when I'm developing for OSX. JAIM: Yeah, if you get extra pixels; put a button in there. And if you're on out, just [inaudible] the menu, you know? ANDREW: Yeah, absolutely. And I can add keyboard shortcuts. But you gotta be careful with that because you still wanna – some of the same considerations that you would have developing on any platform, you need to not go overboard. JAIM: Yeah, you can tell applications if they’ve been around for 20 years and haven’t got redesigned. ANDREW: Yeah, absolutely. CHUCK: Yup. Well, I hate to cut this off, but I know that some of us have some scheduling constraints, so I'm going to push this over into the picks. Ben, do you wanna start us off with the picks? BEN: So my picks are – well the first one is called Mastering Modern Payments. It’s an e-book; it’s really short, and it covers how to do Stripe integration for normals like Stripe stores, like single check-out forms as well as subscriptions. I've already done this twice and I still was able to pick a few tidbits of things that I should be handling. Anyway, it’s a good read, worth the $30, $40 or whatever I paid for it. So that’s my first pick. My second one is a fiction book. I'm trying to read more fiction; I'm just really slow at it, my mind tends to wander, so I'm forcing myself to read more fiction. The first one I got through these past couple of months was The Doomsday Key by James Rollins. So if you're into sort of fiction, or sort of problem-solving in the context of historical fact – I don’t know what genre I'm actually looking for – historical fiction, maybe? Sort of like Da Vinci Code-style books; this was pretty good in that style. And the last one is a video I just watched on – it was more about game development, but this guy was talking about the game feel. It was two things: one, it was a really good presentation in how little tiny details make a game feel so much more playable and fun and enjoyable, and I think the same concepts can be applied to app development. The other thing I liked about his presentation is the [inaudible] slides; his slides, so to speak, were actually playable versions of his game, and so he just advanced to the next evolution of what he added to the game, and he was just playing the game the entire time and advancing it, saying, “Now I'm adding a little bit of camera lag so it feels like the camera is dragging behind the player and all that.” So anyway, a really, really good presentation. I will link all those in the show notes. CHUCK: Awesome. Jaim, what are your picks? JAIM: Okay, last week we talked about MVC and how we kinda communicate between controller and model, and I didn’t know at the time but objc.io has a really good article on the topic. You can check out communication patterns that goes over how the different methods you can talk to have any [inaudible] talk to each other; KVO, notifications, delegation, blocks. If you can’t think for yourself but you can follow a flowchart, it’s got you covered. So if you wanna know which one to do, it’s got you covered. So, check out the communication patterns in issue 7 of objc.io. My second pick, you’ve heard about the land shark, right? “Don’t open the door for the land shark.” CHUCK: The logger? JAIM: Don’t drink that logger, either. Stay away from the land shark. A couple of days ago, The Snow Shark started kind of blowing up the twitter feed in Minnesota and I thought, “Oh, someone made a lil snow sculpture of a shark.” What I didn’t realize, it was 15 feet tall and it was done by a group of high school kids, so I thought it was pretty cool. We have the snow shark, so I’ll send the link to that. Go check it out. Those are my picks. CHUCK: Awesome. Andrew, what are your picks? ANDREW: My picks are kind of themed around our topic today. My first pick is FastSpring. FastSpring is a payment processor for digital goods, but they're used by a lot of Mac developers to sell their apps outside the Mac app store. I use them and I've used them for two years now, and having switched from my own solution that was based on, well, it was a PayPal-driven solution. They do a really good job. I've been very impressed with them in terms of customer support and the experience of buying something using one of their websites and so I definitely wanna recommend it if you wanna sell your own app outside the Mac app store. And then my next pick is just a little script that was released this week on GetHub. It’s called objc-run – objective-C run – and this is just a small shell script but what it does is let’s you run an objective-C .m file with a program in it as if it were sort of like a regular scripting language script on your command line. Objective-C is the language I work in the most, and it’s nice to be able to sometimes write just a little utility that will do something that some people might write a Python script or Shell script or something for but I feel comfortable doing that in objective-C and this lets you run your objective-C files as if it were a script. And then the last is – I actually gave a presentation about this topic we had today about Mac OSX for people who are coming from iOS at Cocoa slopes, which is a conference we had here in Utah a few months back. My slides and also some example code particularly were related to bindings on GetHub, so you can check those out. The slides have a lot of presenter notes, so make sure you open the presenter notes if you're gonna look at those. A lot of the information that I gave is actually in presenter notes. So those are my picks! CHUCK: Awesome. My picks are really simple. The last week I was in Disneyland, so I'm gonna pick Disneyland. I went to New Media Expo and I'm going to pick New Media Expo. And I’ll just put links in the show notes, you can go check those out if you don’t know what they are. Other than that, I guess we’re done with the show. Thanks for listening, hope you have a terrific new year, and we’ll catch you all next week. BEN: Alright JAIM: I’ll go jumpstart my car. [Chuckling] ANDREW: Good luck. CHUCK: Stay warm.