Debug is a casual, conversational interview show featuring the best developers in the business about the amazing apps they make and why and how they make them. On this episode Don Melton, former Director of Internet Technologies at Apple, and Nitin Ganatra, former Director of iOS Apps at Apple, talk about presenting to Steve Jobs, web vs. native, implementing gestures, the importance of affordances, and more.

• Subscribe in iTunes
• Subscribe in RSS
• Download directly
• Follow on Twitter

Show notes

• Debug 11: Don Melton and Safari
• Debug 39: Nitin Ganatra episode I: System 7 to Carbon
• Debug 40: Nitin Ganatra episode II: OS X to iOS
• Debug 41: Nitin Ganatra episode III: iPhone to iPad
• Debug 16.1: David Gelphman on Apple, Core Graphics, and AirPrint

Guests

• Don Melton
• Nitin Ganatra

Hosts

• Guy English of Kicking Bear
• Rene Ritchie of Mobile Nations

Transcript

Guy English: "Debug" is brought to you today by Automatic, your smart driving assistant on your smartphone. Now, Automatic usually costs around 100 bucks, but with this special offer Debug listeners can get it for 20 percent off. Just $80. Go to automatic.com/debug, and once you get you'll save hundreds on gas, you'll never forget where you parked, you'll diagnose things like engine light warnings, you'll get help in a serious crash.

It works on both iPhone and Android, ships in two business days. Try it out. If you don't like it, you have a 45 day return policy with free shipping. Just go to automatic.com/debug. You'll find out if you brake too hard, if you speed, if you're accelerating too rapidly, and it'll keep timelines of your trips. It'll just make your car as smart as your phone. Once again, automatic.com/debug.

Don Melton: I've opened a bottle of 2011 Old Vine Zin Gnarly Head and I'm going to town on it right now.

Guy: Is it from a boxed on?

Don: No, it is not from a box. I'm not an animal.

Guy: Speaking of box, I opened up a brand new box of Black Box Merlot. That's what all the drinking from. I am an animal, I guess.

Nitin Ganatra: I guess you're supposed to be drinking Serena. I mean this is so off topic.

Don: I don't blame the box because I can't fit the fucking boxes in my wine coolers. I have a couple of wine refrigerators. I'm a serious alcoholic.

Guy: I have one of those too. I'm an ignorant and watch this, I'm about to prove it. Are you supposed to put red wine in a wine refrigerator?

Don: You're not supposed to put it in the normal temperature at wine refrigerator's command, but I have one that's turned up to the normal temperature for white wines. The other one which I turn much farther down because I like a little bit of coolness on the red wines especially during the summer here because there's nothing worse than having a wine turn on you. My wife and I keep some of our reds very, very slightly chilled.

Nitin: I love that this is drinking with Don and...

Guy: That's what we were talking about today, right? I thought...

Don: I thought it was all about wine.

Nitin: Nasty, sure.

[laughter]

Guy: Now, tell us about your yacht problems.

[laughter]

Nitin: Yeah.

[laughter]

Don: No, no. You know what? My first boss at Sun Microsystems had his own racing yacht, more of a sloop really. We used to take it out for team meetings on the Bay in San Francisco. I actually leaned how to boat that way. I said, "Well, this is pretty cool. You know, what's it like having a boat?" He said, "Imagine wearing the finest Armani suit, standing in a cold shower, and shredding $100 bills."

[laughter]

Don: "That's what it's like." So no boats, another house.

[crosstalk and laughter]

Rene Ritchie: Firm no boat rule.

Don: Another house is better enough. No fucking boat.

Nitin: [laughs] "No fucking boat" should be a T-shirt. I know.

[laughter]

Don: I know. Have you seen that Internet man with the cat that's wearing the suit, sitting at the table?

Nitin: Yeah.

Don: I should buy a boat.

Rene: It reminds me of "The Usual Suspects."

Don: That's so not me.

Rene: No fucking coke on that boat.

[laughter]

Don: Yes. You know, for some various reason, I watched "The Usual Suspects" again, because I've seen it like 50 times, a couple of weeks ago. I noticed somebody in there who's in the cast that I never noticed before. Did you know Clark Gregg is in that movie?

Rene: I did not.

Don: Yeah. He plays the doctor. I've seen that damn movie like 25-30 times and never noticed that.

Guy: Who is Clark Gregg? I'm sorry.

Nitin: He's Agent Coulson in all of the Marvel movies.

Guy: OK.

Nitin: He's been a director. He's actually in way more places than you would think he would be.

Rene: He's multi-talented.

Nitin: Yeah. He's one of those guys. He's so unassuming looking that you just don't notice, and turns out he's in it.

Rene: He never really used an iPhone, but he's done pretty well for himself.

[laughter]

Guy: I suppose. Yeah.

Don: Did we, unfortunately, start to show already our [indecipherable 0:04:49] ?

[crosstalk]

Nitin: I don't know.

[laughter and crosstalk]

Don: I certainly hope not, because I don't want anything...

Rene: I'm going to edit it in the whine stuff at the top, and then I'll go to the show.

Guy: Whining about your house?

[crosstalk]

Don: Yeah. Whining about my house. You know that horseshit.

[crosstalk]

Guy: I hear you.

[laughter]

Don: Which is, again, why I'm drinking wine this time of the day. But, of course, as a lesson I learned from a friend of mine at Adobe years go, when I went into his office early the morning, we were at a big bug run, and I was trying to describe...I was on the Illustrator team, but he was the lead engineer on Photoshop.

I was on loan to try to help them make a deadline. I went in to talk about a bug. He looked a little bleary-eyed.

I was talking about the bug, and he was nodding and stuff. He opened up the drawer to his desk, and he pulled out a bottle of whiskey. He gestured [indecipherable 0:05:43] with it, and then he said, "Shot?" I said, "You know, Mark, it's like 9:30 AM in the morning." He goes, "I don't drink by the clock."

[laughter]

Don: I've always tried to live my life by that piece of advice. Don't drink by the clock.

Nitin: It's very healthy.

[crosstalk]

Guy: That's right. It is.

Rene: I thought we would get halfway into native versus Web apps before you guy started drinking.

[laughter]

Nitin: I'm feeling like I need to catch up over here. I've been accelerating right now, because it sounds like Don is ahead of me.

[laughter]

Don: I'm already half in the bag, Nitin.

[crosstalk]

Nitin: Maybe I should slow down.

Don: Nitin is on Merlot, and I'm drinking Zinfandel like an animal.

[crosstalk]

Rene: Then again, you guys are supposed to be on Cirò by now. It's 10.10. It's a thing of the past.

Don: Yeah, yeah.

Nitin: Yeah.

Rene: That's a wine [indecipherable 0:06:34] .

Don: Nitin, do you remember all the actual wine code names with the actual cat code names with the actual release numbers? Because I, thankfully, have forgotten all of that now.

Nitin: Oh God, no!

[laughter]

Nitin: I'm sure I don't. Let's see. I'm even trying to figure out now which one was Merlot. Was Merlot tiger?

[laughter]

Don: Huh?

Nitin: I think Merlot might have been tiger?

Don: It might have been a tiger.

Nitin: Yeah. Gosh, I don't...

[crosstalk]

Nitin: There we go.

Don: Rene just popped into Skype...

[crosstalk]

Rene: Tiger power PC was Merlot.

Don: Yeah.

Nitin: OK.

Don: Mountain lion was Zinfandel. Mountain lion was the last one I worked on, but I left before it shipped.

[crosstalk]

Nitin: OK. You know what I'm doing right now?

Don: What?

Nitin: I saw the notification show up on the side, you know, the link that Rene just sent, and now I'm clicking around like a moron trough the Skype UI, trying to figure out how to get to the...

[crosstalk]

Rene: No, they hid it. It's the latest version hides comments.

Nitin: It's ridiculous.

[crosstalk]

Don: The worst thing, Nitin, is that every time you initiate a voice call, you have to go in and figure out how to show the goddamn chat section again. You cannot make that sticky. It's like they keep redesigning the UI to piss you off.

[laughter]

Don: Like I told you before the show started, my sister screams at me sometimes, "Goddamn this free software."

[laughter]

Don: She says I have to keep it in perspective.

Nitin: It's funny. We've been working in the computer industry for so long. I kind of feel like we've been through so many years of working with GUIs and things like that that, at this point, you should be able to figure out any GUI, and you should be able to figure out any app, and things like that. You just run across these apps that are just baffling. On the one hand, I feel like, "Oh my God."

Don: Like Microsoft Word or something? [laughs]

Nitin: [laughs] Yeah, baffling like Word. It's these esoteric apps like Word. But, on the one hand, I feel embarrassed like, "God. Well, if I can't figure this out, what..." Somehow my mom can figure out Skype, and I can't figure out the UI.

But, on the other hand, I'm almost a little bit proud of the fact that I sort of feel like I've kept a little bit of the normal personness that helps kind of guide whether a UI is usable or not.

Don: Yeah. I know exactly what you mean, because a couple of weeks ago, and then it happened to me today, as you all know from the email I sent this morning dealing with freaking Ikea and people who can't do math, I had to scan something in on the Mac. This is the Mac. This is the operating system that we worked on together. I had to use the scanning UI.

Rene: You poor bastard.

Don: You poor bastard is exactly right. It is the worst goddamn user interface ever.

[laughter and crosstalk]

Nitin: You talked about "In preview"? The menu...

[crosstalk]

Don: No. Well, yeah. How the hell do you...? You either go into "System preferences," and you go to the printer icon, and you click "Scan," and you say "Open scanner," or you to go Image Capture and do it that way. Either one of them are just the same path to death. I mean, it's just the worst god damn UI to try to figure out what it's doing...

[crosstalk]

Nitin: You know what though?

Don: It's been like that for years. What's worse is if you ever try to do something like this on this on Windows or worse you had Linux -- oh, shit -- then OS 10 is like a breeze.

Nitin: I was going to say was the only thing that's worse to me, I'm now used to the UI within Preview, if you go on the file menu, kind of close to the bottom, there's the bring up the scanning UI menu item there. At this point, it's sort of like living to a dump. I'm kind of used to it.

Don: [laughs]

Nitin: The problem I have is, that UI is just fantastic compared to any and all printing and scanning UI that's been developed by printer and scanner manufacturers. If you want to see just trash, that's almost the definition of it. If we're recording, please no disrespect to anybody who's developing printing and scanning software...

[crosstalk]

Don: But seriously get your head examined. That's what you're saying. [laughs]

Nitin: Yeah, it's awful. I mean, it's so bad. It looks like it still uses Quick Draw to this day. I never see non anti-alias text until I'm going, ironically, into printing and scanning software.

Don: [laughs] It's like a flashback to your carbon days, right? [laughs]

Nitin: Exactly.

Don: You were swallowing Merlot right then, weren't you? [laughs]

Nitin: I literary actually was going. [laughs] How did you know that?

Don: It's the power of technology. Were you in the exec review when I think it was -- I can't remember whether it was Forstall or Josh -- somebody lost in some exec review, and we were talking about, I think it was AirPrint when we were first trying to do it on iOS and dealing with the printer manufacturers and stuff. The execs were just incredulous about things that were basically impossible because these people were so entrenched in doing it the stupid way.

Nitin: I remember that.

Rene: The printer people?

Don: Oh, yeah. It's just awful.

Rene: [laughs] Someone just flipped out of the industry-wide stupidity.

Don: One of the reasons that printing at iOS, which is still not great, but one of the reasons I think it's actually better -- well, certainly simpler -- than it was 10, you can't scan with any device. There's no solving for that. One of the reasons it's a little bit better is they spent so much effort to work around those things. God, people were not happy when they found out there is limitations and things like that.

Guy: We had David Gelphman on the show a while ago. He...

[crosstalk]

Don: Oh, God. [laughs] What did he say about this?

Guy: The same but he's not as colorful as you.

[laughter]

Guy: At least, publicly. [laughs]

Don: Nitin knows this in meetings. I was actually not the most colorful person in the room depending on the meeting. Although, I was usually second or third -- it's usually second or third -- but not always the most colorful in terms of obscene and things like that.

Nitin: I think that's probably smart, right?

[laughter]

Nitin: You don't want to be the most colorful. You kind of want to sneak in behind your Forstalls and your...

[crosstalk]

Rene: Anyone with an S or C in their title.

Nitin: You're kind of going out on a limb if you're the most colorful unless you really know where everybody stands in the room. It's probably better to be a little more subdued and let people who can take the luxury of being that colorful to take that luxury.

Rene: That's true. Yeah.

Don: Rightfully so. I've been in plenty of meetings...

[crosstalk]

Nitin: I was just going to say that that's the thing is, a lot of times, the most colorful person in the room is right. They're absolutely right. They're talking to somebody else who is, maybe not necessarily defending even something they've developed, but they're just sort of describing how the world works. It could be the printing and scanning ecosystem.

The poor schlub who has to sit there and describe all the limitations around printing and scanning, and why HP wants things this way and Brother wants things that way. The Scott or somebody in their position, they don't care. They're just going off on the person, on the messenger, right? They're kind of shooting the messenger in a way, but they're absolutely right. It's just not something that the messenger can do much about that.

Don: It's not certainly productive, but it's certainly fun to watch if it's not you. [laughs]

Nitin: Yes. That's the other part. Part of it is you're thinking, "Thank God, I'm not defending or describing the printing ecosystem to Forstall or anything like that."

Don: By the way, this is something that I was actually going to reminisce with you about today, which is the whole concept of meetings at Apple. I don't think a lot of people on the outside realize what these are like. We used to complain all the time about boring meetings. Seriously, most of the time what you really wanted was a boring meeting because that means you didn't get shit on because it was boring.

The interesting meetings, what you never wanted to be was the focus of an interesting meeting for exactly this reason. That was just not a lot of fun. How many times did you demo for Steve and things just didn't quite work out exactly as planned?

Nitin: Oh, OK. Let me see.

[laughter]

Nitin: I imagine you did the same, exact thing, right? Was when you know you're demoing for Steve, you run through it. You rehearse that technology to the hilt to the point where you know all of the limitations. You want to be so prepped and so ready.

Often times when you're demoing something, I mean, it's shitty, pre-release software so it's going to be buggy. You're really just trying to get the point across of either progress is being made or...

Don: It's something you would never give to end customers.

Nitin: Exactly. Let's see. I think I can count on one hand certainly and probably on three fingers the number of times that I had demoed just run into a problem that I didn't anticipate or that I didn't know about. What I always found anyway -- and I'd love to hear what you thought about this too -- was if I was demoing something and if I knew that there were just to fall off a cliff here, please don't tap that button because it's all fucked up. It's just never going to work.

Most of the time, the other thing that would happen is Steve would allow you to demo something to him for about three seconds before he snatched the mouse or snatched the phone out of your hand and started dicking around with it himself. So, after the first one or two times that that happens, first and foremost, Greg Christie taught me this one, is do not fight him. Don't try to fight him and get the mouse back.

Don: No, no. It's like I wrote in my retrospective on Steve, and remembering Steve, if he wanted to drive the demo machine, then by God, you let him fucking drive.

Nitin: Exactly.

Don: Jesus, that was the kiss of death. Scott explained that to me years ago.

Nitin: OK, yeah. I always knew that that could potentially happen, so you build that into your preparation as well. OK, there are all the things that I really want to get across in this demo, and there are all the things that I think he really cares about, and then there are the cliffs. That, if you hit this button or if you rotate on this view, or if you do something else, it's just going to be all fucked up. If we can't, during the scramble to get things working well enough to be demo-able, if we can't get these things fixed, them at the very least I want to know about them. I want to know about them so they're not a surprise to me when I walk into that group.

Don: Oh, yeah.

Nitin: At the very least, if I know about it, and if it's not a surprise to me, then I can speak to it and I can at least let Scott, and Steve, and Phil, or anybody else who is in the room, let them know that we're on it and we know what we're demoing here. We know the limitations of what we are showing you, we are not just waltzing in with a half-baked piece of crap and saying "Oh well, maybe it works." Oh, look at that, we ran into this problem, right?

I want to know all of the things that are going to go wrong. So really, when I am thinking about it, it must have been three. I can't imagine, I don't think it was more than three times where I ran into a problem, and I didn't know that it was a problem before walking in.

Maybe that's just because we were demoing things on iPhone, we were demoing things from so early on that I think not even Steve had an expectation that things were going to be working well. So I was able to, at least, I could talk around the fact that, yeah, if you're looking at this address book review, please don't hit edit to bring up the edit the photo you like, because that's just all broken right now.

Don: Well, you know what we did? We cheated sometimes, we would disconnect things, UI elements so they didn't work. It was like a busy box for toddlers, just poke at it and it doesn't do anything, because not doing anything was better than a crashing, because that leaves a sour taste.

The big thing, I've experienced several times where software crashed, you have to prep for it and you have to warn them that that's going to happen. Whatever you did, you never made excuses for it or blame anybody else.

Nitin: Yep.

Don: You just got your ass handed to you if you were going to do that. I watched somebody make that mistake one time, and you know how when you're in a room, and it's really super awkward, somebody has said something stupid? This was much worse than that, much worse. I do not recommend it.

No, I had, I think it was only like you say, one or two times where something happened and my people didn't warn me about it, or I didn't know that that could happen. I've certainly had other things where we've had misbehaviors, or we had the rare crash, but I knew those things were possibilities going in.

My people learned that one thing that I disliked most of all as a manager, and that was to be surprised. I just fucking hated surprises. Not only that kind, but all kinds. I always told people, if you're going to commit to doing something, I'm going to hold you accountable to that. But if you're not going to make it, do not tell me at the last minute. You better warn me ahead of time, because I do not like surprises, because first what's happened is Scott's going to hand me my head on a platter, and then I'm going to go looking for yours.

That's another reason why that was so rare. But the other thing you said was preparation. I look at others, and this was up and down the line, by the way. Preparation for things at Apple, Scott was probably the most prepared person I ever met in my life. Remember his briefing books before the Monday morning meetings, and how much? It's like I wrote that blog post a couple years ago, about after retiring, how Sunday night is a work night for everybody at Apple.

Nitin: Right.

Don: Because it's the exec meeting the next day. So, you had your phone out there and you are sitting in front of your computer. It didn't matter if your favorite show was on.

This was especially worse after the Sopranos ended, because for a while there, you could count on the hour that the Sopranos was on, that Scott wouldn't but you, because he was watching the Sopranos, and that was your reprieve. You could go to the bathroom, you could have a conversation with your family, whatever.

Scott was a late night kind of guy. He was not a morning guy at all, he was a late-night guy. You were basically on until two o'clock in the morning. How many times were you fielding emails from him at 1:30 or 2:00?

Nitin: Actually, that's the interesting thing. The emails that I got, and maybe we can piece together the way Scott actually worked on Sunday from this. I remember, my emails from Scott started about 11 AM on Sunday. If they didn't start at 11 on Sunday, then I always felt, he must be doing something fun today. Or there must be some family get-together or something like that.

Don: Oh, really? Because I used to get the stuff from Bertrand early Sunday morning, and I didn't start getting the stuff from Scott. It was random through the day. But he would always panic at the last minute.

I think part of the reason why I got the last minute things, probably that happened to Henri, Kim and I, because we reported to him directly. He just took an extra special joy in squeezing us. I don't know, and so he would usually, once he was going through Kim's status that she prepared, he would usually hit.

My line managers would hear it from him in the morning and I would get CCed on it, but I didn't get the direct stuff from Scott until usually late at night.

Guy: Isn't that a bit screwed up, talking to the people that report to you?

Don: No, no, I did the same thing. He would always CC me.

Nitin: It's funny, though.

Don: Somebody had written something in the status report or whatever.

Guy: Yeah, it lands on his desk. I guess that makes sense.

Don: Yeah, that's perfect. I never took offense of that at all, and certainly my managers, I certainly hope they never took offense when I would send something, because I wanted the answer right away, because I had somebody beating me with a hammer. I wanted the answer right away, so I would do the same thing.

Nitin: I think that that's another thing that's the difference. That was something that I definitely noticed when Steve Jobs came back to Apple and brought the new, next management along with him.

Before, Apple as a corporation was very hierarchal. VPs would talk to directors, directors would talk to managers and managers would talk to other managers that are may be employees. It wasn't until, this is what I noticed, it wasn't until Avie and Bertrand and Scott Forstall, and Steve, the new management team came in, that you would just get email directly from Avie. If Avie had a question, he was asking your directly. Or if Bertrand had some suggestions on how to implement something, he was just stopping right into your office.

Before the next buyout, it was a rare thing. At the very least, for me, maybe this is where I was in my career. Actually, I did hear this from other people too, that the old VPs, they didn't just turn up in people's offices. In fact, I remember...

Don: No, they were pretty absent. Darren Adler has told me about this many times, and so has John Norochi.

Nitin: Exactly, yeah.

Don: For me, he was insanely useful about learning about the old and the new Apple, because I was familiar with the old Apple as a customer and a developer at other companies, but I didn't start working for the company until 2001, four years after NeXT acquired Apple. John was tremendously useful to me in learning about that. He said the same thing, that it was like night and day.

I was talking to Bertrand about this. I don't know, we were sitting around, prepping for some, whether it was MacWorld or a dev conference. You know how you sit backstage and you're prepping for the show and we're just bullshitting?

I was asking him about the...which is a stupid thing to do with Bertrand, because you lean into something accidentally if you're not careful doing that. But he was a pretty nice guy. I was asking him about that, and he said "It's basically that way because everybody that's at NeXT still thinks of the company as being 50 people."

Nitin: Yep.

Don: They still, the entire mindset of everybody in the management chain was, this was a startup. So, it was very flat that way, in terms of communication was very flat that way. That was quite a bit unlike the old Apple, it was much more compartmentalized, I would say.

Nitin: I definitely remember, in field Apple, being terrified when...One late night, I was working with another engineer. We were trying to bring up the System 7 software on a brand-new piece of hardware that was being brought up. This VP kept showing up in my office every 45 minutes. "Is it working, does it boot yet? Does it boot? Can you get to the Finder? Where is it now?"

Don: Christ.

Nitin: And it was just, oh my God, what do I say? Then I look back at that years later when I go from answering some emails from Avie to talking with Bertrand about specifics around how something should be implemented, and just noticed that huge, huge difference.

You're right, I had heard the same thing from other people as well. The whole management chain, they still felt and thought of it as this very small company, where these communication barriers just don't exist. I think that was actually a very good thing. I mean, it's a little terrifying at times, when you get an email from somebody way up the food chain.

The first couple of times you get those emails, you're like, "Oh, my God! I must not be doing my job right."

[laughter]

Nitin: Or I must be a huge screw up or something is going wrong, but after a while you get used to it. Actually, I appreciated that. It opens communication...

[crosstalk]

Don: It's a real time saver. It creates a lot of clarity, and it actually makes you feel more connected to your management, which is a very, very good thing.

The problem they're having with it now, because I've talked about it...Somebody has been writing about this, in "New York Times," about Apple University. I saw some article fly by on "Hacker News" the other day. I usually don't click on those things because they just irritate me.

One thing we learned about after the fact is that, other than the United States Army, Apple is the world's largest functional organization. Apple doesn't have divisions. Beats may be the first one it ever has. I don't know how that's going to work.

[crosstalk]

Rene: There's this orphaned FileMaker somewhere.

Don: Yes, the orphaned FileMaker. That was a half-division, half something else, but...

Nitin: There was Claire's back in the day, too, right? I think you're talking about modern Apple, post-Steve Jobs Apple.

Don: Yes, modern Apple, post-Steve Jobs Apple. The entire company was run as if it was still NeXT, because that's the way Steve liked it. It's so ingrained in the culture now, they teach everybody that.

Part of Apple University is oddly spreading the Steve vision for how to make the company that he felt most comfortable with. You could argue that that's not necessarily the most efficient way to do it. It certainly goes against every business principles you've ever heard of, but it sure as hell has worked well for him!

Nitin: I have to say I wonder about that though. On the one hand, there's the organization, and there is the structure, and the lines of communication that Steve created, just the environment that he created and worked in. Obviously, there are great successes from that.

The other half of that is Steve himself. I wonder, can you really build an organization like that and have this collapsed hierarchy in some ways, not have these divisions, and have this very functional organization without having somebody a lot like Steve in the middle of it?

Unfortunately, I don't know enough about Tim Cook to know whether he thrives in an organization like that, but I'm curious and I wonder, can you actually build an organization like that without a leader who complements that structure?

Don: It requires a leader like that, who believes in that thing. You have to remember that for the last...how long has Tim worked there? It's 15 years now. He learned at the altar of Steve how to do those things and how to manage for Steve in Steve's absence.

A lot of people forget that. There were two fairly lengthy occasions where Steve was just not there and Tim was running the company. The other senior and executive VPs were doing their thing and everything happened really well. iPad basically happened when Steve was away, right?

Nitin: Yes.

Don: Steve said, "We're doing the iPad," and then he was off to...where was it, to get the liver transplant?

Nitin: Was that Tennessee?

Don: I think it was Tennessee. He was gone for months and months. It was Steve's vision to do the iPad, but the actual execution of it was all of us going about and doing a lot of the details ourselves. After that happened, Apple would never talk about that that's the way it had happened, on the outside.

After that happened, I wasn't worried about the company if Steve disappeared. I didn't expect and was very saddened by what happened a few years after that, but I knew that he company could function without him being their 24/7.

By the way, when you hear the so called apocryphal stories about Tim Cook coming to work at the wee hours and staying late, it's not just some PR person, telling you stories to make you think that Apple executives work really hard like that. They really do that. These people are nuts. They are there all the time.

I know that for Bertrand, certainly when he was there, you would never know what time of the day or night you would get an email from that man.

Nitin: He didn't really make it a secret, either. I don't think he slept more than three or four hours a night. He was pretty open about that. [laughs]

Don: Neither did Steve.

Nitin: It's funny. Now, when I look at executives at other companies, and I have no idea, really...because of where I come from and where I've done a lot of my learning, just looking at these executives, and looking at how hard they work, and how they're always on and always answering emails and always working, I only assume the same thing about other companies. I really don't know that.

Don, I completely agree. It's amazing, the number of emails...you've gotten these, too, right? You've got an email forwarded to you that's not to you, it's from Scott, but it's a forward from Steve and it's just coming at this crazy hour. You just know that there's this fire hose of emails that are just going out at 2:45 in the morning, and there are VPs or executive VPs who are scrambling to get answers.

That was just week after week, month after month over the years.

Guy: What would the people that reported to you guys tell us about reporting to you guys? Like the stories you were telling about your friends...

[crosstalk]

Don: That was wonderful, Guy!

Nitin: That we were the best managers they ever had.

[laughter]

Guy: OK. Problem solved.

[laughter]

Don: I have no idea what I told my folks. You found yourself doing this. If you forwarded something to one of your people at one o'clock in the morning and they didn't reply promptly, you got a little annoyed at them, a very tiny bit.

I told people, I explained to them. I've said this, Rene, I think it was last year we did when we were talking about hiring and stuff.

Rene: Yes, team building on Vector.

Don: At team building, I told new managers, when someone came into my office and said they wanted to be a manager, we're going to set them up to do that, I said, "How did you sleep last night?" They said, "Oh, fairly well." I said, "Good! Because that's the last one you're going to get, the last good night's sleep you're gonna get."

You know Ritchie, it's like that. It's a stressful job, there's a lot of responsibility, and you always have to be on. It's not that it's not fun, it's not that it's not fulfilling. It's not that you don't get to work around all these brilliant people, the bad side effect is they're all workaholic, psychotic brilliant people.

I've also tried to explain to people by using the analogy because they asked, "What's it like being around Steve, and Avie, Bertrand, Scott, Phil, and Tim?" I said, "You know, it's a lot like working in a nuclear power plant, but you don't get a suit, one of those protective suits. It's a lot of radiation and you either learn to survive it or you just die."

They are not mean people, they are not spiteful people, they're not trying to trip you up. They're just very intense and things emanate from them.

Nitin: They're intense, they're looking for the answers. You have the answer and you cannot get the answer to them soon enough. [laughs]

Don: [laughs] That is the best description to that I think I've ever heard. That is just so true. That's exactly it, what he said.

[laughter]

Nitin: The other thing was that when I would send these emails out to my managers...One of the things that I loved the most about managers that I think very highly of was there was this balance between shielding me from the bullshit as much as they could, or shielding me from whatever interference is happening, as much as they can, while at the same time informing me and letting me know what's going on and helping me, giving me all the information I needed to do as good a job as I can.

When these emails would come down...and Scott's looking for the answer. He needs the answer and it's 11 o'clock at night or whatever, and he needs the answer right now. If I can get that answer myself without going crazy, without making myself nuts, and if it means that I cannot bug one of my mangers in the process, I'll do that.

It's only in those cases. For me, I felt like it was not last resort, really, it was second resort, whatever that means. If I can get the answer myself, I'm going to do it and just shield my team and let them have a good night's sleep. If don't get that answer, or for whatever reason I just don't have that information, then I have to pass it down and find out that way.

Don: Yes. Sometimes it's like a roll of the dice. You get the email from your boss, from Scott, you would say something, "I'm not quite sure about this, and then you would reply or forward, include Scott so he would get a reply, and you would send it to one of your people. The death was if that person didn't reply until the morning. Then that person has a black eye and you've just made them look bad in front of your boss, right?

Nitin: Right.

Don: That's what I try to explain to people. It's very subtle. It's not required of you, but let's be honest, it's expected.

Nitin: Right.

Don: That's what you have to do. Still to this day, people ask me why I retired.

Nitin: [laughs] Really?

Don: There comes a time when I could actually enjoy Sunday evening in a whole new other way. You've done this. By the way, I'm sure, Nitin, you've been on vacation and taken your laptop, or taken your phone or taken your Pad. I don't know how many managers I've talked to or had really long conversations in email or on the phone, only to find out later on that they were in another fucking country.

Nitin: Yes. Oh, my God! Yeah, absolutely. To me, anyway, that's when it started to feel a little dysfunctional. It was when...

Don: A little?

[laughter]

Nitin: I'm on vacation, I've got my laptop, I'm going to have Internet access all the time, and I'm probably going to check my email four times a day. That's on vacation.

Don: Slacker! Four times?

Nitin: I know, exactly. If I went to Hawaii, I wasn't going to bring it to the beach, but you're right.

Don: But that's what you do!

[crosstalk]

Nitin: There were times when it felt like...It really did feel like...You say slacker and I know you're joking, but I think you're probably also a little serious.

[laughter]

Nitin: You do feel like a slacker if you only checked it four times. If you let an email go from your boss and you let that email languish for three and a half hours before you got around to answering it, "Oh, my God! Why am I here?"

Don: Yes, exactly. I couldn't do that. I had to do something right away. I said in the article I wrote for "The Loop Magazine," when Steve asked you a question and you didn't ramble or whatever you did, you didn't make up an answer...if you didn't know you said that you didn't know, and more importantly, you told him when you would have an answer.

Sometimes, when you would get these emails, what you would do is, you had to be blunt and say, "I don't know. Here's what I'm doing to get you that answer and when I expect it," you said as your kids were begging you to go out and see this nice sight in France, or wherever the hell you were at. I mean, that's just what you did.

I sometimes have young people come up to me today and ask me about being successful in this business. Part of it is just dumb luck, being in the right place at the right time. I thank God I listened to my wife when I took the job at Apple.

The other thing is you have to realize to really be successful to a sin. It's kind of a Faustian bargain you make, being aware you work. If you're not willing to pay that price, it's not going to come to you. I hate to say that. You have to ask yourself, "Is that really the way you want to live your life?" It's not like I recommend it, either. You have to think long and hard about that.

I know I've read a lot of studies on how this is a stupid way for the tech industry to function, and that's certainly true. This happens all over, and it's not just the tech industry. I think in the tech industry, it's like on steroids, just because of the nature of communication and what we tend to do.

Damn, there is no way you can cruise through a job at Apple Incorporated. That just does not happen for anybody I've ever seen.

Guy: We'll take a quick break so I can tell you about lynda.com.

Lynda.com is an easy and affordable way to help individuals and organizations learn. You can instantly stream thousands of courses created by experts on software, web development, graphic design, and more. I like to think of it as a repository for information readily absorbed by your brain. They have fresh content, new courses added daily.

It's easy to use, there's a high quality video tutorials. It's a great tool, there are searchable transcripts, playlists, certificates or course completion, and it covers the gamut from beginners to advanced. If you just want to learn a new piece of software, maybe you're an expert in other pieces of software, but you want to get better at a certain one, whether it's a hobby, or to improve your career, or to get a job you're looking for, they make all of it accessible and easy.

Twenty five dollars a month gives you unlimited access to 100,000 video tutorials. You can watch them on the web, on your iPhone, on your iPad, on your Android phone, but even Premium Plans, where you can download courses to your iPhone, iPad, or Android to watch them offline, and also download project files and practice along with your instructor.

Some of the newest courses they've added are managing your mobile photos, GoogleDocs and Sheets on iOS First Look, iPad for business, Up and Running with OpenGL, Creating Mobile Games with Unity.

One of the things about Lynda is that they have some of the best people in the industry teaching these courses, but they also get them online so incredibly fast. Apple introduces something new, chances are as soon as it is shipped, Lynda will have a course for you if not that day, then incredibly soon thereafter.

I like Lynda because everybody learns differently, and this is not often accounted for in traditional courses. With Lynda, you set your own pace. You can watch a little bit or you can watch a lot. You can watch it at home, you can watch it on the go. It really molds itself to the way that you like to learn best.

We've worked at a deal with lynda.com to provide you with a special offer to access all courses for free, for seven days. All you have to do is go to lynda.com/debug to try it out. That's lynda.com/debug. Believe me, your brain will thank you.

Nitin: When you were saying, "I don't know and when I will have an answer for you," for me, that was a turning point in when it became a lot more comfortable for me to interact with Steve and with other executives as well.

Don: Did you learn to do that? [laughs]

Nitin: I learned to do that? The first thing, the first step in that education of learning how to deal with someone like Steve Jobs is, "Oh, my God! I need to know everything. Holy shit! This demo needs to go flawless!" That's your first thought.

If you ask anybody who's rubbing two brain cells together, that's what they're going to strive for. They want this demo to be as perfect as every demo that Steve's ever given. If it's not, then he's going to rip your head off. Then the world comes crashing down around you.

When I got to the point where I understood that I could say, "I don't know, but I will have an answer for you by x," or "I don't know, but let me get that information for you and I'll have it back to you by this," and just knowing that that was a satisfactory answer in a limited set of circumstances, that became a kind of relief.

It was just that I don't have to know everything, I don't have to have all the answers right now. That doesn't mean that I can let up on the rehearsals that I do. That doesn't mean that I can't know every fucking bug that's in this busted piece of software that I'm going to show my CEO. That doesn't mean that I can't slack off on preparation or on understanding or things like that. It's just acknowledging that there is...

Don: What it means you can actually swallow your food now.

[laughter]

Nitin: Right. That I can get a couple hours of sleep at night.

Don: What it does is it puts off the inevitable stroke.

[laughter]

Nitin: It doesn't eliminate it. It just puts it off like you said.

Don: Yeah. Exactly.

Nitin: For me, anyway, that was a big turning point was when I realized...In some ways, it was calibrating with the executives and understanding where was the bar.

How much should I have to know and how much did I have to have off the top of my head, as opposed to, "I can go and get the answers, and that's OK." Part of it, probably, was just meeting with Steve enough, or meeting with Avie or any of these other execs enough that, hopefully, there is a little bit of trust built up on their side too, if you're not a bozo enough times.

Don: You got over that initial set of flinching that you did, right?

Nitin: Yes.

[laughter]

Nitin: Or you can hide the flinching pretty well. [laughs]

Don: You can hide the flinching. It was really good for you because you got to see the older Apple and you got to see the new Apple. You worked for Scott before he became a director, right?

Nitin: Exactly.

Don: I started working for him, it must have been one month after he got promoted. So it wasn't that far off that.

Guy: Did you guys ever work together, because you did Mail?

Don: We crossed paths an enormous number of times, sure.

Guy: I figured.

Nitin: One of the first times that I really remember working with you and with your team, Don, was when we were adding HTML composition to mail.app, right?

Don: Yeah.

Nitin: Just working through that. It's one of those things that, it sounds so easy. If you have [laughs] something...

Don: Were you working for Bruce then?

Nitin: No, actually I never worked for Bruce. I was managing the mail team.

Don: Yeah, you were [indecipherable 0:54:12] .

Nitin: Yeah, I was managing the mail team. At that point, I was working for Henri, who was, I believe, a peer of Bruce's.

Don: OK, right.

Nitin: I think that's how it worked out. Yeah, we put in HTML support. It's my understanding that was the first time, of course, that we added just the ability to edit a Web page, which is effectively what you're doing in email when you're composing using HTML. That was the first time that I got to work with a lot of the really great people on your team.

Don: That was a very good collaboration. I thought that worked out really well. Weren't you guys using the old HTML display?

Nitin: Oh, God.

Don: Yeah. [laughs] Oh, God, is a great way to describe that. Not to disparage that, but that's all that they had back then, right?

Nitin: Right.

Don: Was HTML display left over from NeXT or was that done from the acquisition? Even Bruce didn't know that.

Nitin: [laughs] That's a really good question. If Bruce didn't know that, then I feel a little more comfortable, because I managed mail after Bruce did.

[laughter]

Nitin: Before Bruce did again I guess. Anyway, I thought that it was...I don't remember if it originated at NeXT or if it was something newly developed at Apple after the acquisition. I don't think it was after the acquisition.

Don: I don't think so. But it was, very kindly, a big ball of snot.

Rene: Is that the one where it's the text view and you could feed it HTML? Is that what you're talking about?

Don: Yeah, that's essentially what it is. Basically, what somebody did...It is really a marvelous hack in a way. The text view in NeXT step is basically an RTFU, right?

Nitin: Yeah.

Don: It's a Rich Text view. Basically, somebody said, "Well, it's RTF. We have styling and whatever. We'll just overload it and make that HTML." That's not really the way it works at all.

[laughter]

Don: But they actually made this sort of work. You could do HTML3 sort of with this stuff. That's basically what they were doing early on before we went in there and started Safari and WebKit. That's what they were using. That was still better than the old...there was another HTML framework that was used for the original help system.

Nitin: Oh, shit.

Don: That was carbon-based. That was actually even worse.

Nitin: I don't remember what that was, but I remember when we talked about getting our act together as far as HTML rendering goes, that was just a non-starter from the beginning. That was so '90s...

Don: [laughs] Oh, yeah.

Nitin: ...the carbon-based one. I mean it was clear. Even the people who didn't...

Don: For all the fan boys out there wondering if I'm talking about Cyberdog, it was not Cyberdog-based. I get so many questions about, "Did you use any of Cyberdog?" No, Cyberdog was long dead by that time before any of these two frameworks were available.

Nitin: Wait a minute, Don. I'm sorry. I'm just putting this together. Are you the piece of shit who killed Cyberdog?

Guy: [laughs]

Don: Well, technically. No, no. Somebody else popped a cap in its ass before I ever got there. It took me several years to do it, believe it or not, but I killed HTML display. Bruce had wanted to kill it for so long because it was still used. I forget in what damn product. We couldn't seem to get off of that crack pipe, but I think it finally...

Nitin: Was it Sherlock?

Don: It was still in the system. No, it wasn't Sherlock. It was something. I'm the guy who also popped a cap in the ass of Sherlock, too, so we can talk about that later on.

[laughter]

Don: HML was still technically in the system because...I forget for what app but it was still in Tiger. Believe it or not, it was still a framework in Tiger. I think it died after Tiger. I'm not sure. You know Bruce before I showed up. He's the one who hired Ben Holler.

Ben Holler had tried to create a Web browser based on HTML display? Do you remember that? Charlotte was the code name for that project. Charlotte's Web.

Nitin: Yeah, I know Ben, and I remember [laughs] HTML display. I did not know that that was a project that was going. [laughs]

Guy: Wow.

Don: Scott decided that that was not worth pursuing, so that's why he hired me. When did you get disclosed, by the way, on Safari and WebKit? Because in the beginning it was only Scott's direct staff and Bertrand and Avie that knew about it. I actually don't know that Steve knew about it when I was hired. See, he didn't know who the hell I was until probably six months later.

Nitin: You know what's funny? I don't think I was disclosed until relatively late. I don't remember exactly when unfortunately.

Don: Were you working for Henri back then on IB or...

Nitin: I was working for Henri. Actually, well, when I started managing the mail team I reported directly to Scott. That lasted about seven or eight months. Just a few months later, I was managing the mail team and the address book team. Henri took over and was my manager as well, so I think he was doing AppKit, IB, and then mail and address book and syncing as well. Sync services.

Guy: He's phoning it in. [laughs]

Nitin: Oh, my God. Yeah.

Don: Slugging them.

Nitin: [laughs] Exactly.

Don: Let me tell you. Henri Lamiraux never phoned anything in.

Guy: [laughs]

Nitin: No. No, not at all. [laughs]

Don: Talk about your workaholic.

Nitin: To this day, I don't know how he did it, but somehow he managed the sync services team, which at the time just managing the sync services team seemed to me like beyond full-time job.

Don: Oh, yeah. [laughs] totally.

Nitin: I'm sure you remember this, Don. At the time every VP and their uncle had a syncing algorithm that they thought was just the bee's knees.

Don: Oh, Christ.

Nitin: And here they come with, "Here's how you need to think about synching and here's how you need to think about reconciling changes from two different sources." Remember the triangle problem?

Don: Henri, bless him, he had the patience of Job to stand there and listen and nod and be polite.

Nitin: He's a better man than I am, for sure.

Don: I had everybody and their brother telling me how a web engine should work, so I get a lot of practice of the same kind of horse-shit too.

[laughter]

Don: In fact, I talked to Henri about that one time in a meeting. [laughs] We were kicking back, relaxing, so, "You know, this is a nice meeting because nobody is telling us how to do our jobs in this meeting." It was basically just me and him.

Nitin: That's funny. I can't tell you how many people told me how phone apps should work and how an embedded system should work for modern smartphones as well. Literally, I was told in meetings, "You have no idea how embedded systems work."

The sad thing is, they were right.

[laughter]

Don: But it's not like they knew, either.

Nitin: Right. They knew how embedded systems worked 10 years prior, but they have no idea how they should work.

Don: We hired a big VP who supposedly knew how embedded systems work, Zackman. He was a nice guy, but he didn't work it out.

Nitin: I imagine it's an awful lot like politics or maybe like the NFL, where everybody knows how you should do your job better than you know. But they're not the ones who are...

Don: [laughs] I just realized, we're making Apple sound like a totally horrible place to work.

[laughter]

Don: It really wasn't quite like that, because people would run away screaming. But I never were one to [indecipherable 1:03:25] .

Guy: The funny thing is, I think we had a topic and no...

Don: We did?

Guy: I don't know, I thought so...

[crosstalk]

Guy: This is way better, just randomly... [laughs]

Rene: Nitin wanted to talk about gestures versus buttons for navigation.

Nitin: Did I? No, this is way more fun. This is great.

Guy: [laughs]

Rene: And Don mentioned WebKit versus UIkit.

Don: The thing is, that whole conversation is a non-conversation because people are always going to be surprised by...You guys were there at NSNorth, when I went off on that rant in my keynote?

When people ask me, "Should it be WebKit or [indecipherable 1:04:09] ," I would say, "What the fuck is the matter with you? You're asking the wrong question." It's such a stupid thing, use what's appropriate for the time in the right area.

I hate it when people decide, "I really like chocolate, so I want to smear chocolate on everything!"

Nitin: [laughs]

Guy: I've done that.

[laughter]

Rene: He's doing it right now.

Don: So it's a really stupid thing. At Apple, we try -- we didn't always succeed -- to be a little more thoughtful about these kind of things. Use the appropriate technology for the time and what's expected.

Why would you want to cut yourself off for something? People always ask me whether I'm excited about Firefox OS and Chrome OS -- that's a bunch of people who like chocolate right there.

Guy: [laughs]

Don: They're trying to make everything one flavor, and that's so goddamn stupid. Then I hear about last year, the Facebook app, they decided they had a really slow app and they decided the problem was that it was all HTML-based.

Then they rewrote their app. Hopefully, what they've learned after that is they just had a lot of really shitty code. It doesn't matter what it was written in.

If you re-factor and rewrite it, you're going to improve it. It has nothing to do with HTML. Also, people don't understand always what things are good at. If you're going for speed, if you're going for touching the hardware in very subtle, little gestures and effects, and you want to be in the cutting-edge, why the fuck aren't you writing in native?

But if you're going to render a whole bunch of content that you didn't have when you shipped your app or doesn't exist locally or can change dynamically like crazy, or you want to deal with all these complicated secure transactions, why the hell aren't you using the web engine for that part?

The fuck is the matter with you?

Nitin: [laughs] For me, internally, one of the apps that I never understood why it was developed as this native app and it was just staying on the native app route was Radar.

Don: You and me both.

[laughter]

Nitin: It was especially around the time when [indecipherable 1:06:58] , they had a new Radar update every other week, it seemed. Or maybe even every week. There was a new Radar that you had to download and install, and you get this big honking app, it's this 10 megabyte whatever-the-fuck-app.

Don: Guess what? It's a dynamic interface to a big database. Why the fuck weren't they doing that in the web? Then we would have other apps that I could never understand why they were web-based. I was flattered by this, but does everybody realize that the Dictionary app is WebKit?

Nitin: Really?

Don: Yeah. The fuck is that WebKit?

[laughter]

Don: There's no real compelling reason to me.

[laughter]

Don: It's not a native app, that's all the WebView.

Nitin: That's part of what our jobs were, Don, was...In a place like Apple -- and I'm sure that it's true with a lot of high-tech companies -- there are these groups of domain experts and there are these people, let's take the security team.

If you go and talk to them, they will let you know all of the dangerous things that are happening and all of the risks that we're taking with the UI as we have it designed today. If you go to the domain expert for something like security, and if they have their druthers, they would put up fucking alerts everywhere.

Don: [laughs]

Nitin: There were all kinds of authorizations and all kinds of bells and whistles that show you that what you're looking at is a native-hosted or a secured user interface, so that if you're typing in your password, by golly, that's the place you should type in your password, and everything is going to be OK for you.

The same is true with internationals, right?

Don: Oh yeah. I was there one time with Scott Forstall, he tore somebody on the security team, I forget what poor bastard it was, he tore him a new asshole for proposals of that kind. I don't think they ever let the security team talk directly to Scott after that.

Nitin: I think that's the problem, to be truthful. No disrespect at all to anybody on the security team.

Don: They knew what the hell they were doing.

Nitin: But I refer to them, to my own managers as the security Vulcans, because you knew that going into a meeting with the security team, you're going to get back this completely skewed view of technology and how users should interact with a given product. What you need to do, what our job, you, me, Scott, people who are actually tasked with building a product that people might want to pay money for was teasing out the most important aspects of what they were prescribing, and ignoring everything else. Or deferring or pushing back on other things, and looking for a better way to create an experience that was still appealing to users and, at the same time, was still very secure and very stable.

Don: Right. Go ahead.

Rene: The most secure thing is just never turn on your phone, right?

Don: Exactly.

Rene: Moving forward from that.

Don: You want people to use their devices. This was a great lesson in user interface approach that I found from all of these Apple executives, even Bertrand who wouldn't tout his own UI cred. He would always say that wasn't his forte, but he was a big believer...And certainly Scott was, Scott was a genius at this kind of stuff. We need to do the right thing for the users so they don't have to think about it. What's the path that we can go down, where they never even have to know about this.

Rene: Right.

Don: That was always a very, very hard thing in terms of security. To the security team's credit, we're making fun of them a little bit there, but ever time they started to really get this. I mean, they started to really understand this kind of thing and they were trying to do the right thing. It's like a lot of others, it took a while to move people in the right direction that way. I will say, believe it or not, the thing that helped the most was actually doing the iPhone. The reason it helped the most, and Steve mandated this, is I found had to be so damn simple. Mac OS X just owes a huge debt of gratitude for usability to iOS, because we would pioneer things on iOS, trying to make them as simple as possible.

In OS X we go "Oh thank God, let's do it that way here on the desktop and see if that works, let's see if people will buy that, too." Now that Federighi is in charge, I think they're trying to take an even more hold in charge of both, not just because he's in charge, but because he's in charge of both. They're trying to take an even more holistic approach to this. That's why I think the unveilings in June at WWDC were just so stunning to people, in terms of "Oh God, of course that's the way it should work." That's the path of least resistance, and I'm safe, and I get my pony.

But what people on the outside don't realize is how goddamn hard that is to do. I mean, there are just legions of people in offices with very hard walls, bashing their heads into them constantly trying to figure this out. It is really damn hard to do.

This is also why you can understand Apple's irritation and chagrin when companies like Samsung come around and just Xerox what they're doing. If you really want to piss somebody off, that's a good way to do it.

Rene, you wrote a piece, was it this morning? "Samsung Unveils the iPhone 5."

Rene: Yeah, the Galaxy Alpha.

Don: Yeah, you really want to irritate somebody at Apple, bring things like that up. Anyway, sorry I went on a rant.

Nitin: No, no, that was great. I completely agree, and that's the problem is that...Let's see, there are a couple things I wanted to say. One of them was, that was one of the things that I loved about working with Scott, or working for Scott, by default, if you go into a UI review with Scott, he is going to be pushing the UI team and pushing on engineering to come up with the most sensible, what we call "default defaults." Before you ever did anything to interact with an app, what are the default behaviors that it is going to use that you could change?

If you find your way into settings and you dick around a little bit, you could find your way into settings and change it to your liking, but really, what are most normal people going to do? Scott had an amazing ability to zero in on those things. To clear away, if he detected that there was too much configuration, or too much assistance or wizards or whatever the fuck that were thrown up into user's faces.

Don: Never propose a wizard to Scott, that was a bad idea.

Nitin: Those were just bad words. If you say those words within Apple, especially in those UI reviews. You were effectively giving up, you were just giving up on configuration, an app, or configuring some behavior or whatever. So Scott, it was great because, I forget where it was. There was some website, it may have even been Grouper or something like that, where they were talking about Picasso and the 10 illustrations of a bull. You start with the most detailed one, at the very beginning, and you end, the 10th illustration is like four strokes.

But if you look at it, you know it's a bull. Scott had this ability, maybe he wouldn't get you to the 10th illustration. He was always going to take the HI team and engineering to the eighth illustration, or seventh illustration. So you could always get to the 10th, but you were going to skip ahead a significant amount.

Don: Scott was never going to let you be sloppy.

Nitin: No.

Don: Or do something stupid like that. I mean, that's one of the reasons that, it's another reason that made him a great boss, like you say, is that focus. Because this is the first step in making an experience delightful. Because, if you can make it so that you don't notice that you're having an experience, in a way, you don't notice the other things, then the little things that you can do, the little curly Qs, the little effects, those just magnify how pleasant it is to use your device, right?

Nitin: Right.

Don: Because you never had to worry about the other horse shit.

Nitin: Right.

Don: And this was not something that's easy. I mean, it was very, very hard to do, folks.

Nitin: It's a real talent, it takes real talent.

Don: And iteration, it takes a lot of tries.

Nitin: Yes, exactly, that's true. Talent and perspiration, a lot of hard work certainly. But you know, it also takes working with a group of people who value the same thing. If you appreciate the fact that we're all trying to get to that 10th illustration, we're all trying to get there and that's something that we all value. Here's a guy that can take you from the first one or the zeroth one, to seven, oh my God that's a beautiful thing. Now you can iterate, and test, and iterate, and develop from the seventh illustration to get to that 10th. At the same time, that's one of the things that for me, anyway. But I think I can speak for a lot of people who really value what makes Apple a special place. That's what so infuriating about a Samsung is they're going to take that 10th thing, and of course, you can express a bull in four swipes.

Don: It's obvious, that's why it can't be patented.

Nitin: It's only obvious when you see somebody else fucking do it, but it's certainly not obvious.

Don: We drug their ass across broken glass for the last year.

Nitin: Yeah, exactly. Then it's obvious how auto registration in FaceTime and iMessage should work. I mean, these are the things that people kill themselves on, to get these things to work well, or the fallback between iMessage and SMS, things like that.

Rene: Exactly. Great examples.

Nitin: If you describe these things to people, these are just mundane. Why would anybody bother? Make every user on the planet go through these four screens and enter this horse shit, and now you've got a roughly equivalent experience. No, that's not good enough. That's not good enough, and that's the beautiful thing about what we've done in the past, that understanding that that's not good enough. All right, I'll shut up.

Guy: Yeah. So, how do you guys really feel?

Don: I almost wanted to mute myself so you didn't hear my "amen, preach it" kind of stuff there. That also made it a lot of fun working there. I remember when Nick and I were talking about what torment it was some days. When you could actually see something in the end that was like that, you would go, "Damn, we're good. We're doing the right thing." It's also sometimes when people, like I was ranting, I don't know if it is part of the show or whatever. I was ranting about using the scanning software in OS X. When something is bad, we're our own worst critics. We just hate it when we don't quite make it, or we miss something obvious. It's really hard.

On the other thing, I was giving the security team a hard time. These are folks that really matured as a group, in understanding this concept, along with having this tremendous domain knowledge, and continuing to grow that on what's safe. I think by the time I left, they were some of the people recommending "Let's not go over the top here, and do something stupid." That's what made me really proud of being a part of that, being a part of the group of people. Just marvelous people, too. There were days when you wanted to take a few of them and slam them against the wall.

Nitin: That means they're doing their job.

Don: Yeah, they're doing their job. But look at how marvelous it tastes, at the end, on your plate after it's cooked. Try not to think about all those intestines that have to be wrapped around the raw meat to make the sausage, and you had to have your hands in all of that for a while there. It makes it much more pleasant.

That's why you keep doing it. It's really like a drug, really is like a drug.

Nitin: Yeah. Well, and also, so we described some of the bad things, or some of the low points around not really having time to yourself on a vacation, or just knowing that your Sundays, especially your Sunday evenings are just going to be burned answering emails, fetching information, and things like that.

For me, some of the best, some of the high points, some of the stuff that kept me going was the fact that day to day, or week to week, everybody gets new builds. Right? I mean, there's new work that's going on, and there's new features, new functionality creeping into the build as the development process continues.

Because we did have such a flat hierarchy, and it was understood that you could go to anybody and talk to anyone, that was just part of the culture, if something was really, really cool, I could go into someone's office and say, "Wow, this animation that you put in here" for whatever the hell it was, "that's just really awesome."

It felt like every single day, you get a new toy, and the new toy is getting better and better over time. To be sure, there are places where it's just busted, and maybe it deletes really important data, although honestly that didn't...

Don: Like your home directory?

Nitin: Maybe your home directory. That only happened a few times on iTunes.

Don: No, no, iTunes was deleting entire hard drives. It was Safari that was deleting home directories.

Rene: It was your second home directory.

Don: Thank you, Rene. That's very subtle.

But yeah, no, no, Nitin, you're totally right. There were several technologies that were brought up, and I wanted to go up -- you remember migration assistant?

Nitin: Yeah.

Don: When they created that thing? When somebody brought that up and demoed it in a meeting, I was seriously torn between just running up and giving that person a hug. All the shit that you had to do as an employee there...because you have to remember, we constantly updated our systems.

I mean, it was just...I used to joke you would go into the office, get there at like 9:00 in the morning. This was in the day when you could do a net install. Before net install, you had to run down to building one, find Dave or somebody else, and get your set of disks.

Rene: Find Dave.

Don: Yeah, find Dave.

Rene: Just one guy called Dave.

Don: Dave with the disks.

Nitin: I know who Don is talking about.

Don: Dave Carvalho, right?

[crosstalk]

Don: Second floor, Dave Carvalho. Get your set of disks and install yourself, and go have a cup of coffee while your machine thrashes putting on the new OS. You did this every fucking day.

Rene: Oh, you must've loved iCloud Restore when it came around.

Don: I left right around when that came up. But Nitin, remember Purple Restore?

Nitin: Oh yeah. Oh absolutely, that was...

Don: You might have used that program once or twice.

Nitin: Once or twice, or maybe every day.

Don: Constantly?

Nitin: Constantly, even when you're on vacation. The first thing you need to figure out -- for me anyway -- first thing I need to figure out is, can I run Purple Restore over VPN. Because I know I'm going to be away from the office. I want to be able to download and install new builds.

To be clear, this is while I'm on vacation.

Don: To be able to run net install and Purple Restore over VPN. Everything was just peaches and cream, the world was perfect if you could do that.

Nitin: It was so much fun. Honestly, other than the people...for me, the people is far and away what I miss the most. But what I also miss quite a bit, and we've been able to thankfully replicate a little bit of that...

Don: I have a dead iMac next to me. Who I really miss is on-site. Nitin knows who I mean. Your Mac dies, you're in the middle of working. You walk down to building three, first floor. You walk in from the interior, you walk in, you made the hard...

Rene: You find Dave?

Don: No, different person. You walk into building three, make a hard right. There's the poor bastard sitting on-site, in that shitty room. As long as I was there, that was always a shitty looking room. The Dutch door there? You remember the Dutch door there?

Nitin: Oh yeah.

Don: "Oh, my machine has died." They just made it all better.

Nitin: I remember that there was a woman who worked in that room for years and years and years. God, I wish I remember her name, because she...

Rene: It was Dave.

[laughter]

Nitin: Her name was probably Dave. Let's just go with Dave. But I would joke with Scott Hertz about the fact that for whatever reason, he would go down to on-site -- he would have some problem with his laptop, and he would go to on-site.

Don: Scott was always breaking shit.

Nitin: He would just get these scowls from Dave, this woman. She was just never happy to see him. I was like, "Really? Are we talking about the same person?" Whenever I go down there, she's like Johnny on the spot, happy to work, get this thing working. Just going above and beyond every single time I went down there.

So, one time, I actually followed him down. He was like, "OK, my hard drive blew up. Let's go down and talk to Dave and see what she says." Sure enough, we go in, and Scott starts talking to her. This is the first time I've ever seen her give someone the stink eye. She's just giving Scott stink eye like I've never seen before.

Don: What the hell is she doing to Scott? Scott, he's a teddy bear. He's a hyper teddy bear...what?

Nitin: There's got to be a smell that he gives off. I don't know.

Rene: Maybe that was the third time he had been down there that day.

Nitin: But then I swear, I swear, I poked my head around the corner and I just waved to Dave and was like, "Hi, how is it going? Can we get this fixed?" Like night and day, her attitude and everything changed. She hated Hertz is what I'm trying to say, is Dave hated Hertz. It was just a funny thing.

Don: The on-site people, they were saints. It's like, remember, it must've been three years into the iPhone before we actually finally got a real Home Depot, remember, up on the third floor?

Nitin: Yeah. With [indecipherable 1:29:31] .

Don: That's what the room was called. It was called "Home Depot," and god, I loved that. Because you could just go in, and you got all your new stuff, your prototypes. If something was dead there in iOS land, a lot of times that's where you went.

Nitin: Yeah, but the software, updating it every day...

Don: That was building two, not building three. That was third floor, building two.

Nitin: Yes, for any of you historians out there.

Don: Anybody sitting with a map of the campus, on-site, first floor, building three. Home Depot, third floor, building two.

Guy: Don't be creepy.

Don: For all I know, they're still there.

Guy: Everybody is called Dave, but here's exactly where to find them.

Don: I said Dave because I didn't want to name drop her, but Carvalho actually is crazy enough to listen to this. He knew I was talking about him. Not at on-site, at...

Guy: It's my new thing.

Don: Anybody is called Dave.

Guy: At Apple is just Dave.

Nitin: It's better than Bob, right?

Don: Remember we had the joke for a while that we were going to give Scott a moratorium on hiring people named Chris? We had so goddamn many people named, was it Chris, or was it Scott? I can't remember. We had so many people named Chris.

Nitin: Yeah. God, I remember that. I don't remember if it was Scott, or was it Chris though? The only Chris that comes to mind is one of your early hires, Chris.

Don: Oh, C-Blue? Chris Blumenberg?

Nitin: Yeah, exactly.

Don: No, he just left for Uber. Rene, was it Uber?

Rene: It might've been yeah.

Nitin: We need Rene to send [indecipherable 1:31:09] .

Don: Rene was so thoughtful on Twitter. He tweeted this after I told him, direct message, and he didn't give the attribution or the context of what it was about...

Rene: Or the name.

Don: Or the name, or whatever it was about. But he tells me that on a DM one morning, because Rene and I talk on Twitter a lot on DMs, what people don't realize. He said, "Hey, did you know Chris Blumenberg went over to Uber?" There was a beat, and I immediately typed, "Oh my god, I hope it's not driving a cab."

[laughter]

Don: That was just the first thing that came to mind. I don't know why.

You know, I hired C-Blue right out of build, where he had started I guess as an intern.

Nitin: That's right.

Don: So, my group was his first job as a real boy, being a real engineer, you get to do real software engineering. A lot of people don't realize the magnificent work he did in the beginning. I mean, we wouldn't have Java in Safari in the beginning, or plugins actually working, if it hadn't been for Chris Blumenberg. He did a lot of that on his own, figuring it out.

Nitin: Wait a minute, wait a minute. I'm sorry, so you're saying if Blumenberg, if it wasn't for Blumenberg's work, we wouldn't have Java in Safari?

Rene: I wasn't going to say anything.

Nitin: I want to make sure...

Don: It mattered back in 2001.

Nitin: When the Terminators from the future come back, they know who to kill.

Don: Well, they'll probably kill him for some other reasons. But no, it mattered a lot in the beginning, because if you couldn't run that...Do you know how much shit I got from banks about fucking Java and various whack-ass plugins, and how much I tormented Chris about getting all these little things working? It mattered back then.

I was talking about, I was the guy who popped a cap in the ass of Sherlock. There was nothing that would make me happier than to kill Java and plugins, certainly. Or Flash, for Christ's sake. But you have to be real.

That's why, you know, I don't know if you saw the tweet a couple weeks ago. I tweeted a link from a Microsoft blog about them, Microsoft having to basically proof Safari's user agent string on mobile.

Nitin: I did see that.

Don: I said something like, "Wow, just wow," and I put the link. I said, "I guess my evil plan to take over the world worked. I don't know how to feel about that." And I forgot...

Nitin: So when you tweeted that, I thought maybe they would use WebKit, but instead...

Don: Yeah. I forgot when I tweeted that, all my tweets get copied into Facebook. And one of my Facebook friends is Dean Hachamovitch. He read that and he commented on it, and I forget what he said. Dean is just, he took it the right way, that meant I wasn't gloating or anything else, and that I was conflicted about it.

He's just a guy with a lot of class.

Rene: But you're totally paying for drinks next time.

Don: Yeah, I'm totally paying for drinks. But Dean is a great guy. Microsoft is having to do what we had to do back then is you have to be practical about what's possible. Dean didn't write that blog post. I thought they were just a tad whiny at the end, but. That's what you have to do. If that's the new Microsoft, maybe they're getting it.

Nitin: It's pragmatic, right?

Don: Yeah, it's pragmatic. It's a much more pragmatic approach.

Rene: That was definitely...oh, go ahead.

Don: In the early days, I was so afraid any day I was going to get fired anyway. I really didn't care if the technical solution to the problem came from Beelzebub. I was going to use it. Because we had nothing back then. The Mac was like...I remember when Brian Croll started at Apple, he's also ex-Easel. He knew he had such a daunting job ahead of him.

Our market share, the numbers, he would do slides every year. Phil would force him to do slides of the top 100 and stuff. Our market share numbers were not good. They were basically headed into the toilet. So you did what you had to do.

I know in the first iteration of the iPhone, nobody believed we could do a mobile phone, or that we could play in that world. We did some things where we had to make some decisions about compromise and compatibility and stuff. You do what you have to do.

Of course, Apple doesn't have to do any of that shit now. Thank god.

Nitin: Yeah, now Apple is the 800 pound gorilla, right? Other people have to do things to accommodate for Apple's behavior. But you're right, back then 10 years ago, or even longer, it was very different. Apple had to try to fit into a world, fit into the Microsoft-defined world, rather than defining it.

Rene: You had to license Active Sync, right?

Don: Yeah, we had to do that. Actually you know, dealing with Microsoft is dealing with the many-headed hydra. It depends on who you get. Maybe the teeth aren't so sharp on that one. The Active Sync folks were actually quite pleasant.

Nitin: Oh yeah, no. I mean, that was one of the easiest things to integrate for us too on iOS. That was very, relatively smooth. I've got to say, even the Exchange Active Sync, the mobile side of the protocol, it made a lot of sense. It was one of those things where you look at it and you're like, "Well, why doesn't the rest of the world work like this?" Specifically iMap, the iMap protocol, why doesn't it work more like EAS?

Don: IMap is a piece of shit.

Guy: Or Gmail.

Nitin: IMap is insane.

Don: No, Active Sync was a good...and they were good for supporting and stuff like that. We found that to be true -- it's like when the Office 360 folks came around, doing the web stuff, and we're trying to make sure that they could run on mobile and stuff like that, they were real reasonable people.

You know, not everybody at Microsoft was like that. The Office people were a little trying.

Rene: They came around. Only took an ECU.

Quick break so I can tell you about Drobo, smart storage to protect what matters. If you've ever had to set up and configure RAID arrays, it is not for the faint of heart, and it is not for people who are busy and don't have a lot of time, but just need something that works, that's what Drobo is for. It is a storage appliance. It is the Apple-fication of a RAID array.

They offer four, five, or eight drive capacity models with USB 3.0, Thunderbolt plus USB 3.0, NAS, iSCI, basically any kind of interface you need, they have a model for. I want to tell you specifically though about the Drobo Gen 3. That's their most popular model, but it's gotten even better.

I used to have the original Drobo, the old school Drobo, and this is a four bay Drobo, but now it's got USB 3.0, so it's faster than ever. It's three to five times faster than ever, in fact. It also gives you the ability to choose one or two drives for redundancy, so you can have more capacity if that's what you want. But you can also have more safety, if that's what you need.

It's optimized for Time Machine, so you can have all your backups going there. It'll even protect you from power failures. It has an internal battery, a small SSD cache to store data being written to the device in the event of power failure. That's really what you want this for. You want an appliance that'll keep your most important data, whether it's your project files, whether it's your personal photographs, anything that would be incredibly difficult if not impossible to replace.

You do want a copy on the cloud, absolutely, but you also want a copy that's readily accessible. If you have terabytes of information, getting them from a back-up drive on your desk is so much faster than getting them off any type of server.

So here's the deal. It's $349, that's one third less than its predecessor. If you have an original four bay Drobo, you get the new one, you pull those drives out, you push them back in, and you're up and running. It's really that simple.

What I want you to do is go to drobostore.com, www.drobostore.com. Enter in code "debug50." That'll save you $50 off the purchase of any Drobo. If you want the new Gen 3, it'll save you $50 on that. If you want one of the much bigger, much more company-based alternatives, $50 off that too. Drobostore.com, offer code "debug50." Thanks, Drobo.

All right, so I want to make sure we get to this if Nitin wanted to talk about it. Nitin, that was, you mentioned something about gestures versus buttons in discussions around implementation and how to provide good experiences.

Don: Oh yeah, please, Nitin, talk about that. I'd like to hear that.

Nitin: Oh sure. Yeah, yeah. I'm not sure how much I have to talk about, but yeah, let's get started. I've got my glass of wine in front of me.

Don: That would be your third glass of wine, right?

Nitin: To be clear, for the record, for my kids who'll be listening to this in the future, I'm on my third glass of wine right now.

Don: Good man.

Nitin: At the time, we...now this is 2005 at this point, right? We understood that we had this great touch technology that was developed initially by FingerWorks, this company that Apple had purchased at the time. We knew that we had this great technology, and we had the ability to not only detect swipes and presses, but really, it was two dimensional presses as well, and two dimensional swipes.

Well, actually, am I getting my dimensions right? It's actually three dimensional swipes, and three dimensional presses. In other words, actually being able to actually figure out how hard a press was, or how hard a swipe was. Or what was the stroke that was being performed? Was it consistently pressed for the duration of the stroke, or was it pressed hard early on and then tailed off into...

Don: By the way, this wasn't actual pressure sensitive technology. Part of this was how much surface, or how many points were activated. That's how you could tell how strong something was.

Rene: It wasn't a digitizer.

Don: It was very clever to know...it was almost like coverage area, right, Nitin?

Nitin: Yes, exactly. It was coverage area.

Rene: It sees your fingers that aren't on the screen and it's tuned so that only when you're actually touching the screen it detects it right?

Nitin: Right, exactly.

Rene: It's basically a magnetic field that it figures out.

Don: Right, but it can figure out your touch, how much surface area is on there. It can't really detect pressure per se.

Nitin: Right, it's a pressure thing.

Don: You can interpolate pressure. If you press your finger down, your finger gets effectively bigger on the device, right?

Nitin: Exactly, based on the understood fleshiness of fingers, [laughs] you could infer from that how much pressure was actually applied.

Rene: Actually UIEvent has it in there. I think it's public now but at one point, it was private because I know [indecipherable 1:43:42] using it internally at Pixar to do exactly pressure-sensitive drawings and stuff.

Don: Didn't they do that a few years ago, made that public API, the information public?

Rene: At one point, it was private.

Don: Maybe for the stylist people.

Rene: You needed to do KVO to get it. Anyway, sorry, I keep [indecipherable 1:44:00] .

[crosstalk]

Nitin: This is all lovely. I love hearing this.

Don: The long and the short of it is that we have this new toy. We have this fucking, awesome toy that we could play with. We have this technology that we had never gotten, that we never had a chance to play with.

We understood that we had the screen that it was not only a very large screen compared to phones at the time but the entire screen, you could receive touch input from the entire screen.

From very early on, there were some gestures where they sort of deemed intuitively obvious. Things like pinch to zoom, zooming in and zooming out on a photo.

To me, this is the most interesting part, is where is that border between intuitive and now you're going to put up a goddamn user manual as the first experience.

Guy: I was going to say don't necessarily say "obvious" when you're talking to Samsung.

Nitin: Yes. Well, exactly, exactly.

Guy: It's only obvious once you've done it, right?

Nitin: [laughs] By the way, you'll notice that...

Guy: Discoverable.

Nitin: In the UIs where you can pinch to zoom, there is still even to this day a double-tap to zoom on that point. What I'm trying to say [laughs] is in 2005 we had so many of the discussions that came many years later that I got to see on the outside world where there was this discussion around how natural really are these gestures.

Just because you can perform them with a finger or you can perform them with your thumb doesn't mean that you would necessarily think to be able to perform with your thumb or with a finger. That was really the distinction that we drew.

What are the things that you might think are actually things that you can do? What are the things that a user has the best chances of being able to glean just from their own past experience and interacting with things just in the natural world that we could take advantage of and make it so that they can get some delightful experience on the iPhone?

Rene: It's that debate between direct manipulation of which there are a few and abstract gestures of which there are many but aren't anywhere nearly discoverable.

Don: I really remember this discussion a couple years later when [indecipherable 1:46:48] was proposing the app switching gesture and how we were going back and forth on how the hell that would work and whether people would discover it. That was like the whole original argument on steroids because that was such a really hard problem to struggle with.

Guy: I'm so happy about that app because I was going to try to find a way to do it. I [laughs] wrote a piece ages ago when that just came out complaining that that was a poor move.

Nitin: Are you talking about four-finger gestures on iPad?

Guy: Yeah, if you do the five-finger pinch to switch and the four-finger swipe to switch between apps. I'm thinking about the iPad specifically. It limits what iPad apps can do with the number of touches that they've got, right?

Nitin: Well, you would swipe your way from Fruit Ninja into Mailbox.

Guy: Yeah. I can imagine games really easily where four fingers swiping across the screen is not a weird thing or a five-finger pinch.

Don: You've hit the second stage of this set of problems, not just the stuff that Nitin was talking about. The big problem on touch interfaces is actually the limited palette you have.

Guy: Sure.

Don: It's almost literally a palette, and it's figuratively a palette. That's a real problem. You were in the trenches much more so than I in the beginning. Were a lot of these same discussions going on back then in 2005? Because I only heard some of these.

Nitin: Absolutely. I mean, there were so many...Right away, just like if you sat down with a touch device today and were tasked with coming up with all of the different things that you could do to manipulate the workings of the phone, or manipulate the content that you're viewing on a phone, we were doing that back then and coming up with the laundry list of here are all the different things that we can do and here are they ways that you can manipulate things or interact with the device to better view your comment, or manipulate it or what have you.

Forgive me for using these terms like manipulate and content. I fucking hate these words.

Guy: [laughs]

Nitin: I feel like it's...

[crosstalk]

Don: It's cool. I've heard them so often discussions at work that yeah, I just didn't even notice that.

Guy: [laughs] You need to use something, right? Sounds douchey, but whatever.

Nitin: Exactly, exactly. Please, bear with me here. Really, with every single one of these discussions, it always came back to discoverability. Because a lot of the gestures, if not almost every single gesture, needs to have some aspect of discoverability. Really, because of that, it really mean that these gestures had to be...What's the term?

[crosstalk]

Nitin: Accelerators, right? They had to be accelerators for other well-known, well-understood ways to manipulate the UI. In other words, they had to be the mini-button, like hitting CommandQ to quit an app as opposed to going to the file menu or the app menu and selecting command key...

[crosstalk]

Don: Yeah, but it's a very slippery slope with that when you pass that bit. Sometimes you can't even do some of those things on a touch device without using a gesture -- which is why for example slide to unlock, one of the reasons I think Steve went down the path of skeuomorphism. If you make it looks like something that's physically touchable, it makes it much easier for you to intuit maybe I should grab that thing that looks like it's indented...

[crosstalk]

Don: ....slide it with my finger, plus we're putting out in huge, fucking letters, "slide to unlock" there. Because if you look at the original iPhone from 2007 when it debuted to now, I mean, what do you have now? You have a greater than sign and slide to unlock, and this animation that highlights the letters going left to right.

Nitin: It waits a second if you have [indecipherable 1:51:43] . It doesn't even give you that for a few seconds.

Don: Yeah, exactly. Back then, what we were doing was we were trying to put road signs up and everything, and give you visual cues on where to actually place your fingers. Which is why, also, people complained in the early versions of the iPhone, for [indecipherable 1:52:09] or other things, that we didn't have ways to do things like easily delete messages, or do this or that. There wasn't a gesture. We just didn't know whether people would get that whole swipe to delete thing.

Nitin: Exactly, exactly. Well, and bless you, Don, for bringing this up, because...

[crosstalk]

Don: People thought we were fucking idiots.

Nitin: Right. To me, I understand that there's this big push away from skeuomorphism. I agree that in some cases, skeuomorphism just got out of hand. If you look at Game Center UI, you're like, "I don't even know what the fuck that is. It's just this blend of real-world items with virtual computing center guidance and I can't make heads or tails of it."

One other thing is Steve Jobs has had for photorealistic rendering since he bought Pixar...

[crosstalk]

Don: That's basically the reason. Right there, in a nutshell, it was buying Pixar. Thank you very much.

Nitin: He's had a thing for photorealism for a long time. Some of that is because computer graphics and interacting with GUIs has been so far away from photorealism for so long. He saw that as the Mecca that we needed to pursue.

Anyway, to your point, Don. This is a very important thing. We are now the benefactors of understanding how touch displays work and how they should. Like you said, Don, what does "Slide to unlock actually mean"?

If you didn't see a big gray thing that looked like a fucking button in rails, literally...

Don: Yes, exactly.

Nitin: ...that allowed to unlock your screen, would you today understand that a "greater than" arrow next to the word "slide to unlock" with glimmering animation that demonstrates you should move from left to right actually means slide to unlock? I really doubt it.

Don: In my mind, there is no way that if we had debuted the iOS 7 UI in 2005...that's a big fail. If we had debuted the iOS 7 functionality for apps, like the version of Mail back then, nobody would have fucking figured out how to use it, or the version of Safari with its very subtle "is my finger at the bottom of the page?" Everybody figures that out now. It would have just been maddening back then.

Rene: There is some element of evolution. For example, originally you solve one-handed ease of use just by having a small screen. As screens get bigger as you introduce tablets, you can't reach across the screens. Software has to do it.

You start getting things like consistent back and forward gestures and things like on iOS 8 with messages, where you tap and hold to send a message or to take a selfie. It just evolves along with the...as you wanted to do more and more things, you have to evolve the way that those things get done.

Don: That's an issue you pointed out. My particular team got actually really involved in the iPad timeframe because, a typical Apple, we were trying to do too many things at once. We temporarily took over doing some of the apps, actually some of Nitin's apps for the team. We tried to do it cooperatively, but everybody was just too many irons in the fire and not sleeping enough.

I remember when my team started tackling the iPad UIs, this was a terrible problem. It was like this embarrassment of Ritchie's, almost all this space. We didn't want to do what Steve Jobs would retroactively complain about.

With other people, about taking a iPhone, a phone app, and scaling it up to a big screen...we knew from the beginning that that was a stupid thing to do. Which things do you get elaborate on and which new gestures do you introduce? How far do you go? You can make things larger now, but is that a good thing?

Then, you also have to think of this as in a whole ecosystem, "If we do this for this particular app on the iPad device, what does that mean for the other device?"

Rene: You throw "whether" out of the window, first. Then you move on.

Don: Some things were easier, but the hard things were...and we threw the phone app out, we don't have the phone app either. Mail and Calendar, especially right away, were real challenges to not screw them up. The temptation is to do something completely different because you can.

Guy: I would imagine that you could put the OS X mail look to list detail. What's it called? Master-Detail view? Like the three pane approach. You could probably see that working on the iPad.

Rene: We prototyped it!

Nitin: Yes, exactly. We definitely looked at those types of things. I think I mentioned this in the last podcast that I did that very early on, actually Steve was a big proponent of just blowing up the existing iPad or iPhone UI and just not scaling it out.

Don: Even though, later on, he retroactively said that that was a stupid idea.

Nitin: Exactly.

Don: He did that about shit all the time. It was like about iPads themselves, about big screen devices. You remember before we brought the iPad out, he pooh-poohed the idea!

Nitin: Yes.

Don: Steve was constantly doing it.

Guy: It's just funny. I just love the idea of Nitin sitting in his office with the prototype iPad and hearing Steve, "Just shit I love the idea of iPad" He's, "Mm...I stayed up all night!"

[laughter]

Nitin: Thankfully, we actually never demoed blown iPhone UIs to him.

[crosstalk]

Nitin: Long before we ever got to that point, we were already arguing that, "No. We can't do that. This is not going to be a working UI." You don't even have to look at it, on a tablet or Vector. Just imagine the current iPhone address book UI blown up to iPad size.

[crosstalk]

Don: It would be awful!

Nitin: It's terrible. Nobody wants that.

Don: Scott Forstall would never allow us...Greg Christie would never allow us to get that far. He had more sense than that. The one device that was actually easy to do...Greg surprised me about this. I remember the first happening where we talked about this embracing it, it was the iPad mini.

The reason why it made it easy to go to mini is because we had already done Retina. Essentially, the iPad mini was the original iPad just scaled out. It was the easiest goddamn product to do in one way.

What people don't realize in the outside is how fast we did it. You remember that, Nitin?

Nitin: Sure.

Don: That was less than nine months from inception to execution, I swear to God.

Nitin: On the mini?

Don: On the mini. That was the fastest we ever did a product.

Nitin: I think I was out by the time the mini was even released.

Don: What year did you leave?

Nitin: January 2012.

Don: That was a month before I left, because I left in February 2012. We had already started the mini by then, before the time I left. I know you were disclosed on it, for Christ's sake!

[laughter]

Don: Right down the hall, I was talking to you about it.

Nitin: We didn't ship it, we weren't anywhere near...

Don: We shipped it in fall of 2012.

Rene: It was announced in October.

Don: But the conversation, I remember being in Scott's lab. I swear to God, it was end of November when we're first talking about it. I was, "Really?" That was a whole different problem, right? What you had to do then was validate whether your old UI on non-Retina machines would work scaled down 20 percent.

Rene: Was that on 63 PPI?

Nitin: That was what I remember about the iPad mini, was actually trying to figure out all of the points where we knew in the UI that your touch area was not that big. We were already on the hairy edge of having a big enough touch UI.

Those were the first things that we need to look at for something like a mini, because now they're going to be, like you said, 20 percent smaller. Can you still hit those things? As an example, things like scrubbing within the music app or video?

It's understood within Apple, those are areas where there's very little tolerance for having a much smaller touch target. Can we actually handle those appropriately on a physically smaller display?

Don: They did a stunningly good job.

Nitin: Yeah, I own a mini. [laughs]

Guy: I actually didn't think it was going to work, when it got announced or when [indecipherable 2:02:29] start it. That seems like it's weird.

Don: If there's one thing Apple demonstrated over the years, they know how to do transitions -- hardware transitions, software transitions, any stuff like that. There is no company that is more agile in the tech business than Apple that way.

Rene: And agile at scale, which is amazing.

Don: The only thing that Apple still sucks at -- and they're getting better much faster than I thought they would -- there was a real nabob of negativity about this, was services. They're doing much better on services, scaling up faster than I thought they would.

Nitin: Are they?

Don: I think so. You can't believe how bad it was, I had a front-row seat for the MobileMe...

Rene: MobileMe flamethrower.

Nitin: [laughs]

Don: The failure. It wasn't my fault, I was actually trying to make those assholes successful.

[laughter]

Don: They were shitting all over my apps, I was taking the eye on that. The poor bastards, and Steve really took it to them in a hard way. Those days are behind Apple, they're doing much better.

You were talking about Apple being the 800-pound-gorilla, they are not even a gorilla in this space. They're more like a monkey, but they're a very strong monkey now.

[laughter]

Don: They're actually moving into the ape phase right now, they're evolving. They're doing much better this way.

Guy: Monkey with a whole lot of heart.

Don: It's much better. Think about everything in the whole ecosystem that Apple does better than, say, Amazon or Google.

Guy: Focus?

Don: Focus is one of them. That's why people will be disappointed in some ways with the announcements this fall, because they won't get 50 things. They'll get two.

Guy: People always get overly excited about what's coming down the pipeline.

Rene: There's nothing like expectational debt to make you suffer from anticipointment.

Guy: Anticipointment?

Don: What the fuck does that mean?

Rene: An American word. I heard it on a talk show, it's got to be real.

Nitin: American? How dare you!

[laughter]

Nitin: I should get [indecipherable 2:05:09] some time.

Don: I could talk about Apple all day. I was hoping we would break Nitin's previous record.

Rene: Next time, we'll do a follow-up.

Don: By the way, I was so glad you did that six-hour shake. It really is six hours that you talked.

Nitin: [laughs]

Don: I thought I talked a lot.

[laughter]

Guy: You guys are both giant windbags.

Rene: [laughs]

Don: I know we're going to wrap-up because of other time restrictions, but I will gladly get half in the bag with Mr. Ganatra again and go another round.

Guy: Maybe we got a new show, half the day, [indecipherable 2:05:52] Nitin Ganatra.

[laughter and crosstalk]

Don: [indecipherable 2:05:55] with Nitin Ganatra.

[laughter]

Don: I know Nitin hasn't exhausted stories. He's got a lot more stories than that.

Rene: [laughs] Because you gave him some, probably.

Nitin: We both have lots of stories, maybe too many stories. [laughs]

Don: Maybe too many stories! I know we're both willing to comment ad nauseam about the state of Apple today and the industries. Maybe some crazy people would be entertained by that, I don't know.

Rene: "To be continued," is what you're saying?

Nitin: Don, before we wrap up, I want to thank you publicly. This may be wine-induced, but not really.

[laughter]

Nitin: I want to thank you for giving the company that I love a credible web strategy and a web story.

Don: Thank you much.

Nitin: Initially, very early on, when I first found out about Alexander, it scared the shit out of me.

Don: You know the original name? [laughs]

Nitin: It was one of these things that worried me and I was, "Oh, my God!" I was stuck in the 90s mindset at the time, that, "Oh, my God! If we develop our own web browser, what the fuck? We're not going to have IE, we're not going to have anything. Now we're stuck with goddamn OmniWeb."

Don: [laughs] Since [indecipherable 2:07:18] Ken Case who, by the way, is a really nice man if you ever meet him.

Guy: He's a good guy.

Nitin: OmniWeb, it was a solid browser, but it was not IE.

Guy: Everybody takes your point.

Don: It was essentially built on something that was very similar to HTML display.

Nitin: Yeah. [laughs]

Don: Which, by the way, we came out. Ken is not a stupid guy, he just chucked that shit right away. He was one of the first people to attempt to embed WebKit.

Nitin: I remember that.

Don: Ken is a saint.

Thank you very much. I just wanted to tell you that until I listened to your podcast -- and I was thinking about getting them in the novelization format -- I didn't realize how goddamn long you had been at Apple, and that you had come up through one of my favorite routes.

I love people who come up this way. I didn't realize you came up from DTS like Darin. Darin Adler worked for me, I was one of his biggest fanboys back in the days when...

The fact that you have all that rich history and you've contributed so many different projects at Apple, that's just marvelous.

You knucklehead.

Rene: This is getting way too friendly, we've got to get to the part of [indecipherable 2:08:49] .

Guy: I love you two.

Don: It's only partially wine-induced, because I'm in a lot more wine than this cheap Zinfandel to do that.

Rene: Don, while you are wine-induced, where can people find you, if they want to hear more of these great stories?

Don: Not that I've written anything lately, but donmelton.com where you read some of my past exploits. Or talk to me on @donmelton on twitter. Just about anybody who says anything to me, I'll reply because I'm a whore.

[laughter]

Rene: Nitin, you're at Jawbone now?

Nitin: I am at Jawbone, and the best way to reach me, still, is @nitinganatra on twitter.

Don: As I would do. [laughs]

Nitin: That's right. Don, if you want to go get a beer sometime and talk about MobileMe stories, I'd love to.

[laughter]

Nitin: Because I'm doing something that I'm not comfortable sharing in a podcast, I would love to chat with you about them. [laughs]

Rene: I'm booking a ticket now.

Guy: You can always just stop recording.

Don: It's not like there's a huge distance between us, either.

Nitin: Exactly. I don't know about your [indecipherable 2:09:54] , your other house or anything.

Don: There you go. [laughs]

Nitin: Sorry, you may have to edit that.

[laughter]

Rene: It's the third house I'm editing out.

Nitin: [laughs]

Rene: Thank you so much, guys.

Guy: Thanks, guys. That was a blast.

Rene: I want to once again thank Drobo for sponsoring Debug. If you go to www.drobostore.com and use offer code Debug50, you can save 50 bucks off the purchase of any Drobo, including the new Drobo Generation 3.

Up to four drives, one or two drives redundancy, power failure protection, everything you need to keep the stuff that you want and need safe. Thanks, Drobo.

Feedback

Question, comment, recommendation, or something you want us to follow up on for the next show?

Email us at debug@mobilenations.com or leave a comment below.

Debug is a casual, conversational interview show featuring the best developers in the business about the amazing apps they make and why and how they make them. In part 3 of the Nitin Ganatra trilogy, the former Director of iOS apps at Apple talks to Guy and Rene about iOS interface and API decisions, scaling to iPad, life after Apple, and what comes next.

• Subscribe in iTunes
• Subscribe in RSS
• Download directly
• Follow on Twitter

Show notes

• Debug 39: Nitin Ganatra episode I: System 7 to Carbon
• Debug 40: Nitin Ganatra episode II: OS X to iOS

Guests

• Nitin Ganatra

Hosts

• Guy English of Kicking Bear
• Rene Ritchie of Mobile Nations

Feedback

Question, comment, recommendation, or something you want us to follow up on for the next show?

Email us at debug@mobilenations.com or leave a comment below.

Transcript

Guy English: I guess iPhone OS 1, there was a bunch of work done on the API. How did it progress from there? What was iPad? iPad was 3.2, right? Wildcat was the...

Nitin Ganatra: Yeah, Wildcat. Boy, I haven't heard that name in a long time. [laughs]

Guy: What was the scoop with that? How early in the process did that start?

Nitin: There were a couple things that you asked in there. One of them was the API. One of the things, if I may talk about that quick, was that a few months after 1.0, people on the outside were loud and clear that this Web app thing was not going to fly for their apps where Apple had the ability to create native apps.

We started on the task of thinking about; what the SDK was going to be like? what things should be enabled? What features should we allow third parties to be able to do compared to what we could do in the built-in apps?

There was a ton of work related to security -- code signing, provision profiles, and all the other joys of development that have showed up since then.

One of the things that came up too was, we had these internal classes that we had been using already up through 1.0. I'm not sure if people know the names of these, but some of the biggest ones that we were using were these classes called UITable and UIScroller.

It was pretty clear that the performance characteristics...As soon as we came out with 2.0, performance-wise...What we released to the outside world were UITableView and UIScrollView. I'm focusing on those in particular because they demonstrated the biggest problems that we had.

Guy: They also make up like 80 percent of the UI of those first series of third-party apps. A scroll view in the middle is one of the most apps ported, right?

Nitin: Yes, exactly. That's a good point. Maybe that's precisely why I remember it so vividly.

When we released 2.0, it was pretty clear that the internal apps were either using some tricks or something within UITableView or UIScrollView to make them much faster, or internally were using a completely different set of classes that we did not want to expose to the outside world.

Since then, everybody has learned that it was the latter. We had these classes internally, UITable and UIScroller, that we were using. They were nice and fast and relatively simple, but they had an API that at Apple we did not want to release to the outside world.

Instead of releasing those, deprecating them quickly and then coming out with the right API, what we did...Let me be very clear, it was not my team that implemented UIScrollView and UITableView. I believe that even back then it was under Toby Patterson who was managing the UIKit team. I don't want to take credit for him.

Articles started showing up about the fact that third party apps were more poky than the built-in apps, and "What the hell? What's going on here?"

I don't believe he was working for Apple when he wrote this, but Ed Voss, he wrote another article about "How to speed up UITableview to make it so it approaches the speed of UITable."

Believe it or not, these are the types of things that we take pretty seriously inside of Apple. It was completely understood that it was all about time to market and getting an STK out in the 2.0 timeframe and then coming though later and cleaning things up.

The act of cleaning things up, what that meant was getting all of our apps on top of UITableview and UIScrollview, even though we knew that by doing that we were deliberately slowing down our apps by doing that.

We decided to do that anyway, because we knew that nobody's going to stand for mail scrolling slower in 2.0 than it did in 1.0 or, rather, in this case we're talking 3.0 to 2.0.

We knew that, specifically internal management, the HI team, nobody was going to stand for the fact that things were now slower.

What this was doing, and Apple does this all the time, is by switching over to the API that everybody else uses, built in with that is the assumption that you're going to pull that API along and make it so that it performs as well as what you had before, or close enough.

It's going to be close enough, and by doing all of that work, we've now made it so that third-party apps didn't have to work so hard or do these different things than the internal apps in order to get the same performance gains.

Guy: You're taking dog-footing seriously.

Nitin: Exactly. We take it very seriously. Like when you look at the native apps for Apple versus web apps for the outside, even at that time that was sort of a disingenuous story because if the web solution was so great why didn't Apple use it in anything in iPhone 1.0?

We didn't use it anywhere, but yet we were saying, "Yeah, but it's good enough for you fine third-party types."

Guy: Yeah, that was a bit of a dead giveaway.

Nitin: Exactly. It was a dead giveaway.

One of the other things that's come up time and again, especially since the OS X timeframe is that APIs really do become a liability over time. The more classes and the more interfaces you have to support, the tougher your job becomes if you want to make a big sweeping change later.

For example, let's say we had continued to carry forward UITable and UIScroller all the way up through the iOS7 timeframe.

When it came time to change, have a new look and feel, some slightly different behaviors and things like that, now we've made our job in engineering at least twice as difficult because we have to enable this new functionality, not only in the UITableview, but we also have to do it in UITable, the internal thing, because we never got back down to using a single API, if that makes sense.

Guy: Yeah. No, APIs are one of the hardest things to shift because you can always update an app to fix a problem. An API you're stuck with it for probably far longer than you want to be.

Nitin: Exactly.

Guy: Even if you deprecate it, that's at least one release cycle, at least one release cycle, where you're saying you're deprecating it before you can take it away. It's hard. It's always a promise, and it constrains you.

Nitin: Exactly.

Guy: You're putting handcuffs on.

Nitin: Yeah, definitely. To a customer, they're not going to care, right?

Guy: No.

Nitin: All they're going to know, from a customer's point of view, is that they upgraded to the latest version of iOS and their app that they relied on stopped working.

Apple has a great procedure now for deprecating APIs and giving everybody plenty of warning and working with developers to make sure they get off these APIs. If a developer doesn't do that, then the appearance to our customer is that Apple broke their software.

Guy: I think...

[crosstalk]

Nitin: ...that's true. But, yes.

Guy: I think what's interesting here is the way that you're describing the end user of the software. A third party ISV, software person, may see the person using their software as their customer, but Apple is seeing that customer as Apple's customer.

It is their duty to their customer that stops them from shipping API or making promises to third party developers that they may not be able to keep. It's an interesting perspective.

Nitin: Yeah. That's a good point. I almost forgot about that. That's come with enough experience and enough, frankly, probably attempts at blaming a third party before someone far wiser on the executive team says, "That's not what it's going to look like to the customer."

The customer is going to know their last action was that they upgraded their Apple software, and now something else that runs on their Apple device doesn't work. It took a long time for that to come around. It's very tempting, instead, to blame the app developer.

In a lot of cases, they could be exactly the ones to blame. They could be holding up a big middle finger and saying, "F U, I'm not going to change these classes. You support them forever." Or, "We can't make a business case for revving our app. You figure out what you want to do, Apple."

Even in a case where a developer is knowingly not doing the right thing for one of their own customers, it's still, to that customer, going to look like an Apple problem. At the very least, we should treat it like that and understand that deprecating API isn't as simple as just communicate it to everybody and then deprecate it later. "Hey, we gave them warning, and they're gone."

You can still end up with unhappy customers, and that's going to reflect poorly on Apple. We had to take that very seriously.

Guy: I don't even know if that ever gets communicated, at like WWDC. It's so internal to the culture. That's what's behind...First of all, not exposing a bunch of APIs that may or may not exist, forbidding stuff like code injection, a bunch of weird, dirty tricks that get blocked now on the Mac, as well as on iOS.

The intention is not to limit developers and the possibilities of developers, but the intention is to give the customers, the end users, the real customers, the best possible experience. I think that gets lost a little bit by third party developers who...

Every now and then, you hit a brick wall. Or something that you could of done, now you can't. Personally, right now, my app build code gets screwed up, and I need to figure something out. I hate that. Believe me, I hate that. I understand the value for why the code signing and all that works.

It's not Apple putting it's thumb down and squeezing the third party. I think it is from a desire to give the customers the best possible experience. I sound like I'm cheerleading for Apple now, and I don't mean to.

Nitin: [laughs]

Guy: I think it's an interesting cultural thing.

Nitin: Yeah, it's true. I was at Apple for so long. After a while, you build up a little bit of a thicker skin to this kind of thing. There are those times, especially during something like WWDC, or you're talking to developers at a kitchen, or things like that, where what will come through is...

A request will come from a developer and the request will begin with the words, "All you have to do is." It's sort of a "Why don't you add a flags field to this method right here, and then we can figure out something else to do."

Because the request seems so small and it seems like such a nothing of a request, how can Apple possibly say no to that, unless they deliberately don't want third parties to have the best possible software?

At those moments, you have to think hard about when you introduce things, because at some point you are going to want to deprecate them. You have to think about the next five plus years out when you're implementing some of these things or developing these APIs, because, like you said, you're going to be stuck with it for years.

Even these seemingly simple requests that get turned down may appear to the outside world as Apple doesn't care about the little guy, or they're squashing third parties, or they're going to [indecipherable 16:10] lock me next year.

It comes from that hard fought knowledge that every time something relatively simple has worked it's way into an interface, or most of the times that you've tried to cobble over a problem with an API, or provide some new functionality by some "clever trick", those are the things that are going to bite you in the ass hard in three years.

You're going to look back and say, "Why did I ever listen to such and such who was saying, all you got to do is?" Or, "How did I convince myself that all I had to do is?" It's hard to say no at those moments, especially when the request is framed as being so seemingly simple.

This is the thought process that goes behind it; How do you create this smooth experience for customers release to release, upgrade to upgrade over time and make it so that...The thing is if Apple wasn't so good at making it so that these upgrades from one version of iOS to the next was so seamless and so easy...

If all this work didn't go into making it so Apple has this great deprecation strategy, then would Apple have the upgrade numbers that they have? They wouldn't. People would be scared shitless to put the new version on, because they talked to a buddy who, "Hey, I upgraded to iOS 7 and 4 of my apps broke. Stay away."

Right? Pretty soon, that spreads, and all of a sudden...it looks like Android, where almost nobody upgrades, and you just live with the OS version that's on your phone. Now your developers really suffer because of it.

Guy: I think iOS, as far as I can remember, I believe it's the first operating system that people were kind of cool with updating. You'd have to go buy a new Windows. Installing a new Windows was always a pain in the ass.

Even the Mac people would wait a long time, but the iOS, people updated that very quickly, even when you had to do it through iTunes.

Nitin: That's true. The Mac now is in pretty good shape that way as well.

Guy: It's not quite as good, but it's still good.

Rene Ritchie: For a desktop, it's amazing.

Nitin: Exactly. The numbers that you see even for the desktop, it's phenomenal. That helps the company run smoother on the inside as well, when you can count on the fact that a large percentage of your customer base is running this known version. That helps. I'm sure, Guy, you've experienced that too, when you've developed software.

Guy: Yeah.

Nitin: It allows you to make simplifying assumptions in other ways that can speed up your development time or speed up the time to market.

Guy: Software's chaotic enough. Having a chaotic substrate is even worse.

You guys internally, on the apps, clearly the number one consumer of UIKit, which didn't even exist. [laughs] What's the process of figuring out what you were going to take to build UIKit? Now everybody loves UIKit, they clamor for it to come to the Mac which I don't think it will and probably shouldn't.

Everybody loves UIKit. You guys sculpted it. Was there a guiding principle behind that?

Nitin: Early on, literally after we first had a framework, it was Scott Herz who came up with the name UIKit. We knew that we didn't want to call it "AppKit" or "MobileAppKit" or something like that, "AppKit" for reasons that we didn't want to confuse ourselves.

In the early days, we were doing so much development on the simulators, which was running on OS X. We knew it was going to become chaotic in another way to use the name AppKit. "What AppKit are you talking about? Are you talking about the purple AppKit...?

Guy: [laughs]

Nitin: ...or the OS X AppKit?"

Shortly after UIKit came to be, the big motivation for the initial version of the UIKit was we knew that we had this common functionality that was going to be exposed to multiple applications. We knew we had a very small team of engineers working on the apps and we had a lot of functionality to get in.

Early on, in some ways we had to make guesses as to whether or not somebody else would find some piece of functionality useful enough to warrant putting it in a shared framework as opposed to keeping it in the application itself.

We wouldn't want to keep everything in the apps themselves, so that "Now, if you fix a Mobile Mail UIScroller bug, now you have to fix a SMS UIScroller bug and Photos UIScroller bug," and on and on it goes.

There's utility in having these shared frameworks. We also knew that we couldn't keep everything in the apps. All functionality couldn't be pushed into the apps and keep everything isolated, because then you run into the fixing the same bug a million times problem.

We didn't want to be too quick to push everything down into a shared framework either, because then if you have a relatively lightweight app that you want to bring up, now you've got this very porky framework that has all this functionality that you would never use in your lightweight app.

Now, you have to somehow load and initialize some of that code to become available to this lightweight app that would never use it. Even when figuring out where you want functionality exposed, you have to figure out where you want to put things. You can't be too quick to stuff it all in the app or stuff it all into a shared framework.

The initial rule that we had was a rule of three [laughs] which was as soon as you identify a third real client for some shared functionality, that functionality moves down into a framework. In other words, the first app that had something that looks like a navigation controller, it had to be Mail.

I'm pretty sure that first version of that lived in Mail until the SMS designs, we started implementing those. The third thing was...Maybe it was Photos or it might have been Safari in parallel by Richard Williamson's org at that time.

As soon as we identified a third client of any particular functionality, it was deemed shareable. That functionality made its way down into UIKit. Slowly, that was how UIKits came to grow.

We knew that every time UIKit grew, we had an understanding that there were three clients for any piece of functionality in that framework. That was the initial shaping of UIKit.

As far as the API philosophy, a lot of it was very deliberately...We knew we were going to use Objective-C. Gosh, we could talk about that, too.

[laughter]

Guy: Was that ever in doubt?

Nitin: Yeah. Early on, one of the first things that I was involved with after moving up to the Human Interface hallway and starting on these early designs, was the discussion around the API. "What language are we going to use? What facilities are we going to count on?"

There was this very early analysis that was done. The three front runners that we had at that time, that we had identified, were writing our own, something along the lines of UIKit which we know the history there.

Another one was using Web technologies. At the time, it was relatively new. I believe it had already been released.

Guy: [indecipherable 25:56]

Nitin: In Tiger, yes, there were widgets. There were the Web widgets that were available to you. I forget how you bring it up, but there was the screen to the left on the Macintosh.

Guy: [laughs] Dashboard.

Nitin: Dashboard, thank you.

[laughter]

Guy: Nobody in my business...

Nitin: That's a little sad, isn't it?

[laughter]

Nitin: Dashboard. Yes, something very similar to Dashboard and using Web technologies, HTML, CSS, those types of things for defining your layout, and JavaScript in there as well, for actual apps.

Guy: The "thinky bits."

Nitin: The thinky bits [laughs] . Thank you.

[laughter]

Nitin: I knew there was a technical term for that. The third one was AppKit, was bringing a pared down version of AppKit along.

I remember, we had a couple of meetings about that where, first of all, there was a brainstorming meeting. There were early pros and cons for each approach. There was a "Go away and do some studying and let's meet in a week or two," something like that.

I'm pretty sure in that first meeting those three major solutions. That was the short list of what we were going to use to implement the UI on iPhone.

When we met a week or two later, I remember very early on...It was Ali Ozer and someone else, I think it might have been Kristen Forster, representing the AppKit proposal. [laughs] The AppKit delegation was Ali and Kristin.

They had come back and said that "AppKit has too many other desktopisms that are buried in there, and too much baggage to make AppKit a viable alternative."

Guy: What a gas. It's been coming along since the early 90s or late 80s. I'm sure there's all kinds of if-Fs, all kinds of wacky stuff in there.

Nitin: A lot of it was the if-F'ed up baggage and things like that. A lot of it was also, by then AppKit, it had started using Carbon Events for a lot of its event propagation. We weren't going to be using Carbon Events.

Does that mean that we have to take AppKit and heavily modify the code to remove the use of Carbon Events, or do we now have to pork Carbon Events to make AppKit work?

There were things like the menu bar as well. We knew from those early designs we had a status bar, but we didn't have a menu bar. There was no interest in having anything like that.

I believe menus were built fairly heavily -- I'm sure somebody is shaking their head out there -- on the Carbon menuing system.

Guy: Yeah, it was. Like 10.1 or 10.2 or something. Maybe even 10.0, because at one point, they stuck it into the Carbon stuff. I remember a bunch of stuff broke from the NeXT days.

You used to be able to put custom views in there, and then it broke, and then it came back, and whatever. Menus at one point took a bit of a beating.

Nitin: Team AppKit, for starters, they were saying, "Really, you shouldn't use this technology," which was a big, "OK, we're not going to second guess you here." [laughs] A lot of the reasons were related to baggage from the desktop side and not having a clear understanding of how to proceed.

If we chose AppKit, do we start taking out this if-Fing, adding more "if-Fs" to the AppKit code base? By the way, from what I recall of the AppKit code base, I think it's relatively clean of if-Fs to a certain extent.

Guy: I was cracking a joke on that video. [laughs]

Nitin: Foundation on the other hand is littered with it.

[laughter]

Nitin: ...Oddly we took foundation on the IOS.

Yeah, on the adKit side they were arguing against it, they had very good reasons for it, and it was pretty much decided, OK, that wasn't going to be the choice.

On the web side on the other hand, there were a couple of guys from the Safari team and they were very strong proponents of web technology, and saw this as the future of computing, that this is the way things are going.

Some of the biggest examples that were given, in addition to dashboard and the gazillion widgets that are coming up...any student with a computer and BBEdit could go right to widget, and isn't that exactly what we want for the phone

There were compelling reasons there, right?

Guy: Right.

Nitin: On the other hand, there was also an understanding of what the performance was like of dashboard at the time on Tiger, or whatever release had come out, and there were some hard questions around that.

Specifically...and a lot of it was anecdotal, but depending on who's asking or who has the anecdote...for example, if it's Scott Forstall who has the anecdote, what are you going to say?

It's not going to be "Oh, well, you're one data point." You know, that's a little bit bigger than just one data point, you have to take that pretty seriously.

We launched into this discussion about performance and whether we were going to be able to do the things that...by then, we had already had an understanding of...we knew that we were going to want to have a contact's list, right?

There were no discussions about having any limits on the number of contacts, right? This was not going to be an old school, this is not going to be your dad's Motorola or anything. You don't get 100 contacts and that's it, right?

It was you get as many contacts as you have, right?

Guy: Right.

Nitin: That poses some pretty difficult problems if you're trying to scroll a very large list of data on arm class hardware, and now you have web technologies in between various types of markup and DOM trees to be manipulated and things like that.

You know, lots of memory being allocated and de-allocated all the while. The anecdote that a lot of people had sort of latched onto, myself included was at that time I had a Power Mac G5.

I had this super computer at my desktop. I knew that if you tap the dashboard key your machine would pause for a second, and this is on a super computer. What we're advertising is a super computer.

A super computer is pausing, trying to load these widgets. If a super computer can't load these widgets and bring up these views quickly enough, why on earth do we think that it's going to be any faster once we get to...what's going to be the major breakthrough that's handed down maybe by space aliens that's going to make this work well on arm class hardware.

Rene: As a quick programming note, Don Melton told almost...the flip side of this story, agreeing with you completely on a previous episode of vector. I'll put it in the show notes.

Nitin: Oh, nice. Excellent, and I would love to talk to Don about all this now too. I mean, I think we're both pretty clear on

Rene: That can be arranged. [laughs]

Nitin: That would be great, but yeah, those are the reasons that even using web technology...even at that time it was viewed as this is the future of development.

Palm took off running with what I think was closest to the model that was being proposed by the Safari team at the time.

Rene: I deeply truly loved web OS. But web OS 1.0 took me 24 seconds to launch the calendar app.

Nitin: Yes. [laughs] There's a lot of love going around for web OS these days. It was like a five year anniversary that went by.

Rene: Yeah.

Nitin: I liked web OS as well. I happened to know the guy who was sort of the main catalyst behind web OS, a guy named, "Andy Grignon," who worked at Apple, by the way, worked on dashboard at Apple.

He's got some great stories to...

Guy: I didn't know that. That's funny.

Nitin: He later went to Palm to work on their new phone, the Treo was long in the tooth, and the iPhone was out by then, so he sort of took off on the web OS route. The interface is beautiful, and the functionality was amazing.

I don't think the iPhone would have the features that it does today without web OS coming out and sort of demonstrating that there's a real need for this, but like you said, Renee, "The performance was abysmal."

You know, it's easy to gloss over that now and be nostalgic about the great stuff, but there was...

Guy: It's like how everybody loves your Amiga.

Rene: Yes.

Nitin: Right. It is the Amiga of the smartphone world, web OS.

Rene: You know how to hurt a guy.

Nitin: What's that?

Guy: I'm sorry?

Rene: You know how to hurt a guy.

Guy: I'm sorry. I like Amiga, I don't have a problem with it. I'm saying, I agree. Where we are?

Yeah, you end up settling on creating your own UI kit from scratch, which I think, well, I mean 20/20 hindsight, but I think that's the obvious choice now.

Nitin: Yeah, it's true. I think it was...I mean, at the time it was almost by default we had the go off and go create your own thing, but even after that meeting, after we had sort of struck down the app kit solution and the web technology solution we still never quite got a thumbs up on "OK, go do your own thing."

The...And this is one of the things that I remember very vividly, and in some ways very fondly about kind of those early iPhone days was that we didn't get the thumbs up necessarily on the go develop your own thing.

After a day or two and after realizing that nobody was probably going to come by and say, "Go do that. Go make that thing happen," we decided to make it happen.

I imagine this is the type of thing that happens at a lot of companies, and so if you're at one of those companies where you're not necessarily given the thumbs up to run in a direction, but you know you have things to do, and you know what you're supposed to not do.

A lot of times, that's as good as it's going to get. You're not going to get the edict from on high that says, "You need to go make this happen this way."

At those moments, when you're in a situation like that and I'm not saying to be a cowboy and don't listen management and go do your own thing and you'll be allotted for it later, but at those moments you also...those would be the moments when you can sort of define the future, when you can have a big impact to by being the person who's willing to hunker down and make something happen.

That was something that I had seen earlier on kind of around the Copeland time frame.

After hearing from various people that something like an appearance manager type thing could never possibly work with the Mac toolbox and you're going to have all these compatibility problems and this patchwork of apps. What about the apps that have custom looks and things like that?

The team that decided to actually sit down and hunker down and do the work and make it happen was ultimately the team that ended up shipping what would become the modern toolbox on Mac OS 8 and 8.5.

That was something that I had sort of carried on from those days was oftentimes the last person to commit code wins.

You can talk as much as you want, and you can tell people to not do things or talk about why things are a bad idea, but the person who's going in and committing things and making changes and developing something, they're going to win over the biggest nay-saying windbag.

It's good to sort of keep that in mind and don't become stifled at those moments because somebody is saying, "No" or nobody said, "Yes."

At those times, that's when you can make a big difference, and you can really shake things up as well.

Ultimately, that was what happened was...I'm pretty sure it was Scott and I and Gregg and some of the other guys, sort of the original team of three. We were sitting around and talking about "OK, well we had this meeting.

Here's what was shot down, and we never quite got what we should do, but we've got designs to get through and we've got demos to deliver."

This is what we believe is the way these apps should be developed, and specifically that was create this brand new framework, but very much in the spirit of app kit, and use a lot of the same sort of principals and even some of the same sounding names, similar classes, and things like that.

We wanted people...we knew had a fairly large body of engineers to draw from within Apple to help develop these apps, and we didn't want to throw them in front of something that was completely unfamiliar and ask them to get cracking. We knew that we had to make something early on that.

If we made something that felt familiar and if it felt like it's not broken so let's not change it just for the sake of changing it...there's a lot of utility in following those similar patterns, and making it so that an engineer is productive on day one instead of day 20.

Guy: Rather than rethinking idioms like a responder chain or a target action thing, you've got those to hand. You can just use them. You don't need to start from first principles and think about "OK, well, what does UI mean?"

Nitin: Yeah.

Guy: You can sort of, you can hit the ground running and get something out.

Nitin: Right. There's a lot you can leverage from a lot of previous work and everybody is comfortable with it.

Guy: Looping back to Wildcat. How early did that start, and was there a lot of consideration for that, for a different form factor when you were doing the original form devices? Was...you know. Did you adapt as you went?

Nitin: It's funny because now in hindsight, like I had mentioned, the first prototype display slash input device that we saw hooked up to a Mac that had that original iPhone user interface.

At that...a couple of podcasts ago I had mentioned that, a couple of hours ago anyway, it was a tablet form factor and it was sort of squeezed down into a corner to sort of be the phone form factor.

Very quickly even at that time we weren't thinking about the fact that "Oh, we might want to make a tablet someday."

Instead, I think...and maybe it was being super practical or just being scared that we just had not much time at all to get working on this thing, but from those early days, even though we had this prototype hardware, we weren't really thinking too much about a tablet or a different screen size.

We were thinking about that 1.0 phone product.

Guy: Yeah, I think if you'd be thinking about "Well, we're going to create an ecosystem," you'd never ship anything.

Nitin: Exactly. I think that's one of the things about ecosystems that people tend to gloss over is that a lot of times ecosystems are created early on from a great product, or from a popular product, and then that expands into an ecosystem.

It's rarely the other way around where you have this ecosystem and nothing really for customers to gain value from, but "Look at this lovely ecosystem." You know, there's nothing there until you have a product.

Guy: It's going to sound goofy, but their ecosystems are organic.

Nitin: Yes.

Guy: They'll grow from the products and the access that you provide to the products, because I mean, you guys didn't even ship an SDK until 2.0.

Nitin: Right. Exactly, and there was a lot of talk that we're focusing on the product.

This is...remember, at that time what we were modeling ourselves after in a lot of ways was the iPod, and there was no ecosystem around the iPod.

I think even later...I mean, maybe there became an ecosystem with kind of those downloadable apps, those $4.99 apps that you could buy through iTunes or...

Guy: Yeah.

Nitin: You know, maybe that's kind of an ecosystem kind of, but...

Guy: Maybe. Yeah, not.

Nitin: Not really, so yeah, we didn't start thinking about a tablet form factor until I think it was probably late...I certainly didn't start thinking about a tablet form factor or even considering that until late 2008.

You know, I think we went that far. We went all the way through to 1.0 and 2.0, and maybe quite a...part of the way through 3.0 before the word came down that "OK, we're looking at shipping it sort of a tablet form factor, and what does that need."

Guy: 3.2 was kind of interesting. It was spun out.

Nitin: Right.

Guy: Three shipped on the...I'm trying to remember the timeline, but three shipped on the phone.

Rene: 3GS, yeah.

Nitin: 3GS, and then six months after that the iPad came out maybe?

Rene: Yeah, it was so that...yeah, 3 GS shipped June or July, and then the iPad event was January and then it shipped in April.

Guy: Yeah. 3.2 was a bit of a different beast, because it was like a little bit...you know, you were shipping to us at one point.

Rene: Two sets of apps.

Guy: Yeah, because 3.2 wasn't on the phones I don't think.

Rene: Nope, never.

Nitin: Right. Our big unification point was going to be sometime after 4.0, because by the time 3.2 shipped we were already well on our way to doing a lot of the 4.0 work as well, so there was some odd overlap that was happening at that time too.

Guy: How did you manage that, because you guys had a very busy few years?

Nitin: Yes. [laughs] Luckily, around that time...well, then we should...maybe we should talk a little bit about sort of the evolution of iPad as well, sort of the definition around the screen as well because...

Guy: Definitely, yeah.

Nitin: Do you want me to do that now and then we can get back to...

Guy: Yes.

Nitin: How the hell can we do that?

Guy: Yeah, definitely. It's your show.

Nitin: It's your show, but I'll do what you tell me to do. The initial...very early on when we were hearing that we were going to ship a tablet form factor, the next thing that came out of people's mouths, and by people, and this is even Steve Jobs at this time too, was "Think of it as a very large iPod touch."

From a design standpoint of...design of the software, think of this as a large iPod touch. Believe it or not, it took him some doing to sort of convince him otherwise.

In other words, sort of the easiest example was like let's say the address book. You bring up the address book app and it's a big table that takes up 90 percent of the screen and you've got a couple of widgets on top, a couple on bottom, a status bar.

Now, if we stay true to this...you know, this is a really large iPod Touch. What that really means is you're pushing the widgets out to the corners of this very large form factor.

You have this big honkin table with names crammed way over on the left hand side and all this dead space taking up the rest of the screen.

Guy: Yeah, it would look horrible.

Nitin: It would look horrible. It wouldn't do what you want. I mean, that's...it would look...frankly, it would look like a lot of Android tablet apps do today, right?

Guy: Right.

Nitin: Look at how that tablet app market is doing there too. Really, it took some demonstrations from our HI team sort of showing that

Guy: That's not what you want.

Nitin: ...or Mail is an even better example, where on the iPhone you've got this list, the scrolling list of mailboxes. You tap on a mailbox, the whole screen wipes over, and now you've got this scrolling list of messages. You tap on one of those, the whole screen wipes over, and now you've got this single message.

When you're picking a mailbox, is that the only thing that you want to be on the screen, until you've actually picked a mailbox? Of course not! It would look silly.

Guy: The way you describe it, I even feel like you get motion sickness. The entire screen is just constantly shifting away from you.

Nitin: Exactly, and it's not taking good advantage of this nice, big screen that you have. It's funny because there are so many times when we'd hear that Steve wanted some new feature to go in. Nobody'd planned for it, accounted for it, or anything like that and, "Oh, my God. How the Hell are we going to do this?"

Then we have to rally Scott Forstall and other people, to try to go and talk to him, talk some sense, and explain the schedule. Maybe it gets through, but oftentimes it doesn't. We just have more work to do.

The interesting thing here was that this was a case where Steve was arguing for us to do less work and, from the engineering and design side, we were saying, "That's going to be a terrible product."

[laughter]

Nitin: Really, we need to do more work. I don't think it was hard to convince him, especially after seeing some of these concrete examples. We really needed to re-think the UI for a tablet and do the right thing for it.

That was the early iPad UI development. We went from making a big iPad Touch or a big iPhone, to what we have today, which everyone agrees now is a much better experience than that.

Guy: Oh, for sure, yeah. It would have been flop if you hadn't done that.

Nitin: Right. It would have been met with a lukewarm reception. Maybe you're not getting a great value out of having this large screen.

Guy: It's funny because it was met with lukewarm reception.

[laughter]

Guy: Which, surprise, was not to be the reality of the situation.

Nitin: Yes, exactly. As far as, "How the Hell did we do all that work?" the short answer there is the OS X development teams started pitching in in a big way, on iPad development. With that, there were some issues around coordinating the work and who's going to do the work -- the personnel side, the division of labor between the OS X and iOS team.

As you mentioned earlier, there were even questions around, "Do we have the same app that can dynamically relay out its views for an iPad? Should we have separate apps? Should we have the same app, but different installations?

You installed internally what we had called Mobile Safari from the iPhone installation image, and it's laid out for an iPhone? Then you install a different image that has a different Mobile Safari on tablets, and now you get the tablet layout?"

Very quickly, to help preserve our own sanity, we were striving, as much as we could, to make it so that we had a single app that could dynamically relay out its views, or initialize new classes for its views, if you're on an iPad or an iPhone.

A lot of that was so that didn't ask the question, "Which mobile mail were you running? Are you running iPad mobile mail or iPhone?" Depending on how you have that laid out in Xcode and things like that, your classes, you could very quickly get into a situation where you're implementing features twice, or you're fixing bugs twice.

Guy: Yeah, just the worst.

Nitin: Very early on, where we could, we wanted to have a single app that could dynamically relay itself out. As anybody who goes spelunking through the 3.2 images will find out, we did have different versions of the same apps, based on our working relationship, either with the OS X team or maybe on the iOS side itself.

It was largely, "How are we going to chop up this work? How are we going to hit these dates? What's the quickest way? All the while, let's work really hard to not paint ourselves into a corner, where we've got our own code that's ifdef'd all to shit, or turned our own code base into an unmanageable mess."

Even in those cases where we had separate apps, and the one that comes to mind, for whatever reason, the most is probably address book, but maybe calendar we had two versions, as well.

The iPad calendar, that very early version, was largely developed by the OS X team, and the phone calendar was developed by the iOS group.

I believe they both loaded the same underlying frameworks to get their work done, but it was actually two separate apps. Luckily, by the time we got to...it wasn't even 5.0. I'm pretty sure it was 4.2 when we had pretty much unified everything.

There were one or two cases where that wasn't the case, but, from what I recall, things were largely unified and the world had become sane again. [laughs] We went through this crazy diversion for 3.2. And 4.0, like I had said, was well under way, as far as development goes, for the iPhone and iPod touch, so there wasn't chance there.

Guy: Yeah, the iPad didn't get 4.0.

Nitin: Yeah, exactly. The iPad didn't get 4.0. I think 4.2 was the first unified release between iPhone and iPad. [laughs] That's one of those things that...

Rene: Hurray!

Nitin: ...nobody's ever going to, on the outside, think that that's a big deal. Again, when it comes time to shipping 5.0, 5.1, 6.0, and later releases, that's that technical debt that you have to be addressing. You have to address it all the while.

At any moment, it's going to be so easy to ignore it or defer the work and say, "Well, we know we want to do this other stuff that's more important. Can't we defer it for another year?"

Rene: It gave you time to make the clock app for iPad.

[laughter]

Nitin: See! Everybody wins.

Nitin: It's been one of the perennial challenges around software development. How do you express to upper management that the infrastructure work that we did a year ago has made it so that we can run faster this year? That's a very difficult thing to get across.

Guy: Even at a company like Apple? I know you've got a very strong technical management team.

Nitin: Even at Apple, and it's just at those moments. It's not so hard that we didn't do it. To management's credit, we did have time to do this infrastructure work and create new features and new functionality to help drive sales.

Even if your management is very technical, at those moments when you have to decide between some feature that you think is going to help you sell more iPads or more iPhones and doing this infrastructure work, you know...I always felt I knew. I knew where marketing was going to fall on that decision. Right? [laughs]

Guy: Oh, yeah.

Nitin: I was on the engineering side and I knew where I fell on the decision. Even if you have that very technical upper management, it's hard to say. Those are the types of things that it's hard to say, "We really need to go back and shore up that work," or, "We really need to spend some time and..."

Somebody on my team used to refer to it as stopping for gas. You've got to stop for gas every once in a while. Even with highly technical management, it can be a challenge, at times, to get that through.

To Apple's credit, it did get through and I it's made it so that we've been able to have this relatively predicable release cycle where there aren't too many public embarrassments. Things don't feel like they're slowing down yet. I think the WWDC shows that the pace is continuing, which is great.

Guy: How was the yearly release schedule? To me, a year is never a year when you're doing software development. You've got maybe six productive months in there.

Nitin: Yeah.

Guy: Three shoring up the stuff you just shipped, three at the end trying to get it out the door, then in the middle you've got six months where maybe you can do some work.

Nitin: Right. That's true. People have never had a year's worth of time to do development on next year's release, as you said, because there are these other things that are pulling on you. To me, it felt like once we would go through feature review...and the actual task of going through feature review, that's evolved over the year, too.

Really, after feature reviews, generally speaking, you had about two to three months before the feature complete date came. Feature complete, back at that time anyway, was early February or March. For a fall release of iOS software, feature complete is somewhere in February, or maybe early March, at the most.

After feature complete, there's the driving for WWDC. Now, there's this wobbly piece of shit...

[laughs]

Nitin: ...that has all of this functionality -- and a lot of it is, at best, half-baked -- that's in. So, you've made your feature complete deadline. OK, it's all in. You can demonstrate to QA and management that it works, but it doesn't work that well.

From that moment, if you have an early June WWDC, probably from March until mid-May, a big crunch takes place to whip this new functionality into shape, so that it's good enough to send out as a first seed for WWDC.

There's lots of QA happening, STK development is happening, documentation is being updated, and things like that. Yeah, really for future work, for a yearly release, we tended to have about three months of actual implementation time before we came to, "Now, get this thing into shape, refine it, fix the bugs, and address any issues that we've learned about."

That's the other thing, too. I say three months a year, and that's to implement a feature to probably 85 percent completeness, even though we always called it "feature complete" because it was feature complete as the feature was defined when we had started the rush.

Guy: Yeah, and then you learn more about what the problem is, actually solving it, when you...

[crosstalk]

Nitin: Exactly. We learn the problems either as we're developing it, as we're refining the UI, before that first seed. Then even after the first seed or a couple seeds come out, we're starting to get feedback from outside developers about those seed builds. Even based on that, there have been a lot of times where we've adjusted features or functionality, based on early feedback from developers.

This is my way of saying, [laughs] if you're a developer out there, I have no interest in this anymore, but please file bugs because it makes for a better product for all customers later.

That is really red. It's rough on the inside because when you first start getting those bugs coming in from developers, it's like sipping from a fire hose. If there's one bug that you knew went in, some shitty crashing bug that you know went in, but you didn't have time to fix it, you're going to get a gazillion dups on that thing.

Hopefully, you have it fixed for the second seed.

Rene: One thing I've heard and I don't know if it's true or not, but firewall all the bugs that you can as early as you can because as you get closer to release, you only start focusing on the really big bugs.

Nitin: I think that's true. Generally, it's best to not to second guess what Apple is going to do with any bug, and just file them when you run into them or as you hit them.

I understand that can be a hard thing to do for developers who've seen their bugs fall into a black hole and lose faith. Certainly, as you get closer to ship, the types of bugs that are going to be considered for fixing, they need to be lower risk or high priority, obviously.

Guy: It's a pragmatic approach. I had dinner at the end of October in DC with mutual friends. [laughs] Their reaction to the bug reporting tool that's in iOS Beta was kind of funny.

[laughter]

Guy: Apparently, it really works. They got a lot of positive...

Rene: Like millions or something.

[laughter]

Guy: It's way up there. It had been out for three days and it had hundreds and hundreds of thousands of bugs.

Rene: Even I'm using it, which is astounding.

Nitin: How cool! That's great.

Guy: It could be too much. Maybe the bug screeners can't get to stuff, but it's an interesting idea.

Nitin: That's a huge problem. If you're at Apple and you're a bug screener, the time between June and mid to late September is just awful. There tends to be these big spikes. I think it's one day to two days after a seed goes out, we would watch these graphs of the incoming bugs.

[laughter]

Nitin: They would spike, if you had some horrible bug that went into a seed that was too risky to fix at the last minute, you knew that you were going to be buried in bugs. You could visualize it as well.

Our screeners worked so hard during that time.

Guy: Yeah. Break out a few bottles.

[laughter]

Nitin: Yes.

Guy: It is annoying when you get a bug back that asks for a test case. It doesn't make any sense, given the content of the bug. Given how much stuff these guys are doing, whatever [indecipherable 1:12:18] .

Nitin: Definitely.

Guy: 4.2 is the re-unification. What came out with 5? I'm trying to remember.

Rene: ICloud.

[crosstalk]

Guy: What was the goal? I'm trying to come up with a nice way of saying it. This is obviously a company-wide direction, and you're given a mandate to "cloudify" your phone. [laughs]

What does that look like?

Rene: Or at least obliterate mobile media and re-cloudify it.

Nitin: [laughs] Some of the earliest discussions that I remember about iCloud were in meetings with Steve Jobs. He would cite things from "The Innovator's Dilemma." He was very, very aware of the fact that Apple had done great business up until that point by pushing this idea of a digital hub, and pushing the Mac as being the center of your devices, and iTunes being the thing that helps Rhythmix burn and sync your music between different devices.

Guy: Where he introduces that idea, it's like a Babe Ruth moment. He lays out exactly what the strategy's going to be. Over the next 10 years, he executes on it relentlessly.

Nitin: That's true. That's a good point. I hadn't thought of it that way.

To his credit, he understood the home run that Apple was able to hit so many years earlier was very quickly going to become a liability to the company.

There was iCloud, but if you recall, even at that time, in order to set up an iPhone, it required having an iTunes account. You could not do that initial setup without a PC.

Rene: A USB cable.

Nitin: Right. You had to have a PC connecting to it. You had to have your phone connected to a Mac or PC to go through the early setup via iTunes.

Very early on, this was identified as a big blocker for emerging markets for starters. At that time, it seemed like an oddity but it was understood that this was how things worked in the developing world.

At that time, people had access to smart phones long before they had access to computers. [laughs] There was this problem then where yes, you could maybe go and buy an iPhone or you could get somebody to bring one over from the states for you, but God help you if you didn't set it up before it came across, because now you've got to go find a PC running iTunes that's connected to a network in order to complete the initial configuration of your phone.

What was seen previously as a strength, where it was, "You don't have to use your shitty little phone to try to set itself up and talk to a carrier," it was understood later that, "Oh no, that may work for US markets or maybe a little bit of Europe," but as we moved into Asia, South America and other developing markets, that had become a huge liability. We had to address that, too.

Rene: It was probably fair though. In the beginning, almost everyone had all their information on their local machine. It wasn't until mobile media where you had CardDAV and CalDAV and IMAP and everything starting to go into the cloud that you could then pull down, right?

Nitin: The model that we had been following was the iPod. An iPod doesn't do anything for you unless you have a computer. With a phone, yes, it has a network connection but it wasn't so much of a stretch within Apple at that time. Notice all the conditions that I'm placing on this [laughs] "at that time."

Now, it seems, "What were we thinking?" Of course, networking or high speed cellular networks are ubiquitous, but we were coming out of this world of the first iPhone. The best networks you could get on were Edge.

Now, if you get on Edge, I don't know about you guys, but if my only choice is Edge, oftentimes I'll turn off Edge because it's more frustrating than not having a network connection.

That was our best choice seven years ago. [laughs]

We were coming from this world where, by necessity, a computer was part of your digital hub and was needed to help set things up. Very quickly, the world was changing. iCloud and...Gosh, what was the term that we were using internally? I think it was PC3.

There shouldn't be any experience on your phone that requires a PC. If there is, we need to think hard about what that is, either get rid of it or change it or add functionality to iCloud or something else.

That was the early genesis of what would later...Obviously, there was MobileMe by that time, but it was famously bad as well.

It's funny because even at that time, there were these discussions internally -- I'm going to say it -- there were discussions internally about what should this iCloud service be? Very clearly, from very early on, it was understood that "We have to make this thing free. We have to have a free service out there and a free solution out there, because on the Google side, there was Gmail, Calendaring and Contacts." Everything was free on that side.

At Apple, it was understood that it had to be free, but on the executive side, I vividly remember there was this discussion about having a five Gigabyte limit to mail storage. Even at that time, and we're talking mid to late 2010, even then it was understood that five Gigs was pretty tiny. It was, "Are we going to come out with that message?"

Guy: What did Gmail launch at? It was one Gig, which seemed huge at the time, but that was back in I don't know when.

Nitin: Probably back in 2006.

Rene: It scaled quickly.

Guy: 2001, yeah. At least for a while, famously, they had a counter that kept going up on how much space you had. I think coming up with a hard fixed limit at five Gigs, that would have gone over like a lead Zep.

Rene: Which is like the original iCloud limit was, anyway. When you discount all the free stuff they give you, like Photo Stream and Backup, the non-free stuff was still a five Gig limit until this year.

Nitin: Was that a five Gig limit?

Rene: Yeah. Then you had to start paying for more. It ended up being 100 bucks for 50 Gigs. That was the top tier until again until this dubbed up.

Guy: I know I pay money for it.

Rene: Me, too.

[laughter]

Nitin: I pay money too. Sorry.

Guy: I have nothing. Please. There was this struggle over the five Gig limit?

Nitin: Exactly. There was a struggle over the five Gig limit, but it was understood that Apple had to have a viable cloud-based service out there to compete in the new world. Some of it started with Google. I don't remember what Palm was offering at that time.

Rene: Palm was weird because they had the whole Synergy service where they would amalgamate everyone's offerings, and then they had the Palm front end as well.

Guy: At this point, Palm was trying to stay in business.

Rene: It might have been going out of business. [laughs]

Guy: I don't know if they were a real concern at that point.

Nitin: That's a good point. That's true. You're right, they had Synergy, which made it...It wrapped with other services.

[crosstalk]

Rene: ...unified view.

Guy: RIM still had BBM.

Nitin: Yeah, the...

[crosstalk]

Guy: And the NOC stuff, right.

Nitin: Exactly. That was the early days around iCloud, was this understanding that there had to be this service. We had to enable it on iPhone, and we had to make it so that it was completely PC-free, that the whole experience around iPhone was PC-free.

Guy: That must have been a huge amount of work though, to get it so that the OS could download another version of itself and upgrade.

Nitin: Oh, yeah.

Guy: If you've been building with the premise that iTunes is going to fix it, it's a bit of a leap. Right?

Nitin: That's true. We had some pretty good choke points in place already by then, though.

Guy: OS X does it. The base operating system, you quote-unquote "know how to do it." Right?

Nitin: That's true. We were able to do obviously USB or DFU upgrades by then, as well. Because we had these well-defined points where we interacted with iTunes, from what I recall, we were able to really leverage those and make it so that if we were downloading something.

If it was coming from iTunes, or if it was coming directly from a server, that might look different on the other side of this choke point. But on the inside of iOS, it looked largely similar. Of course, that wasn't perfect. There was work to do there, but we were able to, from what I recall...

Rene: Leverage a lot of the work?

Nitin: Exactly.

Guy: That makes sense. At a certain point, I guess it doesn't matter how the functionality gets tickled. You're still doing the same series of steps at some point.

Nitin: There were some things that were brand new that we had to create, like the first time you use your setup and things like that. At some point, once you lay down those settings and then continue booting into the rest of the iOS experience, the rest of it can be largely simpler.

Guy: I'm trying to remember if the Apple TV was auto-updating before. It was, right?

Rene: Yeah, 2010. I think the first Apple TV did it already. I don't remember if the Tiger-based one did, but the iOS one did.

Guy: I do seem to recall that being like a yardstick.

Rene: I think the Tiger one must have, too. People didn't understand sometimes when they got that error and had to take a micro-USB cable to iTunes.

Guy: That got weird quick.

[laughter]

Nitin: Damn computers. It gets me every time. I don't know about you guys. I have a Harmony One smart remote control. In order to sync that thing, once you diddle some of the settings or whatever, just configuring the thing on a computer is the absolute worst part about having that remote control.

Once you close up your computer and everything is synced up, it's beautiful. It's fantastic, but using that computer is so weird. Especially when it says, "Oh, if you want to sync your settings directly, plug your Harmony via USB into your computer." At those moments, it just feels like, "Is this 1999 again?"

Rene: I bought it, and I rage-quit it because of that. I just couldn't take doing that anymore.

[laughter]

Nitin: You bought the most recent ones?

Rene: No. I bought it a year ago, or the year before. I'd set it up, and it didn't give you the ability to line item edit. Which drove me crazy, because I had a weird setup and I wanted to be able to tell it exactly what to do, and it wouldn't let me do that. It felt like it was fighting me every step of the way to use it.

Nitin: The most recent one is slightly better, at the very least, in that you can now, if you want to sync settings to your Harmony, that hub that you have, you can now do that wirelessly. You can actually trigger that from your phone, but you have to trigger it from your phone in order to make that work. It's still a little weird.

Rene: It's madness.

[laughter]

Nitin: It is weird. I understand why they did it, but it's weird. At least you don't have to plug your hub into your computer via USB.

Guy: This is why I'm a huge fan of that Apple TV remote. Just before the show, I got a text. My buddy was trying to tell me to watch the end of the New Zealand-Mexico game. By the time I could figure out how to get my TV to change channels...

[laughter]

Guy: The guide in it VDraws incredibly slowly, literally like 1984 level VDraw speeds. By the time I did that, the game was over.

Rene: Scientific Atlanta is not your friend?

Guy: No, it's horrible. Technology's awful.

[laughter]

Rene: It's the worst.

Guy: There was a bunch of, for lack of a better word, cloudy stuff that came in. When did iMessage come in, Game Center and that kind of thing? Was iMessage 4?

Nitin: I think that might have been 4.

Rene: I think all that stuff was 5. I think iMessage and Game Center and all of that was 5, but I'm not positive.

Nitin: I think Game Message, or Game Center I think...Game Message, hey, there's an idea out there for the enterprising types.

Rene: Yeah, iOS 5.

Nitin: I thought Game Center came out in 3.

Rene: No. [laughs]

Guy: Do you know what's funny, though? When I do talk to Apple people about this stuff, nobody has any idea what made any release, because it's all a mess.

Rene: It's such a blur.

Nitin: What gets baked and sent out the door at any one point, you can't really remember. By the time it goes out, you're already working on the next thing.

Guy: It was iOS 5, too. You probably started it at iOS 3, but it got kicked out the door at 5. [laughs]

Nitin: Game Center, to be clear, I don't want to take credit for that. That was on Richard's side, as well. That's interesting. Wow, it was 5. From what I recall, that was another one of the apps that set off the anti-skeuomorphism attitude that came later.

Guy: Yes. People unleashed the hounds all over that thing.

[laughter]

Nitin: Let's see. There was iMessage, Game Center. Of course, there was Siri. I think Siri was the big thing that came.

For Siri, we had this third party. We had the Siri company come in. We had to work closely with them. Of course, a lot of the work happened server-side. Figuring out what the division of labor is between what's the device responsibility versus what's the server or cloud-side responsibility, there was a lot of back and forth there, as well.

Rene: How was that? Maybe less so given the fact that the iPad group had worked with the OSM group, but iOS seemed to operate under its own umbrella. Then Siri comes in, which is not even an Apple culture. It's got its own. Probably if anything, it's got more of an academic culture to it. Was that difficult to integrate?

Nitin: It's hard for me to say. I hadn't been through too many cases where we had to integrate with a third party, with another company or something like that. That was maybe the first or second time that I had done that in my career.

We were able to ship on time and get things done. There was definitely a culture clash, and a little bit of trying to figure out what people who previously had leadership roles on the Siri side, where do they best fit in now that we're at Apple.

We had some people who filled similar roles. How do you integrate the person who's the specialist at Siri with the specialist at Apple for an area that's pretty similar? To me, it's hard for me to say whether it was smooth or not smooth. To me, it felt like it could have been smoother, but I'm not sure. That could have been just fantastic compared to other companies integrating small outside companies.

Rene: I'm not trying to be negative about it. Everybody can have the best intentions. If cultures are different, then you need to figure out how to get along with each other effectively. It might have felt a little bit rough, but it came together quick. Between the time that acquiring them was announced and shipping, wasn't that long, it felt?

Nitin: It wasn't. We were operating on the schedules and the volume of deliverables for a few years by then. The pace felt pretty normal to us.

[laughter]

Rene: You had a little bit of extra time, because previously iOS always shipped in June or July. That year it shipped I think October.

Nitin: That's right.

Rene: It was like 15 months instead of 12.

Guy: Oh, the luxury.

[laughter]

Rene: You could let out a pants button.

[laughter]

Nitin: From my narrow-ish view of the integration with Siri, as far as that's concerned, because I think the Siri app was relatively light...If you remember that third party Siri app, most of it was data-driven. In other words, it was the speech bubble metaphor that was used there, and most of what you did was read or view results that came back from the server.

In other words, and not to belittle the work that was done there, but I think the star of Siri was the server. It wasn't that client app. If anything, the client app was almost a proof of concept of what was happening on the server.

My team was largely responsible for client-side development, and we understood that we're probably not going to use a whole lot from that client app, I didn't personally have a lot of that overlapping responsibilities in figuring out what to do with people. I didn't have a lot of that to deal with.

I think a lot more of that came on the server side, and figuring out now we've got this Siri infrastructure, and the way that they've been developing their services and their data center, and how does that mix in with Apple's data center. I bet those stories are way more interesting than the stories that I can tell.

[laughter]

Nitin: For me, a lot of the stories were, there were a couple of product managers who very early on, they themselves were trying to figure out where they fit in, what's their role in Apple. At least on the iOS side, or on the OS X side, product managers weren't heavily...

I wasn't heavily involved with product management day to day. I knew who they were, but they were more on the product marketing side. To me, the ultimate product manager was Scott Forstall, and the ultimate-ultimate was Steve.

[laughter]

Guy: Try jumping into that hierarchy.

[laughter]

Nitin: I remember having these meetings with a couple of these people, and they were very frankly asking, "Where does product management fit in, and where do you see me fitting in?" I was as confused as they were, and tried to explain the day to day work and how that works at Apple, and hoped that they could figure it out on their own.

Guy: That's another one of those things where everybody has the best intentions, and yet there's no clear answer what the solution is. Siri itself seems pretty autonic, in that it's effectively a different mode on the phone. By which I don't mean to belittle it or anything, but beyond the speech recognition to insert into the text view, the Siri search mode is its own thing.

Rene: It's like an adjacent natural language interface thing.

Guy: It seems that way.

Nitin: That's true. You're right. A lot of the UI itself is all effectively in its own app, on the iPhone or iPad. Siri is, you long-press on the home button and you effectively bring up these other views that are in another app. You interact with it there, and then when you're done, those views are dismissed and you're done. That's a fair way of explaining it, again, without belittling.

We understood that Siri was this funnel point for all kinds of information that could be expressed on the device side. If you were asking Siri something related to your calendar next week, we didn't want to have a parallel team that was working on Siri, that was then trying to implement a calendar-looking view.

We knew that in that case, what we would rather have is more of a plugin system where the calendar engineers could take a small bit of data and express that in the calendar-iest way possible within the Siri app, as opposed to having a Siri team trying to mimic what happens in the calendar, if that makes sense.

The discussions that we were having client-side were, "What are the nouns and verbs that we're going to get from the server, and what are the types of things that we're going to have to show in the UI, and then, who's the best person? or what's the best team to implement that last bit of functionality around those views?" We didn't have hosted views or remote views or anything like that. We had this plugin system instead.

Guy: It seems like in the future it'll move to...Maybe it does already now, but the hosted view kind of thing. I wrote a while ago -- I'm looking at it now, back in 2001 -- about a Siri API, where I say it's not coming anytime soon, and that the reason is that Find My Friends basically ended up getting hard-coded.

I made a joke out of it. I had a fake conversation between developers and all kinds of different people. I was joking, and then I got an email from a recruiter wanting me to come work on the Siri team. I thought it was nice.

[laughter]

Guy: After basically being mean about it, I thought it was nice that they'd reach out and want to hire me. It seems to me that an API for Siri is an almost insurmountable task in that, like you were saying, the nouns and verbs that you'd get, you need to pick very carefully and vector them towards the correct app.

If any app could just opt into that, then you've got a priority system. People have to vote on how appropriate they feel they are to answer a query. It gets very muddy. I don't expect a Siri API anytime soon. Do you have any thoughts on that? You're not at the company anymore, so obviously nothing's binding. I'm curious about how you'd think about that.

Nitin: When we were defining that interface between the server sending you results and client parsing it and drawing into a view, certainly we wanted to keep that as general as possible so we're not revisiting it all the time every time we want to bring up a new service, or we want to have Siri interact with a new app or Find My Friends or something like that.

It was certainly one of those things where it can become overgeneralized to the point where it becomes mush. It becomes like the Apple Event interface from way back when.

Rene: At least the Apple Event interface, you expressly addressed an app location. With Siri, you're not asking an application anything. You're asking a general question, and then applications effectively have to volunteer to answer it. I don't know how you open that up to third parties without...

Guy: Looking like a Plinko field of collisions.

Rene: Effectively chaos, like anything can happen.

Nitin: That's interesting. I have to confess that I haven't thought about the prioritization issue too much. Let's say you don't have an app that can handle the request that you made. How is Siri supposed to take care of that?

Rene: Or you have three calendar apps.

Nitin: Right. Let's say you have three calendar apps, or maybe you don't have Yelp and you say, "Hey, Siri, what's the Yelp review for bladdy-blah?" Maybe in the Yelp case there's a Web service or something like that, there's a Web view-based fallback type system that you could have. You don't want that to become your...

[crosstalk]

Nitin: ...anything but a fallback. Exactly.

Rene: It's a tricky problem, and I don't think there's a clear solution. The clear solution is effectively AI.

[laughter]

Guy: We all know how that works out.

Rene: It's the end of the world, crazy.

Nitin: Also, it's AI and it's the ability to load and run any app at any time, whether it's installed or not. I think that's the other part of it, too.

Rene: Which we do have a little bit of now.

Nitin: I guess with extensions, right? Is that what you're...?

Rene: Right, you've got these little sub-apps that you run them on process, and they don't necessarily have to put up the front end, I guess.

Nitin: Right. My hope is that someday Apple can 80/20 this, and make it so that it works pretty well in pretty much every case that a customer will run into, and have some graceful fallbacks.

Yeah, that's interesting. I hadn't thought about that in a long time, but I do remember the last time thinking about this that it's almost like another HTTP or XML-RPC, or something like that. It's so open-ended what you could possibly have to respond to.

Guy: Yeah, it's like, "Solve for..." I don't know. [laughs] It's not even, "Solve for X," it's just "Solve."

Rene: It's like that Asimov story. In the end, all you can say is, "Let there be light."

Guy: Right. It's way too open, to me, but I'm not an AI brainiac. It seems like an insurmountable problem on a product level, right now.

Nitin: Yes.

Guy: An API, you've got to be very careful. We were saying, that's a problem. An API for effectively an insurmountable problem does not seem like it's going to be forthcoming.

Nitin: Right.

Guy: What was the last version that you worked on?

Nitin: The last version I worked on was iOS 5.1. I left in January of 2012.

Rene: You kicked Notification Center and Newsstand out the door, and then you had it.

Nitin: [laughs] And Passbook. I think that was the other...

Rene: That shipped in 6.0, but you probably worked...

Nitin: Yes, exactly. Getting back to the "They all blur together" problem.

Guy: Passbook had a good team, a lot of good people on that team.

Nitin: Yes.

Guy: A [laughs] very small number of good people.

Nitin: A very small number of really good people. I was very happy with how that team came together. I'm still excited about Passbook. I wish the first customer experience was better for Passbook.

The thing I always joke with Scott Hers about it is Passbook feels like this empty room. It's an empty room of an app. You go in and there's the promise of cool stuff that could be here, but there's nothing that is there to begin with.

You have to have the desire to go hunt around for something to put in there. I don't think normal people have that desire to go and figure out what should go in there. I think that's hurt adoption a little bit.

Guy: Yeah, it's got a bit of a chicken and egg problem. But, it's a cool app and I love the way it's implemented.

Rene: The Starbucks' Passbook is fantastic. Our Canada one's terrible. It varies so much from provider to provider.

Guy: It's the way that they're defined. I don't know if anybody knows, but it's basically a collection of JSON and graphical elements that you can string together to create a pass. That's cool because you let the third parties define what a pass is.

It's flexible and it's great. On the other hand, as soon as you let a third party define this kind of stuff, somebody's going to be a loser and do a bad job, right?

Nitin: Right.

Guy: Maybe that's a little bit harsh. I've got a beef with Air Canada.

Rene: A lot of banks, a lot of companies that had these weird web-based security and authentication systems, the easiest thing for them to do is wrap it in UIWebView and let you use the website to push something to Passbook, which made nobody happy.

Guy: Right. Anyway, I was super-excited about it when it got announced. Not just because I'm pals with those people, but I thought that was the gem of that release.

Nitin: Yeah, I did, too.

Guy: I think it's got legs.

Nitin: I think so, too. It's funny. I remember early on, yeah, we talked about the Starbucks app, but we'd also even talked about things like gift cards and, "Wouldn't it be great if there was some way, like Starbucks has some idea of an account for an identity and a dollar amount associated with that account. I would love to have the same kind of thing for gift cards.

My kids go to public school, here in San Jose. A lot of the schools here use gift cards as a form of fund raising. In other words, they negotiate deals with, let's say Walmart.

The school will be able to buy $100 gift cards for $90. Then sell them to parents, or anybody else for $100.

To the parent, they're getting a $100 gift card for $100, but the school is getting 10 bucks for it. It's a somewhat convenient way to use them. By not doing much, you're making it so that your school can get a donation and that's pretty cool.

Of course, then you've got the down side of gift cards, right? There's so many down sides [laughs] .

I'm waiting to hear by the way, about the first large scale scam that's pulled by some store somewhere, counting on the fact that people have no idea what their balance is on one their gift cards.

I know that maybe I'm particularly lazy when it comes to this, but every time when I go in and use a gift card I hand it over. Get it back and they say, "Well, you have a $52 balance." That number means almost...

[laughter]

Nitin: It's just in one ear, out the other.

[laughter]

Nitin: The next time I use that damn card is probably a week later and I had no idea that I had a $52 balance. If they told me I had a $20 balance? I would never know any different, and they've just pocketed 32 bucks.

Guy: That's why Passbook is good, because at least the Starbuck's app always updates your balance. It gives you emails so you can track it somewhat.

Nitin: Exactly! I can't wait. Maybe it's dumb optimism, but I have faith that one of these copy's that creates gift cards is going to also come through with a system like this. Where customers can actually buy gift cards and not feel like they've got this dodgy version of cash that they're walking around with instead.

I hope that Passbook is the way that you use these things on IOS.

Guy: I hope so too. It's a great idea, and it just makes sense.

Nitin: Yeah, right.

Guy: Even the way it's implemented. I admire that piece of software, and I hope it gets a lot more use.

Rene: I think with stuff like iBeacons, and when mobile payments become more possible, it'll be a much more interesting app.

Guy: Yeah, like I said, I think it's got legs. There's a good future there.

Rene: Definitely.

Guy: 5.1 was the last one that you got out the door?

Rene: Yeah.

Guy: Then you left.

I was having dinner -- quite a while ago -- with a mutual friend of ours.

You know what, I always avoid names. I don't know why. I don't want her to feel like I'm putting words in their mouth that people have been here. Like our pal that got married recently.

Rene: Yeah.

Guy: Him and his new wife, like this year or so go. Maybe two.

We're sitting at dinner and he starts moaning about how hard it is to support older phones, [laughs] and older operating systems. Because he's since left Apple. Now he's in the real world.

Turns out, supporting older devices and older operating systems is a pain in the ass. I was so happy to hear that.

[laughter]

Guy: It's justice, you know. Yeah, perfect!

Nitin: Welcome to my nightmare.

Guy: There was literally that. I'm like, "See? Told you it wasn't that fun out here."

[laughter]

Guy: How are you adjusting to no longer being at the company?

Nitin: At this point I'm pretty comfortable with it. I've got to say, probably the first two months. Or the first three months were pretty hard. It was just very weird. I'd always had these great mentors, starting in DTS, these crusty older engineers who'd been around the block a couple of times...

Guy: They're the best.

[laughter]

Nitin: Some of them, by the way, still work at Apple. They had been there for 15 years when I started and they're still there.

Guy: I hope they put them in an office, let them chain smoke and drink themselves, and you can just go in there and have a Yoda moment with them.

Nitin: [enthusiastically] Yes! That would be great! There are diners in the Cupertino area that I can tell you offline where you can run into some of these old timers.

For a long time I had always heard, "At the end of the day, Apple is a company, Apple's going to take care of Apple, you need to look out for yourself." You'll always hear the things like, "Don't associate yourself too closely with your job."

You're your own person and, then, there's what you do. If you identify yourself by what you do, that can be very hard later on. Even though I had always thought I wasn't doing that, it turns out that I had been.

That's why probably the first two to three months were pretty difficult. Almost literally I'd been doing this. I'd worked for this company for half of my life, and I'd been in various roles. iPhone itself, even though it was from 2005 until 2012, it was seven years, that felt like 20 years all on its own.

Guy: You did about 40 years' worth of work on it.

[laughter]

Nitin: Yes. If go back and count hours worked, maybe it was closer to 20 years. It was pretty tough. It was not easy being away and not knowing the ins and outs of development and how things were going.

By then, I was pretty set on not being there for...it wasn't something that I'd regretted and wished I could go back, two or three months later. It was just, "Wow! This is weird."

Guy: Changes perspective, really.

Nitin: Right. Just knowing that my baby was in other people's hands, or the thing that I felt was my baby is now in...

Guy: That's exactly what I was going to ask about. How does that feel? You get the itch where you can pick up a phone and get somebody on the line.

[crosstalk]

Guy: Yes. I certainly have had those urges over the years. I've even sent a couple of emails here and there. At the same time, I've also tried to be very...I was there for so long and I'd seen so many people go. I knew the kinds of things that I didn't want to do after I left.

One of them was to be the guy who thinks, "Apple's going to shit ever since I left."

[laughter]

Nitin: You run into those people and it's like, "Well, come on, really? It's just not the case." In almost all cases and especially with Apple, any of those people who were saying that have been proven wrong time and again since they left.

Guy: It's silly to be self-important and you don't want to be that.

Nitin: Exactly. I also didn't want to take advantage of the fact that I know so many people inside, I could make phone calls, I could get things easier or questions answered, or I could get a future request, consider it a bit more.

Honestly, I don't even think that that last one is true. There are people who might feel that way and try hard to, "Hey! You remember me? I was the guy who bla bla. Why don't you do this thing for me now"?

Guy: "I hired you" could be pretty compelling.

[laughter]

Nitin: I'll have to remember that for the next time I need a request.

Guy: If you need a favor, it's like, "You know what? I gave you your job, so give me this."

[laughter]

Nitin: I always wanted to be respectful and let people do their jobs, do the best they can. That's hard, too. Sometimes you feel like you're holding yourself back.

Especially with some of the passbook stuff, where it was really just, "Hey! It's this empty room of an app. It wouldn't be that hard to throw one or two things in there and why weren't those done"?

Guy: That gave you an edge to get in touch.

Nitin: A little bit. By the time I wanted to get in tough it was too late, too.

Guy: I don't know who's doing passbook anymore because people have moved on.

Nitin: I'm not even sure I know either. It was hard. I wanted to keep a distance, be respectful, and let people do their job and not have this crazy guy from the past come and second-guess people's decision as well.

Rene: You don't want to be a sitcom episode.

[laughter]

Guy: Ex-presidents tend not to comment. Maybe that was oddly grandiose!

[laughter]

Nitin: I'd like to say that I did not create that comparison.

Guy: No. That was all on me. It's probably inappropriately enlarging your ego. It's the notion of the people that are there know what they're doing and you don't want to interfere.

Rene: It's almost like grandkids. You've got to let the parents take care of it even though you don't really want to.

Nitin: Yes. Exactly. Let's go with grandkids.

[laughter]

Guy: Yes. That's much better. You get to spoil your grandkids. What are you excited about now?

Nitin: For quite a while, right after Apple, it was even in my mind before I left, "What do I want to do? What do I want to work on? What's next"? I thought hard about that for about six weeks until I realized that I'm making myself crazy, trying to figure out what the Hell I want to do next.

By the time I figure out what I want to do next and start doing it, I'm going to regret not having taken some time between Apple and whatever that next thing is. I should take some time off, anyway.

At that point, I very deliberately took the time off, by then it was six more months. Luckily we're in a position where, thankfully, I can do that. Since I was in that position, why not do that and spend a little more time with the kids?

Guy: You've been at it long few years. I don't think anybody's going to begrudge your six months of slipping out...

[crosstalk]

Nitin: Yes. Over time, one of the things that I've started to become more and more interested in was wearable computing. Looking at the timeline of computing and how it's impacted people...when you look back at the 50s, 60s, 70s, maybe even early 80s, computers were at a military installation and nobody used them except for...a small handful that used them for 8 or 12 hours a day or something like that.

Then, they went into businesses and then, over time, more and more people used them, but they used them for eight hours a day. They went home and there were no computers. Eventually, they worked their way into the home. Even at home there's only so much you're going to do with it.

Now, you use a computer at work for eight hours a day. You come home, dink around and play games or whatever for a few hours a day, and then you turn the thing off.

If you fast forward to where we are now, or where we were a couple of years ago, now everybody has a computer.

Now, everybody has a PC by and large at home, and they've got a computer in their pocket...all or lots of the family members, teenagers and above, by and large. I'm talking strictly developed first world here, so please bear with me on all of that.

It's now gotten to the point where you've got a computer in your pocket. If you walk around your house, there are ARM chips everywhere. They're all over.

If you look at car bought in the past six or seven years, that thing is stuffed with little computing devices. It's got its own little personal network and things like that.

Over the decades, it's become apparent to me that these computing systems are just becoming more and more pervasive. We're finding more and more places where they give us value and improve our lives. They make our lives better in meaningful ways.

On the way to having implants and bionic systems and things like that, one of the other areas is wearables and connected devices at home or connected devices. With connected devices, it's going to follow a very similar path.

You can almost look at drones today. There were these Russian systems back in the 80s, where, it's almost scary to think about it, these missile systems could communicate with each other, calibrate, and coordinate, based on the location of their peers, where they should go.

It's following the same pattern. It's military, commercial, education, home, and then it's everywhere. As long as these systems can make people's lives better, they're going to want to buy them. As soon as they want to buy them, we're talking about new markets that are opening up.

Guy: I totally agree. I think battery technology is the one thing that's really holding that back, right now.

Nitin: M-hm.

Guy: Ultimately, you need to power one of these little ARM chips. They don't take a lot of power, but they take enough power that the battery is an issue.

Nitin: Exactly. In addition to battery, I think the thing that's making battery that much harder is just wireless connectivity.

Guy: Yes. Ultimately, a screen and videos are always going to be expensive in terms of power because their job is to radiate, expand the power into the world. That's what the radio does, it broadcasts. It's spending power and sending it. It's hard to limit that kind of cost. Do you see anything on the horizon that's going to change that equation a little bit?

Nitin: That's an excellent question. Unfortunately, I don't. I agree, there has to be some big breakthroughs on the TX/RX side, as far as radio transmission and being able to create systems where you can have long battery lives. At this point now, these devices don't mean much to us unless they can connect wirelessly with other devices.

That's become the expected level of functionality. For example, the company I work for now is Jawbone.

Just a few months ago, we released a new iteration on the Up band, the health band, that has a blue tooth low energy radio in it. Now, you can wirelessly sync up your activity data or your sleep data to your smart phone app.

Guy: BTI is a big win.

Nitin: Yes. It's huge. There's still a lot of work that can be done on the transport and the protocol side. Ultimately, we're going to need new breakthroughs on that side before this can become truly pervasive. Very quickly, we're going to run into this issue.

If you don't start addressing that now, we're going to run into this issue around charging fatigue. Now, I've got all these wonderful things that are around me, but I need to remember to go and plug them all in. If I don't, then I'm not going to get any value out of them.

For starters, a five-day battery life or something like that, for something that's wearable or something that you want on you all the time, is, by necessity, something you need to have...a 5 to 7 to 10 day battery life.

Guy: Ideally, never.

Nitin: Exactly. Ideally, never.

Guy: I have one of those self-winding watches. I don't wear a watch that often, but when I do, I do out of habit. I love the fact that this thing was made in the 70s and I never have to plug it in. I can either wind it or, if I'm wearing it, it's always powered, it's always telling me the time.

Nitin: You must have a pretty fancy watch. Do you have an automatic movement, like a Swiss movement?

Guy: I have an Omega from 1972 or 1974.

Nitin: Very nice.

Guy: It is nice. I do like it. It's a hand-me-down and not cheap.

[laughter]

Guy: I love the notion of it. I don't need to worry about winding or charging it. As little as I have to worry about charging...certainly, my iPad, that thing I don't understand.

My phone I plug in every night, my iPad maybe once every three days when I realize it's getting a little bit low. By a little bit low, I mean 33 percent. I plug it in because I feel bad for the little power.

Rene: It's like a shock because you've used it for so long, you forget that you do have to charge it.

Guy: Yes. It's good.

Nitin: That's funny. There can be another problem, too. If you have to go too long between charges, and I experience that quite a bit with the Up band or other things, as soon as you have to go seven days without charging it, then you're wondering where the hell your charger is.

I'd love to know, if there were studies, I haven't done any googling on this, if there has there been any research done on figuring out how many devices normal people are willing to actually charge on a regular basis. What is the frequency of charging that people are willing to tolerate?

Guy: Right. People will prioritize the phone, then maybe a tablet or computer, a laptop. Soon after that, it's going to be a precipitous drop, in terms of what we care about.

Rene: We could make our beds wireless chargers and then sleep with our gadgets. That would solve the problem.

Guy: Wireless charging is interesting. Still, you'd have to put it on top of the charging micronet...

Rene: When you get to bed, you could just wear all your tuck in your bed...

[laughter]

Guy: I don't think I'm ready for that. It's a little bit too nerdy for me.

[laughter]

Nitin: I'd worry about a certain tingling sensation that I might be feeling somewhere...

Guy: Catching fire.

[laughter]

Nitin: This is a very cold fire. It's OK.

Rene: I'm burning from the inside.

Nitin: Like you said, we've got phones that we charge every day, we've got a tablet that we charge maybe a couple of times a week. We've got a computer that we're charging every other day or maybe every day, depending on their use.

If you've got wearables or Glass, or something like that...how many more of these things can we add on, before the act of having to charge it overshadows any benefit that you get from wearing them?

Guy: I never thought of asking this. What's your opinion of Glass?

Nitin: For certain applications it's going to be the future. It will be "the" future.

Guy: Have you ever used one?

Nitin: Yes. I've used it a couple of times.

Guy: Vertical markets, that's a good idea.

Nitin: Exactly. Vertical markets...I can imagine somebody walking around a warehouse and having data showing up around them. What do your supplies look like at different coins or for different skews within a giant warehouse?

Guy: Like airline mechanics?

Nitin: Right.

Guy: There's a lot of cases where that makes a lot of sense.

Nitin: Doctors?

Guy: Yes. Going to the grocery store, probably not one of them.

Nitin: I'm sure grocery store owners are salivating at it, but I'm sure normal customers are not.

Guy: Going to a bar at night, definitely not. That makes no sense.

Nitin: Right. Exactly. Golf? I could see golf benefiting in a huge way.

Guy: That's really interesting. I hadn't thought of that.

Rene: It feels like cheating though.

Nitin: Maybe watching sporting events. Maybe you're not even playing golf. You're just watching baseball at a stadium and all of the cool shit that you see on the TV...maybe baseball's not a great example for that, but like NASCAR.

Nitin: Yeah. If you can look at a car or a player and get some stats on that, that's cool.

Guy: Yeah.

Nitin: But it's not there yet. I think it needs a lot more image recognition love to be able to really shine.

Guy: Right. Exactly. That image or that object recognition I think that's a huge, huge part of it. But yeah. Like you said, vertical markets, that's going to be the way that you do some of these things -- I believe. It's hard, though, because at any moment, there's always good enough that's right behind cutting-edge technology.

If good enough is good enough, if a guy in a warehouse can look down at a clipboard and sort-of kind-of have an updated view maybe of the past eight hours of where things are, it's hard to say -- is that good enough? Maybe that is for that particular market. I'm sure golf pros or golf people who seem to be able to spend infinite amounts of money on clubs...

[laughter]

Guy: ...I'm sure they would probably want something like Glass.

Nitin: Yeah. $1,500 bucks still seems a little bit on the high end.

Rene: We're in the tablet PC or Palm Pilot days of wearables still.

Nitin: Right. Yeah. I don't see Glass becoming a general-use thing, kind of like the self-driving cars. I think self-driving cars is going to become something that normal people latch onto far sooner than Glass.

Rene: It's something you want everyone else to have. You don't want it, but you want everyone else to have it.

Guy: Right.

Nitin: No, I see the self-driving car becoming it. Now, they jury-rigged the test a little bit, right? Because they have a map of Mountain View that lets them drive around. But they're Google, so I'm sure they could build it out across the entire country.

Rene: Now that they own Boston Dynamics and Skybox, we just need to start training up some Sarah Connors.

Guy: Maybe it's not 1997 when Skynet becomes self-aware; maybe it's 2017 is what I'm hearing?

Nitin: I'm afraid of...I said that now and in my head one of those zombie-spider-dog robots is already being dispatched to end me.

Guy: Let's keep pushing that day back as far as possible.

Nitin: Yes.

Rene: Right.

Guy: Anything you'd like to plug?

Nitin: I do want to plug one thing. There's this device that's been out there. It's gaining some popularity, but I think it has legs. It's called the iPhone. It's put out by Apple.

Rene: Plucky upstart.

Guy: Oh, I've been calling it the ePhone.

Rene: No, it's i-dash-Phone.

Nitin: Capital I-dash-capital-P Phone. Yes, exactly.

Guy: So you think it's worth looking into.

Nitin: I think so. It think it's going to change the way people look at phones.

Guy: That's interesting.

Nitin: Yeah.

Guy: I'll have to give it a shot.

Nitin: Please. At the very least, go play with one at an Apple store. If maybe the phone call side of it doesn't excite you, then maybe the Internet browsing part...

Guy: A mobile communicator.

Nitin: ...Could be kind of interesting.

Rene: Yeah, I hear there's a mobile communicator there too.

Nitin: One of the last things I wanted to mention was that Daniel Jalket and I, we had a contest going for a while in our respective shareware apps for who had the best About box. I don't want to brag or put words in Daniel's mouth or anything, but I think we could both agree that I had far and away the much better About box in Mouth than he had in gosh, I forget what his...it was an app for recognizing intervals -- interval recognition, between two audio tones.

If anything it was more a reflection of the sad state of app development tools at the time that it was braggable when I had a link that you could click in my About box and it would bring up the net score. It was just "Ooh, aah, how did you do that?"

Guy: Anybody that wants to stick it to Jalket is always welcome on my show.

[laughter]

Nitin: Take that, Daniel.

Guy: Daniel's a good friend. He introduced us. Good work. I've really enjoyed talking to you.

Rene: Go buy a Red Sweater Software t-shirt.

Nitin: Yes. I should plug. Please go buy Red Sweater t-shirt. Go buy MarsEdit, and Daniel is fantastic and I'm so happy that we've been able...

Rene: Listen to Core Intuition.

Guy: Yeah, I think that's the nicest I'm ever going to be to that guy.

[laughter]

Rene: Love you, Daniel. We've got to get you back for...

Guy: So many things.

Rene: We talked for so long and I feel like we never cover anything.

Nitin: We do. There's so much content, but it's like, "Oh, wait, we could have gone down any number of different avenues.

Rene: I hope I'm not to blame for that, because...

Guy: No.

Nitin: ...Made me ramble or something.

Guy: No. It's an interesting time period with a lot of interesting decisions and a lot of interesting stories that you've [indecipherable 2:18:52] .

Rene: It shaped our modern culture.

Guy: Yeah. And there's that.

Nitin: I have to tell you guys, this has been a blast for me, so if you guys ever want to talk again or talk about some other subject or what have you...

Guy: Nitin, thanks so much. Is there something you want to plug?

Nitin: No. Nothing. There's nothing.

[laughter]

Rene: Follow him on Twitter. He's a famous Indian movie star. Kenyan movie star.

Nitin: How about that? Follow me on Twitter. Nitin Ganatra, as opposed to Ganatra Nitin, who's the actual famous one. You'll know me. I'm not the verified one.

Rene: We'll have the right one in the show notes.

[crosstalk]

[laughter]

Rene: No, it's perfect.

Nitin: We didn't even get to your current gig, so some other time.

Guy: More shows. I'm happy.

Nitin: Cool. That's great.

Debug is a casual, conversational interview show featuring the best developers in the business talking about the amazing apps they make and why and how they make them. In part 1 of the Nitin Ganatra trilogy, the former Director of iOS apps at Apple talks to Guy and Rene about his early career in Developer Technical Support (DTS), working on System 7 in the Copland era, and the advent of Carbon.

Support Debug: Go to squarespace.com/debug and use offer code DEBUG to save 10% on your new website! Go to peek.usertesting.com and use express pass DEBUG to get your results back faster on a free 5-minute video of a real person using your site or app.

• Subscribe in iTunes
• Subscribe in RSS
• Download directly
• Follow on Twitter

Show notes

• System 7
• Copland)
• Carbon)

Guests

• Nitin Ganatra

Hosts

• Guy English of Kicking Bear
• Rene Ritchie of Mobile Nations

Feedback

Question, comment, recommendation, or something you want us to follow up on for the next show?

Email us at debug@mobilenations.com or leave a comment below.

Transcript

Nitin Ganatra: I'm actually having a little bit of red wine this afternoon.

Guy English: Oh, a classy fellow.

Nitin: Yeah, well, if you must know, it's actually red wine out of a box.

Guy: Perfect.

Nitin: Maybe not that classy.

Rene Ritchie: That's the kind of show we are.

Nitin: That's fine. I have varied range of taste buds, so, I can drink midrange wines, things like that.

Guy: Right, yeah. It's good enough. You're a famous actor, how did you get into acting?

Nitin: Well a long time ago when I was born in Kenya, I...

[laughter]

Nitin: I'm sure you're referring to the actual famous, Nitin, or Nitin, Ganatra. Interestingly, we've actually made contact with each other over the years. In fact I have a picture of him. I'm not sure if you know this, but there were some ads that were done for the iPod back in 2000, 2001, something like that. Nitin Ganatra was the actor in it. He was the Indianish looking guy dancing to Propeller Heads, or something like that.

I think it was part of the "Rip. Mix. Burn." campaign. A friend of mine who worked in product marketing, she got a chance to talk to him. So I got this Polaroid from him that says, "To Nitin Ganatra, from Nitin Ganatra." I still have that.

[laughter]

Nitin: Even today, we follow each other on Twitter, make comments back and forth, and things like that, although we've never actually met. But, yeah, it's a little odd having what I used to always think was a somewhat obscure name, only to find out that it's the same name as the celebrity.

Guy: [laughs] Yeah, that is pretty funny. If anybody out there Googles you right now, they're going to find out that you've got a pretty successful acting career.

Nitin: Right. I'm really a Renaissance man.

Guy: [laughs] So I guess you program then.

Nitin: Yeah.

Guy: Kind of boring. But yeah. So how'd you get into technology?

Nitin: Oh, boy. OK. I'll try to....

Guy: Right. Reconstruct it.

Nitin: [laughs] Exactly. I'll give this to you in real time. It started when I was nine years old. No, really, my first exposure to anything related to technology was the Apple IIs that we had in our elementary school. We had these horrible text-based games, but that was what we had. The first one that stands out was either called "Trek" or "Star Trek."

It was a very early Apple II game. I think it's 1979 we're talking about here. It was just fascinating that here's this machine that I had only ever seen in pictures in magazines, on important people's desks, or things like that, and look, we get to play with it, too. Not only do we get to actually use this thing, but we're playing a game on it. The whole concept of video games at that time was just so new, too.

The fact that, as a little boy, you get to play games for the first time was just phenomenal. That was my first exposure. I didn't really get into programming and things like that until I got my own Apple II, which was a few years later. I think I was 12 or 13 years old, and I had, oh gosh, I believe it was a II+, but I did have an 80-column card in it, so there was that.

Rene: That's exactly what I had.

Nitin: Oh, really. OK!

Guy: Same here, too.

Nitin: Nice. Nice. It was great, because it had Applesoft built in. It had this other bizarro Integer BASIC thing built in, but I never really wasted time with Integer BASIC. It was all Applesoft.

Guy: I don't know who did. I don't even remember what the purpose of Integer BASIC was.

Nitin: Yeah, exactly. I remember even at that time, it felt like it was this weird thing. It didn't seem as well-documented as Applesoft, and it was different enough. It was all uncomfortable enough that I didn't want to be messing with something that didn't seem like it was as well-documented. But yeah, you're right. I wondered the same thing. Like, "Who the hell did they make Integer BASIC for, and why is it still on this machine if there's this thing called Applesoft on here?"

Guy: My theory was "That's for the big people." Like, "The grown-ups use Integer BASIC."

Nitin: Oh.

Guy: I'm pedaling with the real one, the one that I'm supposed to be using.

Nitin: That's interesting. I never thought of it that way, but I could see how that would come across. Applesoft is kiddie BASIC, and Integer is a man's BASIC or grown-up BASIC.

Guy: Yeah, it has a big word in front of it.

[laughter]

Guy: I was pretty young at the time. I hadn't even realized that, yeah, you'd probably not be using BASIC at all to be writing anything sensible. Was BASIC your first language, and how long did you run with it?

Nitin: Yeah. BASIC was my first language. It started with dopey little programs and getting -- gosh, I forget what the magazines were called. I think there was one called "Apple Insider" or "Apple Cider," maybe. It was C-I-D-E-R, something like that. They had the huge multi-page listings of BASIC programs.

It was funny, now looking back, just realizing that they had these things called GOSUBs, and there were these GOSUBs everywhere. What the heck. In the early days of Applesoft anyway, I never used a GOSUB anywhere. It was just execution starts at the top, you go down to the bottom, and that's it.

It wasn't until a couple years later when I started playing with Apple Pascal, with UCSD Pascal, that I saw the value of having these things called subroutines, breaking programs into functional units, and things like that. So yeah, it was Applesoft for at least three or four years there, and even a little bit of 6502 Assembly, because while I...

Guy: You have to, kind of.

Nitin: Yeah, exactly. Your path to manhood is you have to do something very, very difficult, I guess. I don't know.

Guy: You inevitably hit a wall with Applesoft, where you want to do something cool, you know it can happen, and I think they gave you the manual, didn't they? The ring-bound manual had all of the opcodes and stuff in it.

Nitin: Yeah, that's true. That's actually a good point. I think that the motivation for it was at some point you run into limits around, "How fast can I draw graphics to the screen?" In BASIC, you really can't draw them too fast. It was sort of, "Why are my programs so slow and shitty? There are these games now starting to come out, where things are just bouncing all around the screen. How do they do that?"

The answer was always Assembly. It was just this cryptic thing. That was my first exposure. Unfortunately, I never got as far at that point as writing a game or doing anything more than a page or two or a screen-full or two of Assembly.

Guy: You were already doing it, because you use Assembly where you need to and not where you don't.

Nitin: Right.

Guy: Good discipline there. So you got into the Pascal side of things. On the Apple II?

Nitin: Yeah, that was also on the Apple II. The Apple II that I had had a disk drive, but I didn't have two and I certainly didn't have four. I'm not sure if you ever used UCSD Pascal, but at the time, if you wanted to compile something, you had to stick in another floppy.

When you wanted to link your program, you had to take out that floppy and stick in a third floppy. When you wanted to bring up the editor, you had to go back to the first floppy. It was really the compile-run cycle. There was no debug, as far as I recall, anyway. I never debugged at that time.

[laughter]

Nitin: Really the compile-run cycle was this three-floppy thing. Of course, looking back it was awful. At this point, it's my second experience with a high-level language, but Pascal felt so much more natural than Applesoft. It required these three floppies and it was from this university, and so this is real big-boy computing here. And Pascal just made it so easy to create functions or procedures and pass arguments.

Guy: Structures and all that, or records, I guess.

Nitin: Yeah, records.

Guy: I still have a soft spot for Pascal.

Nitin: I do, too.

Guy: I graduated from Basic into doing Turbo Pascal on a PC. You could do in-line Assembly on it, and so I wrote so many games in Pascal. It seems like it gets a little bit maligned, but it's great in so many ways.

Nitin: Absolutely. Even much, much later in life, when I went to Apple and started working there, there were definitely pockets of people there who felt like, "Why did we give up this Pascal thing?" It didn't have all these pitfalls that you had in C. The compiler the was better. The environment was a little nicer. A lot of people felt like it was a step backwards. I remember feeling that same way, and having a soft spot for Pascal.

Guy: I don't know if Objective C's a step backwards from Pascal. [laughs] Some people just rag on it all the time, and I don't think it deserves it. It serves its purpose well.

Nitin: I'm sorry. To be clear, I was just talking about people who were comparing MPW C to MPW Pascal.

Guy: Oh, OK.

Nitin: Then there was this new thing called C++, which had these horrific compilers. All of that, especially in the early '90s -- we can get to that later -- was...

Guy: Yeah, that's a much more apt comparison.

[crosstalk]

Nitin: No, I don't feel like it's [indecipherable 00:12:01.08] .

Guy: The original Mac was all built around Pascal 2.0 blocks.

Nitin: Yeah, exactly. It's hard for me to now go in there and look. While much later, I expected this wonderful world of something that looked like somewhere between UCSD Pascal and Think Pascal as being the entire operating system, written in this glorious language. Getting to Apple was an eye-opener, realizing what it really was. We can get to that later, too.

Guy: Yeah, we'll end up in the sausage factory, eventually. [laughs] You haven't done any programming in school by this point?

Nitin: When I started to learn Pascal, there was a summer school program that I was taking. That was either late in middle school, or early in high school. It was somewhere around there. I think it was late middle school when I was learning Pascal. That was in a learning environment. Obviously, you learn for two hours and then you go home and plunk away for four or five hours, until you get tired of exchanging floppies and find something else to do.

Guy: The bug caught you early, the iterative programming bug.

Nitin: [laughs] It did catch me early. In some ways, it may have caught me a little too early. By the time I was a junior in high school, I felt like I was done with computers. Obviously, I hadn't learned anywhere near everything that I needed to. There was so much that I, obviously, didn't know and so many things that I hadn't done.

But I had learned enough to satisfy me. I became comfortable in the little world that I understood and felt like, "Maybe I'll go look at other things, like playing tennis, hanging out with friends, or watching music videos."

Guy: That totally rings true for me. I did anthropology and history in university, because I really didn't want a computer job. Turns out I did want a computer job, and they're awesome, but from the other side of the fence, you can see it being boring or staid. It was my hobby, and I didn't necessarily want to sully my hobby by doing it all day.

Nitin: Yeah, that's funny. That's really funny, because that's very similar to what I feel happened to me, too. Yeah, it was my hobby and it was this thing that I was interested in. I don't know what I was thinking. I was a little dopey kid, but I just couldn't imagine going to an office somewhere and doing computery stuff all day.

Guy: Yeah, it seemed it could get boring, right? [laughs]

Nitin: Yeah, it seemed kind of boring, exactly. Like you said, it was taking my hobby, this thing that I was interested in, and now it's become labor. [laughs] Yeah, that's funny.

Guy: But, eventually you did. [laughs] What happened? What'd you do in university?

Nitin: By the time I got around to applying to colleges and things like that, I'd put computers aside and decided it was time to grow up and do something more grown up, or God knows what.

Long story short, I had taken a couple of economics classes in high school and some history courses. I was really more interested in that and, particularly on the economics side, how human behavior is impacted by an economic environment.

Guy: That's interesting. Is that the relative systems from the programming? Is there a kernel of commonality there?

Nitin: I'm not really sure. Maybe there is something there.

Guy: I don't want to psychoanalyze you over Skype, or anything.

Nitin: It's interesting. I hadn't really thought of it that way. We can get to it, but I'm not really sure. There may be something do that, but I feel that it was really music that brought me back into computers, later when I was in college.

I went into college. I went to UC Santa Cruz, in the economics program. I went to Crown College there, for anybody who knows UC Santa Cruz, and very quickly after that went to Kresge, which was the art school. I took maybe two quarters worth of economics courses and realized that I'm never going to get past all this mundane crap to get to the part that I'm really interested in.

Guy: The high-level, human behavioral stuff is fascinating, and then you've got all the nuts and bolts of day-to-day economics, which is a drag.

Nitin: Exactly. Yeah, exactly, the elastic versus inelastic spending, and the macroeconomics and micro. It was just any where near as interesting as I imagined it was, and it certainly wasn't as interesting as the courses I had taken in high school.

After my first year, it was pretty clear that I knew I wasn't going to be an econ major, but I really didn't know what I was going to be either. It was around that time that I had picked up the guitar and started learning how to play guitar. I'm not sure if the same is true in Canada, but in American universities, especially for freshman and sophomores, there's plenty of time during the day to do things other than studying.

Guy: Yes. [laughs]

Nitin: [laughs]

Guy: If there's not, well, you'll just make time. It's fine.

Nitin: Yes, exactly. Even if there really shouldn't be that much time, yes, like you said you'll make that time, and maybe fail a class here or there, or things like that.

After my first and second years in college, it was clear I wasn't going to go into economics. Computers was this thing that I had dismissed long before I ever got to college. Then it was, "Well, political science is kind of interesting." I was taking more and more courses in history and poli-sci, but even that, there was something very unsatisfying about it.

It was really when I had taken some creative writing elective courses that the lack of a correct answer in any of these humanities-based courses just really left me unsatisfied. The fact that anybody could come along and claim whatever the hell they wanted, whatever theory about political systems, about why socialism works well, or why it's the worst thing in human history.

You can argue either side in what's deemed a very legitimate way, and really, there's no right answer, there's no wrong answer. And, that's true. That's how the world works, but that lack of a right answer left me wanting more.

Guy: Yeah, it's unsatisfying, and they're untestable, anyway.

Nitin: Yes.

Guy: You feel like you're going in circles a little bit. How did the music lead you back into programming then?

Nitin: Well, it's funny. I really don't know. It felt like the more I became interested in music and in trying to understand, "Why do we have the major scale and how do we settle 12 notes and 12 notes in an octave, and how is it that octaves are even a thing?"

Once you dive in a little bit and realize that there are these harmonics that are behind music, and audio frequencies tend to double with each octave -- I think that's correct, anyway -- there's real math that describes and helps define what makes something sound pleasant to a human. To me, that part was fascinating. Again, it felt like there was hint of a right answer.

Obviously, people like different kinds of music and people even like different types of performances, but just the fact that everything that people were playing had this basis in mathematics and in physics, it was very satisfying in a way that these humanities-based courses just weren't for so long.

That was the first inkling that maybe I should find my way back around to things where there's more of a right answer, or there's a generally agreed upon correct answer. That's as far as I can tell, you know?

Guy: That's interesting. I know a little bit about music, but I never got into that much. The interplay between music and mathematics has always fascinated me. Music is such a natural thing. Once you understand it there's all of this crazy math behind it that just came out naturally...I don't think people discovered chords necessarily by doing the math to figure them out, but the fact that the math fell out of it fascinates me.

Nitin: Right, exactly. There is this foundation in mathematics that helped explain, as far as we can tell today, what types of tones sound pleasant to a human ear and what ones don't.

Guy: Right, yeah. You can have a discord in sound that makes you feel off edge.

Nitin: Exactly.

Guy: Uneasy, yeah.

Nitin: Yeah, and there are scales and modes that you can play in. In music, there almost is kind of a right answer and wrong answer. If you want to give somebody a feeling of tension or of sadness, you play minor chords, diminished chords, these diminished scales, or things like that. It's almost like seeing through the matrix, right.

Guy: Right.

Nitin: There's music, and some of it sounds good, and some of it sounds bad, but behind all of it there's physics and math. That was very satisfying in a way that other things hadn't been up until then.

Guy: Yeah, I know. I can see that. You what, started taking computer classes?

Nitin: Yeah. It was around that time that I realized that was the part was missing, the fact that everybody could be right or that everybody could be wrong in some of these other courses. I'm sure this sounds like alien to some of your listeners, but there are some of us who are wired up this way I guess.

Guy: I think pretty much everybody out there feels that they are right all the time. Don't worry about it.

Nitin: [laughs] Well, I know I'm right, so yeah.

Guy: Right, exactly. Yeah, me too. See, we're both right.

Nitin: [laughs] Exactly.

Guy: Problem solved.

Nitin: I took a couple of more music theory courses and enjoyed those, and continued playing guitar, although never did anything worth note with it. It was just a fun hobby. Then, eventually, I came back around. I thought, "Well, why not..." I had some friends who were complaining about one of their data structures courses or algorithms courses.

They're describing how sorting works or something like that. All of a sudden I felt like that was something that was very interesting to me. That was something that I wanted to dive in and learn how these algorithms work. The fact that these algorithms can be applied to any computing system was just fascinating.

It wasn't that on an Apple II you must always use Bubble Sort...I don't even know what I was thinking, but the fact that you can really separate algorithms and a lot of the computer theory from the actual system you were running on was also a very interesting thing.

Guy: The science side of things is something versus the engineering side of things. The greater truth of computer science interested you as a purer entity.

Nitin: Yeah, exactly. I didn't go ape shit with it, and it's not like I was real interested in DFAs and NFAs. Computer theory can go off the deep end too, but just the fact that there was this body of work that was done to of show, "Here are how you solve certain types of problems, regardless of the system that you're on," was the first thing that caught my attention and sucked me in.

Then I took some algorithms and data structures courses. By then, I was right back into it. It became the thing I thought about while I was taking a shower. If I got something wrong or if I screwed something up, I really wanted to understand why and learn more. I was just generally interested in it at that point, in a way that I hadn't been interested in anything at university up until that point.

Sadly, this was I think the end of my second year in college. I had taken my first undergrad course in computer science, so I had a lot of catching up to do. I had to move fast to fit in all the course work and graduate in a reasonable amount of time.

Guy: You graduated with a comp-sci degree?

Nitin: Yes, I had a comp-sci degree. I didn't get it in four years. It took me four years and two quarters, something like that.

Guy: That's not bad with two-year...

Nitin: Yeah, that's true. I had put myself through hell. By my fourth year, I was ready to be out of college. I just wanted to get out and work. [laughs]

Guy: Yeah, I bet. Did you join Apple straight out of college?

Nitin: Yeah, I had applied for a couple of jobs and didn't get them. In hindsight, it's great. One of them was working for Amdahl, which was a big mainframe company. I believe they were in Scotts Valley, and a couple of other jobs. It was mid-summer or early summer, after I had graduated, and I was staying up here. Moving back home was not an option. I wasn't giving myself that option, yet.

After applying to a couple of positions and not getting them, I went and joined this contract place called, Oxford & Associates. I had heard that they had some ties to Apple, that lot of people who had contractors at Oxford tended to go on to have contracts at Apple.

Guy: Is that the same one our mutual friend, Juckett, was at?

Nitin: I wonder.

Guy: He did something similar. He had a contracting gig during QA I believe, at Apple.

Nitin: It wouldn't surprise me. Oxford was a big feeder into Apple at the time. Yeah, it wouldn't surprise me at all.

Guy: I'll check with him after, but it's the same story, or at least very similar.

Nitin: Yeah, exactly. I got a job though Oxford contracting to Apple's Developer Tech Support group. I started in DTS. I had worked under contract for six months with Oxford, and then a full-time position opened up at Apple. I applied for it and got the full-time DTS job.

Guy: How was that? That's an interesting job to get right out of school. School, not to sound reductive, but it's a more scholarly approach. When you get into the deep end of QA and all of that, that's a very nuts-and-bolts end to the spectrum. It was at a bit of an adjustment for you?

Nitin: Yeah, it was an adjustment, but, in some ways, it was exactly what I wanted. DTS, I can't recommend it highly enough. I can't recommend it enough. In a lot of ways, I was paid to learn. I was getting, gosh, I don't even remember, like $20 an hour. I was getting paid $20 an hour. I'd never been paid that much before. It was well over twice as much what I had made before that, and I got to learn about Macintosh programming.

I was getting paid, what I thought was a stupid amount of money at the time, to learn. Previously, I had been learning this stuff in university, and I had to pay. I had to pay tuition to learn this. The stuff that I was learning, by the way, wasn't anywhere near as interesting as once I got into Apple.

Developer questions would come in, and I hadn't ever written anything against the Macintosh toolbox by the time I gotten into DTS. The first three months were just figuring out, generally, "Where am I interested in?" and the latching onto the smartest people in DTS who happened to be brilliant people on their own.

It takes a special kind of talent...It's almost cliché now, but when a developer writes in or when anybody ask a question on Stack Overflow, the clichéd response is, "What are you really trying to do?" A lot of times, you get these nutso questions, and it's, "Huh? You want to do want?"

Guy: The question itself is like, "How do I ride my bicycle along a train track. It's like, "No, don't, please don't. Where are you trying to go? I'll give you directions."

Nitin: [laughs] Exactly. I want to use QuickDraw, but I want to use it at interrupt time. It almost works well but not quite, how can I make it work all the time? It was, "Oh, my God. What are you trying to..." At the beginning, it's was, "What is interrupt time and how does that work into how the Macintosh toolbox works?"

Every single question that I got was an opportunity to go and pour over Inside Mac, pour over sample code, and go and talk to the really smart people who were in DTS, who knew this stuff backwards and forwards. Thank goodness, now, they weren't going to give me the answer. They were teaching me to fish. They weren't going to give me the fish, but they were going to say, "Have you looked at 'Inside Mac' memory? Look at the set."

Guy: That's great. You don't know necessarily why interrupt time is special, until you've actually understood how the system works.

Nitin: Exactly, exactly. They're going to spoon feed you just enough so that you know where to look, but then it's really on you to go look and do the deep learning.

Guy: [indecipherable 00:34:45.17] .

Nitin: I'm not sure. I'm going to drop a name here, or maybe a couple of names. One of the people who I work with quite a bit was Jim Luther, who was in DTS for a long time. He wrote More Files. I don't know if you ever used that. He came from the Apple II. A lot of these guys had come from the Apple II.

I could tell that there was a little bit of resentment between the people who are on the Mac who felt like, "This is God's computer, and this is the way of the future. Throw all those sticks and stones called the Apple II away." And the Apple II people were saying, "We're keeping the lights on over here. What have you done? How much does that thing cost again? How much RAM do you have in that?"

There was definitely a little bit of back and forth. That has started settling down by the time I got there. It was just a phenomenal environment.

Guy: They were selling Apple IIs way later than people expect. I think they stopped in the late '80s, maybe early '90s. I don't know.

Nitin: I think I was still there. I believe they stopped selling the Apple II in '93 or maybe even 1994.

Guy: That's a little bit bananas.

Nitin: [laughs] It was nuts. I think even after they stopped selling the Apple II, you could get the Apple II LC card for a while, as well.

Guy: Obviously, your skills grew at DTS. Then you wanted to start writing your own apps or get into a different group. How did that progress?

Nitin: One of the things that I started doing, other than building up my own body of sample code, tips and tricks, and how to figure out developer problems. It took a while. Including the contract time, I was in DTS for about two years. It was from the end of 1992 until the end of '94 when I left DTS and went into the Mac system software.

I went from asking all these people who are way smarter than me, "Where should I look for this? What could be going on here?" or, "Here's the answer I'm about to give. Is that really the whole story? What more should I pass on." to I started picking up new technologies that were being introduced, as well. One of them was this thing called the DragManager or drag-and-drop.

Guy: System 7 introduced that.

Nitin: Yeah. It came out between System 7.0 and 7.5. I think it came out after System 7.1. It was rolled into 7.5, but I think it came out as an extension that you can install on 7.1 or later. There weren't that many apps out there. Obviously, it was brand new technology. There wasn't that much that showed how to use this thing.

In addition to writing the sample code that would go out to developers and things like that, the few times that I had played with a NeXT machine up until then, I really liked the dock. I thought the dock was just the coolest thing. I couldn't understand why there wasn't a dock for the Mac. How many years ago did this dock-like thing come out for NeXT boxes?

It was so cool, but we didn't have one for the Mac. With drag-and-drop, it was an opportunity to use this now built-in system technology to support drag-and-dropping documents or applications from the finder into something like a dock, and using that as a quick launcher.

Guy: Wait, could you do text snippets at the beginning?

Nitin: Yeah, it did. You could do text snippets as well. It had different flavors, they call them, for contents.

Guy: That's cool. You did a dock, a multi-object...

Nitin: Exactly. It was a little shareware app. It was called Malph, M-A-L-P-H. It started as just postcard ware. If you downloaded this thing and you like it, just send me a postcard. Here's my address. No paying or anything like that. I was more curious to see who was going to send me postcards.

Guy: Those were the days. How great was that?

Nitin: [laughs] It was awesome.

Guy: I never did that. I just love the idea of, "Just send me a postcard." Did you get any?

Nitin: I got a bunch. It was phenomenal. I got postcards from Finland and Germany. I definitely got a number from Japan, obviously, the US. From Canada, I got quite a few. It was really cool. I loved it. You get those postcards, it's just a little acknowledgement that, "Hey, I used that thing that you made."

Guy: It's a more warm and fuzzy thing than getting paid. Not that getting paid is bad, but [laughs] somebody took the time to go out and send you a postcard, which is nice.

Nitin: Now, looking back, with the Internet and everything, it feels so quaint in some ways, right? That was another one of those experiences, just creating this dock and coming out with 1.0, and it was kind of shitty. But building on it and coming out with 1.1, 1.5, just the incremental development process and, "What should I work on now? What are the things that it's never going to do? Because I don't think that they're important."

Fending off all of the feature requests. People want it to be something different from what you want it to be. You got to have the...

Guy: It's...

Nitin: Go ahead.

Guy: It's the truth of having a real product. You can program whatever you want, but when you've got a product, you need to make all of these meta decisions about the actual development.

Nitin: Exactly. It's very helpful if you have strong opinions yourself or a strong guiding principle. I didn't create this thing to become a finder replacement. Everybody has who sent me feature requests that were replacing things that you could do in the finder, that's not really what it is. Is this something that I will personally find useful?

I think that was the other part of it, too. By accepting postcards instead of payment, it was liberating in a way as well. It meant that I could do exactly what I want. You can either use it, and that's lovely and I love that you do use it. Or, if you don't use it, I'm not going to feel like I ripped you off or that you paid for something that wasn't what you expected.

Guy: You know what, you're not beholding to your customers? They come and go. If you like it, that's perfect. If not, that's fine. Did you define what you wanted it to be ahead of time, or did it just grow as you got a suggestion, you're like, "Nope, it doesn't fit," and, through the rejection, come to discover what you wanted the application to be?

Nitin: That's a really good question. It was really closer to the latter. Initially, when I wrote this thing, it was to learn about drag-and-drop and to have a dock that I liked using. I'm scratching my own itch here and maybe other people will find it useful. If I really want a dock, maybe other people do to. Here it is. Knock yourselves out.

Really, it was over time, getting feature request or getting feedback that, "I'd love to use it, but it doesn't play..." The most absurd example that I always use was, I can't play QuickTime movies in a dock tile. It was sort of, "It will never do that. I will never, ever add that to this product. If that's what you're looking, then you should move on."

Guy: Didn't they demo that in 2001 with the OS X launch?

Nitin: Oh, yeah. That's like a good point.

Guy: They minimized the QuickTime movie into the dock.

[laughter]

[crosstalk]

Guy: You got SureLocked, don't you?

Nitin: Oh, no! I got SureLocked.

Guy: Maybe those people are finally happy. [laughs]

Nitin: It really was an organic thing or something that developed over time. Initially, you get a feature request and you're like, "That's kind of cool," or you go, "Not really. I want to make you happy, but I'm not going to add that. It's just not going to happen."

Over time, you can see the pattern in the types of things that you want to add because you find them interesting or you think it's going to make a better product, and the types of things you don't. Based on that, you can create a structure that you can help to use to decide whether things are going to come later.

I'm not sure if you've heard of these Steve Jobs stories where before we went and bought a washer, we sat down and thought about the washer-ness of a washer.

Rene: What's the purpose of a washer?

Nitin: [laughs] It was a lot more organic than that. I didn't have a mission statement or any of these other stuff. It was all just, "What do I want to do? What makes me happy with this product?"

Guy: It develops a set of skills that I imagine will come in useful for the longer story. [laughs]

Nitin: Absolutely, absolutely.

Guy: Meanwhile, you're in System 7 group, right?

Nitin: Yes. Then eventually, I'd moved over to the system software team. I believe the first release I worked on was 7.53. At that time, the system software team, I believe its official name was release engineering, maintenance engineering or something like that.

In the name was baked the fact that we're just doing this thing to keep the lights on for now. We're keeping the System 7 thing running. The people over in Building Two are working on shit-hot thing that you're all going to want later.

Guy: Just the Copeland group, right?

Nitin: Exactly, exactly, the Copelands. It was a very small team of generalists. On any given day, you could work on the virtual memory system, and maybe even in the same day, you could work on QuickDraw or cursor handling.

Guy: That's kind of cool. That's up and down the entire spectrum there.

Nitin: Exactly, exactly, just like DTS. I feel very fortunate to have been part of a group like that. Like you said, you can just jump around and work on all of different kinds of technologies and learn, at least a little bit, how they work before you stumble through and try to get a fix in for Performas or whatever the hell we had to do at the time.

Guy: [laughs] How long were you there? This is '94 or '95, right? Things were kind of becoming a bit of a bummer at Apple at the time.

[laughter]

Nitin: I had learned that things were already a bummer. I took my full-time position in April of '93 in DTS, and six months later Apple had their first major layoffs. I was just shitting myself. It was just, "I've only been here six months. [laughs] I'm the low man on the totem pole. Of course, I'm going to get laid off. I would lay me off."

Already, there was evidence that things were not going great for Apple. You're right, from the time I had joined in late '94 or early '95, about a year later was when Copeland started collapsing on its own, around 1996, all that.

Guy: It's been 20 years, but this is purely political. Was there some feeling of vindication from your group that the Copeland guys collapsed, after having been given all the love and you guys were renamed Maintenance Engineering? You know what I mean?

Nitin: [laughs] Yeah.

Guy: I don't want to go negative on anything, but I could see myself feeling that.

Nitin: There definitely was some feeling like that. I always tried to...I don't know. To answer your question, yes, absolutely, there was. All the stories that we had been hearing about...

As release engineer, we had been involved in very mild ways, doing API reviews and things like that of different components that were going to go into Copeland, and engineers can be an opinionated bunch, anyway, as you may have heard. There was definitely some of the, "What the hell are these Copland guys thinking?" Especially when you see an API come by. I very vividly remember looking at some file-system APIs and I was reviewing them for the Copland file system team.

Actually, Jim Luther and I had been reviewing them. Jim was God of the File Manager, and he later became God of VM for System 7 and Mac OS 8. He was obviously the right guy to review this. We were both reviewing this thing together. We were walking through them, looking at this API, and we were just trying to figure out how to create a file. That was it.

[laughter]

Nitin: There were these APIs that were coming back, and they were so overwrought. It looked like they were written by somebody who never wanted to write an API again. They wanted to create the be-all, end-all, most generalized, most abstracted API, to the point where you couldn't even figure out how to do just mundane tasks.

Guy: To be fair, that was a bit of an industry-wide problem at the time. The mid '90s seemed as little bit...a lot of the stuff that Microsoft was doing was super-overwrought. People fetishized the abstraction stuff in the '90s a little bit too much.

Nitin: That's interesting to hear. I didn't realize that this was an industry-wide problem.

Guy: I haven't seen the exact API you're talking about, but, by-and-large, I find that, during that time period, stuff was complicated, overly so, pretty much everywhere.

Nitin: I'm not sure if you've ever seen the Apple Event interface, the APIs for using Apple events.

Guy: Yeah, sure.

Nitin: That was an example. In my mind, and forgive me if you created...I think it was Kurt Piersol and Ed Li, or some people who'd created the Apple event API. Oh, my God, what a disaster! It was just awful.

Before you could send an Apple Event, you had to create an AE descriptor, and you had to add an AE address descriptor that described the destination for this event that you were going to send. There were so many calls that you had to make just to do the most mundane things. It was so hard to use.

Thank goodness something like AE Gizmos came along later and made it so that the most common things were now a couple lines of code, instead of a gazillion lines, and, "By the way, you better check your error codes on the out, [laughs] for each of these calls, too."

The Copland APIs themselves felt like it was the Apple Events team developing this API with even more complexity. It was the Apple Event interface on steroids.

Guy: Would you say that it collapsed under its own weight?

Nitin: I think some of the "under its own weight" was why it collapses. Really, the biggest thing was just the management. I'm trying really hard here to not bash any individual person or anything like that. I'm going to generally say, "The management of Copland."

There were people who were in positions to make real decisions about the future of Copland, and managing the schedules and the deliverable. Neither of those things was done. It was almost to the point where, without saying names, there were VPs of engineering who were supporting parallel efforts on alternate kernels [laughs] that were not the kernel that was slated to ship in Copland.

Guy: Oh, ouch.

Nitin: When you have things like that, it's sort of like, "Do you believe your own story?"

Guy: You're running a research lab at that point, rather than a product company.

Nitin: That's right. That's right. The one person I'm thinking of, in particular, came from a heavy research background. I think that he knew how to spin up new projects and didn't know how to ever ship existing projects.

Guy: There's plenty of really smart people that don't make for great managers. Different skill sets, really.

Nitin: Exactly. Definitely.

Guy: So Copeland collapses around '96. Are you still in the 7 Group?

Nitin: Yes.

Guy: You're in the Systems Group. So how did you take the NeXT acquisition news? Did you guys know about it before the announcement?

Nitin: Yeah, there were some rumors about it. It was understood that BOS were the frontrunners. In Mac hardware at the time, there were some people who were pushing really hard to use the NT kernel from Microsoft, as well.

Guy: I'd heard that too. Which is interesting. It could have been cool, Because it was running on PowerPC at the time.

Nitin: Yeah, it could have been cool. In hindsight, looking at things like power management or security or things like that, I would not want to have the Windows XP story around security.

Guy: No, no, right. I'm not saying...I think the road that was taken was probably the best road to take, but I don't think it's bananas to consider the NT kernel as a basis for the next Mac. I think it was basically a prudent idea to talk to them about it.

Nitin: Yeah. I think you're right. Absolutely. I think it was good that people were open-minded and were considering all options. At the time, I had played with BOS a little bit, but it seemed like there were some pretty big holes there. It really felt like there was more sizzle than steak.

Guy: You could attach your Mac video onto a Cube, but you couldn't print, really.

Nitin: Exactly [laughs] . There was no real, as far as I can tell, internationalization story, no localization story.

Guy: Single-user.

Nitin: Exactly.

Guy: Yeah, exactly. Interesting, but ultimately probably not what you want to build on for the next 20 years.

Nitin: Right. The other thing is that, at that time, one of the things that was sexy about BOS was the idea that they had this fully-threaded toolbox. As far as I can tell, nothing else had a fully threaded toolbox. It was, "No, it's single-threaded, you can have other threads running in the background, worker threads doing worker-thread things, but you should never render into a frame with two threads or have one window per thread."

I think that was part of what was appealing, but ultimately, I'm glad that Apple made the choice, obviously, that it did.

Guy: B also had a C++ API, which at the time was exciting. But [laughs] the fragile base class thing screwed them a little bit after.

Nitin: Gosh, that's right. I forgot about fragile base class problem. Even early versions, I think, of I/O Kit had the fragile base class problem too, right?

Guy: Yeah. Anyway. Bummer. So how did things get shaken up after that acquisition, from your perspective?

Nitin: To go back just a little bit, one of the things that had happened was as soon as Copeland had collapsed, all of a sudden, a lot of the focus around shipping out to customers came back to the release engineering team. We had been shipping on a pretty consistent basis. We had regular updates. Each release was -- in my mind, anyway -- tangibly better. It was easy to see that it was a distinct improvement over the previous release.

In other words, System 7.55 had a bunch of VM work that was done for it. One of the things that I had been working on these power PC native libraries, but if we didn't use the version that was in the ROM then it was, "OK forget it. Let's try to patch it as the best as we can," and hope we don't have too many mix mode switches.

We'd been creating a little bit of a mess along the way. One of the things that was getting teased apart, was getting improved, first with System 7.6 and then later 8.0, and 8.5, were the introduction of more native libraries. It's hard, because you think, "Well, of course. Yeah, compile a native library. That's a MakeFile fix. You want to run native QuickDraw on that box. Add a native QuickDraw target to that particular box." In it goes and, "What's the next job?"

Guy: Yeah, easy as pie.

Nitin: Exactly, easy to find. Unfortunately, because they were all these different ROMs that we had been shipping and memory was still very limited, there was a strong desire to use as much of the code that was in the ROM as we possibly could if it was working.

We really had this mixed system where we had the ROM that was loaded, initialized and was being used. But then on top of that, we would have this native library overrides and ways of overriding the ROM functionality once we have decided that it was suboptimal or buggy or what have you.

Over time, 7.5, 7.6, 8.0 was getting better and better. By the time 7.6 came around, or shortly after 7.6, Copland had collapsed. A lot of the focus around shipping was switched back to of the only teams that with shipping software at Apple, which was our group.

All of the sudden, we went from the small, rag-tag team that was just trying to keep the Mac limping along until this great new OS comes along, to we were the story. We were the thing that was going to be the basis for what would become Mac OS 8, and then 8.5 and 9.0. A lot of Copland technologies came back to Mac OS because of that, things like Application Services, Appearance Manager and things like that.

Guy: The look of Mac OS 8 was cropped from Copeland.

Nitin: Exactly.

Guy: I bought my first Mac in about '96, so it came in for OS 8 or maybe '97. Basically, as soon as the next got acquired, I'm like, "OK, I'm buying a Mac." But I always felt that like system 7, the point releases could have...System 7 has held back a bit because they decided that Copland was going to be 8.

They could never bump the number high enough to actually make the improvements that were happening in System 7 commensurate with the effort and the improvements of the scale of them.

Nitin: Yes, that was absolutely the case. I wish I could remember some more specific examples. But there were a lot of times when the release engineering team wanted to do something. Oh gosh, what will be an example? Let's say Keychain functionality that was first in the PowerTalk release of the System 7.

We decided we want to do this key chain thing. Forgive me. Keychain may not be the absolute correct example of this. The answer we would get back from product marketing was, "No we're not going to add anymore new features and functionality to the System 7 line. That's all going in the Copland. You need to go back to release engineering and just keep this thing limping along."

I talked to a bunch of friends. Thank goodness, I'm still friendly with a lot of the people who were on that release engineering team. A lot of them still hold the grudge against product marketing, screwed up management, or whatever at that time. Like, "You never let us do the great stuff that we could on system 7 because you wanted it all to go in to Copland, and Copland sucked. Therefore, you're stupid."

To me, it never felt that way. I felt like, "If I was running company and if I was placing my eggs in this new basket over here, I don't want any eggs to go anywhere else." It made sense to me. I didn't really resent product marketing, management, or anybody like that for effectively holding back System 7 to make your next OS release great.

The next OS release is really your future. Why do you want to compromise your future just because you can do something today?

Guy: Right, like not irrational decision making. You can see why you'd make that decision. It may not be in your favor, particularly, but that doesn't make it irrational, crazy, or bullheaded. How was OS 8? That one interests me? I think that started after the NeXT acquisition, the actual OS 8 that shipped.

Initially, they said that they would have Rhapsody out within a year or something, which is why I bought my Mac. That turns out not the case. [laughs] That must have been an interesting product. It was really like, "Now you guys have to go make something fancy," but you know that you're effectively going to be end-of-lifed with Rhapsody coming out pretty soon.

Nitin: Yes, that's interesting. The thing that I remember about OS 8 was there was a lot of work that was put in to take the most viable parts of Copland that had been developed already. Some of them were things like the high-level tool box, some of the Appearance Manager work, and things like that. And bring those back to a System 7 foundation. In some ways, it's an embedded operating system. By today's terms, that's an embedded OS.

Guy: For anybody listening, it's effectively the operating system loads up into BAM and the applications are effectively plug-ins. All of the address space is shared. You can poke at other people's stuff. It's very much a very lightweight operating system but today's...

Nitin: Yes, yes. Exactly.

Guy: Sorry, I just wanted to lay the groundwork by what year.

Nitin: Well, thank you.

Guy: Yeah. Pulling it back from Copeland into the 7 branch to create 8, was that a big hurdle or were the APIs similar enough? Was the underlying structure close that you could do it?

Nitin: It was a big hurdle, mostly in that one of the biggest things that went into Mac OSA was a lot of the native toolbox pieces, like a native control manager, a native window manager. The team at the time was, I believe it was managed by a guy named Ed Voss, who's still today...I had hired him back, we'll get to that, years and years later.

He's still in the iOS org right now, but Ed and his team had a lot of these components that were fully native, rewritten in C, just new implementations of Control Manager, Dialog Manager, Window Manager, all of the traditional UI toolbox managers that were there, but they happened to also plug into this new thing called the Appearance Manager.

Now that I'm talking about it, I'm sure I'm getting some of the details wrong because I think a lot of those things actually ended up in 8.5. Around 8.0 was the...Yes, please forgive me. For anybody who's listening, for me, this feels like a memory test.

Guy: Yeah, yeah, don't worry.

Nitin: I know I'm going to fail horribly.

Guy: Getting details wrong is a part of the charm of this show. Don't worry about it.

Nitin: Awesome. Then I will make it very charming.

Guy: [laughs]

Nitin: Yeah, there are a lot of components that were starting to come in Mac OS 8 that, by the time we got to 8.5, we had a lot of these native libraries. The underpinnings of Mac OS were still the same. We had a VM, and it worked a lot better than it did before system 7.55, but it was still a VM that had to operate on a single address space for all applications.

If you had an app, where you wanted use way more RAM than the user expected you had to bring up GetInfo and you type in a new magic number for how much RAM to use. Considering this thing was a Mac, we thought it was always funny, internally. "Oh my god, here's this thing that we've worked so hard to make user friendly, and now we're making this poor user go in type in 4,096 into a size resource or into the Getinfo panel." Poor users.

Guy: Yeah, and what the Mac called a VM is not what you'd see in a comp sci class. A very, very different beast.

Guy: How long was the 8 project? A year and a bit maybe, 18 months?

Nitin: I think it was over a year. I think it was about 18 months. That was sort of when I got an appreciation for shipping frequently. We didn't talk about iteration or agile, or anything like that. The point of these releases, until we got to 8.0 -- it was a little bit stretched out by then -- was we're trying to address customer issues as fast as we can, and get releases out, get high quality releases out as frequently as we can.

And 8.0 stretched it a little bit, but not as much as 8.5 did later. From what I recall there was definitely awareness of the fact that Copeland was this thing that was done. All of the focus shifted back to release engineering.

That was the deployment vehicle for Mac OS, "Until something better comes along, and we thought it was Copeland, but now we know it's not, so we're going to get all our stuff working on this system 7 foundation, and keep that thing going until we get our shit together on the modern OS side."

Even though there was all that work that was taking place, while we were working on 8.0 and 8.5 it never felt like "Why are we doing this?" It never felt like it was pointless work. We had gotten to a point where the developers that we did have were finally...

With Mac OS 8 there was the new look and feel, and with 8.5 there were a lot of new libraries and implementations. If you have an app that's been working for years and years, and if you happen to get lucky and it works by side effects, in some ways...

Guy: Right.

Nitin: Before 8.0 there was this feeling that we couldn't let any app break. We just could not.

No matter how wonky or strange or whatever this app was -- your Super Boomerangs or the things that like patched out half the [indecipherable 01:16:46.04] , "Oh my god, we have to keep all of this cruft working, otherwise people are going to run Windows."

Guy: Especially with a system as slim as Mac OS was. That really ties your hands. You can't even move the address of like a function of something. The date has to be in a certain place at certain times. It's kind of crazy.

Nitin: Exactly, exactly. It was interesting. I can't really point to any one thing that happened, but somewhere between Mac OS 7.6, and certainly by the time we got to 8.5 -- I even think that it was before 8.0 -- there was this acceptance that "We want to advance the OS, and in order to advance the OS we're going to end up breaking some of these things."

Where in the past it was just like completely forbidden, like "Why would you even consider breaking Super Boomerang?" after a while, we got comfortable with having a little bit more of a vibrant development around the OS.

Being able to push back on a developer and saying, "Hey, you've been getting lucky for years now. Maybe you should fix your crap now or if you really don't want to, then it's on you to say you're not supporting Mac OS 8."

Guy: Was that something that came organically from the team or was that like did Avie come in and "Dictate that no other things are going to break?"

Nitin: That's the thing, I don't ever recall Avie specifically saying that. When we get to Carbon, we can talk a lot more about that. When it came time to update the tool box, and we understood that buttons were going to look different and controls we're going to work different than they had in the past, and maybe we're going to call these definition procs with different things set up at different times.

Where in the past it was on system software to make sure that none of that stuff breaks, things started to loosen up a little bit. It was possible now to go back to a developer and say, "We want to advance the OS. We want to make this thing better.

In the process of doing that, we've noticed that you're doing a couple of things that just aren't going to work well, so please, do something to go fix your app, or your init, or your system extension, or whatever the hell, because we're going to break it, and we're going out."

That was certainly not true early. If there were egregious cases where somebody was just doing something horribly wrong and we were going to break them, then all right, F them, you know? But around 8.0 and 8.5, advancing the OS started to come back to having equal footing with keeping the apps working.

Guy: That's cool. That's interesting, because that's almost a hallmark of modern Apple, not that they aggressively break things, but they're not afraid to deprecate things. They're not afraid to just move on.

Nitin: I think some of it started around there. I'm not sure if that was Steve coming in and saying things. I don't think it was. I think it may have been. Maybe it was product marketing just giving up. Timing-wise I'm thinking a lot of these changes happened around 1996 as far as I can recall. I don't think the acquisition happened until 97, so some of that predated a little bit.

Obviously, it got much stronger later, and the idea of advancing the platform and making that as important as keeping the apps working, obviously, that's something that continues today.

Guy: Yeah, I think that's a real strength of Apple actually. Being on the outside, every now and then you get bitten. But, by and large, I think it's a terrific approach.

Nitin: Yeah, and going back to Copeland, when we're slinging poo from the release, one of the things we would comment on is "How can you possibly let product marketing say that system extensions are supposed to work on Copeland? How can you build a modern operating system and make it so that system extensions will work?

Yes, I understand you can be very clever about this and have a Trap table, detect when people are patching things and come up with this very sophisticated way of extending things and what have you, but is that really viable? Maybe you should just push..."

Guy: It's a horrible engineering solution. Exactly, yeah. Yeah, whatever the marketing people say, that's a horrible engineering solution. What you need is a VM. You need BlueBox basically. That's the only thing that makes any sense for that.

So, 8 and 9 progressed pretty quickly with a lot of cool new features, and those are the classic OS's that I ran, while I was waiting for OS X to ship.

That's basically the time that I came to love Mac OS. When I first started, I was coming from OS II, Windows NT, and that kind of thing. The fact that things that stop as I was dragging the scroll bar up and down upset me. [laughs] But, I came to love it and really appreciate it. When does Carbon start to happen?

Nitin: Carbon started to happen, I think it was late 1997, maybe early 1998, somewhere around there. The NeXT acquisition happened, and the party line was still that, "Hey, we're going to have this thing called Rhapsody. Our modern OS story, it's all AppKit-based." If I can very generally paraphrase what the message was, as far as developers go.

Obviously, there was a huge push-back from your Adobes, your Microsofts, and your Macromedias, all your big companies. Those were really the dark days as well, right?

Guy: It's a hard sell, right?

Nitin: Yeah, it's a really hard sell. There were signs of that Steve Jobs brilliance and things like that. Apple, even after purchasing NeXT, that wasn't a credible story. It was going to be a very, very hard thing to push. As we all know, the developers at that time were looking to, I think the terms were, "Preserve their investment in traditional Mac OS development."

Guy: At the time, I was super-frustrated with that because I was at Propellerhead. I was working the games at the time, but just the idea of a cool new operating system excited me. Thinking about it now, that is a very rational position to take, given the many, many millions of dollars that have been invested in this source code.

Nitin: It's funny. I come at it from the other side. It's maybe even irrational in other ways where, "Yes, we've had this Mac toolbox. We can fix it up a little bit, and we can make this existing Mac toolbox. We don't have to go whole hard like the Copeland guys did and just make everything these overwrought APIs.

Instead, why don't we make some of these window records and dialogue records and graph ports and stuff like that? Why don't we make those opaque and make it so that we have a little bit better idea of what developers are trying to do by having these higher-level APIs?

There were certainly people on the Mac OS 8 and the OS 9 side, who felt like, "We don't need to do any of that. MOC is this horrible, message-passing operating system. Message-passing will never be as fast as a direct function call. Why are we even going down this road? Instead, what we should do is build up the..."

There was the nanokernel. We should give the nanokernel, and they could just fully preemptive thing. Get rid of all this message-passing shit, let's just show people what we can do with putting a modern kernel under Mac OS 9."

Of course, by then, the reality of the company and the way management was making decisions, that was just never going to be a viable thing. It was a last-ditch effort by a bunch of the old guard to keep things going.

Guy: This is when Avie was there?

Nitin: Yes, Avie was there at that time.

Guy: Avie's not going to swap out MOC. Pretty sure that's not going to happen. For the listeners at home, we wrote the microkernel that...probably not good to go against that. Interesting, though.

Nitin: I don't think this was as true on the release engineering side. But, on the Copeland side, there was a distrust, not really believing what the execs or the management were saying.

Guy: I can understand that feeling. From there perspective, the golden team and the project fell apart. You don't really know what's happening right now. I don't think it's necessarily rational, but I can definitely understand why the zeitgeist in that group would feel that way.

Nitin: That's true. You asked about Carbon. It was late '97 or early '98. Finally, there was this effort that was put into place to try to figure out, "What are the APIs?" I forget what the number is. I think 6,000 APIs in the traditional Mac toolbox. Maybe there's 3,000. I don't remember, but there were many, many thousands of APIs.

Of the APIs that were available, if we were to create a Mac tool box implementation on a modern foundation, what are the ones that we want to carry along and what are the ones we want to ditch, and why? Let's gather some data as well, to help support whatever decisions we are making.

It was around that time that there were discussions about creating something that I think would ultimately be called the Carbon Dater, which was if you had a PowerPC-native app, it would look up all of your exported symbols, all of the symbols that you need from the underlying operating system, and figuring out, "If you use..."

For example, a standard file, which was the old-world way of picking documents or saving documents, we just knew that that implementation was just horrible. We already have this new thing called Navigation Services, which was a new-world document picker or document saver.

Guy: It came in mid-8, right?

Nitin: Yes, exactly. That was, by the way, one of the things that was originally slated just for Copeland. Once Copeland sort of collapse, then the effort was, "Hey, we really want to ship this thing. Let's ship it on this. Call it Mac OS 8."

Guy: That's cool because actually, 8 and 9 got a bunch of improvements that you wouldn't have expected, but it's cool they were coming back from Copeland. Anyway, I do know the Carbon talk. You encourage people to get onto nav services, more of the stuff that you'd integrated from what was Copeland back into the OS 8 and OS 9 stream.

What was the impetus for Carbon? Did somebody say, "We really need Carbon on OS X."? Was Carbon originally, from your perspective, sanitizing the old Toolbox stuff?

Nitin: I wasn't in any of these meetings where I specifically heard this, but the feedback that I had heard loud and clear was that companies like Adobe and Microsoft, these big players, were not interested in writing a new version of their app in Objective C. That was just not going to for them.

Even in the past, when there was this thing called Copeland, it sounded like Apple had made all these promises to these companies that, "Yes, your existing binaries are going to continue to work, and we're to make sure that they work really well. You don't have anything to worry about."

As soon as this Rhapsody thing came in, then the story was, "Now, throw out all that old shit, it's time to learn Objective C and get on with it." A lot of these companies were pushing back and saying, "No. We're just not going to have a Mac product. Good luck to you, but we're going to release for OS 8 and 9. We're just not going to have anything for this thing called Rhapsody."

I think a lot of the impetus was just, "Oh, my God. How can we make it so that these big development houses come to this new operating system that's so critical to Apple's future?" I really credit Bertrand Serlet with really pushing the idea. In the past, Apple had really strived for binary compatibility, and we needed to keep these things like Microsoft Word 5.0 limping along on Mac OS 8.0 or things like that.

Bertrand was the, as far as I can tell anyway, one of the people in a position of leadership to push back and say, "We're not striving for binary compatibility anymore. We are now going to strive for source code compatibility.

Whatever we need to do to massage your sources or whatever you need to do, developer, to massage your sources to get onto a modern foundation, you should really see this as a big benefit." At the time, the message that was being thrown around and it sounded a little bit silly later, was if you had a moderately sophisticated app, in two weeks with Carbon, you can have that same app running up on OS X, what would become OS X.

Guy: I remember that slide.

Nitin: [laughs] Now you probably roll your eyes at it like, "Oh, uh-huh, two weeks." [laughs]

Guy: It could happen, but probably not. [laughs] It's a great objective, though. Carbon was actually pretty good, and it wasn't that far away from what was considered modern, classic OS stuff, right? Honestly, in those days, compiling work probably took three days, so two weeks is probably a bit short. In general, I think Carbon was a pretty good stab at bringing people forward. Truth is, it worked, right?

Nitin: Yeah, exactly, it worked. Just like we had started this new dynamic around Mac OS 8 and 8.5, we are now willing to push back on developers. We're willing to say, "No, you need to go and fix your app, too. You need to fix your extension, because the boat is leaving. You're either on the boat or you're off the boat."

We had shifted. It's almost the confidence thing where it's, "Oh, no, we're going to wait as long as we need to make this F'd up version of super boomerang limp along on Mac OS 8.5."

Guy: [laughs] You really hate Super Boomerang. [laughs]

Nitin: I do. I really do. [laughs] Mostly because I know the traps that they patched, all those things.

Guy: The thing is, the boat wasn't leaving. The boat was sinking. When the boat is sinking, it's like, "You don't get to sit in the deck chair anymore. You grab a bucket. Help us make this work." I think it was a good cultural shift.

Nitin: I think that that was one of the other things. Switching from binary compatibility to source was saying that, "Developers, this is not a free ride for you. You need to pony up some effort on your side as well. If you want to get your app working on a modern operating system, and believe me, at Apple, we want you to get that thing working in the worst way, so we're going to do what we can.

Make no mistake, you, developer, are going to have to put in some work." There were people at those early WWDCs who did not like that message. There were people who...

Guy: You can watch the video and hear people be upset.

Nitin: I heard some of that feedback myself in some of those sessions as well. It's hard to fault them. I understand. Now, you've got a third operating system to support. How are you going to factor in how much effort you put into that, compared to what the returns are? It becomes very complicated? Is it really worth it after all? What's this Mac thing going to do in the end? Why should I do any of this?

I really credit Betrand and the management at the time for having the stones to say that, "No. We want you to come along but you're going to have to dig as well. Pick up a shovel, pick up a bucket, let's start bailing this thing out. We're all in this together. If you don't, then hopefully, your competitors will."

Guy: [laughs] Yeah, right. With a bit of luck, you can play one against the other. How long were you in Carbon?

Nitin: I was in Carbon. I think it was...Oh, boy.

Guy: Wait. Was it its own cross-platform group?

Nitin: I was in a funny position. Early on, there was a small of people who would come from Copeland, a couple of really smart people. One of the guys, forgive me for name dropping, but he was my manager for a few years and I have a huge amount of respect for him.

He's a guy named John Hirochi. He had come from the Copeland side. It my understanding, he was part of the due diligence and the deep analysis of NeXT, and whether we wanted to get involved in this thing.

He had a couple of people working with him. There were some people from the QuickTime team, believe it or not. The actual, original basis for Carbon was this thing called QTML, which is the QuickTime Media Library. It was a portable subset of Mac Toolbox.

Guy: I did not know that. Now that you mentioned it. I do remember that, because I've used it in Windows in order to record one of those 3D movies, a series of frames that you can rotate around.

Nitin: Oh, yeah, QuickTime VR.

Guy: QuickTime VR thing. For advertising material for game I was working on. The game, you embedded QTML to basically create the VR. I did not know that Carbon was based around that initially or at least used that as a seed. That's interesting. Makes a lot of sense, but I have never heard that.

Nitin: Around that time, I had a chance to work with a couple of really, really sharp people from the QuickTime team as well. We were taking this QTML thing which had been ported to Windows, to Solaris, believe it or not. [laughs] It had been ported to a couple of other Unixy platforms. I don't think it ever shipped on any of those. What was the SGI one? Irix?

Guy: Yeah. I was just about to guess SGI would be Irix, yeah.

Nitin: It already had support for a Unixy-type system. It was a natural fit to start at least building the prototypes for what would become Carbon. Some of the very earliest prototypes that we built, in fact, to my recollection, the earliest prototype that we had built and demoed to Steve Jobs at the time was ClarisWorks, the entire Works package. This is really dating myself here. [laughs]

Guy: What are you talking about? You're just talking about working on System 7, you're dated. Don't worry about it.

Nitin: [laughs] Now, I'm worried about it with ClarisWorks? That's the one I focus on? [laughs]

Guy: That's a good one, because that's an honest-to-God application suite. It does real work, pretty popular. Had the source code. I don't know if it was spun out of the company by that point but whatever, you could get the code.

Nitin: We had the code. It was a pretty significant body of code, obviously. It was very full-featured. For the demos that we did for Steve, it wasn't something that he could install on Rhapsody with these crazy libraries and get something working. It was certainly demoware.

It was enough to prove the point that you could take a significant body of code, and with some tweaks and some largely mechanical changes through the code, in other words, accessing records to using getters and setters and things like that, you could have something that ran.

Guy: You didn't need to reinterpret the entire project and back. You could tweak a few things here and there. That was successful. That's a good sign for Carbon.

Guy: Did you work with third-party? I don't even know if you can say it. [laughs] Maybe not.

Nitin: I don't now if I can say either, but I'm going to say. [laughs] We work...

Guy: [laughs] It's been long enough.

[laughter]

Nitin: At the time, we had Macromedia in the offices. Oh, boy, it wasn't Director. It was another gigantic offering system. When I hear the name, I'll remember it. Anyway, yes. Macromedia was in there. We had our cobbled together headers that allowed us to successfully build and run ClarisWorks.

That was sort of the early, early basis of Carbon. We had been working with Macromedia to get a port up and running. We wanted to get it ready, and we wanted Macromedia to get up on stage at WWDC and say, "Hey, we did this port, and it took us a little bit of time, but, now it runs here, and it's the same source base that works everywhere."

Unfortunately, it never quite got to that point. One of the biggest things that we ran into, believe it or not, was the case sensitive file system on Rhapsody. It was all UFS-based, Unix File System.

Guy: Oh, yeah, I forgot about that. The first ones were all UFS. Wow. That's funny, that comes back with iOS.

Nitin: Yeah, so that bit us pretty hard, back at that time, just getting the thing ported. We really wanted to tell that story and have a third party tell that story, too. Ultimately, it was OK, because Greg Gilley from Adobe -- he was managing Photoshop or something like that at the time -- was able to get up there. I don't think it was a port of Photoshop that they got up and running. I think it may have been Adobe InDesign.

Guy: InDesign was more modern.

Nitin: Exactly. Adobe was one of the companies that had a very early version. They had InDesign and they were jazzed about this. They liked the story and they weren't pushing back, squawking too hard on, "You're going to have to make changes, but hey, you want to get on it. You want to get on a model class, you've got to pay.

Guy: InDesign, at the time, was the underdog to Quark.

Nitin: Yes!

Guy: I honestly think the OS X effort from Adobe is a large part of why they ended up eating Quark's lunch. Quark was so slow to, for lack of a better word, modernize, to come to OS X.

Nitin: Yeah, exactly. Those were the early, other than ClarisWorks and this Macromedia app that I wish I could remember the name of -- InDesign was one of the other early clients -- that we were able to get up and running, and prove to ourselves that, "Hey, this thing is viable."

Guy: Were you more at the Foundational level? I believe Core Foundation stretches back to Carbon, right? That got backported to the OS 8 and 9 tree.

Nitin: Yeah.

Guy: While Carbon was more like an HIToolbox. Was that maybe a bit later? I'm trying to remember.

Nitin: Certainly when we'd shipped, yeah, HIToolbox was definitely a big part of it. My early involvement with the Carbon team -- with John Hirochi and a couple of other people -- was around taking this giant body of APIs and saying, "Are you in or are you out?" Going through and making the call on these things.

Guy: Being the editor.

Nitin: Right. By then I had had a fair amount of experience adding new features and functionality to Mac OS and understanding, at least to some degree, what developers were using and what their expectations were. What APIs can we get rid of and developers will just shrug it off? Versus what APIs would we get rid of and they're just going to scream and call up their marketing person and tell us what a horrible idea this was?

My early involvement was on evaluating the APIs and then coming up with a plan for building this thing called CarbonLib out of headers. We also added some facilities to the interface generation tool that we had within Apple that allowed you to take this language that almost looked like a header file, but it was really generalized. You could build Assembly files for it, Pascal files, PowerPC, or 68k, and extend that so that it could spit out getters and setters for some of these records that we wanted hidden.

Guy: Right, because that's a huge effort. Just for the audience, it used to be these records...well, you're calling them records because it's Pascal lineage. But these strucs, these structures, used to just have all of their members exposed and you could just read and write to them willy-nilly in the code, which does not work well in terms of moving into the future.

One of the big efforts in Carbon did really seem to be effectively taking a more object-oriented approach, where you'd have functions that would get and set this to guard against people just poking random stuff. I didn't know that was automated. That's interesting.

Nitin: Yeah, that was actually automated. My earliest versions had started as a Perl script, but then worked with...

[laughter]

Nitin: So it was "automated" with air quotes. Then, yes, it got formalized and built into the tools that we used to create those headers. Later, my involvement was more on the OS 8 and the later OS 9 side, building this thing called CarbonLib. I was the lead on CarbonLib for OS 8, just figuring out how this library is supposed to work.

We knew we wanted to get rid of these things called definition procs or def procs. Within the Mac toolbox, if you wanted a menu that looked different from the traditional Macintosh menus, you had to create a definition proc that said, "No, the rectangle really is this big. Instead of just drawing text in Chicago 12 this way, draw a little grid of colors that a user could choose from," things like that.

Guy: I never really looked into it that much. Is it a callback system?

Nitin: Effectively, that's what we turned it into. Yes, you're right. It was a callback system but really it was code that was embedded in its own resource that would get these different messages for "Highlight item one," or "Draw the title bar or "Draw the selected title bar." Effectively it was.

Guy: Based on the message it would get, and by message you mean an int. You'd get, "This is the action that was happening," and then it would do something to the graph that it was responsible for.

Nitin: Exactly. The way that had traditionally been done on the Mac was, in modern terms, you had to have your own sub-project or target that built a little resource of code that the system then loaded and used to handle the definition of the look and feel of this thing.

For Carbon, we didn't want that anymore. We didn't want people to write code resources. We wanted it all in a single binary executable. What we did is effectively create a callback system, where we just had a generic code resource, a generic def proc, that ran on Mac OS 8 that would just bind to the application's shared library and call the routines directly from there.

If you're writing an application, you just implement these callbacks. It was just a much nicer system, even.

Guy: Yeah, it's way nicer.

Nitin: It was trying to marry the two worlds and make it so that if you did all this work to modernize your application code base, we wanted to make it so that it worked well on OS 8 or OS 9 as well, as part of preserving your investment in this code base and keeping your apps working through the releases as we make this giant transition.

Guy: Like at DTS, this must have been a huge learning experience. Not only do you need to know all the internals of the classic OS, which you'd been working on, but you needed to quickly learn a lot about what I believe at the time you were still calling Rhapsody. How did that feel? Was that like jumping into the deep end a little bit -- a brand-new operating system?

Nitin: Oh, God, yeah. [laughs] But it was fun too. Yeah, you're right. It was an awful lot like being in DTS, where you're being paid to learn. How many chances do you get in your life to be paid to learn?

As an engineer, you get paid to learn every day, if you have the right attitude about it. Really, whatever your attitude is, you have to learn how the existing system works and how to make something new that works well on the new system.

It was a little bit of going off the deep end. Because I went to Santa Cruz and a lot of the computer systems there were UNIX-based, I had some experience with it, obviously not a huge amount. We didn't have NeXT stations or NeXT cubes at UC Santa Cruz.

Guy: I don't even think they existed by that point.

Nitin: Yeah. They were there. I remember seeing them here and there. Late in college anyway, I remember seeing one.

Guy: What happened with Carbon? Eventually you transitioned out of that group, a very successful project. We would not have the Mac today without Carbon. As a guy that's basically an app-kit, open-step guy, or that's at least my vector into the platform, there's no denying that Carbon is really what made it into a viable platform for the long term. Good job.

Nitin: [laughs] Thank you.

Guy: Problem solved. What happens next?

Nitin: Thank you. Thank you for saying that. I agree. It was critical at that time. You can look at it technically and say, "All you did was hide some symbols and expose some new symbols and covers for some of these APIs," but, yes, I believe it was critical. History has borne that out.

Guy: At the time, I would probably have been one of those people that was holding their nose up about it like, "It's a Carbon app." The truth is, yeah, it's a Carbon app and it's Photoshop. Guess who uses Photoshop. A lot of people use Photoshop, or Word or what have you, or the Finder, iTunes.

Nitin: There was definitely...

Guy: It's a big deal.

Nitin: Yes, I agree. I wish that it was a little bit more integrated into the system sooner than it was, or felt like it was integrated. In other words, when you launched Internet Explorer, which was the browser at the time for the Mac, on Mac OS X, you knew you were in a Carbon app.

The text rendered a little bit different. It was pretty ugly compared to Cocoa. If you were using Office, it took a little longer to launch. Actually, maybe it didn't, but when it came up, you definitely felt like it was something different than the rest of the system.

Guy: It took years to get services working in them. There was a bunch of stuff that was like, "This is clearly a Carbon app." On the other hand, dang it, these are murky apps. If you didn't have them on your system, it would be the Amiga running on a PowerPC. It's pointless.

Nitin: Definitely. On the Carbon team, we really held on to that. We used that to keep us going, too. Even at the time, it wasn't like Carbon was held up as, "Angels sing when you see a Carbon app."

Guy: No, it was always a necessary evil, which is a downer to be on.

Nitin: Exactly.

Guy: [indecipherable 01:57:28.02]

Nitin: You don't want to work on something that everybody just begrudgingly accepts that, "Yeah, it has to be here, because things would be so much worse without it." Who wants to work on that? You want to work on, "Oh, my god. This thing is fantastic."

Guy: It's funny. I'm just realizing that you were on the 7 team, which was the necessary evil team. Then you did Carbon. You're an under appreciated fellow is what I'm saying.

Nitin: [laughs] Yeah. Thankfully, I never really felt that way for me, but who knows what I'd be doing?

Eventually, yes, I did transition over from the lead on CarbonLib for OS 8 to working in the Carbon team, working for John Hirochi who reported to Scott Forstall directly. That was long before OS X shipped. I think I made that transition in 1999, when I first started working for John full time. I was working on the core services components of Carbon, in particular the File Manager.

File Manager, Resource Manager, those low level bits, some Process Manager in there, things like that. Some of the challenges there were that we wanted to have this single, unified API. At that time, Avie Tevanian was the VP of Mac OS development. He was a very strong believer in heterogeneous systems, and fitting into existing networks of computers and things like that.

Guy: Hence, the insistence of file extensions and a bunch of other things.

Nitin: Exactly. Getting rid of resource forks. Resource forks were seen as this weirdo Mac thing that no other file system had. Later, Windows added it to NTFS. They had multiple streams. Even then it was a bizarre thing.

Guy: It was two-headed. Invariably when you try to zip something up, forget it. Everything would break anyway on all of these systems.

Nitin: Right. [laughs]

Guy: It's a nice idea. It's a really nice idea, but keeping things simple is a noble goal, too.

Debug is a casual, conversational interview show featuring the best developers in the business about the amazing apps they make and why and how they make them. On this episode Matt Drance of Bookhouse Software, Ryan Nielsen of Tumult, Daniel Jalkut of Red Sweater, and Jason Snell of Macworld join Guy and Rene to talk about Apple's WWDC 2014 keynote — the Swift programming language, Extensibility, Cloud Kit, Metal, and more.

• Subscribe in iTunes
• Subscribe in RSS
• Download directly
• Follow on Twitter

Show notes

• Apple WWDC 2014 portal
• Macworld WWDC 2014 coverage
• iMore WWDC 2014 coverage

Panel

• Matt Drance of Bookhouse Software
• Ryan Nielsen of Tumult
• Daniel Jalkut of Red Sweater Software
• Jason Snell of Macworld
• Guy English of Kicking Bear
• Rene Ritchie of Mobile Nations

Feedback

Question, comment, recommendation, or something you want us to follow up on for the next show?

Email us at debug@mobilenations.com or leave a comment below.

Vicki Murley, former Safari Technology Evangelist at Apple, current founder of Sprightly Books, talks to Guy and Rene about web technologies, speaking at conferences, and beating Dan Brown at the book game.

• Subscribe in iTunes
• Subscribe in RSS
• Download Directly
• Follow @DebugCast

Show notes

• CSS Transforms: An Interactive Guide
• Vicki Murley, "Know Your Platform: Desktop vs. Mobile" at W3Conf 2013
• Renaissance 2014

Guests

• Vicki Murley of Sprightly Books

Hosts

• Guy English of Kickingbear
• Rene Ritchie of iMore.com

Feedback

Yell at us via the Twitter accounts above (or the same names on ADN). Loudly.

David Gelphman, former graphics and imaging engineer at Apple, talks to Guy and Rene about writing the book on Core Graphics, developing AirPrint, and discovers Montreal has bagels (Part 2 of 2).

• Subscribe in iTunes
• Subscribe in RSS
• Download Directly
• Read the transcript

Show notes

• David Gelphman's blog
• Programming with Quartz: 2D and PDF Graphics in Mac OS X (The Morgan Kaufmann Series in Computer Graphics)

Guests

• David Gelphman

Hosts

• Guy English of Kickingbear
• Rene Ritchie of iMore.com

Feedback

Yell at us via the Twitter accounts above (or the same names on ADN). Loudly.

Don Melton, former Engineering Director of Internet Technologies at Apple, returns for a special follow-up episode with Guy and Rene to discuss the newly announced Google Blink and Mozilla/Samsung Servo HTML rendering engines, and to tell us what us which new bear he's trying to get dancing.

• Subscribe in iTunes
• Subscribe in RSS
• Download Directly

Show notes

• Blink: A rendering engine for the Chromium project
• Mozilla and Samsung Collaborate on Next Generation Web Browser Engine
• Úll conference

Guests

• Don Melton of donmelton.com

Hosts

• Guy English of Kicking Bear
• Rene Ritchie of iMore.com

Transcript

Rene Ritchie: The world needs to calm the fuck down a bit, I think. Sorry. [laughs]

Guy English: Alright, this is Guy English.

Rene: This is Rene Ritchie, and welcome to debug. Today we are revisiting Don Melton because the minute after we let him go the last time Google announced Blink, Samsung and Mozilla announced Servo, and the entire world went topsy-turvy. Is that fair Don?

Don Melton: Yeah, to talk about Blink first. By the way, I don't normal comment on Apple's current efforts, policies, and things like that but since Webkit is an open source project, I'll keep my comments narrowed to that. I was surprised it was that particular day from the announcement, but this was not unexpected. Something like Blink, well the name was unexpected, "Blink," who the hell came up with that?

I've really been expecting them to fork for a while. I figured they would fork after we announced Webkit2, so it's not unexpected. They're allowed to fork, Webkit is open source. Essentially, I did the same with KHML AND KGS almost 12 years ago.

It's not that big a deal. To get to it, everybody needs to chill the fuck out, to use the f-bomb again. It doesn't mean the death of Webkit, or the ascendency of Blink, or anything else like that. Some things just got easier and some things got harder for both projects and both teams. I get real annoyed at the press because Blink isn't suddenly more streamlined, since it's left the quote unquote crusty old Webkit.

I can guarantee you code is being jettison from Webkit2, maybe even more so than from Blink, but who knows? It's not that big a deal.

Guy: Do you think that the stated goal was to jettison a bunch of platform support that they don't need and try to clean things up a little bit?

Don: I think that's the stated goal, but in a way it's really about control.

Guy: OK, yeah.

Don: I mean all forks are about control. Doing a big cooperative project like that there's always body checking. [laughs] Especially when you have big companies and big personalities, but it's not really that big a deal. The thing is when you're in the web browser or web content engine business you know everybody after awhile.

I mean I've worked on... well depending on how you count three of these systems, and I know a lot of people, and there's nobody that I don't want to talk to. I mean, I still talk to folks from time to time. I still talk to Brandon Ike on occasion. Mike Shafer even though he's over at Facebook now. I talk to Dean Hasimovich at Microsoft every once in awhile. Hell, he's a Facebook friend.

These things are complicated and I don't want to project something onto the situation that was not there. I don't think anybody is particularly panicked or all that upset on either side. You have to remember that the projects are still more alike than they're different now and they probably will be for awhile.

Rene: Was it a reasonable fear that you know people would wake up and it would be IE 6 all over again and you would have to add special exemptions for Blink, and different code for Chrome, and the web would go back to having isolated islands? I think that was the panic response when the announcement came out.

Don: There's been a panic for awhile about the whole Webkit mono culture thing, and it may be the only good thing that comes out of this in the short term is it calms those people down because you've got two of these things now. I think that was some concern, but let's see what happens. It's too early. Anybody that claims to know what's going to happen here is full if shit. Including me.

[laughter]

Don: The other the thing to keep in mind is that like I said the press that I read about this was really annoying me because you know it's all the, "It's great for Google, it's bad for Apple," kind of thing, and that's kind of horseshit. It cuts both ways. Google is not going to have the crew that started Webkit.

They don't have Maciej Stachowiak, David Hyatt or Darin Adler, that are still working on Webkit. They don't have Adele Peterson, Sam Weinig or Jeff Garret. Those are kinds of things that they miss, too. They don't have the other resources. Apple's not going to have, obviously, some of their people and some of the other things, but it's not death. It's OK.

Guy: You feel it got spun into being a massive corporate kind of battle...

Don: Yeah, it's not really that big a deal. It's big corporations, and I think when you work on Webkit, you try to ignore that as much as possible. If you talk to some of the Webkit and Blink people, probably, dealing with W3C and other organization's more of a hassle that that, that's always been a headache over the years.

Rene: You're basically telling the kids that mommy and daddy won't live together anymore, but everything's still going to be OK?

Don: The thing is they're still going to have to live together. If you think that if Apple does a security patch in a piece of code that it needs to be shared, fixes some bug. You don't think Google is not going to go over and figure out what the div is patch and put that in. They're going to have to do that kind of work. They're going to have to work together and talk to each other still for that kind of thing, and it goes both ways.

If Google comes up with something in a piece of shared code they used to have, and Apple thinks that would be useful, the Apple guys...It's not just the Apple guys. There are lots of other people besides Apple working on Webkit, and there are other people besides Google working on Blink. Maybe, this is something that doesn't completely last.

There have been times when projects have forked and they've come back together. Who knows. One of the more interesting announcements was Servo. I wasn't quite expecting that.

Rene: Apparently, from the rumors at least, that was deliberately done right in front of Blink just to get out ahead of them. It was interesting.

Don: [laughs] If [indecipherable 7:55] , I would have done that...

[laughter]

Don: ...to get everybody distracted. They needed some press there. It's a...

[crosstalk]

Guy: What do we know about Servo? It's a whole new thing.

Don: Nothing. It that they're wanting to go out and rewrite their engine, and use the new language that they've been working on for several years called Rust to rewrite the engine. They're not rewriting everything in Rust. They're rewriting the core. They're essentially rewriting large parts of Gecko in Rust.

I don't think they're rewriting everything. I think it would probably be crazy to rewrite everything. I'm not sure. One of the reasons they said they needed to use Rust was for performance. I'm not quite buying that because C++ seems to have been working fine for Webkit and the LLVM Teams for years. I'm not buying that.

Guy: The other one was they said security, too, right?

Don: Yeah. I don't know why the language really...You can write secure code in COBOL.

Guy: [laughs] I think it has affordances that makes it easier to avoid buffer overruns and the basic stuff.

Don: That kind of stuff, yeah. We investigated things like that at Apple. You have to be very careful with that, because you can also introduce tremendous performance penalties if you try to do it in a generalized way in places where you don't actually need it. You want to focus on where the real problems are, so you have to be careful with that.

Rewriting an engine from scratch is not always wise. When we started Safari in Webkit, I didn't want to rewrite the engine from scratch. I knew that they would fire me before I was able to get something done. That's why I used something off the shelf. We eventually rewrote it. People don't realize is that WebKit has being rewritten multiple times. It's always rewritten, refactored, [laughs] and redone.

It's a subtle thing that the WebKit team has always been doing. That's why it's so up-to-date and cool, because it's always being reengineered. But it's done in small chunks, carefully.

Guy: I does seem a little foolhardy to just publicly say that you're going to be writing an engine with a new language. It's biting off a lot to chew.

Don: Props to them for having the stones to do it, if they can pull it off.

Rene: Yeah. I think the Samsung angle is really interesting here too, because they do Android, but they used to do Bada, now they're doing Tizen on the side. They have the Android browser, and the Chrome browser, but now they're doing Servo on the side.

Don: Samsung, I cannot figure out. It seems to me that there's somebody with a magic eight ball over there, just rotating it and trying to figure out technology choices, at least for software. Software, I can't figure out what the hell they're doing.

Guy: Yeah, I don't understand them at all. They're making money, so [indecipherable 11:32] , but I still don't understand what their thinking is.

Don: In the mobile space, it's basically the two people making money on hardware are Apple, who makes the most, and then Samsung, and nobody else [laughs] makes really any money these days to speak of. Hey, maybe they're up to something...

Guy: So did Gecko need it? Sorry, go ahead.

Don: I'm sorry, maybe they'll pull this off, who knows. Best of luck to them. I know some of the people over there working on that. They're good people, they're smart people.

Guy: That's certainly an interesting direction to go in, rather than just grabbing off-the-shelf stuff, trying to actually roll your own. It's an interesting play for them.

Don: Yeah. Being a Web engine geek, I'm sure I'll download it, try to compile it, and stuff like that, like I do occasionally when the fit hits me for other things and see what's happening. You know running WebKit nightlies and stuff, I've done that for years to keep appraised of what's going on, and to nag people I know about some bug or something else that I've had.

I do that for lots of other projects, just hobbies, but it goes back to having the superpowers. As a geek, you can do that stuff. I do not recommend this for other people. [laughs]

Guy: The nightlies aren't for everybody?

Don: No, WebKit nightlies are very, very stable, but I don't recommend them for everybody. I think a lot of people who run them are actually not the developers. The code developers there are website developers, content developers, who run the nightlies. I think that's actually a really good thing, because that's especially who you want feedback from.

Guy: Yeah, good valid testing.

Don: You need to listen to those people.

Guy: Is that true for Servo? Is this Servo public at all yet or is it just a name?

Don: I have no idea, I haven't looked yet. I'm waiting until I see something on Hacker News, and like, "Oh, OK. I'll go..."

Guy: Yeah, exactly. It seem like...

Don: That's what everybody does, right?

[laughter]

Don: Anyway, the sure thing is, everybody calm down about WebKit and Blink and let the teams do their jobs, Servo is interesting, and best of luck with that.

Guy: [laughs]

Don: Yeah, they're all going to work. There's not a...

Guy: I don't think we're going to get back to the time where the Web is so bifurcated between totally different engines. I don't think it's in anybody's best interesting.

Don: It's not the engines we should be worrying about with the Web. It's co-opting the Web in other ways, it's what we should be worrying about. If governments take over essential services and technologies, that's when you worry, because governments always know what they're doing. That's the kind of crap I worry about.

But this...these little pissing contests between engines and other stuff like that, or supposed pissing contests, because there's not really that kind of thing going on. For example, I know some of the people in the Blink team. Some of those guys, I hired, either at Netscape, at least one at Apple, one over there. These are nice people. They're not jerks...

Guy: Yeah. I don't think this needs to be a consumer level conflict, necessarily. It's just the way the code is going, and it makes sense to split it down the middle and go in different directions.

Don: Yeah, we'll see what they come up with, and yeah, whatever.

[crosstalk]

Guy: I love that this is the big news and you're just bored by it.

Don: No. As you said, that was several weeks ago. But my attention [laughs] span is very short, anyway.

Guy: It should be, because it's certainly not now.

Don: The thing to do is that a year from now I have a retrospective and, say, we still don't know [indecipherable 16:38] .

Guy: Yeah, and even a year from now, I can't see, anything huge. Like what? Like and extra [indecipherable 16:48] .

Don: I think a year from now...I think the projects are still going to be very similar. It's not that big a deal.

Guy: It seems like a huge codebase and it would take a long time to go in a radically different direction. Not only that, but the goal is to render everything the same anyway, so from a user's perspective, I don't see this being such a big deal.

Don: No, from the user's perspective it could be an improvement because of competition. Look at what happened when we came out with WebKit and Safari. I talked about this during my talk at Google, how we made Safari fast. We started the second browser war, it was a performance war. That was just better for everybody.

Guy: Yeah. When you're building this, you're making decisions. You're like, "This is the way we're going to go," and any one of those decisions might have gone either way. With WebKit and Blink, you get a bit of an A/B test. You can try different approaches.

Don: Right, and there's competition among teams. There certainly always has been. Remember the ACID test, the silly ACID test, that even Hicks says that they're silly. There's competitions between all the different browser teams to try to get the best scores on that. Some of that was just nonsensical, but in other ways, it improved everybody's engine. It's a shame that there's not going to be an Opera engine anymore.

Guy: Yeah, I forgot about that fellow. Poor Opera, man. What happened there? They decided to go with Blink?

Rene: Ice and Blink.

Guy: Well, they've decided to go with Chromium. What I get is they're really choosing is Chromium because they needed a GUI because they were not only letting go of members of the core team, they were letting go of members of UI team and stuff like that. They needed a project that was a browser too.

They'll naturally follow the Blink path rather than the straight WebKit path because they need GUI. I mean, Apple does not open source Safari.

Guy: That's a shame. I know they had weird, spotty support at times, but I like having that sort of biodiversity.

Don: Oh yeah. You know I'm a browser geek, so I have every browser ever made. I usually have...Let me go into Launchpad here. On my top row in Launchpad, I've got Safari, Firefox, Chrome, and Opera right up there.

Then I got VMware, so I can run, not VMware, VirtualBox, so I can run multiple versions of Internet Explorer. I got a simulator around here somewhere, so I can run the older versions of stuff just when I get nostalgic.

Guy: You have some browser cred is what you're trying to say.

Don: That's like being a browser fanboy, that doesn't mean cred. But a lot of content developers have that same thing. I've had that for years for testing purposes and stuff.

Guy: You mentioned breifly, but you were in Dublin for the Úll conference recently. You've got to talk about making Safari faster.

Don: Actually, it's pronounced "ul." Not "yul," "ul." I got dope slapped for that a couple of times at Úll conference. It was the best conference ever. Let me tell you, it was fantastic. The hosts, Paul Campbell and Dermot Daly, are just wonderful people.

They put together this conference that's not only wonderful for all the speakers but wonderful for all the attendees. If I was a sponsor of the conference, I think for the sponsors too. It was fantastic to go to Dublin, I'd never been to Dublin, and to meet all those wonderful people and listen to just some amazing folks.

I met Matt Gemmell and his silky smooth Scottish voice. I told Matt that I wish I could bottle that voice and take it back to America. I got to meet Gruber finally in person, he's hysterical, along with my old friend Michael Lopp, and Horace Dediu, and Michael Johnson, Dr. Wave, from Pixar. I got to have dinner with them and Neven Mrgan.

Guy: Neven's great too.

Don: Horace is a brilliant man. We were in the...I think it was one of the breaks in the afternoon. In this session, we were all in this pub. I think it was one of the pub sessions that was sponsored by either Dropbox or Github.

We're standing there next to the bar interfering with other people's ability to get Guinness [indecipherable 22:31] . Horace would say things and would talk about the industry and say, "Anyway, that's my theory. What do you think Don?" I was getting the point, and I was just joking with him and I was saying, "Damn it, Horace! You're right once again." At least in my opinion, he is a brilliant guy.

Of course, Michael Johnson, he's got so many stories from Pixar. He and I had probably, between the two of us, some of the best Steve Jobs stories there. We actually were to of the people, as we were both joking, we were two of the people who, Steve actually knew our names which was a good thing and a bad thing.

[laughter]

Don: Other people there, Jamiee Newberry from Black Pixel, she was great. Charles Perry, a guy I never heard of from the company called Leaf Hut Software. He did this talk on accessibility. Oh my God, It's the best talk on accessibility I've ever heard.

Guy: Yeah, I think that's an overlooked technology at times. I'd like more attention payed to that.

Don: Of course, Jim Dalrymple was there. He talked about, I think in his podcast last week, about his "panel discussion" he had with Dave Wiskus and Kyle Neath which was not a panel discussion at all. It was a performance.

They went out and set Dave and Kyle and one of the other people, I forget who it was, were introduced by, I think it was Durment, sat on these stools as if they were going to do a panel discussion. Then they said, "Here's Jim Dalrymple," and he walks out with a guitar. The panel was actually a band.

They did 12 cover tunes, all the original songs of course which are in my iTunes playlist, I don't know about your...classic kind of rock, Led Zep, AC/DC, Nirvana, and stuff like that. It was great stuff. Then an original composition by Jim, that was fantastic.

Guy: Sounds like it was a blast.

Don: Yeah, the people there were great. I got to meet the Lord Mayor of Dublin. He's hysterical. I had to practice pronouncing his name, spelled N-A-O-I-S-E. I guess it's pronounced "Neesha." My new friend, Oisín Hurley, he was one of the sponsors and his buddy, Barry Scott, from Converser. Oisín's name is spelled O-I-S-I-N. Gaelic, it's hard.

[laughter]

Guy: It's not even a word. It's not a name? It's not even a word.

Don: What you learn to do is you have another Guinness. Let me tell you, if you go to Dublin, if you go to Ireland, you need to have a Guinness because when I went to Dublin and I drank my first Guinness, and not my only Guinness let me tell you, it made every Guinness I've had in the States taste like piss. You know what they say, "It doesn't travel well," and they're right.

My wife went with me. We went to St. James's Gate Brewery for the tour which was fantastic and had one each poured for us up in the Gravity Bar up on the, I don't know, seventh or eighth story, where you can overlook Dublin, fantastic view. It was like this marvelous beer milkshake. Oh, my God!

Guy: [laughs] That sounds great. I got to go there. I'll try to go next year.

[crosstalk]

Guy: Don't worry. They'll put in a good word for you.

[laughter]

Don: Paul Derman! I love you guys. No, seriously, they're really fantastic.

Guy: You gave a talk about speeding up Safari. Do you want us the gist of it?

Don: It was a bit of history about how we made Safari fast. One of my jokes in the talk was, we made it fast by making it slow first. [laughs] Fortunately too slow. Why I wanted to do the talk is I wanted to delve into a bit of history, and inside baseball for people, because they seemed to enjoy that, and things that they may not have heard, that nobody had ever heard, as far as I know, outside of the fruit company.

Outside of my little sessions, I would do at Apple in my department...The new people in the department would sometimes say, "Gramps, tell us a story. Something about back when you and Al Gore invented the Internet."

Guy: You'd sit around the campfire in the office?

Don: Yeah, pretty much. Around the couches and stuff like that. I would tell stories, usually with Darin Adler hanging around too because Derin's got...Hell, he's got even more stories than I do in a way because he was back at Apple back in the late '80s and early '90s. He and I would have dueling bullshit going on sometimes. That was a lot of fun.

We, as you well know from talking to me, he and I could both talk for hours, so a lot of fun. The new folks would actually listen and were semi-respectful. Hopefully, they'll learn something from those talks. I'm hoping they make a lot of stories of their own now. That's what they're doing.

Guy: I'm sure that's happening. It's the way things go, right?

Don: Yeah.

Guy: What was the gist? What's the take away from your talk?

Don: Well, the gist was that...What the hell? I had my speech laying here. I'll just get out my notes. The gist of it was, I asked, at the end after I told the background story was, "What do you want to learn from this?" It's real simple principles that a lot of people know is you set the bar high and performance. You don't optimize ahead of time. You measure first.

This is something people always do wrong. You focus on the bottlenecks, and you just lather, rinse, repeat that. You make sure over time you add metrics. You never ever regress, ever, never. Did I say never? You never ever...

Guy: I think that's the big one.

Don: The other one is you make it your religion. Dante's sixth, not the seventh, circle of hell, it's good to be precise, has a place for people who invent their own religion. I'll probably be there right next to L. Ron Hubbard one day.

Guy: [laughs]

Don: I told a thing at the conference. I said, "Some teams out there like to have a performance month at the end of their projects." After they have an 18-month project and they have a performance month where they focus on performance before they ship, and we used to joke on the Safari team, we have perform months too, 12 times a year.

Guy: [laughs]

Don: Either you make it your religion, and you get serious about it, or you're not really focused on performance.

Guy: Yeah. When I worked on games, obviously performance is an issue, and so often, before some big milestone, there would just be a giant push to try to get everything performing well. It just felt like exactly the wrong thing to be doing. We should be more conscientiously keeping the frame rates up and keeping the times down.

Don: Yeah. [indecipherable 31:29] all the time.

Guy: Throughout the entire process.

Don: Yeah, yeah, that's what we learned. That's what the object lesson from the...The joke I made, it's how did we make Safari fast, well we made it really slow first. It was my fault. We took our eye off the ball. I was so focused in the beginning of the project, just getting that bear to dance that I was unaware that it was shuffling across stage, not dancing. We fixed that.

Guy: OK. [laughs] One interesting thing about Web engines is that the content isn't under your control.

Don: Oh. Interesting is not that's the word that I used for that.

[laughter]

Guy: What's your word, Don?

Don: That's like the Chinese [indecipherable 32:18] we live in interesting times.

Guy: [laughs] Exactly. What's your word? You can be as impolite as you like.

Don: O God, that would take more that the [indecipherable 32:33] .

Guy: [laughs] It's difficult to make something perform when you don't control the input, or you have no hope of controlling the input at all.

Don: Right. You have to realize that you have to approach a Web engine the way you would approach a operating system. It's almost as complex. Very, very close. People will do crazy-ass things with your APIs. You have to keep that in mind. That's why, when I said Webkit nightlies, I'm always delighted when I hear content developers are out there using it. I was like, "Yes! Yes! Please do that!"

Because if you notice something stupid in terms of capabilities, breakage, or, more importantly, performance on your site, we always encourage a lot of the big JavaScript framework folks, "Please use the WebKit nightlies, and tell us if you notice something going south right away," because one, we'll fix it, and two, we'll figure out a way to turn that into a test, another metric, because a lot of those systems are so complex they're very hard to test.

Guy: Was that something new that you...When you were at Netscape, did you guys do a bunch of tests all the time? Did you have a test suite and did you do the time test suite, the similar stuff that you do in Safari?

Don: It was not as rigorous back then as I'm sure the Mozilla team is doing now. They're much more rigorous now. Because after WebKit debuted and Safari really shot up there in terms of performance compared to other browsers and people were publishing stats on that, the Mozilla team had their "come to Jesus" moment and they really got serious about performance, too.

They adopted a lot of the same techniques and they developed other things. Especially the Mozilla conformance test, they're open-source, so everybody uses those. Some of the ones that we have, they use, because they're open-source. They do that now, but back in the old days, we didn't really have criteria before shipment, we didn't have policies during development that prevented regressions. We were not as focused on that.

Guy: How does that work at a mechanical level? There's a check-in, then there's an automated test that runs, and if the timing is slower, then the check-in is just rejected, somebody gets an angry email, or what?

Don: It's usually an angry email and then a club. [laughs] In the beginning, what I was talking about, my talk, when we discovered the sloth and stuff, we didn't have the automated test on Safari in the beginning. We had a testing harness that Ken Kocienda wrote, God bless him, and that we were able to use.

But it was very hard to get consistent results from it, because you're testing the network, the IO, and other things. Believe it or not, I was one of the few people on the team who could actually run the damn test and get consistent results. I used to aggravate the engineers.

Guy: [laughs]

Don: Being able to do that calls for this anal retentive psychosis.

Guy: [laughs]

Don: That's just perfect for me. In another life, I was a QA engineer. I run the tests, and if I detected we were slower, I closed the tree. That was the beginning of my policy, that policy that I pulled out of my hiney. Boy, talk about making yourself popular on your team doing that!

Guy: [laughs] Let's say you'd literally lock down any other commit until the speed was up?

Don: The engineers, at first, were like, "Why are you locking everybody out?" I was like, "Prove to me that it was just one check-in that's the failure. Unless we know what the problem is, I don't want anybody adding to the noise. I don't want to give up any gains." Why would you give up a gain? Never regress.

The thing is, with a no regressions policy...By the way, the engineers balked at first, but they very quickly, to their credit, the team, totally got it. They're carrying on in my place now. It's jihad now over there. They totally get it. The thing that we found out from the no regressions policy is, even if you're not focused on performance and you're just checking, making check-ins on other things, but you never regress performance, dumb luck...

Guy: [laughs]

Don: ...will make you faster. Entropy will make you faster. You're going to get gains not even trying. Why would you ever regress? That's crazy. Don't give up ground on good fortune. You're winning the lottery there. Maybe one percent, but one percent is one percent. If you could measure it and repeat it, well, ka-ching!

That's money in the bank. You certainly never want to give up gains on hard work. That's just crazy.

Guy: How do you balance that with...Let's say there's a certain CSS feature that you need to implement, but...

Don: That's a story in my talk right there. That's a great example. When Dave Hyatt, the brilliant Dave Hyatt, shortly after he joined the team, we noticed that...He noticed because he's much smarter than the rest of us, and he was the first person on the team that really allowed us to actually spank KHTML, because I had the rest of the engineers focused on making everything around the engine actually work until they got enough domain knowledge to go in and actually change things.

But Dave had been working on Web engines at Mozilla for a while, so he had the experience. He came in and, first things he started on, because he joined the project a year in, was that KHTML was really awful at DOM whitespace handling at the time. This would mean you would get an incorrect DOM being created, and it was causing all sorts of compatibility problems.

Dave worked on this huge patch for over a week, and we really needed this correctness improvement. He told me he was working on this and I thought it was a great idea. He came to me and said, "OK, the patch is ready." I said, "OK, what's the performance impact? How did you test?"

We put it on the scope, and it was eight percent slower. [laughs] I was like, "We really need this feature, Dave, but you can't check it in." [laughs] He was like, "But it's doing so much more work!" because it was doing a lot more measurements and stuff like that, and, "It has more features."

I would hear that thing from people over the years, and I was like, "Nope. Find a way to make it faster." He grumbled at first, but he went away for a few days and he came back with another version of it that was one percent faster than what was in the tree. He made a nine-percent improvement and posted on the line. Not only do we get the new feature, but we get a one-percent performance improvement.

That's what you do. You never regress. When I hear about people that are, "Well, it's doing all this extra stuff..." Now, you have to be very, very careful about what your metrics are, what your benchmarks are, upfront.

Guy: I was just going to ask that.

Don: Yeah. You don't want to bite yourself in the ass later on. Engineers have learned showing me demos of little things that they're working on at that time, not just showing me something that's really performing because it's not using real data or not connecting over the network, not a simulation, because if they show me the real thing after that and it's slower, that, I don't like it. Don't show me that's not going to be the real behavior, because that's going to make me angry.

Guy: [laughs] Yeah, I think that's a good point about the metrics. If you're not measuring the right thing, then this Middle Ages fervor to meet the metrics is just going to end up being misguided. I think that's probably the key is trying to dissect and figure out exactly what you want to measure and what you want to stick to.

Don: It's really hard. It took us a while the get the hang of that on Safari and Webkit, it really did. We had too many simplistic metrics in the beginning. These benchmarks are really hard, especially when you're dealing with live content, and making this stuff consistent. You have to deal with static pages, and then you have to simulate live connections, in other ways, it's maddening. But there are smart people working on this, much smarter than I am.

Guy: So there's hope. [laughs]

Don: Yeah, there's hope. The thing that I interjected in the process was anal retentiveness and a willingness to be an asshole, because that's what you have to be. If you're going to lead a project, you have to say, "No, we're going to do this and you have to be willing to be unpopular."

It's tough work, but in the end the engineers work is much harder. They were the ones doing the real heavy lifting. I just got to sit back and be a jerk.

Guy: [laughs] Cash a paycheck.

Don: Yeah, I'm sure they had a [indecipherable 43:59] . Obviously, I did more than that.

Guy: Of course, yeah.You haven't been writing. Last time we chatted, you said you were going to be writing, but you've been typing instead.

Don: Well, two things happen. One was the Úll conference. When I first wrote my talk, which was supposed to be for...25 minutes talk, and I wrote a 4,000-plus-word outline, and I just tried to stand and record myself and do the outline. I hit over 90 minutes and I went, "Oh, God! I'll have to stop and cut this," so I cut, cut, cut.

I was actually cutting until the night before Dublin again. [laughs] I cut some more stuff out there to try to fit in into 25 minutes. I was focused on that, and I just exhausted myself in terms of writing with that. But the other thing that happened was our family member, our dog, our little girl, a Labrador retriever, Penny, passed away.

When I say, "passed away," what that means is we had to make a decision, and life was not very pleasant for a while.

Guy: Yeah, that's tough. I've been there myself.

Don: Yeah. I just walked off the end of something, and just didn't want to anything for a while. But I had to get my stuff together and do something for Úll and focus on that. When I got back, [laughs] unfortunately I had to deal with the fact that we had a plumbing disaster in our house, water everywhere, and ruined carpeting, and walls with holes in them, and stuff like that, so I was...

Guy: Oh, that stinks.

Don: Yeah, literally. It did stink.

[laughter]

Don: Plus, we're having to get carpet pads replaced this week and some other stuff done, so we had to do that. The other thing is, I started writing again, but it was not on my website. It was code, stupidly. I don't know why. I just got a hair up my ass and started writing some code.

Guy: You're going to tell us what it is?

Don: Oh, yeah.

Guy: [laughs] You don't have to.

Don: No, no, no. It's fine. I'll probably put it on my git hub project page after a friend or two of mine looks at it and tells me, "Well, this isn't embarrassing, and won't ruin your career, or your street cred."

Guy: [laughs]

Don: But just to explain, it's not a big thing. I'm not trying to sell this. It's just a little utility. I feel embarrassed that it took me a week to write that damn thing. But I haven't been coding, especially...This is written in Objective-C. I hadn't written in Objective-C in a long time. People probably think I write iPhone apps every other day, or something like that. I just don't do that. I'm too lazy for that.

Guy: [laughs]

Don: I stopped my development of Objective-C and Cocoa geekiness when John Sullivan joined the Safari project, because he was so brilliant at it.

Guy: Yeah, that's the thing about being a manager. It's that you stop doing your trade and you start doing a new trade, which is managing people, which is a very different thing.

Don: Yeah. There are managers who can code and still code, but I didn't want to be the kind of manager, because there was so many things I had to deal with on, at first Safari, and WebKit, and then all the other projects I was managing, and then be the asshole that blunders into the tree, stomping around and ruining it for the developers.

As a manager, what part of your job is, as I always say, you stand at the backend of the elephant and you let it shit on you so it doesn't shit on your team. You deal with all that stuff, and you make your...

Guy: [laughs] That's graphic.

Don: Yeah, it's graphic, but it gets the point across. When I would have people in my department who wanted to be managers, who wanted to move into that role, I always gave them the talk, at first, to frighten them. I gave them the "shit's in," I like to call it, which is "Here's the good news. Glad you want to be a manager. Here's what it's really like. That's the poop in-between the layers of tasty bread. Yeah, I think you can do it, be on your way." Anyway, enough fecal humor.

Guy: [laughs]

Don: In this little project, basically, I just had a piece of software that was annoying me for a trivial reason and I decided to do my best at rewriting it. I'm a encoding geek. I like to encode video and audio and test it out, play with stuff. Before the podcast started today, Rene and I were talking about encoding a little bit. I was boring him about it.

Rene: Not boring me at all.

Don: [laughs]

Guy: Do you like the math side of it?

Don: No, not at all. In fact, one of the problems with doing this project was, I forgot...When I started writing it, I was like, "Oh, shit! They told me there was not going to be any math!" No. At least in this code, I like dealing with the whole system, but in terms of encoding itself, I like getting good video quality and good audio quality with the minimum amount of work, and time, and size, and figuring out what the tradeoffs are there.

I've gotten very good at that as a hobby over the years. Trust me, folks, this is something that you'd never want to do. By the way, I always say there's three tiers to consuming video and audio. What I always advise people when they see what I'm doing, "Oh, could I do that?" I always say, "Well, you could, but really, what you should do is, you should go to iTunes Store, or Netflix, or Amazon Prime, or something, and stream stuff and not worry about this crap.

Or if you have Blu-rays or DVDs, what you should do is, you should use a tool like MakeMKV, rip them, and play them back that way. Only an idiot like myself reencodes the Blu-rays and DVDs they have." In fact, as we're having this podcast, I've got a batch script with the Handbreak command line app that's been running for weeks now. Actually, since I was away at Úll, re-encoding my close to 300 titles of Blu-rays, in the background, because I want to see what the results of that are.

Guy: It's a bit of dedication.

Don: No, it's not dedication. This is insanity.

[laughter]

Don: Normal people should not do things like this. It takes a lot of disk space and time, but I'm retired, I'm patient. Anyway, I do this encoding stuff and you have to test it. I'm a command line geek. I obviously like GUI's and stuff. I spend, I swear, the...

There's a few apps I spend most of my time at. There are, Terminal, VBedit, Safari, mail. things like that, but Terminal I spend a lot of time in. Not to disparage my friend [indecipherable 52:31] who's in charge of the finder. I do well, too.

Guy: [laughs]

Don: I spend a lot of time in Terminal. I test stuff with Nplayer. The Nplayer command line utility. It's really good and because you can pass all sorts of different options to it and things like that.

It tends to decode h264 more consistently than actually VLC does or something like that. It has other problems, but anyway there's Nplayer on a Mac can actually put up a window and have it show you video and stuff like that.

It does annoying things, like they put up this beautiful video window and then the bottom corners of the window have turds in them, like white turds. When you go full screen there are these white turds in the corner. It's like, guys how hard is it not to put these white turds in the corner of the window?

Guy: Weird, it's what? Just part of the window chrome?

Don: It's the way they're rendering the open GL later, that they created, into the window. They're screwing up the mask or something.

Guy: That's weird, OK. Don: I'm looking at the code and it's hard to figure out. I thought at first about just going in and debugging it and running a patch. I hate running patched versions of things because then you have to keep running the patch when there are updates, running the patch and stuff like that.

I went, "Well there's this project out there called Inplayer OS10, and Inplayer OS10 Extended, Inplayer X. I think I'll actually all embed Inplayer, how do they do that? I bet I could do that, and write a littler wrapper for that."

Because I didn't like the way that they operated either, you can't operate them from the command line, and they do other annoying things even though they are nice pieces of software. I thought, "How the hell hard was that?" That's hubris and ignorance, once again. It twisted my arm and I'm such a sissy when they gang up on me, and so I just started typing. I had to relearn coco and objective c and stuff. I had this little app, its only about 600 to 750 lines of code. It's a command line app, which wraps Inplayer and dynamically becomes a coco app, which is fun.

Guy: Well that's a bit of a trick, right? Because you got to...?

Don: Yeah, because Nibs is for sissy's, and I'm doing all sorts of things I really didn't use before, core animation, OpenGL, Local event monitoring for the sense, nstask, nsconnections, because I've got to run Inplayer in another process and communicate with it. Having to use grand central dispatch and blocks, you know all the new toys the kids like.

Threaded connections and threaded rendering, full screen shenanigans with nsview and stuff like that. I actually asked a question on Twitter the other night because I got stuck, I got some good help from a friend of mine. It's fun and it works. It took me a while to reverse engineer Inplayer even though I have the source code in front of me. It's huge, it's old, and it's kind of corrupt, but it does work. To their credit it does work very well.

Don: It's almost done, I've got to do a few other things and make the code not look like it sucks and then I'll put it on my git hub page, and I thought, "You know, what I really need is a better player app," and so I may have convinced myself to actually write a real coco application that's a media player.

Guy: That could be good.

Don: Quicktime Player's full screen mode annoys the hell out of me, because it uses Mountain Lion full screen mode. I hate that.

Guy: Yeah, that used to be an awesome app, Quicktime 7. The current Quicktime player basically seems like a wraparound QT kit, effectively, which is fine, but...

Don: It actually is a nice GUI and I'm glad that they did something that a lot of people don't do with apps, they just sliced off an enormous number of features. The problem was, they sliced off the features and they didn't put them anywhere. [laughs] You have to have both apps around. If you're going to take features out, you have to make sure people have a way to do those things. That was a problem.

It was a nicely designed app, but I don't like the full screen mode. I've never liked the Mountain Lion full screen mode due to the slow ass switch. I want something instantaneous. It doesn't play very many formats. It's really good for MP4s and certain kind of AVIs, but if you have other things you can't play them with it.

Rene: Like MKV, it's just not...

Don: It just doesn't work, you need VLC, or one of the in player wrappers for that.

Rene: VLC is ugly. I don't like VLC either.

Don: The issue with VLC is it's got the iTunes disease. It's become everything. Now that works for iTunes. iTunes, especially the new interface in iTunes, people have laid a lot of hate on the iTunes team for I think is actually great.

Guy: It's definitely an improvement over the old one.

Don: It's definitely an improvement. It's simplifying the app without actually simplifying it. Which I think is a great thing. What I meant with the iTunes disease was a joke we used to make every once in a while, you keep putting features into it. VLC has too many features right now. I'm a maniac about, before I release any code or release anything, what I always go, "What features can I cut out of it? What don't we need?"

Even before I released my little piddle-y Magneto, my site generator? I cut features out of it. Not that it has a lot of features right now, but I thought, "Why am I doing that?"

Rene: Features that you weren't using yourself?

Don: No, they could be done another way, and one that I wasn't using myself, so why would I want that in there? They were pretty minor features, as an example. There are features in Safari that I've tried for years to cut out. I can't do anything about it now. Look at the preferences in Safari, I think you could probably take about half of those preferences out of there.

Guy: Yeah, that's a good focus.

Don: A really smart man, Darren Adler, taught me something years ago. He was talking about assessing features, assessing preferences, deciding on how to do a preference, and the thing to do when you're arguing back and forth about something. He said, "OK, it's a preference. But which is the default? If you're going to have a preference, you have to have a default setting."

You decide on what the default setting is, and then you get rid of the preference, because you decided on the default, and you never ship that. That's the whole point. Make decisions. Limitations are clarity, they're features too. That's really an Apple approach. Back in the old days at Netscape we used to joke, "How many preferences does Netscape Navigator have? All of them."

You could get really lost inside that preferences dialogue back in the old days. To the team's credit, with Firefox they've vastly improved that, but it's still pretty complicated.

Guy: I think not only is it good for the user, a giant preferences box is confusing, but it's good for the team and the software itself because it's just fewer places for things to go wrong, really. There's fewer pathways to disaster.

Don: Exactly. Exactly. Less stuff to test. Less things to confuse people. I know I've been responsible for features that I thought at the time were really good ideas and they turned out to be not popular or confused people about something else that you wanted people to use. I think Apple is one of the best companies out there doing software and hardware for keeping things simple and keeping the focus right. We still didn't do everything great.

That's why I really applied the iTunes team and the idea of trying to focus things down. That's very hard to do. It takes courage to do that and possible annoy people.

Guy: Especially with such a high visibility app, right?

Don: Yeah. I think they did a really good job walking that line. I use it. I find it's fine. It still has way too much stuff in it but they're doing a much better job of hiding it.

Guy: Hiding it without it being totally inaccessible, tucked away maybe more than hiding.

Don: Yes. Very, very hard to do.

Guy: You're working on an iTunes killer?

Don: No, no. When I say media player I'm considering writing something basically a video player, something that's very simple and straightforward, and something that could sit alongside QuickTime player to be pretty and to play other formats. MPlayer X has the potential to do that but it seems to be maintained sporadically, and there are certain design decisions in there that are just maddening to me.

Guy: I would like that because a lot of that stuff just seems janky to me. A lot of it seems like it came from the Linux world and got a Mac paint job.

Don: Right. Literally it did because it's got MPlayer which started out as the Linux movie player. What was his name? I don't know if I can even pronounce his name, [indecipherable 64:33] . I don't know where he's from. The guy who did the original MPlayer OSX project back in the turn of the previous decade. That's essentially what he was doing is he was putting a Mac wrap around MPlayer.

You can do that and you can do it the right way. You can basically hide the fact that that actually exists and make it look like a real McIntosh application. I think [indecipherable 65:12] , the guy who does MPlayer X, made a good stab at that, but there are certain behaviors and other things that still don't very well.

Then we have VLC whose interface looks like VLC. It's a good app, though. Anyway, I'm thinking about it. I'm thinking about it.

Guy: I'd encourage you to do so.

Don: I'll probably come to my senses.

Guy: [laughs] Please don't. Stay crazy.

Don: The worst thing about doing it, though, is then I'd have to maintain it. [indecipherable 66:01] because he has a real job and he's doing that on the side. I don't have a real job. I'd really have to maintain it. That's the worst thing about putting stuff out there is maintaining it. I don't want to just throw something over the wall.

Guy: You could. You just toss it out and have somebody else pick it up and run with it.

Don: Oh yeah, but I've got way too huge an ego. I put these pretenses on about being a humble guy but I'm just as much of an asshole as everybody else out there about that stuff. When I've worked on other open source projects I've obviously tried not to do that, back when I briefly worked on Lame, the MP3 encoder. I tried to play nice with that community and it worked pretty well back there. Thankfully, they've rewritten all my code by now. I had to stop contributing to it when I went to work for Apple.

Guy: I hadn't realized you'd been involved with Lame.

Don: Yeah. I didn't do any of the really hard stuff. I did the easy shit. Early on somebody had added the ability to do ID3 tag support, ID3 version tag support, and the world had moved on to ID3 version two, which was, in a way, an over-engineered, wacky...

Guy: Yeah, it's a nightmare.

Don: Yeah, it's a nightmare, but it was what everybody was using. I hated running a tagger after I would encode something so I started doing a hack and it just got out of hand. I developed it into a set of patches and asked the team if they wanted to use that and they accepted it in the tree. Robert eventually rewrote all of my stuff, thank God.

Guy: Would you say that that's how a lot of open source contributions happen? There's two things. We were just talking about Google and Apple and their splitting and forking and they've got full time employees working on stuff.

Don: Yeah, that's actually very rare.

Guy: I was going to say, most open source is just random people getting annoyed with something and fixing it.

Don: Yeah, it's scratching an itch.

Guy: Was that true for Webkit at any point or is that more of a professional?

Don: I think that's true for some of the people who joined the team from the open source world. They went in because there was something they wanted to do and it got out of hand and became a career because it was scratching an itch.

Guy: [laughs]

Don: I've hired plenty of people like that, just amazing engineers, that way. The projects that I've contributed to, which are very few, sometimes they started out that way, or this program that wrote this last week. It's like, "Oh, damn it, I want it to work this way. Not that way," and I did something really stupid. I wrote a completely separate program, rather than develop a patch for what was there, which is the height of ego-maniacal stupidity.

Guy: I don't know. I'm looking forward to it. [laughs]

Don: We'll see. I've got to make sure I don't have any bugs. I ran into a hideous big last night. There's this protocol in MPlayer, that I think was developed by originally one of the OS 10 contributors for communicating with a gooey app, and I supposed it was a good idea in its day, but it's really hideous. It sends the host app through an NS connection that you create.

Guy: Yeah. You mentioned that. That seemed odd to me.

Don: Yeah. It sends you the height, and width, and the aspect ratio. It sends you the aspect ratio as an integer.

Guy: [laughs]

Don: Which is just completely useless, so I had to come up with...Yeah, so all the arguments are integers, so it's completely nuts. It defines some functions that can be called. Start, render, and stop, which are supposed to be called in that order. Of course, except when they're not called in that order by Mplayer as it's running in the background. I had a crash error last night, I discovered, when it was calling stop before it ever called start.

Guy: I hate that kind of stuff. [laughs]

Don: That's classic communication protocol stuff.

Guy: Yeah, that's the worst.

Don: It would do that for every AVI file I would flow through it. I'd stupidly been testing it the whole week with MP4s and MKVs and stuff like that. I hadn't run an AVI file with xbit in it, and it was like, "Here's I'll stop before I start."

Guy: Why? It's weird that AVI is different. Is there a command stream in an AVI file, or something?

Don: I have no idea. This is why I'm such an idiot to do something like this, because a lot of those kinds of internals, I never really pay attention to. I'm more concerned with [indecipherable 71:41] . I actually enjoy writing all the pluming. It was just a boat load of fun figuring out how to run something as a separate task. I had set over code before, and talked to my engineers before, but I never actually sat there in an editor and wrote all the stuff, or put the distributive object type connection and stuff like that, done it myself, it was a lot of fun.

You know, I had other code to look at, some of which was very nice examples, and some of which was like "Ahh!"

Guy: [laughs] Yeah, distributive objects are cool, but crazy.

Don: Yeah, crazy. It's just a pseudo-distributive object. Basically what you do is you create an object locally, and say it has this protocol, and then you register via connection of this name. The crazy thing was it usually worked the first time I did it. I couldn't believe it. I thought I'd done something wrong.

That actually turned out to be one of the most straightforward parts of it. It was like the renderer. I spent all this meticulous time not even testing the open GL code, but just writing it and code reviewing. I ran it and I didn't get anything rendered at first. I went "Oh well...it's too hard".

Guy: It's open GL. That's...it never happens. It never works the first time. It doesn't do that.

Don: But the open GL code was perfectly fine. It rendered perfectly. I had passed the wrong parameter to one other function down the line, and that was the entire reason why it didn't work.

Guy: I don't know about you, but I never am more nervous about my code then when I run it and it works perfectly. Every time, like if I type it and it works, I'm like "Whoa, something is screwed up here, something really bad is happening."

Don: [laughs] Yeah, some of the more trivial things that didn't work that threw me...like, I ran into every noob's screwjob with NS notification center. I've got two threads running in the app, and I stupidly tried to notify the other thread with notification center, forgetting that that doesn't work at all. I was getting called back on the same thread.

Why does it work that way? That's because that's the way it's designed to work that way. That's a feature, not a bug. I go, "Oh, shit. What's the best way to communicate with another thread?" I gave it a quick iMessage to my old buddy and former engineer Ricky Adams, and I said, suggestions? He said "GCD is your friend", I went "oh yeah". A little asynch dispatch call took care of that painful swelling, and all was well.

Guy: Yeah. I'm pretty sure you got a contact list that can help you with a lot of these problems.

Don: [laughs] It's like crib notes during a test.

Rene: Or a lifeline during a game show.

Guy: It works, come on. Exactly

Don: Yeah exactly, lifelines that's what it is. Rene, that is perfect. I got a lot of lifelines, and they're all brilliant people, a lot smarter than I am. I'm sure they could have written everything I've written in like a day. [indecipherable 75:03] They probably wouldn't have wanted to write this. Who the hell would? We'll see what comes next, but I've got to get back to my website writing.

Guy: Yeah, please do.

Don: What I'm going to do is probably take this 4,000 plus pages of notes that I wrote for that talk, and turn some of those into blog posts. I just get so tired of repeating and rehearsing the talk that I don't want to look at the material. I actually told you...

Guy: Just read it into Siri. Have her dictate the posts for you.

Don: [laughs] A question for you. How often do you guys actually use Siri?

Rene: A lot.

Don: Wow. I'm impressed.

Guy: Yeah, seldomly. I use it for setting timers and alarms and shit that it can't fuck up.

Rene: I dictate posts while I am driving so I don't forget the hook that I had when I thought about it.

Don: Apple loves people like you Rene.

Rene: [laughs]

Don: I always think whenever I use it and it just works perfectly, and it does what I want, I think to myself why don't I use this more often?

Guy: Right, yeah.

Rene: Yeah, then it screws you.

Don: Occasionally it will get confused, but usually that's an amusing interlude...

Guy: One thing I do find cool about Siri is yeah, it's an amusing interlude. If I'm telling it to remind me or something and it gets it wrong, at least when the reminder comes up, there is enough phonetic information there that I know what it's talking about.

Rene: Yes.

Guy: Maybe it screws up the name and it says "Rave" rather than "Dave", and it's like OK, fine I know what it's talking about.

Rene: It's much faster UI to enter reminders, and calendar events, and anything that's touch based.

Don: Oh yeah, yeah. Doing it with Siri is much easier than typing it in on a phone. My friend [indecipherable 77:15] , he is the person probably most responsible for the keyboard interface for the phone, I still prefer talking to Siri for doing long things like that, rather than typing.

Guy: Really?

Don: I'm all thumbs, literally. I can actually type very fast on my Mac compared to some people on the phone or the iPad. I do type very fast. In fact, typing is probably the most useful thing I learned in high school. I swear, it's the thing...Not the math, not even English lit., it's typing, learning to type. I still hit the Cupertino's all the time and it drives me crazy.

But I never turn it off, because it also saves me more times than it screws me up. Yeah, because my spelling is atrocious. What I would write would look like Middle English. Spell checking.

Guy: Yeah. Spelling is over. Computers can do that now. Yeah.

Rene: I think I said this before, but I have a godson who is four years old and can't write, but he uses Siri to send me text messages, which is awesome.

Don: See, that's what it's perfect for. That was like Charles was saying at Úll. Charles Perry, saying at Úll, you don't realize it but there are sight impaired people out there who can use a phone right now to see. There are apps out there that exist that they can hold up to take a picture with a camera, and they can tell them the colors of what's in their room, or their garden.

Guy: That's so cool. I'm really fascinated by this kind of stuff. I think there's...so the way that the accessibility software works is that you basically describe the functionality, or the...I don't know, how would you describe it, Don? You don't describe the layout, it's not about the visuals or anything. It's about what the content represents.

Don: Right, and you have to realize that iOS, like MacOS is one of the most advanced operating systems out there for providing accessibility support, because most of the stuff you just get for free. You don't have to do anything, but there are parts, like the stuff you're talking about, Guy, that you do. But I'm not an expert on this.

Guy: No, no. Neither am I, but it totally fascinates me, and I love the idea that if you set everything up correctly in your iOS or Mac App, there can be a totally different interface to your application, put on top of it via the accessibility stuff.

It just so happens that voice over is the one that works, but the way the content is described when it works out, can work in so many different ways. It blows my mind, fascinates me.

Don: Charles had this video that he played during his talk, of Stevie Wonder talking. This was before Steve Jobs passed away, I believe it was the Spring when it was known he was very sick. It was from Stevie Wonder, one of his sessions, and he got up in front of the crowd after his set and asked people to pray for Steve Jobs, because he talked about how much he loved his iPhone. He said "Here, I finally have a device where I can do everything you can do."

Guy: Wow.

Don: It was very powerful and moving. That's why I loved Charles' talk, because it was just intellectually precise and then it was emotionally moving, which is both the best speaking coming from being trained as a Minister, and the best writing there is, you want to be able to ever do. When you think about it, it's not just prose. I always want to impress upon people when they create software.

You don't need to just make software that makes sense, that's well designed. You need, if you want, your software to be used you need to make software that delights people.

Guy: I agree.

Don: That tugs at them, right? That gives them a reason to use it even when they don't need to use it. That's the best stuff in the world. If you can do something like that, man that's...you know, I've had glimmers of being able to do that over the years and that's the kind of thing that always gets you back to writing.

Guy: Well I think that people feel that they should be playing all the time. That software should be a toy. That it's to be enjoyed.

Don: Yes, and that's the right way to approach it. That's what you want. You want people to play and get a shitload of useful things done. Even if that play is in a game itself. Gaming isn't just frivolity.

Guy: Well that's why I never really found the animations frivolous in OS standards.

Don: Exactly. Well, the...

[crosstalk]

Guy: OK, there's some of the animations.

Don: I just have this quirk in my personality I just don't like the full screen transition. And, I know the guy who wrote it. He's a friend of mine, but it just always bugs me. They're not frivolous.

Guy: Right. Yeah, it could bug you but it's not frivolous, like you know why it's there, right? It's for...

Don: Right.

Guy: Not you. It's just...

Don: Oh, no, it's not for me. In fact, the reason why the full screen animations transition there's a very good reason. It's to give people context for what's happening.

Guy: Exactly.

Don: The way people try to solve their problem before is what they would do is they would, the first time you went into full screen they'd put up a dialogue and say "Do you realize we're going to full screen now?" and it was like, "What the hell?"

I like instantaneous full screen but that's because I'm a geek working at a command line. That's what I like. The reason why it's done that way on OS 10, it's brilliants because people go "Oh, I can see my other desktops sliding away. I can see this other thing coming in." There was a lot of work put into that.

Guy: Right. It is quite slow. Yeah sure, it's quite slow but I think it's the right speed that people see what's happening.

Don: Yes. Yes.

Guy: Like they're thinking during that process, "Oh my desktop is going away, and here's my new thing coming in." For me, it's like just do it, just get it out of my way and just do it. That's fine. But, I can understand why it's so of laborious in that way.

Don: Let me ask you two, the first time you used OS 10, you didn't get the light and the animations. When I was trying to think of what I was going to do at easel as it was auguring into the desert floor dying. I borrowed that G3 iMac from Andy Hertsvel, and I was playing with OS 10, the thing that got me going back there even though I didn't have a lot of apps there.

I had like Terminal and Text Edit and something else. Whatever was in that first version of Cheetah. I would go down to the dock and I would minimize and expand Windows, and just watch that kind of thing happen. Drag stuff around, and I thought, "Man this is so cool."

Guy: I love that. At that time I was writing video games, and just the graphic stack on OS 10 just seemed, to me, to be the way of the future. To steal a phrase. Draw everything into a backing store and then blit it to the screen with a Windows Server.

Don: It's a video game approach. That was the great thing about it, right Guy?

Guy: It felt like that. Like put everything in a texture. It wasn't in that earlier version, but I could see the way it was going to be. Everything is fully buffered, just draw into the buffer and then throw a bunch of textures around the screen. Awesome.

Don: By the way, it's very mature doing that stuff now. I was really stunned and delighted when I was writing this little app about all of the wonderful stuff in there, like the first time I created a CG, or core animation texture cache. It was like totally easy.

You just attach a layer to a view. You say to the view, "Set once, layer, set layer," and it automatically re-sizes and moves around. Everything is taken care of for you magically.

Guy: It's so good, it's so good.

Don: It's like one of those Japanese toilets that wipes your butt and it's just so good. It's like an art.

Guy: [laughs] I don't know if I would have said that.

Don: Well that's OK, it's me being fecal again. This is the first time I've actually written something in Ark. It's like, "Oh my God," I'm never going back.

Guy: Yeah.

Don: It's like retain release, screw that. Before I do release, I have to put the scope on this and see if I actually am leaking anything and do some other measurements. Performance is really good, but you can have really good performance because you're leaking the world.

You can use Ark badly and having multiple threads and stuff like that, you have to be careful with. Syntactically, and the clarity, and the code, and everything else you're doing, I'll never go back from that. But, I still like the original name for Ark that we had.

Guy: Oh yeah, it was ARR.

Don: Yeah. ARR. Because we were walking...

[crosstalk]

Guy: Yeah, you were telling me that [laughs] .

Don: Yeah. Automatic Retain Release. ARR. But the marketing guys got a hold of it then it became Ark. Damn it. Because you can write C, because that's what objective C is with this weird syntax from small talk. You can write C like it's Ruby or Python.

It's just so easy. You have to take a few precautions, like this stunt where you have a command line app that becomes another application, I have to have my main function, I have to wrap that in an at-auto release pool, little thing there. You have to remember to do that on your thread entry.

Guy: Yeah, it's whatever.

Don: It's not that it's not a nice attempt. An at-auto release pool, the great thing about it is even if you're not using Ark, those directives will do all the other old stupid nonsense for you, anyway.

Guy: Yeah. There's a bunch of good stuff to consider. It still hurts my brain looking at, just calling eloquent on something, then not releasing it someplace later. I just still trip over that mentally, but I'm just being an idiot.

Don: It took me about a half an hour, and then there was no looking back. [laughs]

Guy: My main product that I work on is not Ark yet, but I'm working on a bunch of other stuff that is Ark. I'm slowly getting...

Don: You know what's not Ark yet, but will be hopefully this summer is XCode itself.

Guy: I sadly believe that. You know what, XCode was GC. It was garbage collected.

Don: Right. Because XCode always was the big [indecipherable 89:51] dog food thing. You got to respect the XCode team for that.

Guy: Oh, totally, yeah. It gets a lot of hate that it doesn't deserve, I think.

Don: Although, I was cursing it this week. The online documentation thing is fantastic. XCode is the best environment to work in, even though I'm not using it now. I'll explain why. To work in, compared to everything else that is out there, like if you're developing Android apps now, XCode is so much better than what the Android folks have.

The documentation viewer is so damn slow when you type into that little search field. Oh, I just want to strangle somebody. It's the indexing. I don't know what's going on there with indexing but it just makes me nuts. I can actually go into Safari, type what I want into a Duck-Duck-Go window, what I want, even saying site: developer.apple.com, and hit return and get results faster than I can sometimes looking at the documentation.

Guy: That is exactly what I do.

Don: Yeah.

Guy: But without the Duck-Duck-Go. [laughs] I should try that out a bit more. But like the documents windows...

Don: It's not built into Safari, but I try to reduce my surface area as much as possible with Google.

Guy: [laughs]

Don: No, not to dispirit. It's just privacy and other concerns.

Guy: Yeah. That's not a bad idea.

Don: I don't recommend that for everybody.

Guy: Go ahead.

Don: I said I don't recommend that for everybody. I also don't recommend the stunt that I'm doing now to develop the whole app. I am actually not writing in XCode, I am writing in VBedit.

Guy: That's pretty old school.

Don: Yeah. Well, I'm 56 year old, so there is nothing I do that's not old school.

Guy: Come on. You're still hip with the kids.

[laughter]

Don: Yes, that new lingo. Sometimes I try to talk like the pseudo-hip person just to annoy my 22 year old son, especially when his homies come over. They were over the other night.

Guy: [laughs] You swear far more than anybody that age, so don't worry about it. You're rocking.

Don: Anyways, I like to embarrass him. Getting back to VBedit and the way I was writing this, it's basically VBedit and a make file. It's all like one file because I'm heinous. What I'll do once I'm done is then I'll break it up into separate source files and probably stick it in to XCode just to make sure everything else runs. Also, so I can do some automated tests. It's nothing for me just to whip out a text file, do a make file in like five seconds, and boom you're good to go, right?

Guy: Yeah.

Don: This is crazy, but when you start a project and it's really small, doing it in a single source file is actually very useful because it makes it much easier to search and replace, and do everything else, and understand the context of what you have. Once you get to a thousand lines, well you're screwed.

Guy: Yeah. I had to help fix a project like that. It was like a game from the jailbreak world that we ported to run on the first iOS SDK. It was one giant file.

Don: How many lines?

Guy: Oh God, more than a thousand. It got out of hand, but it was just the guy having fun and just hacking on it, and it turned into a product. Wow, that was a bit of a pain in the ass.

Don: I'm sure that program was still shorter than the original NetgetURL function in Netscape Navigator Four, still shorter.

Guy: [laughs] I bet.

Don: Sorry, I interrupted you.

Guy: No, no, no. I was going to say that, yeah, I can see that joy of just having one file, and just typing in a bunch of stuff and having it work. That's how we got into programming, right?

Don: Exactly. It's like writing a script, right? But don't listen to the old crazy man.

Guy: Yeah, do not do this, but I can see the appeal.

[laughter]

Don: For me that was useful because I can scroll...it's funny, I can scroll it up and down in my head. I don't know about you, Guy, but after years of programming, when you're not in front of the terminal, you can scroll you're code up and down right in front of your eyes. Make the edits, and stuff like that.

Guy: Yeah, I can see the structure.

Don: Yeah.

Guy: I just know where stuff is.

Don: Yeah, that's creepy. You describe this to other people and they just think that you're some kind of serial killer. It takes the same capabilities to do that.

Guy: I don't know, I've been watching a lot of "Dexter" recently. I don't want to get...

Don: Oh, really? God, I'm like two seasons behind now.

Guy: I just started. I'm like in the middle of the second season.

Don: Oh really? Oh. I got to say, the first season of "Dexter" was one of my favorite...

Guy: It was brilliant. It was brilliant.

Don: ...episodes of television. Just terrible, in a way when you think about it, the morality of rooting for a serial killer.

Guy: It's horrible. [laughs]

Don: What they do to your head, it's like, "I can't..."

Guy: It's Soprano's morality.

Don: Yeah, exactly. It's like the Soprano's. I love that kind of stuff.

Guy: Yeah, I'm enjoying it.

Don: I don't know why I'm encoding all this stuff, because I got so much stuff queued up that I still haven't watched. I probably got a year's worth of TV and movies that I still need to watch.

Guy: [laughs] It's your affectation, and it's just what you got to do. What do you do? You encode. That's it.

Don: Yeah...I want to see if I can get the best possible thing at one time. I was talking to Rene before the broadcast started about getting stuff from iTunes, and Rene's saying, "Well it's still not Blu-Ray quality".

Rene: Yeah, we did that. One of our recordings we did in 4K and we're playing around with trying to get it online right now.

Don: I just think that's insane that it's 4K. Wow, I'm impressed, 4K.

Rene: Well we'll be impressed if it works. We'll see.

Don: At those bit rates you're never going to get Blu-Ray quality.

Guy: Yeah.

Don: But you can get something that is reasonable that 99 percent of people can see on their HDTV sitting across the room at five megabits, 1080 P. That is what iTunes, most of their 1080 P video is. The odd thing is, they're 720 P video, it's four megabits.

You go, "Hmm, wait a minute, I'm watching 720 P and it's four megabits, and the 1080 P is only 20 to 25 percent larger, in terms of number of bits and bit rate? How the hell does that work when the actual viewing area is two and a half times?"

It's the weirdities of our eyes and resolutions and stretching things that actually pulls it off.

Guy: I was watching "Zero Dark Thirty" over iTunes, and in that helicopter assault scene, it's awful. It's like blocky, it's like mpeg city. I was distracted to the point of just being angry.

Rene: I saw the movie, and that whole scene was poorly shot in terms of the darkness. They could have shot it all through infrared and made it much more legible to the viewer.

Guy: Oh yeah? OK.

Don: Not to dive too deep on encoding problems. There's a few problems that encoders run into. H264 converting, you run into, and that's the blockiness. There's also the thing where you can get a lot of blockiness where you have very subtle color change.

Guy: Yeah, because it doesn't' capture it, right?

Don: Make yourself sad and watch a couple of animated films on iTunes and you'll see some large, very tapered surfaces which seem to have some stair-step effect. The way to fix that is simply more bits. That's the only way you're going to get around that problem.

That's the problem that a lot of people make the mistake at. The big thing these days, a lot of people are really hot for, obviously doing things like, I don't know if you're familiar with X264. That's the encoder I'm using built into [indecipherable 99:28] .

They have a mode CRF, Constant Rate Factor, which you give it a quality setting and then it goes and does stuff, and you basically get a variable bit rate encode. This sounds like a wonderful idea. Except that to use the same quality setting on every movie, if you're going to take Blu-Rays, or DVDs as source bits, you're going to have to set it to such a high quality setting that, on occasion, you'll have output that is larger than your input.

Believe it or not, the way Apple is doing it, by doing essentially a fixed bit rate, is actually a better way to go with getting consistent quality, because really noisy stuff is going to look noisy anyway. If it's complex, the original was noisy, the encoded version was noisy, and for things that are very still, animations, or very quiet movies, you want a lot of bits in that stuff because your eyes will notice the details.

You can't use a lower quality setting, a lower bit rate. What I've developed is a way to do, believe it or not, single pass and codes with X264. They get a lot of the same benefits as CRF, and it's through a very simple little option that you pass to X264. It's called Rate Tolerance Equals Infinite.

You get a fixed bit rate, single pass encode that behaves like a CRF encode. It looks a lot like what iTunes is doing. It occasionally runs into some of the same quality oops', but not nearly as many.

Guy: That's cool.

Don: I can record a Blu-Ray on average in real time on my iMac that way.

Guy: That's pretty impressive.

Don: Yeah.

Guy: That is interesting.

Don: If you ever want to waste another two hours talking about encoding, boy can I bore you, because I've done a lot of things.

Rene: It's a date.

Don: Yeah, it's a date.

Guy: Perfect.

[cuts off]

Feedback

Yell at us via the Twitter accounts above (or the same names on ADN). Loudly.

Daniel Pasco of Black Pixel, Brent Simmons of Ranchero Software, and Justin Williams of Second Gear talk to Guy and Rene about iCloud Core Data sync, why everyone seems to be in a bad mood about it, and how, if at all, Apple can fix it.

• Subscribe in iTunes
• Subscribe in RSS
• Download Directly

Show notes

• The Return of NetNewsWire
• Why all my iOS Apps are on hold - or iCloud sucks Part II
• Response to Sync Issues
• Under the Sheets with iCloud and Core Data: Troubleshooting
• Why is iCloud Sync not working
• Your App Needs to Sync
• Apple's broken promise: why doesn't iCloud 'just work'?
• The Gathering Storm: Our Travails with iCloud
• A tale of two iClouds
• Why Developers Shouldn't Use iCloud Syncing, Even If It Worked
• iCloud: State of the Union
• Why Elements For iCloud Doesn't Exist

Guests

• Daniel Pasco of Black Pixel
• Brent Simmons of Ranchero Software
• Justin Williams of Second Gear

Hosts

• Guy English of Kicking Bear
• Rene Ritchie of iMore.com

Feedback

Yell at us via the Twitter accounts above (or the same names on ADN). Loudly.

Don Melton, former Engineering Director of Internet Technologies at Apple, talks to Guy and Rene about assembler on the Apple II, open-sourcing Mozilla, building Nautilus, creating WebKit and the Safari browser, teaching bears to dance, and cleaning cusses from code bases.

• Subscribe in iTunes
• Subscribe in RSS
• Download Directly

Show notes

• Bitsplitting Podcast Episode 1: Guy English
• Code Rush documentary
• Nautilus file manager
• WebKit.org
• Safari
• Keeping Safari a secret
• Safari is released to the world
• Why I retired from Apple
• Regarding fake projects and loyalty tests

Guests

• Don Melton of donmelton.com

Hosts

• Guy English of Kicking Bear
• Rene Ritchie of iMore.com

Transcript

Don Melton: Will this be Debug number 11?

Rene Ritchie: Yes.

Don: Wow, that's great because then Debug goes to 11.

Rene: Correct.

[laughter]

Don: Wish we had show tunes.

Rene: I'm Rene Ritchie and joining me is my co-host Guy English. How are you, Guy?

Guy English: Great. Thanks.

Rene: We are absolutely thrilled to have with us today Don Melton, formerly of Apple, and whom you may know from projects like WebKit and Safari. How are you Don?

Don: Itchin' absolutely.

Rene: We are literally using your work as we engage in this conversation.

Don: Yeah, that's both flattering and frightening.

Rene: How did you get started with coding? How did you get into this business?

Don: It's funny I started thinking about that again the other day when I was listening to Guy appearing on Daniel Jalkut's new podcast Bitsplitting and you were talking about your first computer being an Apple II. I thought that was funny because of the timeline you were talking about. Just out of curiosity how old were you then?

Guy: I was about seven to eight then.

Don: OK. What year was that? That was around...

Guy: Eighty one, eighty two.

Don: Yeah. So I got in at the same time with the same computer Apple II Plus. Of course, a slight difference in age. I was 24 at the time. But it was kind of funny, learned on that. But see, my background, I was already at the age of 24. I was going to school to become a minister. Really long story.

Guy: Really? Wow.

Don: I was working almost full time. I was working about three-quarter time at the "Orange Country Register," which is the big newspaper in Orange County, California.

That's where I was putting myself through school. I was a commercial artist there. Graphics artist, that's my background in journalism. I've had a really weird life and strange jobs and things like that.

Anyway, I was getting bored and disillusioned with the whole religion thing. I wasn't sure I was going finish my degree, and I thought, I really need to get something here to hang on to. I thought, I'm going to finish this year of college and decide what I'm going to do, and I got to get more into this graphics thing that I already am. I thought, "Well, computer graphics! That's the way of the future. I got to learn how computer graphics."

So I decided to get a computer and teach myself some of that computer graphics stuff.

Guy: That's very forward looking for the time, because computer graphics at the time were like 80x20 or 80x40 screens.

Don: That's probably the only time in my life I've ever been forward thinking. That's about as organized as I ever get, in a way.

So I borrowed this enormous amount money from my dad, and I bought an Apple II with the whole set-up. Two of those clanky-ass disk drives and...

Guy: With the machine-gun noise when they would start to...?

Don: Yeah. Thank God I didn't have a pet at the time, because it would just traumatize the pet.

You know, 48K of RAM, it was huge. I got this whole set-up and everything. I had it for a week, and then I realized I had made the biggest mistake of my life. I couldn't do anything that I sort of imagined that I could do with this thing. I was really disappointed.

I didn't want to go back to my dad and, you know, "Remember that five grand you lent me? Oops!"

So, it languished in my room at this house I was sharing with three other guys off-campus at college for six months. I mean, I played video games and stuff with it and do a few other small things. I got really good at Nasir Gebelli's "Space Eggs"? You guys remember that?

Guy: I do yes, that was fun.

Don: Until I got sick one three day weekend. I forget if it was Labor Day or Memorial Day or something like that. I was just sick enough that my roommates didn't want to have anything to do with me so I was banished to my bedroom.

I was just well enough to be bored out of my mind and because I never throw anything away. My room is filled with all kinds of crap; I had all the manuals and everything else with the Apple II laying out there on the desk.

In those days they actually, when you bought a computer they...

Guy: They told you how it worked.

Don: Yes they showed you how it worked and it was this nice little bound book, everybody that had an Apple II remembers this, introduction to Apple Soft Basic. I thought, Saturday morning, what the hell I'll just open up the book and start going through it. By the end of the day I was a basic programmer, I could do that.

I didn't know you couldn't learn it in a day.

[laughter]

Don: It was a lot of fun I actually I stayed up late that night and Sunday morning I skipped chapel and I was typing away like crazy at the Apple II. I bombed one of my programs into the machine language monitor, you remember that right? It's like what are all these numbers with letters in them.

I had to take a little break there and learn hexadecimal and conversions and stuff like that and went you can dissemble a code. Then because it was a three day weekend, by the end of the day Monday, I had started teaching myself machine language programming. I was writing basic programs with data statements and writing machine code, hand code it on a piece of paper once I figured out how the instructions worked.

I shove them into the data statements and I call them and then hook them up via the Ampersand Vector that I had noticed that you could do in the back of one of the appendices of the manuals and I was calling out.

I didn't know you couldn't do that, you couldn't learn things like that I just...

Guy: You went on a three day fever fuelled vision quest? Came out an assembly programmer?

Don: Because you've probably seen on my site that one of the things I define myself as being is a tinkerer. I love to tinker with things and I was just curious and I kept tinkering and I kept tinkering. I finally got where the programs I was writing were semi-useful, at least to me and they didn't crash all the time.

Then I started learning, I can't remember whether it was Forth next or Pascal and then I was learning C. Which C on an Apple II computer was just a real pain in the ass. It's the eight bit processor.

Guy: What was the compiler for C on the Apple II?

Don: I cannot remember this was, I think it was Astexy, no it wasn't Astexy I forget what it was called.

Guy: But it was commercial there was no...

Don: Yes it was commercial. I wasn't into the hacking crowd yet because I didn't know enough people who did that.

Anyway, several months later I ran into one of my friends who was going to City College. He was actually taking programming course and this whole time that I'm working around like this on my computer in my bedroom and at home and stuff like that. I had no illusions, I'm not professional I don't really know what the hell I'm doing.

Anyway, I talked to him I'd say hey how's the course going, because I'd love to be able to have time to do that. He was in the second year and he said "this is like really tough, I'm really struggling here." I said "can you show me one of your books, I'd love to see one of these things." He was showing me some of his exercises and I started looking at it and realizing that the man could not write a four loop to save his life.

This stuff was just incredibly simple or at least simple to me by then because I'd taught myself this stuff. It was after that, meeting him at lunch and looking through the thing and realizing this, I went maybe there's something in this for me. I got really, really interested in it and just went deep and that was the start of it all.

Then became a real fan-boy, because I had the Apple II, and when the Mac came out I went...what's the name of the store. It was right in downtown Costa Mesa. They were demoing a Macintosh, and I wrote the last 200 dollars in my checking account as a down payment on a Mac when it came out.

Guy: So you got straight into the Mac, right?

Don: Right into the Mac, when it first came out. I had no idea how I was going to make the payments on the Mac.

Guy: Just a leap of faith.

Don: Yeah, Just a leap of faith.

Guy: Now, programming the Mac is lot different than programming an Apple II-style thing, because of the way the event loop and all that works. Was that a big leap?

Don: Yes.

Guy: You have to invert your thinking a little bit.

Don: Yeah, especially when you learn like me. I don't have any classic training at all in data structures or algorithms and things like that.

But it was very useful, in the sense, the way that I learned, because you learn early on, especially when you're learning to write assembly code and everything else, you understand what a pointer is. You understand how things work in memory.

Whether you've been formally or classically-trained in data structures, you understand what these things are. Believe it or not, when the Mac first came out, the only programming environment on it was BASIC. It was Microsoft...that was the only thing I could get.

I was doing the same dumbass thing, which...DATA statements. Doing 68K assembly language programming that way, until the Consolair Assembler became available, and then Consolair C, and then I was off to the races. I still have my day job as the graphics artist at the Orange County Register, and I was not getting paid to be a programmer or anything. My first job, paid programming job.

Do you guys remember, well obviously, MacWrite, everybody remembers MacWrite, don't you? There was this add-on that was sold by Chrichton Development called MacSpell Plus, and the guy who was the primary developer on it was a friend of mine in the Orange County hacker crowd, Christo Rossi. He wound up later on working at Apple and other places.

I guess he had gotten a tiff with Chrichton Development and walked off with the source code to the thing. Lo and behold, a new version of MacWrite comes out, and the way MacSpell Plus worked, I think that's what it was called, was it dynamically patched MacWrite, which is grotesque.

But everybody did that, back in those days. A friend of mine who was basically admin project manager over there, that I knew from school of all things, not through the hacking crowd, asked me if I could figure out how to fix it, and save their bacon.

I went, well, I don't know, bring it over, and I watched what it did, dropped it into MacsBug, and thought, OK, the big problem here is this one section. Insert a few no-ops and a branch, and that kind of stuff, and patch the binaries.

Guy: Straight-up binaries patching.

Don: Yeah, well they didn't have the source code, so I took their old binary and I patched it for them. So, that's the way that I came from, programming. The crowd that I hung around with in Orange County was, that was the crowd that started the Mouse Hole. A bulletin board for hackers back then, trading wares.

Also out of that, sprang up MacTutor. I remember the old MacTutor magazine, and I started writing for them, MacTutor. I'd written two or three articles, and I decided after almost eight years at the Orange County Register, which is the longest I'd ever had a job until I worked for Apple years later, was I've got to get out of Southern California.

I've got to get to Mecca, which was up north. I've got to find a job up there, and I didn't have any...sure I'd patch the binary of MacSpell Plus. I didn't have any [indecipherable 0:14:35] , so I couldn't get a job as a programmer up here in Silicon Valley, but I came up to be their computer graphics specialist at the San Jose Mercury News.

While I was standing around at some conference, I don't know what it was, and Andy Herzfeld was speaking, and I was a real fan-boy. I would later, strangely, work with Andy Herzfeld, but I was just standing in a crowd and I forget what dumbass question I asked him, but there was a guy standing behind me who tapped me on the shoulder and heard me ask.

Lo and behold, it was a guy I had known since I was 15 years old, I had no idea he was in the area. He was trying to break into the business as well, and we had an epiphany. Let's start a company. You know entrepreneurs.

Because I was a graphic artist, I really designed these business cards, back in the days when business cards mattered, that were kind of eye-catching and my friend Mike who now works at Google, the whole world is connected in a way when you think about it. Pin the things up on various boards around the Bay Area, and Tops. Does anybody remember Tops File Sharing?

Guy: You know I'd heard of it, but during this period, I was more into the PC stuff.

Don: Oh, you traitor!

Guy: Yeah, I know, I know, I'm sorry. [laughs]

Don: I did that myself later. Some recruiter for Tops saw it, and went...oh, we need some warm bodies, these guys look like they might do it, and I went in for the interview with Gary [indecipherable 0:16:29] , the guy who was one of the founders of Tops.

Guy: Just for the audience, it's basically NFS for Macs.

Don: It was like Apple File Sharing that wasn't Apple File Sharing, or NFS. And he had read my MacTutor articles and used one of the techniques in Tops. So, I was in. That was my first job when I got out of the newspaper business.

Guy: Was it natural, or did it...I imagine you still do, enjoy illustration and drawing.

Don: That's funny somebody asked me that the other day and I can't remember when the last time I drew anything other than that little avatar you see at my face...

[crosstalk]

Don: ...online. People go, "What you don't draw anymore"?

You don't realize I started drawing when I was four years old. My parents had discovered that I could draw at that age, and they were amazingly nurturing of it. Again, it was one of those things where it was a rainy day, and I'm bored they gave me a pencil finally instead of crayons, thinking that I might just not poke my eye out with it and some paper.

I sat down and I started drawing things that were on the table in front of me. They discovered when I was around four or five that I could just draw whatever I could see. It was just something that I could do and later on when I started going to school, I think it was in the first grade. I never went to kindergarten. I can't remember why, but I never went to kindergarten.

I remember we got some class project. You're supposed to draw something. I sat down, I just drew, and looked around at the other kids, and they were struggling. It was some stupid thing, it was like a pumpkin and other stuff.

These kids couldn't make a circle and I realized that I had a super power. It's like one of the X-men! Of course, it still didn't mean that people didn't beat the crap out of me and take my lunch money and stuff like that.

Guy: But you could at least draw the perp.

Don: Yeah, I could do the police sketch. Years later, I would wind up doing some things like that.

Guy: Oh, really.

Don: I just really got into it. When my brother figured out that, I could draw. His plan for my life was to draw comics. He drew me into the whole world of comics, and then that's what I wanted to be when I was a kid. A comic book or comic strip artist and then draw, draw, draw every day. Then I got a job in the underground comics back in the '70s.

Guy: Back in the '70s, if you're going to do underground comics that's a pretty good time for it.

Don: Yeah, and I the stupidest thing, this is my acute business acumen. I stepped away from comics just about the time the entire thing heated up and everybody became bazillionaires. I'm just always great at that, just picking the wrong time to change.

[crosstalk]

Guy: I'm going to go with technology over comics.

Don: I don't know Avi Arad, I knew that guy when he was that dumpy snotty nosed kid standing under the stairs at the San Diego Comic-Con.

Guy: Oh, really? Wow.

Don: I can't remember whether I was at the second or third, I didn't make it to the first Comic-Con, but I remember working my ass off all summer to save money, early summer, to go to the third Comic-Con.

This was back when it was in the El Cortez Hotel in San Diego. I think this was the first time it was at the El Cortez Hotel, and I remember going down a few weeks before to Shelldorff's Comic Book store out near the ocean front, and going in the back of the store and collating programs with the other schleps off of a mimeograph machine or something like that.

Comics, comics that was the whole thing, but in the early '80s that changed for me.

Guy: Did you get sort of an endorphin rush from illustrating or drawing? Did you start getting it from programming instead?

Don: Yeah, in a way it's the same kind of thing, because it's a different kind of tinkering but it's also something that ego maniacal people like myself have. You're able to create and control entire worlds. With drawing you're creating the characters. You're basically God, right. You're saying what they look like, how they behave, what they say.

With a computer, that's a very similar thing. It's the addiction and the ability to control your environment when you can't really control your real environment. That's why a lot you meet a lot of creative people who are just complete spazzes, but they can do all these other things because that's where their focus is. It is very addictive. I say on my website now, I'm a recovering programmer.

Guy: Yeah, I love that description.

Don: I'm sure I'll fall off the wagon again. I go to the meetings and I haven't programmed in...

Guy: You got you 30 day chip?

Don: Yeah, 30 day chip and stuff like that.

Guy: Why are you recovering? What are you trying to recover from? An all consuming, constantly running virtual machine in your head or what?

Don: No, the thing is, I was very fortunate to make some career changes in my life and they seemed to work out very well. I like the idea of change. In fact, the idea that I worked at Apple for over 10 years is mind boggling to me in retrospect, because I have the attention span of that four year old kid.

I have the ability to focus very, very deeply but I also I see something, oh, bright and shiny, I got to go play with that.

To me, it's not required of me to do the same thing my whole life. Also I know that I can do it. It's like drawing. I know that I can draw. OK I solved that problem. Let's move on and try the next thing. Why wouldn't you do that? You only get so many years at this. I've burned through 56 of them so far. I've got to be a little more judicious about this.

The thing is that I know what I can and cannot do, and while I was never the world's greatest artist, I was never the world's greatest programmer either. I was good enough to do what I did, but I'm also not the super creative inventive type that's going to come up with the next app or this or that or whatever.

Especially after working at Apple for 10 years, I was around so many smart people. You've got to understand, my goal was to hire people smarter than me, which was not that hard but these people are just brilliant.

When you've got people like Darin Adler and Kinka Shinden, Richard Williamson, Machi Stilloviach, Dave Hyatt, Adele Peterson and people like that working for you. You've got geniuses.

Then you have to look at my management chain. When I started at Apple, I worked for Scott Forstall, who worked for Patron Serlay, who worked for Aveta Veinion, who worked for Steve Jobs, right.

Guy: Right, an all-star stack going on.

Don: Yeah, and those guys are just the crème of the crop. You had to bring you A game every day. There was sometimes I thought, boy they're going to find out I'm a nitwit and I'm just gone. Later on, I found out everybody except the most delusional person out there has days like that. When you're around that kind of people, it's kind of daunting.

The other thing I wrote a few weeks ago when I talked about why I retired from Apple. I was just tired. Not burn out. People online assumed I meant I was burnt out. No, I know what burnt out is, I was not burned out.

Guy: Yeah, just time to move on.

Guy: You were done it sounded like.

Don: Yeah, I was done. Stick a fork in it. Go do something else. You have to understand that I'm an incredibly lazy man.

Guy: Some of the best programmers are.

Don: Yeah that's probably...

Guy: Hopefully, I don't mean that in a negative way.

Don: They get the machine to do it for them, right.

Guy: Looking at the stuff that you've worked on, I think a common thread is that you sort of try to enable creativity. I don't know if you've made these choices intentionally or not. You've worked on Director, Illustrator, vendering engines for the web.

Don: Mm-hmm.

Guy: Is that something you're conscious of or something you're drawn to, or is that just happened stance?

Don: Probably the later, happen stance. I didn't end up working on a lot of tools that were creative tools, and that was because of my background as an artist. One of the attractions I had when I left Tops and what was then Sun Microsystems, because they did acquire Tops, to go work for Macromind, it was called then before it was called...

[crosstalk]

Guy: Oh, right! I forgot...

[crosstalk]

Don: That was when it was in the old building on the corner of Fourth and Townsend. That was a great building by the way. It was a four-story building, we found out later on, we wondered why the floors sloped in the building, and you couldn't put a pencil on your desk without it rolling off.

We found out the floors sloped because it was a slaughterhouse at the turn of the century, and the floors were sloped to drain the blood off into the catch pan.

Guy: [laughs]

Don: We thought, "Isn't that the perfect environment to program in"? The history is so rich it's bleeding you out there. I went there because I wanted to do something that was not low-level file sharing stuff. Although I do love networking and stuff like that, that's a lot of fun.

I wanted to work on something creative, then when I went to Macromedia to work on Illustrator, which was like coming full circle for me, because I had used Illustrator, when I was a professional illustrator. To be able to meet the original creator, someone I had respect for was fantastic. In a way, it's kind of like that, but it's also dumb luck.

Like I said my life plan a lot of it has been, oh, bright and shiny I'll go over there for a while. I wound up at Netscape, not because I was trying to go and do something marvelous with the web. I was out of a job. I got laid off from Adobe, and this other place I ended up working at in between. I thought Netscape was doing something interesting and they were doing a lot of hiring, so I went there. Dumb luck.

Guy: Was that your first introduction to working on web stuff?

Don: Yes, well it wasn't my first introduction to the web, I had a little bit of that at Adobe, but certainly working on web stuff it was.

Guy: On the engine.

Don: I planned to write about the story on the blog in a few weeks, but that's where I got my nickname and met a lot of fantastic people. I got to be in a documentary there.

Guy: You were there when Netscape open source navigator, which was a huge deal. Like you said, there's a documentary about it. Was it as crazy as a documentary makes it look?

Don: Oh no, not at all! It was much crazier than that. Before we started the recording session, just to tell the audience here, I asked Rene and Guy, "Do you bleep me? Is it OK if I drop a few F bombs or something else here?"

Guy: Everybody here is a sailor.

Don: Exactly. One of the ways I got my particular assignment for the open sourcing of Mozilla was my familiarity with, you might say, colorful metaphors. They had decided...We were just getting crushed by Microsoft and Netscape, obviously...and Driesen just pulled out of his ass this Hail Mary idea of open sourcing Navigator, and then we realized "oh God, we've got to do this."

I was a manager there and I was on the mailing list that night as we were discussing how the hell we are going do this, and what some of the tasks were.

One of the things that came up was, "Oh God, we've got to clean up the source code if we're going to open source it." Somebody might've said shit or hell or damn. I was like, "What, are you kidding?" We had one source file that used the word "fuck" repeatedly as sort of a line separator between sections of the source. It was the engineers' way to comment on what he thought of the code.

And they said, "Well, we've got to correct the source and search for those seven dirty words. You know, George Carlin's seven dirty words. Find those and we'll be good." I was like, "What, are you kidding me? What about..." and I rattle off thirty in the email.

The entire management team was on the mailing list, and Driesen was reading it too, my boss and everybody else. This was Netscape, and I wasn't spanked for that. It was like, "Oh yeah, Gramps is right. You're in charge! Don, your job is to sanitize the source.

They say, 'Only Nixon could go to China.'" Cleaning up the source, and obviously shepherding the Mac version through. And cleaning up the source was really hard, it actually turned out to be easier to get rid of the F bombs than getting rid of all the things that were proprietary code. That was just maddening.

Guy: I remember a scene in the movie where somebody just ends up calling Steve and getting an OK to ship something that was basically Apple's.

Don: I was in the room at the time! So, that was nuts, with days, if not hours to go.

Guy: It was a pretty short time span between when the decision was made to open source it and when it actually went open-source, right?

Don: It was less than three months. Driesen made the call in the first week of January, and then March 31st, three-three-one day, that's what we had to hit. It was like, "Couldn't you have made it June?"

Guy: You just picked a date, right? And everything had to happen?

Don: Yeah, we did it. Up until the time, that was probably one of the most fun things I've ever done, I made friendships that I still have this day...great people. It was fantastic being there and being part of that, and saying you got to change the world.

Which is one of the reasons when I got the opportunity to go to Apple, and they wanted me to do a web browser again, that was one of the reasons I did it. The idea of being able to do something crazy, if it's really, truly nutty, and sometimes even hopeless, I was like "Whoa, I'm in! That sounds fun." That's one of the reasons I did it.

Guy: Let's put pause on that Safari project for a little bit, because in the middle there you did something kind of crazy and kind of fun. You tried to do Nautilus, which is a file browser for Linux. With Andy Herzfeld, who you spoke about earlier, that's why I want to bring up.

Don: Well, to get to how I got there to Eazel, Andy Herzfeld and Bart Decrem's company, they were the two cool founders there...I started at Netscape in 1996. I just missed the IPO, so I was not a "Bazillionaires" there like everyone else. That's what we called them, "Bazillionaires." AOL had acquired Netscape by that time, and AOL was very slowly but methodically running the company into the ground, and worse, the soul of the company into the ground.

Guy: As they do.

Don: I was getting really tired of it because I'd been there for a while, four years, because I earned my sabbatical. I went on my sabbatical, this was fall of 2000, I was gone for six weeks on vacation and I came back and I just had to stick a fork in my leg every day to go to work. I was just not enjoying myself. The fun that we had from doing navigator in the early days, of open sourcing Mozilla; AOL wasn't behind it the right way.

One of my engineers had just dropped out and left about the same time I took my sabbatical. He went off to do the startup of, I didn't know what the name of it was, but one day he sort of called me out of the blue and said, "Gramps, we need some help over here. We need some managers who know what they're doing over here." and I was like, "Well, what the hell are you calling me for." He said, "No, you could this." I had gotten into Linux at the time because I was really disappointed with where Mac was going.

Guy: This was 1997-ish?

Don: No, it was 2000.

Guy: OS X still wasn't out.

Don: OS X still wasn't out and although by this time Scott Forstall had convinced [indecipherable 0:38:27] Burtron and Steve to do Carbon, nobody had it and nobody knew about it at the time. I didn't know that was going to be the way forward. While I liked YellowBox, which was the Cocoa machine, and I love Cocoa, I told, when I was at Netscape, the Apple guys, "What, are you out of your mind? Am I going to rewrite a million lines of code on Navigator and move it onto this new OS? That's not going to happen."

So I was really disillusioned and although the Bonding Mac's had just come out and the "Think Different." campaign had come out, a lot of us old guys from the old world didn't think much of that. We thought it was kind of...this is kind of stupid in retrospect, which shows you what excellent judgment I have about marketing...I just thought, "Wow, this is desperate. This is not good."

Guy: In all fairness, Mac OS 8 and OS 9 were not compelling for anybody who knew their stuff.

Don: It was not the next big thing. I knew that the other operating system efforts had failed, because everyone talked to those people. So, I'd gotten into Linux and I liked the environment, but the desktop was still crap.

I went over and interviewed at Eazel and what their goal was to remake and make money from the desktop on Linux. I actually didn't pay much attention to the business plan because I just wanted out. I thought it was the coolest thing that I got to interview with Andy Herzfeld and he was like one of my idols. Just a total teddy bear, probably one of the most fun interviews I'd done in my life.

The other guy I got to interview with who was going to be my boss, the hiring manager, Bud Tribble. Good God! He was the guy who ran the original Mac software team back in the early 80s. He's a super-genius as well, a medical doctor, and an exceptionally good bass player, too, by the way, when he gets to play.

I got to interview with Darren Addler. I was going to be his boss, and I was also one of Darren's fan boys. I've got to tell you, of all the interviews I've done over the years, that was the one I probably sweated the most and worried about the most. Darren was one of the fiercest damn interviewers; I still give him grief about that to this day.

Guy: Really? Technically or just?...

Don: You have to know Darren. Darren was doing a really good job. He was trying to find out, "Do I really want this person as my boss? What does this person know about management?" Up until that time I'd been a manager at a couple of different companies by then, engineering manager, but nobody had really grilled me on it like Darren had, and he was good; which I would leverage later on certainly to interview other people over the years at Apple.

He was a real tough interviewer and I was nervous about that because Darren was the guy who started the "Blue Meanies" back at Apple in the early 90s. He went on to some fame at General Magic with Andy. He's a really good guy.

I took the job at Eazel and they were already pretty far along. Well, not far along enough with Nautilus. A lot of the big decisions had been made but they just couldn't seem to get the damn thing done, so I came in as the director of client engineering, my first job with that title, Engineering Director.

Bud had to go worry about investors and all kinds of other things, and he told me "Your job is to get this thing done." We didn't have enough engineering management talent, so I had like twenty-five people reporting directly to me. If you ever want to go nuts as a manager, you do that.

But they turned out to be some of the most fantastic people in the world. Not only Darren, but Maciej Stachowiak, John Sullivan, Pavil Shisler. Ken Kocienda was there, too. Ken didn't report to me, he eventually became the other server-side director of engineering, I directed client and Ken and I became really good friends. When I did wind up going to Apple later on, after we went completely toes up at Eazel, I knew who I was going to fill my team with. A lot of those guys.

Guy: Eazel seems like one of those companies that had a lot of stars packed in all at the same time.

Don: Brian Croll was also there, he was the head of marketing. Brian also went to Apple, he's the head of OS X marketing and stuff like that. It was a lot of fun. I went there because it was going to be fun and all these smart people were there, and it was not Netscape. I just wanted to do something different. Even though it was a fool's errand, we got Nautilus out on time, and then a day and a half later we laid off half the company.

It was one of the worst things ever. We're going up towards the deadline for bringing Nautilus out and working these enormously long days. I get to work early in the morning and Ken Kocienda meets me outside and is like, "Oh, the shit's hit the fan." and I'm like, "What?" "We have no money. The funding didn't come through."

So we went inside and the entire board was inside, in the board room we had, and they wanted to talk to us and said, "We've come up for a plan to keep going." The entire board, and my boss, all the executives were going to basically not pay themselves.

I'm thinking to myself because I had a mortgage right then, it's like, "Will Ken and I get paid," just as a little aside there, "if you do this?" They said, "Yeah, but we're only going to do this if you guys stay here." I said, "Well, thanks for thinking of us like that. I'm not sure if your priorities are completely right."

They said, "We're going to have to lay people off." and I go, "Oh, crap. Well, who were you thinking about?" and they show us a list of people and I went, "OK, we'll do it if you keep paying us but one more qualification, you've got to let us pick who's on the list, because these are the wrong people on the list." Ken and I did one of the worst jobs you'll ever do as a manager.

Guy: I've had to do that, it's horrible.

Don: We went to this dive bar Japanese restaurant place in downtown Mountain View, it had the worst damn tea. We sat there, and writing on a napkin we figured out who was going to live or die, and then we had to get Nautilus done.

I remember the night we were trying to get done, it was after midnight, it was like one o'clock in the morning, and Ken and I are managing the bug reports sitting in this room and this young kid, one of the QA engineers, runs in the room and says, "I've found it, I've found the last bug that was holding us up. We can run the build now because John's got a fix." Ken says, "That's great!" Kid runs out, shuts the door, and Ken slams his head on the desk. That's one of the guys we were going to lay off. So, that sucked. If you ever get a chance, don't ever do that.

So, I was out of a job and we were still trying to save the company. We were trying to sell it to RedHat and do all sorts of other whacky things. I knew I had to find some place to work because I knew my wife wouldn't want me lounging around all summer, kind of like what I do now.

I started trying to look around at what was out there. I remember we were focused on gnome because Nautilus was a gnome file manager. I started looking at KDE and I was playing with KDE, and I got re-exposed because before I went to Eazel I had been kind of a KDE guy, and I got re-exposed to Conqueror. I thought, "Yeah, they did a pretty good job here while we weren't paying attention."

Guy: Which was their file manager, sort of Windows-style where it was based on a lot of web technology?

Don: Exactly, and it was using KHTML and kJS, as core commands. I looked into it a little later on. I thought, "That's pretty good, but there's no money in KDE, I got to find something to make the..."

Guy: Got to pay rent.

Don: Yeah, I got to pay rent. Just then Mac OS X Cheetah had come out, and Andy Herzfeld sat across the isle from me and I said, "Andy, what do you think of Mac OS X? Did you play with the developer preview? Because I really hadn't played with it." and he said, "No, but Don, if you're interested in it, do you want to borrow a machine?" I didn't really have a Mac, anymore, and Andy lent me one of his G3 towers to run Cheetah on.

Guy: One of the blue ones?

Don: No...

Guy: Oh, one of the beige?

Don: No, it was either blue or right when they went to the first ones with the grey. Anyway, Andy's the most generous guy in the world, a wonderful person. He lent me one of those and I was using Cheetah at the very last developer preview when I started playing with it, and I went "Wow, they did a really good job here. It's slower than shit, but..." It was really good and I thought, "This could be something. I would like to work on this."

I'd become a real expert on the old operating system, basically system 7 era. Working at Tops doing system software, I had my own hand-annotated dis-assemblies of parts of the ROM. You had to do that back in those days, and this was something completely different, and I was excited by something new.

I didn't really want to go back to classic Mac-style program. I went over and talked to Bud and I said, "Bud, you obviously still know people over there." Because Next had acquired Apple, that's what we had all deemed what had happened. Even when I was at Apple, that's what we had called what had happened.

I said, "Can you get me a gig?" The funny thing is, going back to your thinking, Guy, is Bud thought I'd want to do the creative stuff. So, he got me an interview with the iPhoto team, which strangely enough, was being run by my old friend Glenn Reid from Adobe. It was a pretty easy interview and stuff like that.

As much as I like Glenn and stuff, there were some tells about the organization and stuff like that. I didn't want to work on iPhoto. I wanted to work on the core. The interview was pretty good. I went back and told Bud, "I'd really like to work in Systems Software," He's said, "Well that's funny because somebody over there wants to talk to you, apparently." I went, "Oh really? What the hell do they want to talk to me about?"

So I went over like a week later and that was when I met Scott Forstall, yeah.

Guy: Not a bad person to meet.

Don: Yeah. I was not aware, at the time, that he was the man behind Carbon but I found that out talking to him. It was a really funny interviewer. I went...

Guy: Actually have to overlook quite a bit is that like one of the old Next guys is one of the people that pushed for Carbon to be in there.

Don: Yeah, which is totally crazy. But that's the great thing about Scott. I mean, he's just totally the world's most pragmatic guy.

Guy: Right.

Don: He got it. He gets it. That's part of his genius. So we did an interviewer with him and I had to sign a non-disclosure to do the interview, which is like no big deal. But we are sitting in his office, Scott's interviewing me, and he's asking me questions, kind of probing. Like, if we wanted to do this how would you?

I'm like, "You want me to do a web browser?" He was like, "Hold that thought." Runs out of the room, gets his admin. They bring in another NDA.

[laughter]

Don: Go through the whole rigamarole, signing, witnessing the NDA, stuff like that. His administrative assistant leaves the room. We watch her leave the room. Shut the door. Scott turns to me and says yes.

[laughter]

Don: Then, I talked to him about how we'd do a Web browser and how they would do a Web browser. They just thought it was nutty, right?

Guy: It did seem crazy at the time. When the project was announced, it seemed to come out of left field.

Don: Yeah, we surprised a lot of people especially like I said, we punk'd a lot a people with what we'd use. It was in that original interview with Scott that when he asked me, "How would you do it?" I was just full of piss and vinegar that day I guess and I thought, well, I'd base it on Konqueror. He was like, "Really? And not Mozilla?"

I was mostly doing it to be snarky and silly and stupid, but that's what we wound up....I told him why at the time, but that's eventually what we wound up doing. After I looked at every technology there was early on, that's what we decided to do.

Guy: I want to get into that a little bit, because I think that's one of the four big software choices that Apple has made that's really paid off for them. First, is using NeXTSTEP for Mac OS. The Quartz compositing over the display postscript -- I think that was a huge, huge move even though it was as slow as hell, KHTML, and using Cocoa and [indecipherable 0:54:33] for iOS is the fourth one.

Honestly, maybe you were just trying to be wacky in that interview, but choosing Konqueror as the basis for Safari and WebKit is a huge decision. What drove you? Because you'd worked on Navigator. You'd worked on NeXTSTEP. Nautilus didn't use Konqueror. What was the impetus behind it?

Don: Here I am. I'll tell you some of this and I'm going to ruin yet another blog post that I have in draft, but I did promise people a story. The impetus? You have to remember what Mozilla was like at the time. It was huge. It was several million lines of code.

Now, WebKit is that size now, kind of amusing me, but that was an enormous amount of code. It was code at that time written in a style that was very obtuse. The Gecko rendering engine. I think it was Ken Kocienda made a joke that it had this object model that had objects to represent all the bits almost that was really, really complicated and slow.

One of the early goals of the project was not only to build a web browser, be able to use the technology that we use elsewhere. Which was one of the things that Apple couldn't do with Internet Explorer for the Mac. You couldn't take the engine out.

In the interview process and of course on the job, I met Bertrand Serlet who was Scott's boss at the time. I knew that Bertrand wasn't going to let several mean lines of code into Mac OS X. It wasn't that big at the time almost. I had to come up with something lighter-weight than that. So that was one thing.

The other is it was not exactly a star at performance either at the time. It was pretty slow. There were also some very subtle issues thinking about it in a kind of Machiavellian way. I knew that we were going to have to do this project quietly.

Let's be blunt and secret. Nobody could know about this. I am going to go off and do this for a year or 18 months. I'm going to come out -- ta da. We based this all on Gecko and we forked it. We would just get -- flayed -- by that because the Mozilla community was so huge.

If I based it on a smaller project that nobody knew about, smaller community. To be perfectly honest, the hangers-on were less rabid. I had a chance of pulling that off politically. It was actually harder to do with Mozilla that way.

Getting back to the size of the code. There was a really important thing, with the size of the code, was getting the engineers to wrap their heads around it.

Ken's the first engineer on the team, but he started that same day as I did at Apple. Technically I did not hire him. I made sure he was on my team when he got hired. Richard Williamson was the first guy that hired him a month after we started.

I had to get these guys to wrap their heads around a code base. I knew from working on Gecko myself, you just don't go into that lightly. I mean it's a monster. I had to get something that they could grok. That was another reason.

It turns out the code at the time certainly was much more...shall we say hackable than Mozilla and Gecko was. It was much more pliable and it was simpler. I wasn't fooling myself. It was not complete. It was not as standards compliant. It didn't render everything as well. It was not as accurate, but it was a good basis.

That's one of the reasons I did it, so I picked that. When I say I picked it, I didn't like -- Don comes down from the mountain -- and says.

I stood around. Actually, Richard had the office across the hall from me and Ken had the one next to me on the same side. I think we were actually standing in Richard's office at the time because we had some things on his whiteboard.

I said we got to do this. We got to pick one of the solutions we've been investigating. I said I got to go tell Scott, and Bertrand, and Javie what we're going to do here. We're going to lay out the plan. I said this is what I want to do. Are you guys in? Do you buy this? They were like yes.

I was not going to pick this without those two saying yes we're going to do this. I certainly wasn't going to go that way without approval from my management chain.

That goes back to another thing. I say in my blog, by the way, credit where credit's due, that I started the project. Technically when you look at it, Scott Forstall started the project. You can argue everyone at that management chain, Scott, Bertrand, Steve they all started the project...

Guy: Sure.

Don: ...but I was the one...

Rene: You drove it.

Don: Yeah, I drove it, and drove it like a vicious psycho crazy person at the time.

Guy: I was going to say, one year between picking Konqueror, one year and 18 months, and shipping Safari 1. That's a lot of work. Safari was quite a bit ahead of Konqueror when it did ship, in my recollection.

Don: Yeah. We had fixed in all...I'll go into some of the things we'd fixed, especially the performance aspect of what we changed, in my talk. Here, he works his plug into the conversation at the Úll Conference next month, where I talk. My talk, 25 minutes of gramps talking about how we made Safari fast.

One of the things we did were some speed improvements to KHTML and KJS, but also some correctness improvements, and things like that.

Guy: One of the things you keep hearing about the Safari project is that you have performance-based tests. If a commit makes something slower, then it gets yanked.

Don: Yeah.

Guy: Was that your doing?

Don: Yes.

Guy: I can imagine, when a deadline is looming, you may be tempted to let that slide a bit.

Don: I never did. There were times when I was the most hated person on my team for that. This is actually the point of my talk next month, it's that that is the key. You can never go backwards. That's the Safari secret. That's become the culture. If I have a legacy with Apple, it's that would be a big thing there you never...

Guy: Sometimes before.

Don: Yeah. And you have to turn it into a religion.

Guy: Yeah, it really has to be the one thing you won't [indecipherable 1:02:59] . I think you have to pick one thing that you will not sacrifice and you've got to stick to it. Otherwise, everything can get turned into a mush.

Don: Yeah. It was a hard thing to do, because like I said it doesn't make you well liked with your own team, and not everybody will understand the process at first, but it's not an issue anymore, because the entire team became...

Guy: Now it's part of the culture, aren't that right?

Don: Yeah, it's like a jihad.

Guy: The other interesting thing about Safari is that you are one of the very few teams in Apple that open-source in a pretty big and loud way. I suppose just using Konqueror means that you had to be, right?

Don: Yeah, because it was LGPL.

Guy: Was that a hard sell to management?

Don: Yeah. In a way, the hard sell was not the initial one, because we were also considering resource for open-source. But the hard sell was becoming truly open-source. In other words, when we first came out, we were just throwing tarballs over the wall periodically. We didn't have a [indecipherable 1:04:23] people think of the way WebKit is run right now, it's a very high-visibility, very, very open and, we hope, transparent system, but it wasn't like that the beginning.

Who we have to thank for pushing to do it that way is Maciej Stachowiak and David Hyatt. They were the ones really pressing Darren and I. Darren, of course, was for it. I went to Scott and Scott approved. Bertrand was the one who made the call and allowed us to do that. Part of it is because Apple did have, certainly, a history with open-source. It was much easier to do with Apple than it would be at other companies.

Guy: Really? I think people would be surprised to hear that, because Apple is so well known for being very secretive and closed, despite the fact that they do actually have a lot of open-source.

Don: A lot of open-source. Look at Clang, look at LLVM, look at Darwin. There is a huge history of that there. That's how we could get away with that. Was everybody happy about that? Not always, but not everybody was happy about the engine choice that I took the credit/blame on with KHTML and KJS.

You have to remember, when it first came out, Safari was really not very compatible with the Web, partly because its brand-new engine WebKit brand-new engine and it was not IE.

It had some of the same problems that Firefox had when it first came out and the new engine. Worse, because it was so obscure, which is why the User-Agent string, which is probably the lasting thing that's still in the code that I did that's in there, why it's crafted that way to be as compatible as possible.

But, for a while, there were some, not my management chain, not the team, but there were some, and well-meaning people, I don't dislike them for doing this, they were trying to do the right thing, but they would second-guess me, like, "Oh, we should work with," something more compatible...

Guy: There's always going to be some kind of bias no matter what you...

Don: Right. And then, later on, we did the iPhone. Richard went off to start the Mobile Safari team -- Richard Williamson should be credited for starting that project. [indecipherable 1:07:19] and others wanted to do that. When that came out, it was very clear that we could not have used Gecko at the time, because it was just too huge for the platform.

WebKit was the perfect choice, KHTML and KJS, and I was a genius again. Then, when Google decided to do Chrome, then I was a knucklehead again, because it was open-source and they could walk off with it. You get a real thick skin in this business. The whole time, you stay the course. As I told my team over the years, "Your plan, our plan, is to take over the world."

Rene: What was it like for you, looking...I was using a lot of mobile devices back then, and there was WAP browser, there was Pocket IE, there was Blazer on Palm, and none of them could really show you the Web. You really seem to have a goal of actually making the mobile Web useful.

Don: In retrospect, you can see that was the goal. At the time, when Richard went off to do the project and to do this, we were just trying to get the bear to dance. We were just trying to get it on the device and get it working and have an experience that would fit on that size of a screen.

I think the innovations at his team came up with where the way you navigate, working in the other gestures, the way pages rendered. Some people hated it at the time, but it was the way that we could get the performance out of it, the...

Guy: The tiled?

Don: The tiled stuff, the other subtle things with the way the chrome...and I use the word chrome generically. I hate that Google picked that name for their browser, because for a decade I've been using the word chrome just to describe the box that's around the web content. That's forever screwed now.

Guy: Jerks.

Don: Yeah, you've got to go lower case "c", chrome.

Guy: They've co-opted it.

Don: It was what I told Mike Pinkerton and Ben Goodger, "Well, way to go to screw up our vocabulary." That was great. That just drew you in. And getting the gesture stuff right, they did a fantastic job with that. While Richard was responsible for the front end and did the initial version, obviously, of getting WebKit to work on there, because they had to do some other stuff, we eventually folded all that back into the main Safari projects. By the time I left Apple, I was responsible for that.

Guy: It was interesting because some people had tried to do proxy browsers where they'd render everything on their servers and then push it down to you as an image. And some people just prioritized the content so the entire interface would lock up while it tried to render things. But mobile Safari always seemed to want to retain that immediacy and the liveliness of the web.

Don: Oh yeah, and that was the total goal. Steve was very clear that that's what we had to do. That's what he wanted. There were a couple of glorious hacks that Richard's team did that enabled part of that. We had stuff going both ways that we folded back into desktop Safari for some of that responsiveness.

I am so glad people were...it was great to see people delighted by it and being able to browse and do things on a device that small. I think mobile Safari where my favorite environment to use it is actually not the phone, it's on an iPad. I just love that way. It's just buttery smooth. That's what I love about it.

You're talking about the proxy thing. My friends over at Danger -- I think it was Danger -- tried that experiment first. Was it Danger?

Guy: Danger did it. Rem did it. Opera did it.

Don: I think it was Danger or Opera who did it first. I went and looked at it, and I was not impressed. Well, I was impressed with...it was a great hack. But you really couldn't get a true rendering of the page because you're trying to execute JavaScript remotely. That's not where the Web is going when more and more JavaScript was being pushed to the client.

I looked at that and was like, "Well, that's not going to scale. That's not going to last." Then it was a couple of years ago Amazon brought out...they touted their...

Guy: Silk.

Don: Silk, thank you. Talk about silky smooth. They talked about a Silk browser. There were lots of smart people at Amazon. I thought, "Whoa, they've figured it out." I had my guys go out. We bought a couple of the devices just to check it out. I went, "Nope. Still not there yet. Still does not work."

Guy: You reminded me. Do you remember those Internet accelerators that they used to try to sell, because dialog was so slow.

Don: Oh, yeah.

Guy: It seems like it's filling slack in the market, that this is a problem that the natural evolution of technology will solve for you more quickly than you will gain any acceleration in the market share.

I remember at both the iPhone event and the iPad event, Internet communicator and a better web browser, it was such a cornerstone of Apple's pitch for these devices that I can't imagine it being anything other than a core part of the experience.

Don: Yeah, the whole responsiveness. If we ever had a hang in any part of the phone, that was total anathema. We had to fix that. In the early testing, we were told to pay very, very close attention to this.

We were worried about not only Safari, but other applications. When you've got a lot of data in them, would they slow down manipulating that data? This was a problem, actually, in Safari. If you had an enormous number of bookmarks or an enormous number of items in history, Safari would start to get slow. We worked really hard to fix those kinds of problems.

Rene: Yeah, that's a weird kind of problem that you don't necessarily think about. A giant history is not the thing that you're thinking about making fast when you've got a whole web browser to port over.

Don: The axes of...the things you have to worry about with performance in a Web browser are so vast, it's staggering. Getting back to the Amazon Silk thing, I said they didn't solve that problem. They came closer to solving that problem than anybody else had. But I think the correct solution is faster web browsers and smarter caching.

You don't have to get...to a certain extent that's what Silk is, is smarter caching, and server-side caching and trying to leverage things like AWS and stuff like that. We're getting pretty damn fast right now. One of the other legacies at Apple was starting the second browser war, a different kind of browser war, which was the performance war.

I like to think that the Safari team was one of the reasons that Mozilla really got serious about performance. They did a really good job getting serious about performance. Firefox has improved tremendously over the years that way. I know when Dean Hachamovitch took over the IE team at Microsoft, he was also really serious about it. And certainly the Chrome guys are nuts about that, too.

We're all racing against each other. I think that's fantastic for end users. It made all of us better. It made certainly the experience with JavaScript, which is where the web was going, much better.

Rene: I was going to ask, so is that where most of the gains have been had, and is that the future of performance enhancements for the Web?

Don: It's kind of hard to quantify that. It's like, most at what time? In the early development of Safari, Richard Williamson made a huge gain just by making Safari 30 percent faster by speeding up text rendering. But that's when it was slower than crap, so you could do things like that then. Ken Kocienda made a big performance boom in Network [indecipherable 1:16:25] . Certainly [indecipherable 1:16:28] and Darren were the first to tackle speeding up KJS and going down that route. Geoff Garen and his team are in charge of that now over at Apple. Certainly there are going to be gains that way in JavaScript. But I think there are...

Rene: You need to look at the whole stack.

Don: Yeah, you have to look at the whole stack. You have to measure. That's the key thing about winning the performance war. Darin Adler had a great expression. He said he's got a 100 percent record of guessing where the next performance bottle is. He's always been wrong.

[laughter]

Don: Which is not actually true. He's not always been wrong. That's the thing, is you don't make assumptions that way. You go out and measure. So I actually have no idea what that is. Also, the nature of Web browsing has changed over time.

I think it should continue to change. I'd like to see it move from...you know, Web browser interfaces from a document based world -- and we've had that forever -- to something that's a little more subtle than that. Right now I think Web browsers have too much crap...

Rene: Too much chrome sort of thing?

Don: Yeah, too much chrome, too much stuff. You're slowly seeing the evolution away from URLs, which I think is a great thing. Obviously the plumbing, I don't ever want that to change. But the fact that people have to type things in like that is just...why do we do that? It's 2013. Or why do we have all these other little doodads like reload buttons, and stop buttons, and things like that? It should be...

Guy: More human?

Don: Yeah. It should be more obvious. Explicit back and forward buttons are a little odd, too. That's why I love the world of gestures and doing things like that. But I am out of the game. Try as I might, I try to stop doing this stuff.

Guy: It's interesting to me that if anyone had told me at the height of Windows and IE 6 that we'd all be walking around with little net boxes in our pockets, and WebKit would be arguably the most popular...not even arguably anymore, the most popular browser in the world. Then you have Safari, Chrome. Palm based an entire OS on WebKit. Blackberry is using Torch WebKit now. It's almost ubiquitous. That's a remarkable sea change from just a decade ago.

Don: Yeah. I was joking with [indecipherable 1:19:19] , before he left Apple. I told him...the joke...you know, Pinky and the Brain, our job is to take over the world. That was the goal. I didn't think we'd actually do it, and we kind of did that.

Rene: Now what?

Don: Yeah, now what? It was kind of stunning to me. I think back to that day and sitting in Scott Forstall's office trying to figure out how we're going to do that, starting a little snowball rolling.

And what's happened? There are people that are much better at this stuff than me. After 10 years they need their time with their hand on the wheel, and they'll be better at it than I ever was, leading that effort.

I left this stuff in Darin Adler's hands, to run Safari and WebKit, the greatest guy in the world to do that. He's got people like [indecipherable 1:20:27] working for him, worrying about that stuff. They're all geniuses. Lots of other people working for him, too, worrying about that stuff.

I still, obviously, talk to them from time to time. If I see something that's stupid, I'm not going to drop a note or call them or whatever. It's like the recovering programmer thing. It's like a recovering Web geek thing. I fall off the wagon every once in a while.

I have lunch with Darin every once in a while, and we talk in vague terms about how things are going. I'm actually much more concerned about people. Darin's not going to tell me what the next project is or anything else like that. I never would want him to do that, or anyone else there. I don't want to know that stuff.

For what we can talk about in the WebKit at [indecipherable 1:21:20] , because that is open source. Like, where is this going? Are we thinking about this? I still do it from time to time, but I don't know whether they even listen to me or not.

Guy: I want to ask you about WebGL.

Don: God.

Guy: Does that scare the crap out of you or what?

Don: Well it scares the crap out of me in the sense that of making it safe. Does it scare the crap out of me for changing the nature of the web?

Guy: Oh, yeah, no I don't mean that.

Don: No, no.

Guy: I mean keeping it safe.

Don: Yeah, keeping it safe. I mean that's sort of one reason it's not turned on by default in Safari. It's like there are certain cases where you could do that. I don't get to say anymore because I'm not there. But until the parts of the hardware where the operating system that interpret OpenGL are a little bit more stable and can't crash or corrupt your machine or block around memory here and there, I think let's be careful with that.

I mean, it's kind of far more dangerous right now then JavaScript is, in a way. We figured out how to tame that beast. As soon as we tame GL, I think we can turn it on by default. Other browsers do turn it on by default.

Guy: Yeah, that seems crazy to me.

Don: So I'm like, I don't want to do that.

Guy: Like you really need like a hardened stack. From the drive all the way up.

Don: Yes, it's from the driver all the way up that's exactly what you need. It's a lot harder than people think it is to do that. Look, you know that day is coming that will happen, and I think that will be great. The key thing with that is to, you know it's like what people thought about with SPG, that's not going to replace HTML and CSS and stuff like that. That would be stupid to do so, why would you do that.

Guy: It's just nice, another tool in the kit basically.

Don: Exactly. It's a way to augment things. I mean you never want to walk too far away from HTML because we haven't completely solved them. But accessibility to the content of HTML has been a problem that smart people have been working on solving for years. If you start rendering text inside canvas blocks, which we also helped enable in Apple, that was a hack that Richard Williamson came up with by the way, that image element implemented the first time. If you do that inside of web GEO content you know you have to be really careful, you have to make this stuff accessible, researchable and everything else like that so let's not get ahead of ourselves.

Guy: Right, yeah.

Don: I would like to move on from that world because you've got to remember I've been involved with web browsers since 1996 and that's kind of long enough for anybody. What I'd like to do is I'd like to learn how to write, it's so incredibly hard to do that well and...

Guy: You're doing a great job so far.

Don: I think part of that is just the subject matter. I'm probably the first guy to break the first rule of fruit club, I talked about fruit club and that's what's drawing readers in. I'd like to be able to compel people to read my stuff when I don't put the word Apple or WebKit or Safari or something else in there like that.

In this last post I did, I think day before yesterday, I...

Rene: It was a good one. I liked it.

Don: Oh, thank you. Well, I had watched that. That was like me being the angry old guy. "You kids get off my lawn." I really have to watch that that I don't do that to often. But I intentionally, when I first wrote that, I had...What was the title? Regarding fake projects and loyalty tests at Apple.

Rene: I loved it.

Don: Then I struck at Apple off the title. The headline wrapped much better with that because it was like, no, just put that up, because that was certainly going to be more SEO friendly to do that. But I could give a rats ass about being SEO friendly or all that other stuff, and things like that.

Rene: I don't think you have to worry about that.

Don: No. So what surprised me, when I first started the blog, was the response I get. I was basically writing the thing for my friends on App.net, Twitter, and Facebook and here and there. I thought they'd find it was funny, right? I had no idea I'd get the response I got. It was like stunning to me.

Also, I must say, that for the most part 99 percent of people online have been very polite and very nice. I've made some new friends that way. Rene, I ran into you that way. I'd never actually talked to you in person, guy. I've admired your stuff for a while.

Rene: Thanks. That's very kind.

Don: I'm glad of the impact for those reasons. I got to meet and talk to people like Jim Dalrymple who I had read for years.

Rene: Yeah.

Don: You know Jim's yep, nope.

Rene: Yeah.

Don: When I was at Apple, even though I was director, I was clued into everything that we were doing. I'd check LoopInsight to find out what we were actually doing.

[laughter]

Don: I told Jim...I was talking to him on the phone. I said, "Boy, if I ever found out one of my people was a source of yours I would have fired them on the spot for leaking that." But, of course, that's not how Jim does it. That's not how [indecipherable 1:28:15] does it. That's not how any of the smart people do it. They do it using a technique I pointed out in that last blog post. It's like, you watch, you learn, and you slick what makes sense.

Rene: Well, a lot of time the individual rumors are kind of pointless, right?

Don: Yeah, they're. Like the ones going on now are just...

Rene: Yeah.

Don: You put the visual aid, you might be me rolling my eyes.

[laughter]

Don: It's stupid. I get real tired of that.

But what I'd like to learn, in terms of writing thing, is how to be more productive. Like, the out put. Rene your output is just...God, how do you do that and stay sane? I mean, write to that...

Exactly what you spoke about with trying and you spoke about with Guy and you spoke about with coding, is I have the stuff in my head. This is my current medium for getting it out of my head and putting it on a shelf somewhere. The blogging is the shelf that I'm using.

Rene: Absolutely. I have like 5 different things that I keep wanting to write up just I can't go anywhere with it.

Don: In my Open GL sucks.

[laughter]

Don: You've got to do something. If I wasn't such a lazy person, I think would do it. I'm sure preparing for the Ull conference I'll wait until the last minute before I write up my whole piece. I'm particularly going to try to perform in blog post, as if it was a blog post.

Rene: A dramatic reading.

Don: A dramatic reading of a blog post. That was good.

Rene: I was happy to...

[crosstalk]

Don: Yeah, I met Paul Campbell on Monday. He's a super nice guy.

Rene: Yeah.

Don: What they are trying to do, it'll be a lot of fun. He had nice things to say about you guys, because I told him I was going to be on your show.

Rene: So where can we find you on the web?

Don: Oh...

Rene: You know about the web right?

Don: Yeah, yeah, yeah. Like I said one time, somebody else who...do something really cool. I said, "Yeah, I'm telling you, this web thing is going to catch on."

[laughter]

Don: Just DonMilton.com. That's the blog. I tried to hide it but, you know.

Rene: Lot's of good stuff there, right? I actually enjoyed your [indecipherable 1:30:39] post here.

Don: Oh, right. I did the old man ranting thing again but...

Guy: I like it, I like it. Gosh, it works for you.

Don: Yeah.

Guy: On Twitter your @donmilton?

Don: Yeah, Don Milton. You can just about pick any damn service out there and I've tried to make myself obscure with the whole Don Milton thing.

[laughter]

Don: The same thing happened at App.net. So I hang out on Twitter and App.net quite a bit. Recently it was, myself being sick and my dog being sick, I haven't done as much of that. But I'll probably do that a little bit more.

Guy: You're both on the mend now, right, I understand from your post.

Don: Yeah, she's on the mend right now. We don't know when she will take her next turn. She'll be 16 in June so everyday that we have her...

Guy: Is a gift.

Don: ...is a gift. My wife and I are her long term care insurance plan right now. We are just around to pay back. I'm just around to pay back the enormous debt I owe to her for helping me keep my sanity. She was with me the entire time I was at Apple. There's nothing better than coming home from work and having someone at the door who is glad to see you, which was not always my wife and son.

[laughter]

Don: You know my dogs were, "Wow, dad's home. Does he have anything to eat?" Sit in the floor. You touch your dogs, and all the stress of your life just...

Rene: Evaporates.

Don: ...fades. It's magical how they do that. So now's my turn to take care of her.

Guy: That's great. Well, we wish them all well. And your whole family.

Don: Thanks. And it was great talking to you guys today.

Guy: Yeah, I had a blast. Thank you so much. Again, I could just keep talking forever, but we'll do it some other time.

Feedback

Yell at us via the Twitter accounts above (or the same names on ADN). Loudly.

Guy and Rene talk to Paul Haddad of Tapbots about coding on NeXT, deploying Tweetbot and Netbot on multiple platforms, for multiple services, pricing for scarcity, in-app purchases, push notifications, iCloud sync, and his beef with AppKit. This is Debug.

Here's the audio, again, in case you missed it. And now, for the first time, here's the full transcript! (Yes, we're doing transcripts now!)

• Subscribe via RSS
• Subscribe via iTunes
• Download Directly

Debug 2 transcript: Paul Haddad of Tapbots

Guy English: Hi, my name's Guy English, and this is the second episode of Debug.

Rene Ritchie: I'm Rene Ritchie, and joining us today is Paul Haddad from Tapbots, who you might know from a fine collection of small, automated iPhone apps like Waitbot, Calcbot, Tweetbot, and now Netbot. How are you, Paul?

Paul Haddad: I'm all right. How about yourself?

Rene: Very good, thank you. The way we usually like to break the ice, get started, have the first round poured is to ask you how you got involved in Mac / iOS development.

Paul: You have to go back...Oh God, it's a little bit over 20 years ago, when I first saw a NeXT station. I was in college at the time and went into their bookstore / computer store thing, and I saw one of the black and white NeXT stations. I started playing with it, and I knew I had to have one. Begged, borrowed, and stole and got one. Pretty much started coding on them from there and followed that throughout my career.

Rene: What was it like coding on a machine like that back then when it wasn't the biggest, most popular brand on the planet?

Paul: It was interesting. Unless you consider it turning into Mac OS and iOS, it never really became popular at all, but it was definitely better than anything out there from a user perspective, which is where I first got into it. There was nothing else like it. There was high-resolution display, multi-tasking. All the stuff that we take for granted now didn't exist really back then unless you were talking about really, really high-end workstations. This was the first operating system where it was friendly, easy to use, and a complete package.

If you went and you looked at the little Macs back then with their little, tiny screens and the PCs with, I don't even remember, VGA graphics or something ridiculous like that, this was a completely different experience. It's very much like what we're used to today, although obviously a lot slower back then.

Guy: When I was doing prep for this show, I went on the Tapbots site, I looked you up, I read a bunch of your blog posts, and everything. I ended up back at an old site with your resume on it.

Paul: [laughs]

Guy: One of your first gigs that you list is writing an object-oriented wrapper that worked on NeXTSTEP and Windows 3.1.

Paul: That was actually my first real job. I didn't...

Guy: That's crazy. Sorry, just for the audience, Windows 3.1 is a segmented memory model 16-bit, and NeXT is like an actual, modern operating system. That's a big challenge.

Paul: Yeah, it was way back...To be honest, I didn't write the wrapper. I just had to work with it. A consulting company came up with it for a small company. The kind of stuff you'd never see happen, I would think, today. It was for something really boring, reinsurance contract management. Compared to coding for Windows, it was so much easier and better stuff to do. [crosstalk]

Guy: I'm sure. It shocked me, the difference between those two platforms and that you would try to support them with one approach.

Paul: If I recall, and this, like I said, was way back then, the coding would happen on the NeXT machines, and the executables would run on Windows. It used the Stepstone compiler and all sorts of craziness. It was an interesting time. [crosstalk]

Guy: Yeah, a little bit. So you ended up doing contracting a few years and then finally got into iOS.

Paul: Yeah. I had real jobs, contracting jobs. At some point I decided that I just don't like going into an office and just went that route where I would mostly do contract work for different companies. Golly, four or five years ago, I don't even remember, the iPhone first started, they first started letting people write applications for it. Mark [inaudible 05:154] , my partner, and I were both working at Oakley and we were just in the middle of some big, hairy project. It was a Sunday or something like that and we were both really burnt out, talked, and said why don't we create an application? Went back and forth on it a little bit and decided to do something simple to track our weight, or at least that we thought was simple back then, and went back and forth.

Somehow WeightBot and TapBot was borne out of that.

Guy: Were you into the Jailbreak scene at all? Were you excited when the phone itself came out or were you more into after the SDK got released?

Paul: Neither. I didn't buy the phone when it first came out. It wasn't so much that the phone wasn't cool, which it certainly was. I'm kind of cheap and I hate paying for recurring services like data plans and things like that. I was perfectly happy with the cheap, pay as you go phone. I kept that until I couldn't do that anymore.

Guy: What was compelling about the iPhone? Or was it just that time marched on and you figured that you didn't want to get left behind?

Paul: Once I actually got the phone and the API was actually opened and I got to play with it a little bit it definitely was cool. Before that, certainly it was something that I was keeping an eye on but I just didn't feel the need to get one, which is strange because I've gotten every single device since then.

Guy: I've got a giant stack right next to me.

Paul: Yeah. I've been doing some iCloud stuff this week and I have like six different devices hooked up at the same time trying to deal with conflict management and all that fun stuff.

Guy: I'm sure. If it wasn't 11:00 AM I'd send you a beer or something. Why WeightBot? I have a line of questions about the whole bot theme. What was the initial impetus behind WeightBot? Was it because it was simple and you thought you could do it? Was it like scratching an itch kind of thing?

Paul: I could be totally wrong on this. It was probably because I was trying to lose some weight and I wanted something to track with it and we figured, like I said, it would be a fairly simple app. You put in a weight every day and keep track of it, or at least it would have been simple before Mark got his hands on it and came up with this insane concept of a robot with noises and all sorts of flicking actions.

Guy: Which is now the TapBot's trademark.

Paul: Correct. If it would have been a real simple weight tracking app, it never would have gotten anywhere. As much as I may make fun of him for coming up with crazy stuff, it seems to work for us.

Guy: I think I bought it the day it came out purely, not purely, largely because of the design and the attention to detail and the approach to it. That TapBot aesthetic has worked well across your entire line. It's branded you, not just with sticking bot at the end of everything, but it's down to the icon, it's down to the look and feel of the applications themselves, that metal look. It's very opinionated.

Paul: Yeah. We've actually talked about should we do an app without that branding, for lack of a better word, but we just haven't yet because it just works for us. Especially these days, getting anything going in the App Store is very hard. We found something that works for us, so do we stick with it, or do we go crazy and do something completely different?

Guy: Yeah. I'm sure I've said this before. Not to your face, though. [laughter]

Guy: It's a little heavy for me, it feels like. Like a little bit overwrought, especially with the sounds and all that. I love the attention to detail. It's amazingly well implemented, it's beautiful. I love it for what it is, but it feels a little bit heavy for me. That said, TapBot and Tweetbot and Weightbot, I basically use them all multiple times a day, all of the time. You're certainly not losing a customer. It's not really detracting from my experience at all.

Paul: We've heard the heavy comment often.

Guy: I feel like maybe I'm being an old man. I feel like maybe Delicious Library came out, and I'm grumbling because it should just be a list view or regular icon view, rather than being the bookshelf. I feel maybe I'm getting a little bit overly conservative.

Rene: Is there a line between...You have an incredible design language. It's a very good differentiator for you, can instantly tell a Tapbots app, but at the same time, you now carry that design with you everywhere. It might be a mixed blessing for you sometimes.

Paul: Yeah. Like I said, we've talked about doing something different. We just haven't quite gotten there yet. Everything we've looked at has felt right going into this same look and feel, for whatever reason.

Guy: Mm-hmm. Definitely everything looks correct. I can open up any Tapbots app and feel like this, it's a consistent work of art. Every attention to detail has been paid, and the little characters all fit in. Everything's great.

Paul: It's interesting to see. In the last version of Tweetbot, we made some changes in the icons which was supposed to make it a little bit lighter. We get a ton of people saying they love it. We get a ton of people saying they hate it. It's like, "Argh," you know?

Rene: You've almost made the apps into characters for people. They're getting an attachment to it because of the identity you've given them.

Guy: I think it's a great idea, by the way. Definitely character-driven apps are...

Paul: You've got to do something to stand out in the marketplace, right? There's thousands of apps released every week. If you don't have something that stands out, it's just going to get buried.

Guy: Oh, yeah. The fact that you can cross play the brand is amazing. I love that when you launch a Tapbots app, it's got the serial number stamped into it. It's great, great little touches, you know?

Rene: It's interesting. I don't want to bring up the skeuomorphic word, because it's horribly overused. Weightbots could have been a very dry, very list-driven app. There are hundreds of those kinds of apps, but you made it fun. You made the actual usage of the app an enjoyable experience, which makes you want to use it more often.

Paul: Right. That was definitely the plan for Weightbot. It's kind of boring to track your weight. We wanted to do something where it would make it somewhat fun, where you'd feel a sense of accomplishment putting in your weight every day. That's where that all came from.

Guy: Would you say that Convertbot is the one that goes furthest along that access?

Paul: Yeah. I think we both feel like it may have gone a bit too far in that direction.

Guy: Because of the dial UI?

Paul: Yeah. The dial, it's great and it's fun, but it's not the most efficient way to pick currencies to switch from. It's kind of a tricky one. Especially now that we have the iPhone 5 coming out, stretching that app just doesn't seem to work right. It doesn't feel right because it's so heavily around that wheel, and the wheel is tuned to the screen ratio of the original iPhone.

Guy: Right. Just for listeners who haven't seen it, it looks almost like an iPod click wheel that you can turn around and dial your different units, and press the middle button to select them.

Paul: Right. If you want to go with the UI heaviness, that's probably one where we may have gone a little too far.

Guy: I'm pretty sure you guys put out a blog post explaining exactly how you did this, or at least the iterations you did to get to it. From the nerd perspective, I find that really fascinating. [laughs]

Paul: Yeah. That was all Mark, I guess kept notes during that design, and showed how the wheel came to look or why those dimensions were chosen and all that good stuff.

Rene: What's it like for you when you get some of these designs back from Mark, and you have to implement the physics, and you have to implement the scrolling? You have to make what he designs feel...I can't say real world-like, but feel correct on an iOS device?

Paul: Sometimes I'll just look at it and just shake my head, and curse him out in my head and go, "Ugh, how am I going to implement this?" It's always interesting to see. We'll often go back and forth once he does come up with a design, with me saying, "This is impossible." Or, "This is going to take to long to do, and can we switch this around?" Kind of go back and forth a while to try to figure out just exactly what we can do with those designs.

Guy: I think it really worked for you, because you're one of the few teams that I can think of, small teams that works so consistently well together. Every app is very polished. It's not very sharp edges. Everything's very consistent between app to app. You have a company voice that is very distinct. Given that there's two of you, you'd think that it could go one way or the other sometimes. It seems that you guys put out what you wanted to put out. It doesn't seem that you...Not half-assed stuff, but it doesn't seem that you haven't been happy with any of the stuff that you've put out so far.

Paul: Yeah. I think a lot of that is how we work. We try to keep to our areas of expertise. I can't draw a circle to save my life. Mark can't code, and so we try to keep our responsibilities separate. Anything design-related, even if I don't particularly agree with it, it's Mark's decision to make. That seems to work well. We'll collaborate together, but at the end of the day, design is his area. The user interaction is his area. He has the final say on that stuff.

Rene: What happens when you're working on something like Netbots? You already have Tweetbot on both iOS and iPad, and then you're bringing out Netbot, which is a variant of that, it's still going to be iPhone and IPad, but now you're doing a different service and you're hitting ADN. Is that challenging? To keep an app sane on two different platforms, and then two different services as well?

Paul: It will be interesting to see as it progresses. The apps were separated once I started working on that Netbot. It's not all the same code base. Obviously one was copied from the other and then I went in and made all sorts of changes to get Netbot working on the different service. Fortunately a lot of it was architected purely by luck, so that it was some what easy to switch from the different services. It will be interesting to see as it progresses.

I've been making changes on one, and then going to the other, making the same changes there, keeping up that way. It will be interesting to see as both services and both apps fork more and more away from each other.

Guy: It's not like a shared library that you use between the two?

Paul: Well, we definitely have a common library that's used between all the different apps that have generic classes that we use. Like, our Alert Panel and our different types of buttons, et cetera. That's all shared between all the different apps, but the code itself that talks to Twitter, to ADN, the code that displays all the different view's for different app's are completely separate at this point.

Guy: You've been remarkably positive in all of your expressions. Like there's a lot of, and this is not to disparage anyone, but there's two lines of thought. There's one, people either act positive about the app store being screwed up in various ways, or positive about various business things, or people complain. I don't mean that in a bad way. They outline the realities that their business's have to face and point out where things are tough.

You guys seem to have always been positive. Is that a conscious thing, or is that just a personal attitude?

Paul: Probably a little bit of both. Regardless of what happens with the app store and Twitter, we're really just two guys that got together and started a company and were successful at it. We don't have to work for some large corporation doing really boring stuff.

Guy: You're living the dream.

Paul: Yeah.

Guy: You can take a few hurdles, right?

Paul: Right. Nothing that's happened in the past year has been particularly bad. Every year has been better, let's say revenue wise, than the year before. So, there's really not that much to complain about.

Guy: It's en vogue to wail on Twitter, because frankly they've been doing some weird stuff, and that directly affects, what I imagine is, a large portion of your business, but It's water off a ducks back. I read your blog post again last night. You seem very positive about it?

Paul: Yeah. They've definitely said what they're going to say and have made the moves that they're going to do. They could have been a lot worse.

Guy: That's a great attitude.

Paul: For whatever reason they've decided that, at least for now, they could change their minds at any point, that they don't want new Twitter clients coming out. The existing ones, they've structured in such a way that most of the existing ones will be able to continue for at least a couple years.

Guy: Yeah, you've got a long runway, given how early you were on the platform, I imagine?

Paul: Right. So did some of the other clients as well that have been around for a while. It's just new clients, or clients that have just launched that can have issues with that. With those restrictions.

Guy: I just realize we talked to Lauren last week. This is basically the Twitter developer podcast. Maybe we can get Craig on next week. So, Netbot, the App.net client, was because you wanted to do it? Rather than being a reaction to the Twitter stuff?

Paul: Yeah. We wanted to see where the service would go. There's definitely a lot of support associated with doing a client like that, but the original merge port over from Twitter to ADN wasn't particularly difficult. We had a lot of people asking for it, so we figured, "Why not?" We had a Tweetbot for Mac coming out, and I had some time in my hand to do something, so I went off and did that.

Rene: What was that like? You weren't as early as Twitterific or Tweety, so they probably had a more mature API for you to write against. ADN, you were there almost from the beginning. Was there a large difference in writing against those two services?

Paul: The API's are somewhat similar. It actually seems like the ADN-API is somewhat better in a lot of ways. Probably because they don't have a lot of baggage.

Guy: I prefer, looking it over. I've implemented a little bit of both, like what you guys have, but the ADN one seems to be informed. Where Twitter sort of took some missteps.

Paul: Right, but then again, it's a lot easier to do something like that once you see what mistakes made by the previous people coming before you [?] .

Guy: Oh, yeah. I'm not saying that to knock Twitter in any way. You can definitely learn from what other people have done. Do you have a preferred service? Which one do you fire out first, Netbot or Tweetbot?

Paul: I alternate actually between the two. In the morning when I wake up, I'll sometimes do Netbot, sometimes I'll Tweetbot, skim through my timeline and go from there. I don't necessarily go with one or the others, as far as what I first open or last open at night.

Guy: Do you use them differently?

Paul: Yeah. I think at this point, for Tweetbot or Twitter, I'm mostly doing a lot of support stuff. Answering Tapbot's, on the rare occasion answering Tweetbot accounts. On ADN I mostly do my little geeky tech posts, or complain about whatever is bugging me at that particular moment.

Guy: I basically do the same thing too. Except I don't do support. I'm more of a jackass on Twitter. I just crack jokes all the time.

Paul: I didn't say I was particularly good at support. I probably shouldn't do it, and all the Tweetbot stuff. For the most part it's done by someone else.

Guy: You guys have a support guy?

Paul: [inaudible 25:00] guys.

Guy: Right. Sorry. I knew that, Ash.

Paul: Yeah. Otherwise, nothing would ever get answered.

Guy: I'm sure, yeah. With the number of app's you've got, and their broad appeal, I'm sure you've got a lot of people who need support.

Paul: Yeah.

Guy: With that in mind. Does the Netbot stuff have a lower support per user class, than say, Tweetbot?

Paul: Well, it depends. The Netbot users are definitely more advanced than the average Twitter user. Which I think everybody would expect. There's definitely more changes going on with the ADN-API than the Twitter API. So while there's less technical support, as far as answering questions on ADN, there's the other side of technical support. Which is implementing new features and adapting the changing API's.

Guy: Maybe you can't say, but do you work closely with Dalton and those guys?

Paul: Yeah. We'll talk to them, and they've often asked, "Is there any particular API you would like to see us work on next?" We'll ask questions about, "What do you guys have coming up in the pipeline?" They're pretty open with everybody about that stuff too. It's definitely a [inaudible 26:36] experience.

Guy: That's great. Do you ever foresee the net stuff taking over your Twitter stuff? Not in terms of global popularity, but in terms of where your revenue or attention is going to be spent?

Paul: Not at this point. The user base of ADN is just so small now compared to Twitter, that I would expect something else would overtake Twitter and ADN, before ADN overtakes Twitter. We're known for Tweetbot now because we've been focusing on that for the last couple years, but like you mentioned before, we've done other app's and we're going to be doing other app's.

Guy: Do you have any plans? I mean, don't spill the beans.

Rene: Yeah, no spoilers.

Paul: Yeah, no spoilers. We're revising one of our existing app's now with some new stuff. We'll figure out something completely different to do sometime next year. We'll come up with something.

Rene: You do one of my favorite things on ADN and Twitter, where you post some of the support requests you get from people who pirated your apps. And on ADN it's even funnier, because it's such a small user base.

Guy: And they paid $50.00 just for the privilege of being there. I guess it's like $36.00 or something now.

Rene: Is that just for catharsis, or does that actually help you curb that practice?

Paul: No. They don't care. They literally don't care about any of that stuff. They certainly aren't following me if they're pirating the app. At least the vast majority aren't. It's just blowing off steam or having fun with it.

Guy: Does it get to you, or do you just roll your eyes and think [inaudible 26:36] ?

Paul: Well, here's the thing. For the most part I don't care about pirating, other than having some fun with it. Except now when people are pirating the app, it's actually taking away tokens that we only have a limited supply of. While normally I would say, "Those people were never going to buy the app anyway so I'm going to have a little fun with it, but I'm not going to waste a lot of time dealing with it." Now, there's a different situation going on.

Guy: Right. That whole argument that you can make a copy of software and it's infinite and nobody loses anything is out the window, because there's a finite limit of tokens out there.

Paul: Right. So we have to be a little more aggressive with curtailing those limits. Curtailing those guys from using pirated versions of the app, because it literally is costing us potential future money.

Guy: Again, with a very positive tone, you wrote a piece about the pricing of Tweetbot after the token limit came in. Can you talk about that a little bit?

Paul: For Tweetbot iOS, we have a fairly large number of tokens. We've been selling it for, I think, 18 months prior to the new limits coming into place.

Guy: Is that it? Wow, it feels like forever, iOS moves fast, man.

Paul: Yeah, it does. But, if you can imagine, assuming we kept it at the same rate, we'd still have at least 18 months to go after that. Whereas, on the Mac side it's quite different, where fortunately we had that public alpha and beta, we were able to get over the 100,000-token limit before the cutoff.

Guy: That's great. I hadn't heard that. That's good news.

Rene: Was that you being prescient, like you just had a sense that you should get that thing moving faster than you might have otherwise?

Paul: Yeah. We definitely felt like something was happening. There were a few blog posts coming in from Twitter, throughout that time. We just felt that it's going to be a lot harder to shut down a client that's out there than one that's not.

Guy: There was "a tremor in the Force".

Paul: Yeah. But, we definitely didn't have any inside knowledge of what exactly was going to happen, because if we did, we would have structured things a little bit different. We came out, I guess, as well as we could from that situation. But, we definitely don't have an unlimited number of tokens available on the Mac side, and that impacted what we could do on the pricing side of things.

Guy: You charge 20 bucks for Tweetbot for Twitter, on the Mac.

Paul: Yes.

Guy: That used to be a reasonably low-priced Mac software pricing tier. These days you have to make an argument in support of that being a fair price. How do you feel about the downward pricing pressure? I know on iOS, they're not cheap, but they're certainly way cheaper than you would have expected, traditionally, from Mac stuff. Was that a warning to you when you started with Tapbots, or was that something you just rolled with?

Paul: No, because back then, there wasn't this downward pressure. When we first started it was very soon after apps first came out, so there really wasn't a history of what pricing should be for the applications. With the App Store, you would see a lot more volume than anything you would ever see on, the Mac side, for example, back then. The pricing on iOS is what it is. I know a lot of people seem to complain about it. But I think the volume you see on there pretty much overwhelms any of the pricing concerns.

On the Mac side, again, it's a little bit different. I think the big pricing issue on Mac, right now, is Mountain Lion being $20, which everybody compares every other piece of software to.

Rene: Which is heavily hardware-subsidized, that $20 price.

Paul: Right. I almost wish they would have Mountain Lion be free instead of charging that $20, because then you wouldn't be comparing the two. You don't pay for iOS upgrades, at least, not anymore. I wish they would do the same on the Mac side.

Guy: I feel like I've had this conversation with so many developers that putting something at $20 puts an upper-end on the complexity of your software. Everybody can say, "You're not as complex as the operating system, so, why would I pay $20?" It's like an apples and oranges comparison.

Rene: That's their place.

Paul: They make it anyway. When people complain about price, that's the number one thing I would hear is, "This is as much as I paid for the operating system." I'm like, "No, you actually probably paid a couple of grand for the hardware that ran the operating system that subsidized that $20 price."

Guy: What are you going to do, write a long email, "Here's, actually, how the financials break down"?

Rene: "Here's what Numbers charges. Here's what Aperture charges."

Paul: I, definitely, would wish either Apple would make it free, or maybe, just remove it from the top charts. It would give a little more room to other people, so that they don't go and see Mountain Lion for $20 every time they go into the App Store.

Guy: I see them do that for all their apps. I understand why they don't, because I think the App Store tries to be, "Here's just the raw numbers. We're not going to mess around with it." But Top Paid is just full of Apple stuff, constantly, it's impossible to break in. Well, not impossible.

Paul: It's impossible to beat Mountain Lion on Top Grossing. It's undoable. I have a rough idea of what they make there on a daily basis, and it's insane.

Rene: Make Mountain Lion an app purchase for Lion and just get it off there.

Paul: Do something. I would, actually, just prefer it be free at this point. I know relative to any other developer they're making a ton of money every day on there, but, it's got to be beans compared to what they're making on Macs and iPhones.

Guy: You can tell they dropped it to $20 in order to encourage rapid adoption.

Paul: Right. Make it free, and then there's no rapid adoption problem, because everybody's just going to upgrade to it. Make a bunch of developers happy.

Rene: Was there a lot of math going into figuring out the $20, or did it just feel right? Did you go, "There's a scarcity of resources, we only have so many tokens, we have to be able to develop it and support it going forward for X number of years, a bunch of fancy math inserted there, this is the price," or was it more of a gut feel?

Paul: There was some math, and there was a lot of gut feel for, "What's the most we can charge and not lose a ton of customers, and still support the app," like you just mentioned. It was definitely a lot of back-and-forth on what exactly we should charge for the app, because even if we're charging more than we would want to, it's better for the people who buy the app, long-term if we, actually, make money off the app and continue to support it, and don't run out of tokens in a couple of days.

Rene: Different than the iOS version, you actually handed off development of the Mac version. What was that like? A lot of developers say that their apps are their babies, and you gave this one to a babysitter for awhile.

Paul: It's not for awhile, because Todd Thomas, who's working on it, is still working on it. All the Mac code is stuff he wrote. The low-level code that actually talks to Twitter is shared between the iPhone, iPad, and Mac versions, and that's all the stuff that I wrote. But, I just didn't have time to get into the Mac side of things, and spend a year doing that, and still supporting Tweetbot, and keeping it updated. It's just not something one person, I don't think, code-wise could handle.

Along with, every time I start looking at AppKit after having done UIKit for awhile, it's just not something I can handle, for whatever reason. I did it for years before. But after being on the iPhone side for awhile, it's just not pleasant to go back to.

Guy: What's your beef, to be blunt about it? We were talking before we started recording. Paul's been doing this for a long, long time since, basically, the beginning of NeXT, pre-OPENSTEP, right?

Paul: Yeah, NeXTSTEP.

Guy: Pre-Foundation? Pre-NS String, when everything used to take a character pointer?

Paul: It was before NSObject. If you go way back, it was, actually, Object.

Guy: Yeah. It was just Object at that point. NX code and all that? All of the crazy, deprecated stuff you see in AppKit, like NX Color and all that, Paul probably dealt with that at some point.

Paul: I've blocked it off my memory.

Guy: I'm going to make you bring it up now. A lot of people that basically came to Apple development with the iPhone and iOS, take one look at AppKit and find it primitive, and don't want to deal with it anymore. Even knowledgeable people, who know what they're doing, just don't want to deal with it. But, you've got a ton of experience with AppKit. My position is that often AppKit is doing a lot of things that UIKit can't do. That's less true with each release of iOS, but I think you'd probably agree with me that certainly all the text stuff was, until recently, like night-and-day better on AppKit. What's your beef with it? Is it the sales?

Paul: It hasn't really been upgraded, at least not from what I can see, since UIKit started taking off. It's just stagnated along. They bolt on layers here and there. But, if you get in there and you try to make a customized UI with buttons, with different backgrounds, and try to animate stuff, it just doesn't work right. There are a lot of bugs in it.

Guy: Yeah, just yesterday, I was trying desperately to tint a button. Not desperately.

Paul: You kind of have to go in, and rewrite it all yourself. After you're used to UIKit where it seems to be the case where you're looking at Twitter versus ADN-APIs, like we were talking about earlier. UIKit learned a lot of mistakes from AppKit. I would love to see a unified kit, App-UIKit, whatever you call it, that merges the two.

Guy: Do you think it's possible?

Paul: I don't know. They can, definitely, do it like the Carbon to AppKit transition, where they just said, "AppKit's legacy now. UIKit is new. It takes awhile before all the features that were available in AppKit are now available in UIKit. But, it's the future." Eventually, a few releases down the road, it gets deprecated, and everybody forgets about it, unless you have to run an app that was only updated 10 years ago, or something like that.

I would like to see it either get a lot of love, where you can do animations as quickly as you can do them on UIKit and things work right or as expected, or just toss the whole thing out, and start something fresh.

Guy: ...as much as AppKit. Everything is layerbacks. Even when the density was such where they needed a sub-pixel add-on type of thing, and besides, you could take it to a device and it would break anyway. But AppKit has all of these affordances to account for its history, and to account for the variability of hardware. Do you think if you bolted everything that was required of AppKit into UIKit, UIKit would be as straightforward and effective as it is now?

Paul: That's a good question. They definitely added on stuff to UIKit. Like you mentioned before, the text system for UIKit was very basic at the start, and they seem to have done a pretty good job of putting in functions throughout the different iOS versions to improve that and make it more like what you can do on AppKit. I think if they did it right, if they took their time, it definitely could be done in a way where it wouldn't be this ugly behemoth that didn't make any sense. It would take awhile, and probably, five years from now, we're all going to be complaining that UIKit is now not the cool stuff because some other kit came out for some other Apple device that has yet to be dreamed of.

Guy: The Twitter app, like Loren did a cross-platform, UIKit, sort of thing, and Sean wrote Chameleon, which was their sort of UIKit on the Mac thing, how did you guys approach the same problem, point a Twitter client from the iOS to the Mac?

Paul: We used AppKit, believe it or not, as much as I don't really care for it, and this was, actually, mostly my decision, which was maybe a bad decision.

Guy: I don't think so.

Paul: But, we wanted to make sure we could use the text system, and all that good stuff that AppKit provides, but on the other side animations aren't as smooth as they could be, and we have to deal with layers causing problems in some places where they don't cause problems on UIKit doing those same type of things. There's no UIKit-clone framework for Tweetbot, it's all AppKit-based.

Guy: There are two approaches to writing cross-platform UI code. At one point, and I'm sure you know this, NeXT used to run on Windows, so you used to be able to compile it. You'd have all the Display PostScript and all that, and it would fake drawing the windows inside a Display PostScript context.

Paul: Yellow Box?

Guy: At one point they were shipping it, weren't they?

Paul: I don't know if they ever actually did, but maybe they did. It was awhile back.

Guy: Before the Apple XGeN, right?

Paul: Yeah.

Guy: I thought you could compile NeXT stuff onto Windows NT. Whatever.

Paul: They used to have the OPENSTEP that ran on four different hardware platforms.

Guy: That's probably what it was.

Paul: That's different from what I think was Yellow Box.

Guy: I do know that if you'd look in the headers, maybe not now, but in earlier OS X releases, there was an NSWindow, Windows extension. There'd be an "ifdef" and there'd be an "hwin" to get a Windows window-pointer out of your NSWindow thing. There's that approach, where you basically just plunk your kit on top of some other base APIs. Then, there's the other approach where it's, "I'm going to rewrite the UI later." It seems like you took the latter. Is that out of experience, or is it just because you felt that going with the platform UIKit would be easier than fighting against it and trying to impose your own UIKit view?

Paul: As much as I don't care for AppKit, I think it's the least-worst choice to write an application in for the Mac, because it is the native UI for the system. I don't like applications that are ugly ports from other platforms, like Java-based UIs and stuff like that. We're big believers in making the application feel right for the device, for the operating system. It's one of the reasons why we won't port to Android. We're not going to take our UI and our feel and just move it over there and have it run the same way, because it's just not something that we feel is the right thing to do, as people.

Guy: I think that goes back to what you were saying about the Convertbot and the iPhone 5 screen, in that you designed that app very specifically for a certain-sized screen, and now that it's changed, it's problematic to recapture that feel on the larger screen.

Paul: We could definitely stretch out the top and the bottom but does that really make any sense? Is that something that we would be proud of?

Guy: You could just give it a big Imax-style chin on the monitors.

Paul: That makes it somewhat tough, that we care so much about how these apps work and feel. Where if we'd used something like TWI or Chameleon, maybe it would have made the process of porting a bit easier, but are we then losing out on some of the nice things that AppKit provides that are behind the scenes and that you just subliminally notice?

Guy: Stuff like accessibility. Like when you do your own sort of interface kit, you lose a lot of stuff that comes with the system, like being able to select text and run a service on it, maybe. Weird, little things. Like, edge cases that just drop away.

Paul: Right. Then, as Apple upgrades the operating system, new features probably don't work quite right, if you're using those things. A perfect example, going back to the twUI, it's all fuzzy now. Why is it fuzzy? Because it's using their own UI, crazy layer-backed stuff that's not AppKit. When they moved to the retina screens, it wasn't ready for it. Now the app looks fuzzy to everybody.

Guy: I'm sure that bugs Lauren, but I didn't want to ask about it. [laughter]

Guy: It's not his problem anymore.

Paul: I'm sure that's something that could be fixed in a fairly simple manner, but if it was written with AppKit, it probably would have just worked.

Guy: Exactly, You were saying that five years from now, maybe there will be some other kit that we all wish UIKit worked like. You've been doing NeXT stuff for a long time now. I've been working in the field for 6 years. I've been doing it for maybe 15, doing programming on the side and doing tools for work and all that. Do you ever worry you're going to get blindsided by a different platform?

Paul: No, I don't. A few years back, before the iPhone came out and the Mac stuff was waning or at least not as popular as today, I spent quite a bit of time doing Ruby and Ruby on Rails type of stuff. I'm not terribly worried about it. If it, for some reason, dies out, there's always something else I can jump into. Fortunately, I really like the Mac stuff, the Objective-C libraries, and think it's the best stuff out there. It took a while, but at least the last five years, it's been really great.

Guy: Definitely. It used to be, and this was a different time too, there were more operating systems around in general. I don't want to say I experimented in my youth but... [laughter]

Guy: I used to use OS/2 and Windows NT and Classic Mac, and that's how I came to find out about all the NeXTSTEP stuff and all that. These days, I find myself, because I work and I work on Apple technologies. I sometimes wish that I would go and maybe check out what it's like to program on Windows Phone 8. Every now and then I'll go read through the docs, but I don't actually practice it. Is that-that's not something you care about. That's just...

Paul: If any of those platforms besides the Android actually take off in some way I'll definitely take a look at them. I refuse to look at Android just because I have a rational hate of Java and all things Java related. But I certainly, if Windows 8 sold more than a couple phones a week I probably would be interested in taking a look at it.

Rene: On the flipside, some people like John Syracuse have been critical or maybe hypercritical about objective-C and its future when compared to the higher-level languages and the way that you can develop for more, I don't want to say more modern, but more recent devices. Maybe like Windows Phone or maybe some of the stuff that Microsoft is doing with C#. Do you see the same kind of limitations in objective-C and are there directions that you hope that Apple takes it beyond what they're doing now?

Paul: I really like the way, actually, Apple has been handling objective-C where every year they're making some significant but not overwhelming change to it. They've recently added the whole, what was it? The new memory stuff?

Guy: The boxing.

Paul: Boxing, but the new memory stuff, what's it?

Rene: ARC.

Paul: ARC. Yeah. In there, which really changes a lot of how one writes an application.

Guy: Have you ever-sorry. Have you seen apps been using that?

Paul: Nope. Nope. I mean it would be nice to, but it would involve a lot of going back and changing classes that have been working for years now. It's not something...

Guy: I can't stop writing retain release, like I cannot do it. I've got to break that habit, but... Anyways, sorry Craig [inaudible 55:22] , go on.

Paul: It's not something I have a problem with myself, since I've been doing it long enough that I can retain release in my sleep. But it's great for new developers. On the other hand they added block recently which I used pretty much all over the place. I've even almost got the syntax memorize for how to write a block without copying and pasting it from somewhere else. I like the way they're improving the language without throwing it all out and starting from scratch. Which...

Guy: It certainly seems that from '97 to almost 2007 nothing changed and then for the past five years we've been getting pretty big improvements.

Paul: Right. You can almost see it's a yearly cycle and a lot of those improvements they make it so it will run on a previous version of the OS, which is great as well. Is it as fancy as whatever new JVM based languages they're coming up with? Probably not. The language is only half the issue. Even less than half the issue. It's the frameworks that go around and I don't think there's anything anywhere near as mature that works as well as foundation in UI kit.

Guy: You can say that, begrudgingly.

Paul: I guess it doesn't have all the whiz bang features but it's been improving at a good, sustainable pace. If you look at something like Ruby on Rails as a counterexample, they add new whiz bang features to it, to the framework, every dot release and it gets to a point where if you haven't kept up-to-date with each and every one of those releases and you go back and try to update an app you almost have to toss the whole thing out and start over to deal with whatever new features they decided had to be added without any regard to previous working code.

Guy: Incremental improvement without churn. You don't have to toss everything out.

Rene: No rip and replace.

Guy: One thing I find heartening in retrospect, but at the time I was annoyed by it, not annoyed, I'd written a large app using Garbage Collection, which was dumb because it used a lot of graphics, too, and a lot of the graphics stuff didn't end up being properly garbage collected, and then they abandoned it. It was a little concerning. Because under Garbage Collection you could write retain and release and it was a no-op, I'd been doing that anyway because I couldn't break the habit, so it wasn't that much a pain in the ass to switch back to the regular.

In retrospect, I kind of like that because they went a direction and within a year, year and a half, maybe two, they just ditched it and they went to Arc, which I find to be a very compelling argument they are taking the stewardship of objective C and their platform seriously and they won't commit long term to something they don't think will work.

Paul: Yeah. Garbage Collection is definitely an interesting edge case where, for whatever reason, they decided it wasn't working and they just reversed course and went a completely different direction. Fortunately, I don't think it impacted too many people. Like you said, you're writing release and retain code anyway. I don't think I've ever used it.

Guy: Very, very few. Very few third party developers used it.

Paul: It's nice that it's consistent improvements and course corrections, if needed, year after year as opposed to waiting three or four years and tossing in a bunch of stuff and breaking backward compatibility. Everything seems to be pretty compatible with everything that came beforehand.

Rene: Is there a direction you'd like to see them keep going with those iterations?

Guy: I definitely would love to see blocks just everywhere. Go in and make sure that any operation that takes any amount of time has a completion block. Stuff like TableView updates. When you go in and you do some animated UITableView updates, there really should be a completion block so you know, "Hey, we're done with the graphical side of this." If you need to do something else, continue on. I love to see them just making sure, "Hey, everything any kind of animation, any kind of long-running operation, has some kind of block or some kind of call back to it." Also, the GCD stuff is awesome. I love to see them keep going with that, making sure it's more well-defined.

When you make a call using GCD, you should know, "Is it coming back in the same thread that called it? Is it coming back in a different thread?" have all that stuff documented. I love to see that stuff happen.

I've been playing, like I said earlier, with iCloud this week. I'd love to see them improve those APIs. They're currently way too hard to use, at least the document-based side of iCloud.

Guy: Are you using the UI document stuff, or are you using the stuff from Foundation that UI document builds upon?

Paul: Right now for Tweetbot and Netbot we use the key-value style API for...

Guy: That in my experience works reasonably well.

Paul: When it works, it works reasonably well. The API is certainly very simple to use. It's great for what it should do. It sometimes, for whatever reason, refuses to work.

Guy: Can you explain a failure case to me?

Paul: It just doesn't work. [laughter]

Paul: The API is very simple. You set a value and you read a value. When you set the value, it should go up to the Cloud.

Guy: I'm trying to think, there's no...Do they have an error reporting API on that? I don't think so. It just looks like user defaults, right?

Paul: Yeah, it's literally a copy of user defaults with some notifications of when things change. For some reason...

Guy: There's no way to query for an error, and there's no notification that you get an error.

Paul: Yeah, and I literally have some devices that it just refuses to work on. I'll set the value. I can watch the traffic coming out from that machine. It just never goes up anywhere. It just stays there. You have no idea, obviously as a developer, you have no idea that anything wrong is happening, because you get no call backs or anything.

Guy: You think it's on the back end?

Paul: No, it's definitely on...There's probably back end problems as well, but this is definitely on the device itself. I'm watching traffic to and from it. As I set a value, it just won't go anywhere. It just stays on the device. There's no network call out to the iCloud servers doing whatever they do.

Guy: Is this some kind of timeout thing?

Paul: No, I just...

Guy: I don't know. I'm trying to debug your [inaudible 01:04:10] .

Paul: I've sent tons of logs over to Apple, but still haven't gotten a response of what's happening. It's been happening since 5.x, it's not a new 6.0 type problem. It's just [inaudible 01:04:26] API for whatever reason, sometimes on some devices, refuses to work and then, once in a while, it will start working again on the same device for no rhyme or reason. It's probably the number one support issue we have with the Tweetbots is sometimes iCloud stuff doesn't work.

Guy: It's frustrating because it's not something you can dig into and fix. That's for simple API.

Paul: The document-based API is much, much more complicated. It does seem to work more reliably, though, for whatever reason. It's very complex API-wise. There's a lot of different failure cases that you have to handle. Everything is asynchronous and some of those asynchronous operations don't have call backs to them, or not, at least, easy call backs. It's just much more complex of an API than I think it should be. It probably explains why so many people have problems with it.

Guy: If you can say, which Apps are you using that in?

Paul: We're actually looking at doing some stuff in Calcbot with that.

Guy: Oh, interesting.

Paul: For example, it would take the tape on one device and synch it across multiple different ones.

Guy: That's cool. That makes sense.

Paul: Once we have that working, we'll probably go in and look at getting it working on Tweetbot for stuff like graphs, as an example, where your graphs could by synched between different devices, where it's not that thing where you're possibly talking about, "Yeah, 140 character graph, that's no big deal," but you an image, or several images, that may go along with it. That stuff doesn't really fit into that key-value API that's simple to use. You need to do something like the document-based API where you're dealing with large files.

Guy: No, I think that's exactly the right thing to do. They call it the [inaudible 01:06:56] API, right? Just the idea of having all your drafts transparently everywhere that you've got Tweetbot seems like a great idea. Oddly, I don't think anybody's going to....

Paul: [inaudible 01:07:05] pretty complex.

Guy: I'm sure. I'm sure the amount of work you put in, you'll not get enough kudos. People will just notice that the draft's there and they'll be like, "Oh, cool." You'd be a month of blood, sweat, and tears to make that work.

Paul: Yeah, it's been a good week, plus just getting this tape going back and forth between different devices. I ended up rewriting it three or four different times just to deal with different API issues/limitations.

Guy: What's your policy in terms of supporting the most recent operating system? I ask that because let's say iCloud never gets fixed on iOS 6, but for some reason it works on iOS 7. Would you just move to iOS 7? Would you limit that feature to iOS 7? What's the policy?

Paul: My overall view is that you should support the two latest major OS versions.

Guy: Yeah, I think that's common.

Paul: I think Apple's actually almost forcing you to do no more than that. You can't build an App for the iPhone 5 that works on 4.1. The 4.2 SDK stopped supporting deployment for iOS 4.2 and earlier. Something like that. Apple's almost forcing you to only do the most recent two OS versions, under iOS.

Guy: Yeah. With iOS, they're definitely dragging everybody along. Users and developers alike. They're just dragging people along. I think they see each device as having a two year life span. Maybe not the 3G. That must have been longer. But sorry, I cut you off. Go ahead.

Paul: You can probably count on two years of updates, up until the point they stop selling that particular device. I would expect, actually, the 3GS to get at least iOS 7, possibly iOS 8. But I wouldn't expect much more than that.

Guy: I'd be surprised by iOS 8. Only because I think they'll just be... [inaudible 01:09:39] .

Paul: That one is an edge device. It's been selling for so long. But I definitely think you shouldn't expect much more than two years worth of updates from the time they stop selling the device.

Guy: That makes sense.

Rene: The thing that's interesting with Apple is that it has so few features of iOS 6, but it still supports iOS 6. Apple's point of view is that it wants it to be binary compatible, so that when you write apps against iOS 6, those can all run on the install base of iPhone 3GS devices. When you look at things like Windows Phone, which loses binary compatibility after one generation, that becomes key for their market.

Paul: The Windows stuff is kind of ridiculous, at this point. They're still selling the Nokia something or other.

Rene: 900.

Paul: And then three months later, it's obsolete. Because it won't run Windows Phone 8. What are they thinking? Android's even worse than that. It's nice that Apple has a fairly consistent story there.

Rene: For a user, yes they're upset they don't get Siri, for example. But if they couldn't bind new apps, that becomes a big problem, especially for a device that was being sold, up until fairly recently. The binary compatibility is the layer that they try to move forward the most.

Guy: Paul, we talked about AppKit, UIKit and iCloud. All of these things, basically, are under one guy. They're all under Federighi now. Do you think that makes a difference? Do you think we're going to see more cross-pollination or a tighter coupling of this stuff?

Paul: I have no idea. To me, the whole way that Apple works is a black box. I certainly have no inside knowledge of what happens there, other than every year they come out and announce cool features or not so cool features, as the case may be. I hope they start getting a little more aggressive with iOS. The last couple versions have been somewhat lackluster. The devices have gotten better and better, but the OS, I won't say it's getting stale. But it could use some cool new features, here and there. I'd love to see apps being able to tie in to Siri somehow.

Guy: I looked at that. That's really hard to do. Do you just mean launching them? Providing a service is tough.

Paul: Yeah. But there's got to be ways to do it. I don't know enough about how Siri works down low and that kind of level, to be able to say what can be done.

Guy: The problem is disambiguation, basically. If you just put a list of keywords in your PList and you've got three apps, you've got Twitterific, Tweetbot and Twitter for the Twitter app, what happens when you say, "Send a tweet," or, "read my replies to me"?

Rene: "Do you want to send that tweet to Tweetbot, to Twitterific or to tweet, press the button."

Paul: You could set a default service. You can have a default mail service, like you do on Mac. I don't see why you couldn't have that on...

Guy: It's an interesting problem to look at.

Rene: I still think though, they're doing that as partner plays. They're not going to give out the revenue they can get from brokering deals with the Yelps and the Ticketmaster companies, just to provide a free way for apps to do it.

Paul: Possible. But if Google goes in and starts opening that up, they might not have a choice. If some other operating system starts integrating those cool features and they're not, just because they might lose some revenue, they're not going to stand for that.

Rene: The bigger problem with the Siri stuff right now is, for example, Google's doing on-device voice parsing, which makes the experience much faster. Anything that doesn't have to go to the cloud doesn't go to the cloud. I can set an alarm. I can do all sorts of things and never have to worry about the cloud being a point of failure. Siri sends everything to the cloud, still. Google Now is also doing all the predictive stuff. Where it knows where you are, it knows where your appointments are and it starts providing information, even before you ask, where Siri is still a query, response engine. They're already falling behind in several of those areas that Google excels in. They should get a move on on that stuff.

Paul: Yeah. That's what I said. I would hope that the future OS's are going to be a little more aggressive with cool new features that we can't even imagine today. The last few versions haven't quite done that.

Guy: Yeah. They've solidified a lot of stuff, but they haven't really leaped forward in any way.

Paul: For iOS 6, what were the killer, must-have features. Maps, I guess.

Rene: The kids got Facebook, Paul. Come on.

Paul: Yeah. That's true. More account stuff, which is actually pretty nice but will take a while to go through all the different applications to start using that stuff.

Guy: Where do you sit with the Twitter integration in iOS? Does that help you at all? Does that run parallel to you? When they start introducing things like Twitter integration, Facebook integration, built-in reading lists, are those things that you look at to add value or do they take away a layer from your business?

Paul: All that stuff they've added is great. Especially being able to launch Tweetbot on a new machine and not have to enter in your passwords, because it's using the Twitter integration stuff to get all that, is pretty cool. None of that stuff has impacted us in any negative sense. I'd love to see them add in the reading list API, because right now there's no API for it, on iOS. We keep getting requests for that.

Guy: It seems like a gimme. It seems like they could implement a URL scheme and just make it work.

Paul: They added it into Mac OS. It's a little bit hidden in there.

Guy: They did?

Paul: Yeah. It's in there. I didn't know about it.

Guy: Where? [inaudible 01:16:31] workspace or something?

Paul: It's in the sharing API.

Guy: Oh wait, I did see that. Sorry.

Rene: One of the things I also wanted to ask you about is that you've resisted doing in-app purchases. A huge swath of the iOS economy has gone into in-app purchases. Some people have done it in Twitter applications for multiple accounts or to get rid of ads. You basically buy Tweetbot, you get Tweetbot. Was there ever any discussion about, "Hey, we could do photo filters or make mute filters an in-app purchase"?

Paul: No. Not seriously. The one area where we talked about it was for push notifications. But we were able to...

Rene: Because of the server expense or because you thought that it would drive...

Paul: Because of the server expense side of things. We thought it would be a lot more involved, cost-wise, then it ended up being. And it would have been if I'd outsourced the push stuff, which was our original plan. But then I ended up just writing it all, writing it on server. It's a point where it doesn't cost enough to justify charging an IAP for it.

Guy: I imagine you have a lot of traffic on that. But you don't need a big, heavy-duty?

Paul: Yeah. I want to say we're almost to our billionth push notification. Some time soon.

Guy: What are you running on, a 386?

Paul: No, it's a Xenon. I don't know. Something we rent.

Rene: It's not a hacked Xbox. Paul No. But it's not a crazy machine either, with 36 cores or anything ridiculous like that. It's a normal-sized server that is enough to handle the traffic and then some.

Guy: So unless you're doing Tweetbot level traffic, you're fine with just a basic server to handle push notifications?

Paul: We were even fine with a basic server.

Guy: That's good to know.

Paul: At least the way we're doing it, it's not that intensive of resources.

Guy: Yeah. What are you, using Web Objects?

Paul: [laughs] I used to really love Web Objects.

Guy: I know. I was talking to Lauren about it last week. I wanted to bring it up with you, because you actually did it, professionally.

Paul: Until they switched to Java and then I almost immediately lost all interest in it.

Guy: Did you hear last week's show? Lauren got Objective-C running on servers.

Paul: It's doable. The server stuff, I just stick with Ruby, just because it's pretty easy to use on there. But yeah, a while back Web Objects would run on servers and was Objective-C based and was all fun to use.

Guy: Yeah, it used to be awesome.

Paul: Then they started doing Java wrappers around Objective-C classes and all sorts of crazy stuff. Now, I think they should just take it out back and shoot it.

Guy: They have, right? It doesn't ship anymore. They still use it, but nobody else does.

Paul: Nobody uses it, but something still exists.

Guy: The store. iTunes Store runs it and a bunch of their other stuff uses it. The Apple Store uses it.

Paul: And their iTunes Connect back-end still uses it, which is probably why it's so bad.

Guy: Probably. [laughs] Wait, just fact-check me from last week. I said that they moved to Java because they wanted to run on app servers. There was something about cross-platform, right? You would know. I fumbled through it.

Paul: The reason was that Java was becoming really big, back when they made that choice. Objective-C, it was a lot harder to find developers who knew the language. At that point, I believe Web Objects was their big product. They were charging...

Guy: It was like 999 bucks or something.

Paul: No, they were charging more than that. I think they were charging like $50,000 or something like that. It was their big, money-making product. They probably had a bunch of corporate clients who said, "We can't find Objective-C guys. This is great, but we only have Java developers. We can find Java developers. Port it over to Java for us."

Guy: The irony now is there's like 100 WebObjects guys in the world that know what they're doing, and that's about it.

Paul: Yeah.

Guy: Oops.

Paul: Ruby on Rails works, or one of the offshoots of that works well enough that there's no point in going through the whole craziness that is WebObjects at this point.

Rene: The iPad has now gone smaller. You were wondering if at some point Apple would go bigger. Is that an actual problem that you would like them to solve?

Paul: No, I don't think they're going to go bigger. I actually more meant it's possible that the 10.1 inch iPad Maxi goes away, and they go and focus on the smaller one instead. At least from my personal experience, I much prefer the new, smaller one from a carry-around, play-with standpoint versus the old one. The only thing I prefer on the older one is browsing the web because of the bigger screen. Other than that, it's like this lumbering dinosaur. I compared it to the MacBook Pro 17 inch, where they just got rid of it.

Rene: The battleship

Guy: I watch a lot of video on my iPad, so I prefer the larger. It's like a portable TV for me. I'll go sit outside on my deck and watch TV on my iPad, so I prefer the larger one. I was not going to buy a Mini on account of the one X screen, but then when I actually saw one... It's pretty good. It's really good. I'm pretty sure I'm just going to go out and buy one as soon as I get my druthers together to do so. I do agree that it feels amazing. The build quality is great. The screen is way better than I thought it was going to be.

Rene: It feels like what's next.

Guy: I agree with you, Rene. You had a piece about not expecting a Retina screen, and I wouldn't, for at least the next rev.

Rene: It's one of those things that Apple's still bound by the laws of physics and the laws of economics. If you put a Retina display on it, it becomes an iPad 4. For people who don't want to carry a laptop, the iPad 4, the large size iPad Maxi still makes a lot of sense because it gives them a lot more area to be productive with, whether it's using the iWork apps or it's typing or anything like that. But if you have a ton of other Apple and iOS devices, the Mini really is a sweet spot now.

Paul: We'll see how it progresses. The MacBook Pro 17 had a lot of fans, me included, but it went away too even though they could probably still sell them today. They just sell so many more of the smaller devices. It'll be interesting to see. I definitely like the Mini better with the exception that I wish it had some more memory in it, like the newer iPads, the 1 gig versus the 512. Other than that, I don't miss Retina. I don't really miss the extra speed that the iPad 4 has.

Rene: It feels more like a mass-market device. When you hold it, it feels like that next breakthrough product.

Paul: I just wish it was a bit cheaper, but what are you going to do?

Guy: Wait a year. [laughter]

Guy: What do you want to see? Either in terms of software, besides killing AppKit... [laughter]

Guy: ...or hardware, is there something that you're...That sort of fanboy, Apple insider, I'm going to refresh the page until I read all the rumors on this kind of thing. Is there something you're excited about coming up or are you just pleased with the current iteration?

Paul: I'll answer that with two different hats on. From my business person hat, I would love to see cheaper iOS devices. I want to see the better iPod Touch, the 32 gig down to the $200 mark. I would love to see the iPad Mini down at the $250 mark. From my geek hat on, my personal hat, I'm really excited to see a 16-core Mac Pro with modern insides, as opposed to the current two-, three-year-old version that's out there.

Rene: You'd stick with the Mac Pro and not go iMac?

Paul: Ew, no.

Rene: [laughs]

Paul: No, I run a Mac Pro now. I'm not going back to those little, slow iMacs.

Rene: [laughs]

Guy: You know what? I did that for years. I was always on the Pro side of stuff. Then I bought an iMac Core i7, one of the earlier ones, because my Mac Pro was dying. It was old, and there was no update in sight. I figured, "Well I'll buy this 27-inch iMac," with a Core i7 and I forget what else. "I can use it as a screen when I eventually buy my new Mac Pro." But the iMac was just fast enough, and it was awesome, and I kept using it. I'm not sure I would go back to a Pro.

Paul: It is fast enough, but once you're running with the old 12-core Mac Pros, which is what I run, and you stick a bunch of SSDs inside, and... [laughter]

Rene: Some racing stripes on the back.

Paul: Put a couple monitors to it. I don't necessarily need it, but I really like it and want the latest and greatest and even better version that comes out next year.

Guy: Can't blame you for being into hot rods. Rene : Jardine has the cars. You have the computers.

Paul: He definitely...I still drive a 10 year-old minivan. [laughter]

Paul: I'll [inaudible 01:27:41]

Rene: It's got the racing stripes though.

Paul: No, but I actually got a bunch of paint on it from the side where I scraped against the garage. [laughter]

Paul: I'll spend the money on cool toys and hardware, not car stuff.

Rene: [laughs] Car stuff. If people want to find out more about you and more about Tapbots, where can they reach you?

Paul: Go to tapbots.com or follow me on probably best App.net these days, and @pth is the user name.

Rene: You went for a different user name on App.net than Twitter.

Paul: Definitely shorter, and I like the pth.

Guy: Got to go with the three letter [inaudible 01:27:40] .

Rene: Guy's a huge fan of the three letter name.

Paul: It's much easier to type, and you can reply to more people with the shorter names. Longer reply tweet or post.

Rene: Guy, where can we find you?

Guy: I'm @gte on Twitter and App.net, and my website is kickingbear.com.

Rene: You can find me @reneritchie or you can find me on iMore or just look up Debug on iTunes and subscribe. Paul, thank you very much for joining us. That was awesome.

Paul: Sure, Renee.

Guy: Paul, it's been great. Thanks a lot.

Paul: Nice meeting you, Guy.

Guy: You too. Take care.

Debug 2 transcript: Paul Haddad of Tapbots

Guy English: Hi, my name's Guy English, and this is the second episode of Debug.

Rene Ritchie: I'm Rene Ritchie, and joining us today is Paul Haddad from Tapbots, who you might know from a fine collection of small, automated iPhone apps like Waitbot, Calcbot, Tweetbot, and now Netbot. How are you, Paul?

Paul Haddad: I'm all right. How about yourself?

Rene: Very good, thank you. The way we usually like to break the ice, get started, have the first round poured is to ask you how you got involved in Mac / iOS development.

Paul: You have to go back...Oh God, it's a little bit over 20 years ago, when I first saw a NeXT station. I was in college at the time and went into their bookstore / computer store thing, and I saw one of the black and white NeXT stations. I started playing with it, and I knew I had to have one. Begged, borrowed, and stole and got one. Pretty much started coding on them from there and followed that throughout my career.

Rene: What was it like coding on a machine like that back then when it wasn't the biggest, most popular brand on the planet?

Paul: It was interesting. Unless you consider it turning into Mac OS and iOS, it never really became popular at all, but it was definitely better than anything out there from a user perspective, which is where I first got into it. There was nothing else like it. There was high-resolution display, multi-tasking. All the stuff that we take for granted now didn't exist really back then unless you were talking about really, really high-end workstations. This was the first operating system where it was friendly, easy to use, and a complete package.

If you went and you looked at the little Macs back then with their little, tiny screens and the PCs with, I don't even remember, VGA graphics or something ridiculous like that, this was a completely different experience. It's very much like what we're used to today, although obviously a lot slower back then.

Guy: When I was doing prep for this show, I went on the Tapbots site, I looked you up, I read a bunch of your blog posts, and everything. I ended up back at an old site with your resume on it.

Paul: [laughs]

Guy: One of your first gigs that you list is writing an object-oriented wrapper that worked on NeXTSTEP and Windows 3.1.

Paul: That was actually my first real job. I didn't...

Guy: That's crazy. Sorry, just for the audience, Windows 3.1 is a segmented memory model 16-bit, and NeXT is like an actual, modern operating system. That's a big challenge.

Paul: Yeah, it was way back...To be honest, I didn't write the wrapper. I just had to work with it. A consulting company came up with it for a small company. The kind of stuff you'd never see happen, I would think, today. It was for something really boring, reinsurance contract management. Compared to coding for Windows, it was so much easier and better stuff to do. [crosstalk]

Guy: I'm sure. It shocked me, the difference between those two platforms and that you would try to support them with one approach.

Paul: If I recall, and this, like I said, was way back then, the coding would happen on the NeXT machines, and the executables would run on Windows. It used the Stepstone compiler and all sorts of craziness. It was an interesting time. [crosstalk]

Guy: Yeah, a little bit. So you ended up doing contracting a few years and then finally got into iOS.

Paul: Yeah. I had real jobs, contracting jobs. At some point I decided that I just don't like going into an office and just went that route where I would mostly do contract work for different companies. Golly, four or five years ago, I don't even remember, the iPhone first started, they first started letting people write applications for it. Mark [inaudible 05:154] , my partner, and I were both working at Oakley and we were just in the middle of some big, hairy project. It was a Sunday or something like that and we were both really burnt out, talked, and said why don't we create an application? Went back and forth on it a little bit and decided to do something simple to track our weight, or at least that we thought was simple back then, and went back and forth.

Somehow WeightBot and TapBot was borne out of that.

Guy: Were you into the Jailbreak scene at all? Were you excited when the phone itself came out or were you more into after the SDK got released?

Paul: Neither. I didn't buy the phone when it first came out. It wasn't so much that the phone wasn't cool, which it certainly was. I'm kind of cheap and I hate paying for recurring services like data plans and things like that. I was perfectly happy with the cheap, pay as you go phone. I kept that until I couldn't do that anymore.

Guy: What was compelling about the iPhone? Or was it just that time marched on and you figured that you didn't want to get left behind?

Paul: Once I actually got the phone and the API was actually opened and I got to play with it a little bit it definitely was cool. Before that, certainly it was something that I was keeping an eye on but I just didn't feel the need to get one, which is strange because I've gotten every single device since then.

Guy: I've got a giant stack right next to me.

Paul: Yeah. I've been doing some iCloud stuff this week and I have like six different devices hooked up at the same time trying to deal with conflict management and all that fun stuff.

Guy: I'm sure. If it wasn't 11:00 AM I'd send you a beer or something. Why WeightBot? I have a line of questions about the whole bot theme. What was the initial impetus behind WeightBot? Was it because it was simple and you thought you could do it? Was it like scratching an itch kind of thing?

Paul: I could be totally wrong on this. It was probably because I was trying to lose some weight and I wanted something to track with it and we figured, like I said, it would be a fairly simple app. You put in a weight every day and keep track of it, or at least it would have been simple before Mark got his hands on it and came up with this insane concept of a robot with noises and all sorts of flicking actions.

Guy: Which is now the TapBot's trademark.

Paul: Correct. If it would have been a real simple weight tracking app, it never would have gotten anywhere. As much as I may make fun of him for coming up with crazy stuff, it seems to work for us.

Guy: I think I bought it the day it came out purely, not purely, largely because of the design and the attention to detail and the approach to it. That TapBot aesthetic has worked well across your entire line. It's branded you, not just with sticking bot at the end of everything, but it's down to the icon, it's down to the look and feel of the applications themselves, that metal look. It's very opinionated.

Paul: Yeah. We've actually talked about should we do an app without that branding, for lack of a better word, but we just haven't yet because it just works for us. Especially these days, getting anything going in the App Store is very hard. We found something that works for us, so do we stick with it, or do we go crazy and do something completely different?

Guy: Yeah. I'm sure I've said this before. Not to your face, though. [laughter]

Guy: It's a little heavy for me, it feels like. Like a little bit overwrought, especially with the sounds and all that. I love the attention to detail. It's amazingly well implemented, it's beautiful. I love it for what it is, but it feels a little bit heavy for me. That said, TapBot and Tweetbot and Weightbot, I basically use them all multiple times a day, all of the time. You're certainly not losing a customer. It's not really detracting from my experience at all.

Paul: We've heard the heavy comment often.

Guy: I feel like maybe I'm being an old man. I feel like maybe Delicious Library came out, and I'm grumbling because it should just be a list view or regular icon view, rather than being the bookshelf. I feel maybe I'm getting a little bit overly conservative.

Rene: Is there a line between...You have an incredible design language. It's a very good differentiator for you, can instantly tell a Tapbots app, but at the same time, you now carry that design with you everywhere. It might be a mixed blessing for you sometimes.

Paul: Yeah. Like I said, we've talked about doing something different. We just haven't quite gotten there yet. Everything we've looked at has felt right going into this same look and feel, for whatever reason.

Guy: Mm-hmm. Definitely everything looks correct. I can open up any Tapbots app and feel like this, it's a consistent work of art. Every attention to detail has been paid, and the little characters all fit in. Everything's great.

Paul: It's interesting to see. In the last version of Tweetbot, we made some changes in the icons which was supposed to make it a little bit lighter. We get a ton of people saying they love it. We get a ton of people saying they hate it. It's like, "Argh," you know?

Rene: You've almost made the apps into characters for people. They're getting an attachment to it because of the identity you've given them.

Guy: I think it's a great idea, by the way. Definitely character-driven apps are...

Paul: You've got to do something to stand out in the marketplace, right? There's thousands of apps released every week. If you don't have something that stands out, it's just going to get buried.

Guy: Oh, yeah. The fact that you can cross play the brand is amazing. I love that when you launch a Tapbots app, it's got the serial number stamped into it. It's great, great little touches, you know?

Rene: It's interesting. I don't want to bring up the skeuomorphic word, because it's horribly overused. Weightbots could have been a very dry, very list-driven app. There are hundreds of those kinds of apps, but you made it fun. You made the actual usage of the app an enjoyable experience, which makes you want to use it more often.

Paul: Right. That was definitely the plan for Weightbot. It's kind of boring to track your weight. We wanted to do something where it would make it somewhat fun, where you'd feel a sense of accomplishment putting in your weight every day. That's where that all came from.

Guy: Would you say that Convertbot is the one that goes furthest along that access?

Paul: Yeah. I think we both feel like it may have gone a bit too far in that direction.

Guy: Because of the dial UI?

Paul: Yeah. The dial, it's great and it's fun, but it's not the most efficient way to pick currencies to switch from. It's kind of a tricky one. Especially now that we have the iPhone 5 coming out, stretching that app just doesn't seem to work right. It doesn't feel right because it's so heavily around that wheel, and the wheel is tuned to the screen ratio of the original iPhone.

Guy: Right. Just for listeners who haven't seen it, it looks almost like an iPod click wheel that you can turn around and dial your different units, and press the middle button to select them.

Paul: Right. If you want to go with the UI heaviness, that's probably one where we may have gone a little too far.

Guy: I'm pretty sure you guys put out a blog post explaining exactly how you did this, or at least the iterations you did to get to it. From the nerd perspective, I find that really fascinating. [laughs]

Paul: Yeah. That was all Mark, I guess kept notes during that design, and showed how the wheel came to look or why those dimensions were chosen and all that good stuff.

Rene: What's it like for you when you get some of these designs back from Mark, and you have to implement the physics, and you have to implement the scrolling? You have to make what he designs feel...I can't say real world-like, but feel correct on an iOS device?

Paul: Sometimes I'll just look at it and just shake my head, and curse him out in my head and go, "Ugh, how am I going to implement this?" It's always interesting to see. We'll often go back and forth once he does come up with a design, with me saying, "This is impossible." Or, "This is going to take to long to do, and can we switch this around?" Kind of go back and forth a while to try to figure out just exactly what we can do with those designs.

Guy: I think it really worked for you, because you're one of the few teams that I can think of, small teams that works so consistently well together. Every app is very polished. It's not very sharp edges. Everything's very consistent between app to app. You have a company voice that is very distinct. Given that there's two of you, you'd think that it could go one way or the other sometimes. It seems that you guys put out what you wanted to put out. It doesn't seem that you...Not half-assed stuff, but it doesn't seem that you haven't been happy with any of the stuff that you've put out so far.

Paul: Yeah. I think a lot of that is how we work. We try to keep to our areas of expertise. I can't draw a circle to save my life. Mark can't code, and so we try to keep our responsibilities separate. Anything design-related, even if I don't particularly agree with it, it's Mark's decision to make. That seems to work well. We'll collaborate together, but at the end of the day, design is his area. The user interaction is his area. He has the final say on that stuff.

Rene: What happens when you're working on something like Netbots? You already have Tweetbot on both iOS and iPad, and then you're bringing out Netbot, which is a variant of that, it's still going to be iPhone and IPad, but now you're doing a different service and you're hitting ADN. Is that challenging? To keep an app sane on two different platforms, and then two different services as well?

Paul: It will be interesting to see as it progresses. The apps were separated once I started working on that Netbot. It's not all the same code base. Obviously one was copied from the other and then I went in and made all sorts of changes to get Netbot working on the different service. Fortunately a lot of it was architected purely by luck, so that it was some what easy to switch from the different services. It will be interesting to see as it progresses.

I've been making changes on one, and then going to the other, making the same changes there, keeping up that way. It will be interesting to see as both services and both apps fork more and more away from each other.

Guy: It's not like a shared library that you use between the two?

Paul: Well, we definitely have a common library that's used between all the different apps that have generic classes that we use. Like, our Alert Panel and our different types of buttons, et cetera. That's all shared between all the different apps, but the code itself that talks to Twitter, to ADN, the code that displays all the different view's for different app's are completely separate at this point.

Guy: You've been remarkably positive in all of your expressions. Like there's a lot of, and this is not to disparage anyone, but there's two lines of thought. There's one, people either act positive about the app store being screwed up in various ways, or positive about various business things, or people complain. I don't mean that in a bad way. They outline the realities that their business's have to face and point out where things are tough.

You guys seem to have always been positive. Is that a conscious thing, or is that just a personal attitude?

Paul: Probably a little bit of both. Regardless of what happens with the app store and Twitter, we're really just two guys that got together and started a company and were successful at it. We don't have to work for some large corporation doing really boring stuff.

Guy: You're living the dream.

Paul: Yeah.

Guy: You can take a few hurdles, right?

Paul: Right. Nothing that's happened in the past year has been particularly bad. Every year has been better, let's say revenue wise, than the year before. So, there's really not that much to complain about.

Guy: It's en vogue to wail on Twitter, because frankly they've been doing some weird stuff, and that directly affects, what I imagine is, a large portion of your business, but It's water off a ducks back. I read your blog post again last night. You seem very positive about it?

Paul: Yeah. They've definitely said what they're going to say and have made the moves that they're going to do. They could have been a lot worse.

Guy: That's a great attitude.

Paul: For whatever reason they've decided that, at least for now, they could change their minds at any point, that they don't want new Twitter clients coming out. The existing ones, they've structured in such a way that most of the existing ones will be able to continue for at least a couple years.

Guy: Yeah, you've got a long runway, given how early you were on the platform, I imagine?

Paul: Right. So did some of the other clients as well that have been around for a while. It's just new clients, or clients that have just launched that can have issues with that. With those restrictions.

Guy: I just realize we talked to Lauren last week. This is basically the Twitter developer podcast. Maybe we can get Craig on next week. So, Netbot, the App.net client, was because you wanted to do it? Rather than being a reaction to the Twitter stuff?

Paul: Yeah. We wanted to see where the service would go. There's definitely a lot of support associated with doing a client like that, but the original merge port over from Twitter to ADN wasn't particularly difficult. We had a lot of people asking for it, so we figured, "Why not?" We had a Tweetbot for Mac coming out, and I had some time in my hand to do something, so I went off and did that.

Rene: What was that like? You weren't as early as Twitterific or Tweety, so they probably had a more mature API for you to write against. ADN, you were there almost from the beginning. Was there a large difference in writing against those two services?

Paul: The API's are somewhat similar. It actually seems like the ADN-API is somewhat better in a lot of ways. Probably because they don't have a lot of baggage.

Guy: I prefer, looking it over. I've implemented a little bit of both, like what you guys have, but the ADN one seems to be informed. Where Twitter sort of took some missteps.

Paul: Right, but then again, it's a lot easier to do something like that once you see what mistakes made by the previous people coming before you [?] .

Guy: Oh, yeah. I'm not saying that to knock Twitter in any way. You can definitely learn from what other people have done. Do you have a preferred service? Which one do you fire out first, Netbot or Tweetbot?

Paul: I alternate actually between the two. In the morning when I wake up, I'll sometimes do Netbot, sometimes I'll Tweetbot, skim through my timeline and go from there. I don't necessarily go with one or the others, as far as what I first open or last open at night.

Guy: Do you use them differently?

Paul: Yeah. I think at this point, for Tweetbot or Twitter, I'm mostly doing a lot of support stuff. Answering Tapbot's, on the rare occasion answering Tweetbot accounts. On ADN I mostly do my little geeky tech posts, or complain about whatever is bugging me at that particular moment.

Guy: I basically do the same thing too. Except I don't do support. I'm more of a jackass on Twitter. I just crack jokes all the time.

Paul: I didn't say I was particularly good at support. I probably shouldn't do it, and all the Tweetbot stuff. For the most part it's done by someone else.

Guy: You guys have a support guy?

Paul: [inaudible 25:00] guys.

Guy: Right. Sorry. I knew that, Ash.

Paul: Yeah. Otherwise, nothing would ever get answered.

Guy: I'm sure, yeah. With the number of app's you've got, and their broad appeal, I'm sure you've got a lot of people who need support.

Paul: Yeah.

Guy: With that in mind. Does the Netbot stuff have a lower support per user class, than say, Tweetbot?

Paul: Well, it depends. The Netbot users are definitely more advanced than the average Twitter user. Which I think everybody would expect. There's definitely more changes going on with the ADN-API than the Twitter API. So while there's less technical support, as far as answering questions on ADN, there's the other side of technical support. Which is implementing new features and adapting the changing API's.

Guy: Maybe you can't say, but do you work closely with Dalton and those guys?

Paul: Yeah. We'll talk to them, and they've often asked, "Is there any particular API you would like to see us work on next?" We'll ask questions about, "What do you guys have coming up in the pipeline?" They're pretty open with everybody about that stuff too. It's definitely a [inaudible 26:36] experience.

Guy: That's great. Do you ever foresee the net stuff taking over your Twitter stuff? Not in terms of global popularity, but in terms of where your revenue or attention is going to be spent?

Paul: Not at this point. The user base of ADN is just so small now compared to Twitter, that I would expect something else would overtake Twitter and ADN, before ADN overtakes Twitter. We're known for Tweetbot now because we've been focusing on that for the last couple years, but like you mentioned before, we've done other app's and we're going to be doing other app's.

Guy: Do you have any plans? I mean, don't spill the beans.

Rene: Yeah, no spoilers.

Paul: Yeah, no spoilers. We're revising one of our existing app's now with some new stuff. We'll figure out something completely different to do sometime next year. We'll come up with something.

Rene: You do one of my favorite things on ADN and Twitter, where you post some of the support requests you get from people who pirated your apps. And on ADN it's even funnier, because it's such a small user base.

Guy: And they paid $50.00 just for the privilege of being there. I guess it's like $36.00 or something now.

Rene: Is that just for catharsis, or does that actually help you curb that practice?

Paul: No. They don't care. They literally don't care about any of that stuff. They certainly aren't following me if they're pirating the app. At least the vast majority aren't. It's just blowing off steam or having fun with it.

Guy: Does it get to you, or do you just roll your eyes and think [inaudible 26:36] ?

Paul: Well, here's the thing. For the most part I don't care about pirating, other than having some fun with it. Except now when people are pirating the app, it's actually taking away tokens that we only have a limited supply of. While normally I would say, "Those people were never going to buy the app anyway so I'm going to have a little fun with it, but I'm not going to waste a lot of time dealing with it." Now, there's a different situation going on.

Guy: Right. That whole argument that you can make a copy of software and it's infinite and nobody loses anything is out the window, because there's a finite limit of tokens out there.

Paul: Right. So we have to be a little more aggressive with curtailing those limits. Curtailing those guys from using pirated versions of the app, because it literally is costing us potential future money.

Guy: Again, with a very positive tone, you wrote a piece about the pricing of Tweetbot after the token limit came in. Can you talk about that a little bit?

Paul: For Tweetbot iOS, we have a fairly large number of tokens. We've been selling it for, I think, 18 months prior to the new limits coming into place.

Guy: Is that it? Wow, it feels like forever, iOS moves fast, man.

Paul: Yeah, it does. But, if you can imagine, assuming we kept it at the same rate, we'd still have at least 18 months to go after that. Whereas, on the Mac side it's quite different, where fortunately we had that public alpha and beta, we were able to get over the 100,000-token limit before the cutoff.

Guy: That's great. I hadn't heard that. That's good news.

Rene: Was that you being prescient, like you just had a sense that you should get that thing moving faster than you might have otherwise?

Paul: Yeah. We definitely felt like something was happening. There were a few blog posts coming in from Twitter, throughout that time. We just felt that it's going to be a lot harder to shut down a client that's out there than one that's not.

Guy: There was "a tremor in the Force".

Paul: Yeah. But, we definitely didn't have any inside knowledge of what exactly was going to happen, because if we did, we would have structured things a little bit different. We came out, I guess, as well as we could from that situation. But, we definitely don't have an unlimited number of tokens available on the Mac side, and that impacted what we could do on the pricing side of things.

Guy: You charge 20 bucks for Tweetbot for Twitter, on the Mac.

Paul: Yes.

Guy: That used to be a reasonably low-priced Mac software pricing tier. These days you have to make an argument in support of that being a fair price. How do you feel about the downward pricing pressure? I know on iOS, they're not cheap, but they're certainly way cheaper than you would have expected, traditionally, from Mac stuff. Was that a warning to you when you started with Tapbots, or was that something you just rolled with?

Paul: No, because back then, there wasn't this downward pressure. When we first started it was very soon after apps first came out, so there really wasn't a history of what pricing should be for the applications. With the App Store, you would see a lot more volume than anything you would ever see on, the Mac side, for example, back then. The pricing on iOS is what it is. I know a lot of people seem to complain about it. But I think the volume you see on there pretty much overwhelms any of the pricing concerns.

On the Mac side, again, it's a little bit different. I think the big pricing issue on Mac, right now, is Mountain Lion being $20, which everybody compares every other piece of software to.

Rene: Which is heavily hardware-subsidized, that $20 price.

Paul: Right. I almost wish they would have Mountain Lion be free instead of charging that $20, because then you wouldn't be comparing the two. You don't pay for iOS upgrades, at least, not anymore. I wish they would do the same on the Mac side.

Guy: I feel like I've had this conversation with so many developers that putting something at $20 puts an upper-end on the complexity of your software. Everybody can say, "You're not as complex as the operating system, so, why would I pay $20?" It's like an apples and oranges comparison.

Rene: That's their place.

Paul: They make it anyway. When people complain about price, that's the number one thing I would hear is, "This is as much as I paid for the operating system." I'm like, "No, you actually probably paid a couple of grand for the hardware that ran the operating system that subsidized that $20 price."

Guy: What are you going to do, write a long email, "Here's, actually, how the financials break down"?

Rene: "Here's what Numbers charges. Here's what Aperture charges."

Paul: I, definitely, would wish either Apple would make it free, or maybe, just remove it from the top charts. It would give a little more room to other people, so that they don't go and see Mountain Lion for $20 every time they go into the App Store.

Guy: I see them do that for all their apps. I understand why they don't, because I think the App Store tries to be, "Here's just the raw numbers. We're not going to mess around with it." But Top Paid is just full of Apple stuff, constantly, it's impossible to break in. Well, not impossible.

Paul: It's impossible to beat Mountain Lion on Top Grossing. It's undoable. I have a rough idea of what they make there on a daily basis, and it's insane.

Rene: Make Mountain Lion an app purchase for Lion and just get it off there.

Paul: Do something. I would, actually, just prefer it be free at this point. I know relative to any other developer they're making a ton of money every day on there, but, it's got to be beans compared to what they're making on Macs and iPhones.

Guy: You can tell they dropped it to $20 in order to encourage rapid adoption.

Paul: Right. Make it free, and then there's no rapid adoption problem, because everybody's just going to upgrade to it. Make a bunch of developers happy.

Rene: Was there a lot of math going into figuring out the $20, or did it just feel right? Did you go, "There's a scarcity of resources, we only have so many tokens, we have to be able to develop it and support it going forward for X number of years, a bunch of fancy math inserted there, this is the price," or was it more of a gut feel?

Paul: There was some math, and there was a lot of gut feel for, "What's the most we can charge and not lose a ton of customers, and still support the app," like you just mentioned. It was definitely a lot of back-and-forth on what exactly we should charge for the app, because even if we're charging more than we would want to, it's better for the people who buy the app, long-term if we, actually, make money off the app and continue to support it, and don't run out of tokens in a couple of days.

Rene: Different than the iOS version, you actually handed off development of the Mac version. What was that like? A lot of developers say that their apps are their babies, and you gave this one to a babysitter for awhile.

Paul: It's not for awhile, because Todd Thomas, who's working on it, is still working on it. All the Mac code is stuff he wrote. The low-level code that actually talks to Twitter is shared between the iPhone, iPad, and Mac versions, and that's all the stuff that I wrote. But, I just didn't have time to get into the Mac side of things, and spend a year doing that, and still supporting Tweetbot, and keeping it updated. It's just not something one person, I don't think, code-wise could handle.

Along with, every time I start looking at AppKit after having done UIKit for awhile, it's just not something I can handle, for whatever reason. I did it for years before. But after being on the iPhone side for awhile, it's just not pleasant to go back to.

Guy: What's your beef, to be blunt about it? We were talking before we started recording. Paul's been doing this for a long, long time since, basically, the beginning of NeXT, pre-OPENSTEP, right?

Paul: Yeah, NeXTSTEP.

Guy: Pre-Foundation? Pre-NS String, when everything used to take a character pointer?

Paul: It was before NSObject. If you go way back, it was, actually, Object.

Guy: Yeah. It was just Object at that point. NX code and all that? All of the crazy, deprecated stuff you see in AppKit, like NX Color and all that, Paul probably dealt with that at some point.

Paul: I've blocked it off my memory.

Guy: I'm going to make you bring it up now. A lot of people that basically came to Apple development with the iPhone and iOS, take one look at AppKit and find it primitive, and don't want to deal with it anymore. Even knowledgeable people, who know what they're doing, just don't want to deal with it. But, you've got a ton of experience with AppKit. My position is that often AppKit is doing a lot of things that UIKit can't do. That's less true with each release of iOS, but I think you'd probably agree with me that certainly all the text stuff was, until recently, like night-and-day better on AppKit. What's your beef with it? Is it the sales?

Paul: It hasn't really been upgraded, at least not from what I can see, since UIKit started taking off. It's just stagnated along. They bolt on layers here and there. But, if you get in there and you try to make a customized UI with buttons, with different backgrounds, and try to animate stuff, it just doesn't work right. There are a lot of bugs in it.

Guy: Yeah, just yesterday, I was trying desperately to tint a button. Not desperately.

Paul: You kind of have to go in, and rewrite it all yourself. After you're used to UIKit where it seems to be the case where you're looking at Twitter versus ADN-APIs, like we were talking about earlier. UIKit learned a lot of mistakes from AppKit. I would love to see a unified kit, App-UIKit, whatever you call it, that merges the two.

Guy: Do you think it's possible?

Paul: I don't know. They can, definitely, do it like the Carbon to AppKit transition, where they just said, "AppKit's legacy now. UIKit is new. It takes awhile before all the features that were available in AppKit are now available in UIKit. But, it's the future." Eventually, a few releases down the road, it gets deprecated, and everybody forgets about it, unless you have to run an app that was only updated 10 years ago, or something like that.

I would like to see it either get a lot of love, where you can do animations as quickly as you can do them on UIKit and things work right or as expected, or just toss the whole thing out, and start something fresh.

Guy: ...as much as AppKit. Everything is layerbacks. Even when the density was such where they needed a sub-pixel add-on type of thing, and besides, you could take it to a device and it would break anyway. But AppKit has all of these affordances to account for its history, and to account for the variability of hardware. Do you think if you bolted everything that was required of AppKit into UIKit, UIKit would be as straightforward and effective as it is now?

Paul: That's a good question. They definitely added on stuff to UIKit. Like you mentioned before, the text system for UIKit was very basic at the start, and they seem to have done a pretty good job of putting in functions throughout the different iOS versions to improve that and make it more like what you can do on AppKit. I think if they did it right, if they took their time, it definitely could be done in a way where it wouldn't be this ugly behemoth that didn't make any sense. It would take awhile, and probably, five years from now, we're all going to be complaining that UIKit is now not the cool stuff because some other kit came out for some other Apple device that has yet to be dreamed of.

Guy: The Twitter app, like Loren did a cross-platform, UIKit, sort of thing, and Sean wrote Chameleon, which was their sort of UIKit on the Mac thing, how did you guys approach the same problem, point a Twitter client from the iOS to the Mac?

Paul: We used AppKit, believe it or not, as much as I don't really care for it, and this was, actually, mostly my decision, which was maybe a bad decision.

Guy: I don't think so.

Paul: But, we wanted to make sure we could use the text system, and all that good stuff that AppKit provides, but on the other side animations aren't as smooth as they could be, and we have to deal with layers causing problems in some places where they don't cause problems on UIKit doing those same type of things. There's no UIKit-clone framework for Tweetbot, it's all AppKit-based.

Guy: There are two approaches to writing cross-platform UI code. At one point, and I'm sure you know this, NeXT used to run on Windows, so you used to be able to compile it. You'd have all the Display PostScript and all that, and it would fake drawing the windows inside a Display PostScript context.

Paul: Yellow Box?

Guy: At one point they were shipping it, weren't they?

Paul: I don't know if they ever actually did, but maybe they did. It was awhile back.

Guy: Before the Apple XGeN, right?

Paul: Yeah.

Guy: I thought you could compile NeXT stuff onto Windows NT. Whatever.

Paul: They used to have the OPENSTEP that ran on four different hardware platforms.

Guy: That's probably what it was.

Paul: That's different from what I think was Yellow Box.

Guy: I do know that if you'd look in the headers, maybe not now, but in earlier OS X releases, there was an NSWindow, Windows extension. There'd be an "ifdef" and there'd be an "hwin" to get a Windows window-pointer out of your NSWindow thing. There's that approach, where you basically just plunk your kit on top of some other base APIs. Then, there's the other approach where it's, "I'm going to rewrite the UI later." It seems like you took the latter. Is that out of experience, or is it just because you felt that going with the platform UIKit would be easier than fighting against it and trying to impose your own UIKit view?

Paul: As much as I don't care for AppKit, I think it's the least-worst choice to write an application in for the Mac, because it is the native UI for the system. I don't like applications that are ugly ports from other platforms, like Java-based UIs and stuff like that. We're big believers in making the application feel right for the device, for the operating system. It's one of the reasons why we won't port to Android. We're not going to take our UI and our feel and just move it over there and have it run the same way, because it's just not something that we feel is the right thing to do, as people.

Guy: I think that goes back to what you were saying about the Convertbot and the iPhone 5 screen, in that you designed that app very specifically for a certain-sized screen, and now that it's changed, it's problematic to recapture that feel on the larger screen.

Paul: We could definitely stretch out the top and the bottom but does that really make any sense? Is that something that we would be proud of?

Guy: You could just give it a big Imax-style chin on the monitors.

Paul: That makes it somewhat tough, that we care so much about how these apps work and feel. Where if we'd used something like TWI or Chameleon, maybe it would have made the process of porting a bit easier, but are we then losing out on some of the nice things that AppKit provides that are behind the scenes and that you just subliminally notice?

Guy: Stuff like accessibility. Like when you do your own sort of interface kit, you lose a lot of stuff that comes with the system, like being able to select text and run a service on it, maybe. Weird, little things. Like, edge cases that just drop away.

Paul: Right. Then, as Apple upgrades the operating system, new features probably don't work quite right, if you're using those things. A perfect example, going back to the twUI, it's all fuzzy now. Why is it fuzzy? Because it's using their own UI, crazy layer-backed stuff that's not AppKit. When they moved to the retina screens, it wasn't ready for it. Now the app looks fuzzy to everybody.

Guy: I'm sure that bugs Lauren, but I didn't want to ask about it. [laughter]

Guy: It's not his problem anymore.

Paul: I'm sure that's something that could be fixed in a fairly simple manner, but if it was written with AppKit, it probably would have just worked.

Guy: Exactly, You were saying that five years from now, maybe there will be some other kit that we all wish UIKit worked like. You've been doing NeXT stuff for a long time now. I've been working in the field for 6 years. I've been doing it for maybe 15, doing programming on the side and doing tools for work and all that. Do you ever worry you're going to get blindsided by a different platform?

Paul: No, I don't. A few years back, before the iPhone came out and the Mac stuff was waning or at least not as popular as today, I spent quite a bit of time doing Ruby and Ruby on Rails type of stuff. I'm not terribly worried about it. If it, for some reason, dies out, there's always something else I can jump into. Fortunately, I really like the Mac stuff, the Objective-C libraries, and think it's the best stuff out there. It took a while, but at least the last five years, it's been really great.

Guy: Definitely. It used to be, and this was a different time too, there were more operating systems around in general. I don't want to say I experimented in my youth but... [laughter]

Guy: I used to use OS/2 and Windows NT and Classic Mac, and that's how I came to find out about all the NeXTSTEP stuff and all that. These days, I find myself, because I work and I work on Apple technologies. I sometimes wish that I would go and maybe check out what it's like to program on Windows Phone 8. Every now and then I'll go read through the docs, but I don't actually practice it. Is that-that's not something you care about. That's just...

Paul: If any of those platforms besides the Android actually take off in some way I'll definitely take a look at them. I refuse to look at Android just because I have a rational hate of Java and all things Java related. But I certainly, if Windows 8 sold more than a couple phones a week I probably would be interested in taking a look at it.

Rene: On the flipside, some people like John Syracuse have been critical or maybe hypercritical about objective-C and its future when compared to the higher-level languages and the way that you can develop for more, I don't want to say more modern, but more recent devices. Maybe like Windows Phone or maybe some of the stuff that Microsoft is doing with C#. Do you see the same kind of limitations in objective-C and are there directions that you hope that Apple takes it beyond what they're doing now?

Paul: I really like the way, actually, Apple has been handling objective-C where every year they're making some significant but not overwhelming change to it. They've recently added the whole, what was it? The new memory stuff?

Guy: The boxing.

Paul: Boxing, but the new memory stuff, what's it?

Rene: ARC.

Paul: ARC. Yeah. In there, which really changes a lot of how one writes an application.

Guy: Have you ever-sorry. Have you seen apps been using that?

Paul: Nope. Nope. I mean it would be nice to, but it would involve a lot of going back and changing classes that have been working for years now. It's not something...

Guy: I can't stop writing retain release, like I cannot do it. I've got to break that habit, but... Anyways, sorry Craig [inaudible 55:22] , go on.

Paul: It's not something I have a problem with myself, since I've been doing it long enough that I can retain release in my sleep. But it's great for new developers. On the other hand they added block recently which I used pretty much all over the place. I've even almost got the syntax memorize for how to write a block without copying and pasting it from somewhere else. I like the way they're improving the language without throwing it all out and starting from scratch. Which...

Guy: It certainly seems that from '97 to almost 2007 nothing changed and then for the past five years we've been getting pretty big improvements.

Paul: Right. You can almost see it's a yearly cycle and a lot of those improvements they make it so it will run on a previous version of the OS, which is great as well. Is it as fancy as whatever new JVM based languages they're coming up with? Probably not. The language is only half the issue. Even less than half the issue. It's the frameworks that go around and I don't think there's anything anywhere near as mature that works as well as foundation in UI kit.

Guy: You can say that, begrudgingly.

Paul: I guess it doesn't have all the whiz bang features but it's been improving at a good, sustainable pace. If you look at something like Ruby on Rails as a counterexample, they add new whiz bang features to it, to the framework, every dot release and it gets to a point where if you haven't kept up-to-date with each and every one of those releases and you go back and try to update an app you almost have to toss the whole thing out and start over to deal with whatever new features they decided had to be added without any regard to previous working code.

Guy: Incremental improvement without churn. You don't have to toss everything out.

Rene: No rip and replace.

Guy: One thing I find heartening in retrospect, but at the time I was annoyed by it, not annoyed, I'd written a large app using Garbage Collection, which was dumb because it used a lot of graphics, too, and a lot of the graphics stuff didn't end up being properly garbage collected, and then they abandoned it. It was a little concerning. Because under Garbage Collection you could write retain and release and it was a no-op, I'd been doing that anyway because I couldn't break the habit, so it wasn't that much a pain in the ass to switch back to the regular.

In retrospect, I kind of like that because they went a direction and within a year, year and a half, maybe two, they just ditched it and they went to Arc, which I find to be a very compelling argument they are taking the stewardship of objective C and their platform seriously and they won't commit long term to something they don't think will work.

Paul: Yeah. Garbage Collection is definitely an interesting edge case where, for whatever reason, they decided it wasn't working and they just reversed course and went a completely different direction. Fortunately, I don't think it impacted too many people. Like you said, you're writing release and retain code anyway. I don't think I've ever used it.

Guy: Very, very few. Very few third party developers used it.

Paul: It's nice that it's consistent improvements and course corrections, if needed, year after year as opposed to waiting three or four years and tossing in a bunch of stuff and breaking backward compatibility. Everything seems to be pretty compatible with everything that came beforehand.

Rene: Is there a direction you'd like to see them keep going with those iterations?

Guy: I definitely would love to see blocks just everywhere. Go in and make sure that any operation that takes any amount of time has a completion block. Stuff like TableView updates. When you go in and you do some animated UITableView updates, there really should be a completion block so you know, "Hey, we're done with the graphical side of this." If you need to do something else, continue on. I love to see them just making sure, "Hey, everything any kind of animation, any kind of long-running operation, has some kind of block or some kind of call back to it." Also, the GCD stuff is awesome. I love to see them keep going with that, making sure it's more well-defined.

When you make a call using GCD, you should know, "Is it coming back in the same thread that called it? Is it coming back in a different thread?" have all that stuff documented. I love to see that stuff happen.

I've been playing, like I said earlier, with iCloud this week. I'd love to see them improve those APIs. They're currently way too hard to use, at least the document-based side of iCloud.

Guy: Are you using the UI document stuff, or are you using the stuff from Foundation that UI document builds upon?

Paul: Right now for Tweetbot and Netbot we use the key-value style API for...

Guy: That in my experience works reasonably well.

Paul: When it works, it works reasonably well. The API is certainly very simple to use. It's great for what it should do. It sometimes, for whatever reason, refuses to work.

Guy: Can you explain a failure case to me?

Paul: It just doesn't work. [laughter]

Paul: The API is very simple. You set a value and you read a value. When you set the value, it should go up to the Cloud.

Guy: I'm trying to think, there's no...Do they have an error reporting API on that? I don't think so. It just looks like user defaults, right?

Paul: Yeah, it's literally a copy of user defaults with some notifications of when things change. For some reason...

Guy: There's no way to query for an error, and there's no notification that you get an error.

Paul: Yeah, and I literally have some devices that it just refuses to work on. I'll set the value. I can watch the traffic coming out from that machine. It just never goes up anywhere. It just stays there. You have no idea, obviously as a developer, you have no idea that anything wrong is happening, because you get no call backs or anything.

Guy: You think it's on the back end?

Paul: No, it's definitely on...There's probably back end problems as well, but this is definitely on the device itself. I'm watching traffic to and from it. As I set a value, it just won't go anywhere. It just stays on the device. There's no network call out to the iCloud servers doing whatever they do.

Guy: Is this some kind of timeout thing?

Paul: No, I just...

Guy: I don't know. I'm trying to debug your [inaudible 01:04:10] .

Paul: I've sent tons of logs over to Apple, but still haven't gotten a response of what's happening. It's been happening since 5.x, it's not a new 6.0 type problem. It's just [inaudible 01:04:26] API for whatever reason, sometimes on some devices, refuses to work and then, once in a while, it will start working again on the same device for no rhyme or reason. It's probably the number one support issue we have with the Tweetbots is sometimes iCloud stuff doesn't work.

Guy: It's frustrating because it's not something you can dig into and fix. That's for simple API.

Paul: The document-based API is much, much more complicated. It does seem to work more reliably, though, for whatever reason. It's very complex API-wise. There's a lot of different failure cases that you have to handle. Everything is asynchronous and some of those asynchronous operations don't have call backs to them, or not, at least, easy call backs. It's just much more complex of an API than I think it should be. It probably explains why so many people have problems with it.

Guy: If you can say, which Apps are you using that in?

Paul: We're actually looking at doing some stuff in Calcbot with that.

Guy: Oh, interesting.

Paul: For example, it would take the tape on one device and synch it across multiple different ones.

Guy: That's cool. That makes sense.

Paul: Once we have that working, we'll probably go in and look at getting it working on Tweetbot for stuff like graphs, as an example, where your graphs could by synched between different devices, where it's not that thing where you're possibly talking about, "Yeah, 140 character graph, that's no big deal," but you an image, or several images, that may go along with it. That stuff doesn't really fit into that key-value API that's simple to use. You need to do something like the document-based API where you're dealing with large files.

Guy: No, I think that's exactly the right thing to do. They call it the [inaudible 01:06:56] API, right? Just the idea of having all your drafts transparently everywhere that you've got Tweetbot seems like a great idea. Oddly, I don't think anybody's going to....

Paul: [inaudible 01:07:05] pretty complex.

Guy: I'm sure. I'm sure the amount of work you put in, you'll not get enough kudos. People will just notice that the draft's there and they'll be like, "Oh, cool." You'd be a month of blood, sweat, and tears to make that work.

Paul: Yeah, it's been a good week, plus just getting this tape going back and forth between different devices. I ended up rewriting it three or four different times just to deal with different API issues/limitations.

Guy: What's your policy in terms of supporting the most recent operating system? I ask that because let's say iCloud never gets fixed on iOS 6, but for some reason it works on iOS 7. Would you just move to iOS 7? Would you limit that feature to iOS 7? What's the policy?

Paul: My overall view is that you should support the two latest major OS versions.

Guy: Yeah, I think that's common.

Paul: I think Apple's actually almost forcing you to do no more than that. You can't build an App for the iPhone 5 that works on 4.1. The 4.2 SDK stopped supporting deployment for iOS 4.2 and earlier. Something like that. Apple's almost forcing you to only do the most recent two OS versions, under iOS.

Guy: Yeah. With iOS, they're definitely dragging everybody along. Users and developers alike. They're just dragging people along. I think they see each device as having a two year life span. Maybe not the 3G. That must have been longer. But sorry, I cut you off. Go ahead.

Paul: You can probably count on two years of updates, up until the point they stop selling that particular device. I would expect, actually, the 3GS to get at least iOS 7, possibly iOS 8. But I wouldn't expect much more than that.

Guy: I'd be surprised by iOS 8. Only because I think they'll just be... [inaudible 01:09:39] .

Paul: That one is an edge device. It's been selling for so long. But I definitely think you shouldn't expect much more than two years worth of updates from the time they stop selling the device.

Guy: That makes sense.

Rene: The thing that's interesting with Apple is that it has so few features of iOS 6, but it still supports iOS 6. Apple's point of view is that it wants it to be binary compatible, so that when you write apps against iOS 6, those can all run on the install base of iPhone 3GS devices. When you look at things like Windows Phone, which loses binary compatibility after one generation, that becomes key for their market.

Paul: The Windows stuff is kind of ridiculous, at this point. They're still selling the Nokia something or other.

Rene: 900.

Paul: And then three months later, it's obsolete. Because it won't run Windows Phone 8. What are they thinking? Android's even worse than that. It's nice that Apple has a fairly consistent story there.

Rene: For a user, yes they're upset they don't get Siri, for example. But if they couldn't bind new apps, that becomes a big problem, especially for a device that was being sold, up until fairly recently. The binary compatibility is the layer that they try to move forward the most.

Guy: Paul, we talked about AppKit, UIKit and iCloud. All of these things, basically, are under one guy. They're all under Federighi now. Do you think that makes a difference? Do you think we're going to see more cross-pollination or a tighter coupling of this stuff?

Paul: I have no idea. To me, the whole way that Apple works is a black box. I certainly have no inside knowledge of what happens there, other than every year they come out and announce cool features or not so cool features, as the case may be. I hope they start getting a little more aggressive with iOS. The last couple versions have been somewhat lackluster. The devices have gotten better and better, but the OS, I won't say it's getting stale. But it could use some cool new features, here and there. I'd love to see apps being able to tie in to Siri somehow.

Guy: I looked at that. That's really hard to do. Do you just mean launching them? Providing a service is tough.

Paul: Yeah. But there's got to be ways to do it. I don't know enough about how Siri works down low and that kind of level, to be able to say what can be done.

Guy: The problem is disambiguation, basically. If you just put a list of keywords in your PList and you've got three apps, you've got Twitterific, Tweetbot and Twitter for the Twitter app, what happens when you say, "Send a tweet," or, "read my replies to me"?

Rene: "Do you want to send that tweet to Tweetbot, to Twitterific or to tweet, press the button."

Paul: You could set a default service. You can have a default mail service, like you do on Mac. I don't see why you couldn't have that on...

Guy: It's an interesting problem to look at.

Rene: I still think though, they're doing that as partner plays. They're not going to give out the revenue they can get from brokering deals with the Yelps and the Ticketmaster companies, just to provide a free way for apps to do it.

Paul: Possible. But if Google goes in and starts opening that up, they might not have a choice. If some other operating system starts integrating those cool features and they're not, just because they might lose some revenue, they're not going to stand for that.

Rene: The bigger problem with the Siri stuff right now is, for example, Google's doing on-device voice parsing, which makes the experience much faster. Anything that doesn't have to go to the cloud doesn't go to the cloud. I can set an alarm. I can do all sorts of things and never have to worry about the cloud being a point of failure. Siri sends everything to the cloud, still. Google Now is also doing all the predictive stuff. Where it knows where you are, it knows where your appointments are and it starts providing information, even before you ask, where Siri is still a query, response engine. They're already falling behind in several of those areas that Google excels in. They should get a move on on that stuff.

Paul: Yeah. That's what I said. I would hope that the future OS's are going to be a little more aggressive with cool new features that we can't even imagine today. The last few versions haven't quite done that.

Guy: Yeah. They've solidified a lot of stuff, but they haven't really leaped forward in any way.

Paul: For iOS 6, what were the killer, must-have features. Maps, I guess.

Rene: The kids got Facebook, Paul. Come on.

Paul: Yeah. That's true. More account stuff, which is actually pretty nice but will take a while to go through all the different applications to start using that stuff.

Guy: Where do you sit with the Twitter integration in iOS? Does that help you at all? Does that run parallel to you? When they start introducing things like Twitter integration, Facebook integration, built-in reading lists, are those things that you look at to add value or do they take away a layer from your business?

Paul: All that stuff they've added is great. Especially being able to launch Tweetbot on a new machine and not have to enter in your passwords, because it's using the Twitter integration stuff to get all that, is pretty cool. None of that stuff has impacted us in any negative sense. I'd love to see them add in the reading list API, because right now there's no API for it, on iOS. We keep getting requests for that.

Guy: It seems like a gimme. It seems like they could implement a URL scheme and just make it work.

Paul: They added it into Mac OS. It's a little bit hidden in there.

Guy: They did?

Paul: Yeah. It's in there. I didn't know about it.

Guy: Where? [inaudible 01:16:31] workspace or something?

Paul: It's in the sharing API.

Guy: Oh wait, I did see that. Sorry.

Rene: One of the things I also wanted to ask you about is that you've resisted doing in-app purchases. A huge swath of the iOS economy has gone into in-app purchases. Some people have done it in Twitter applications for multiple accounts or to get rid of ads. You basically buy Tweetbot, you get Tweetbot. Was there ever any discussion about, "Hey, we could do photo filters or make mute filters an in-app purchase"?

Paul: No. Not seriously. The one area where we talked about it was for push notifications. But we were able to...

Rene: Because of the server expense or because you thought that it would drive...

Paul: Because of the server expense side of things. We thought it would be a lot more involved, cost-wise, then it ended up being. And it would have been if I'd outsourced the push stuff, which was our original plan. But then I ended up just writing it all, writing it on server. It's a point where it doesn't cost enough to justify charging an IAP for it.

Guy: I imagine you have a lot of traffic on that. But you don't need a big, heavy-duty?

Paul: Yeah. I want to say we're almost to our billionth push notification. Some time soon.

Guy: What are you running on, a 386?

Paul: No, it's a Xenon. I don't know. Something we rent.

Rene: It's not a hacked Xbox. Paul No. But it's not a crazy machine either, with 36 cores or anything ridiculous like that. It's a normal-sized server that is enough to handle the traffic and then some.

Guy: So unless you're doing Tweetbot level traffic, you're fine with just a basic server to handle push notifications?

Paul: We were even fine with a basic server.

Guy: That's good to know.

Paul: At least the way we're doing it, it's not that intensive of resources.

Guy: Yeah. What are you, using Web Objects?

Paul: [laughs] I used to really love Web Objects.

Guy: I know. I was talking to Lauren about it last week. I wanted to bring it up with you, because you actually did it, professionally.

Paul: Until they switched to Java and then I almost immediately lost all interest in it.

Guy: Did you hear last week's show? Lauren got Objective-C running on servers.

Paul: It's doable. The server stuff, I just stick with Ruby, just because it's pretty easy to use on there. But yeah, a while back Web Objects would run on servers and was Objective-C based and was all fun to use.

Guy: Yeah, it used to be awesome.

Paul: Then they started doing Java wrappers around Objective-C classes and all sorts of crazy stuff. Now, I think they should just take it out back and shoot it.

Guy: They have, right? It doesn't ship anymore. They still use it, but nobody else does.

Paul: Nobody uses it, but something still exists.

Guy: The store. iTunes Store runs it and a bunch of their other stuff uses it. The Apple Store uses it.

Paul: And their iTunes Connect back-end still uses it, which is probably why it's so bad.

Guy: Probably. [laughs] Wait, just fact-check me from last week. I said that they moved to Java because they wanted to run on app servers. There was something about cross-platform, right? You would know. I fumbled through it.

Paul: The reason was that Java was becoming really big, back when they made that choice. Objective-C, it was a lot harder to find developers who knew the language. At that point, I believe Web Objects was their big product. They were charging...

Guy: It was like 999 bucks or something.

Paul: No, they were charging more than that. I think they were charging like $50,000 or something like that. It was their big, money-making product. They probably had a bunch of corporate clients who said, "We can't find Objective-C guys. This is great, but we only have Java developers. We can find Java developers. Port it over to Java for us."

Guy: The irony now is there's like 100 WebObjects guys in the world that know what they're doing, and that's about it.

Paul: Yeah.

Guy: Oops.

Paul: Ruby on Rails works, or one of the offshoots of that works well enough that there's no point in going through the whole craziness that is WebObjects at this point.

Rene: The iPad has now gone smaller. You were wondering if at some point Apple would go bigger. Is that an actual problem that you would like them to solve?

Paul: No, I don't think they're going to go bigger. I actually more meant it's possible that the 10.1 inch iPad Maxi goes away, and they go and focus on the smaller one instead. At least from my personal experience, I much prefer the new, smaller one from a carry-around, play-with standpoint versus the old one. The only thing I prefer on the older one is browsing the web because of the bigger screen. Other than that, it's like this lumbering dinosaur. I compared it to the MacBook Pro 17 inch, where they just got rid of it.

Rene: The battleship

Guy: I watch a lot of video on my iPad, so I prefer the larger. It's like a portable TV for me. I'll go sit outside on my deck and watch TV on my iPad, so I prefer the larger one. I was not going to buy a Mini on account of the one X screen, but then when I actually saw one... It's pretty good. It's really good. I'm pretty sure I'm just going to go out and buy one as soon as I get my druthers together to do so. I do agree that it feels amazing. The build quality is great. The screen is way better than I thought it was going to be.

Rene: It feels like what's next.

Guy: I agree with you, Rene. You had a piece about not expecting a Retina screen, and I wouldn't, for at least the next rev.

Rene: It's one of those things that Apple's still bound by the laws of physics and the laws of economics. If you put a Retina display on it, it becomes an iPad 4. For people who don't want to carry a laptop, the iPad 4, the large size iPad Maxi still makes a lot of sense because it gives them a lot more area to be productive with, whether it's using the iWork apps or it's typing or anything like that. But if you have a ton of other Apple and iOS devices, the Mini really is a sweet spot now.

Paul: We'll see how it progresses. The MacBook Pro 17 had a lot of fans, me included, but it went away too even though they could probably still sell them today. They just sell so many more of the smaller devices. It'll be interesting to see. I definitely like the Mini better with the exception that I wish it had some more memory in it, like the newer iPads, the 1 gig versus the 512. Other than that, I don't miss Retina. I don't really miss the extra speed that the iPad 4 has.

Rene: It feels more like a mass-market device. When you hold it, it feels like that next breakthrough product.

Paul: I just wish it was a bit cheaper, but what are you going to do?

Guy: Wait a year. [laughter]

Guy: What do you want to see? Either in terms of software, besides killing AppKit... [laughter]

Guy: ...or hardware, is there something that you're...That sort of fanboy, Apple insider, I'm going to refresh the page until I read all the rumors on this kind of thing. Is there something you're excited about coming up or are you just pleased with the current iteration?

Paul: I'll answer that with two different hats on. From my business person hat, I would love to see cheaper iOS devices. I want to see the better iPod Touch, the 32 gig down to the $200 mark. I would love to see the iPad Mini down at the $250 mark. From my geek hat on, my personal hat, I'm really excited to see a 16-core Mac Pro with modern insides, as opposed to the current two-, three-year-old version that's out there.

Rene: You'd stick with the Mac Pro and not go iMac?

Paul: Ew, no.

Rene: [laughs]

Paul: No, I run a Mac Pro now. I'm not going back to those little, slow iMacs.

Rene: [laughs]

Guy: You know what? I did that for years. I was always on the Pro side of stuff. Then I bought an iMac Core i7, one of the earlier ones, because my Mac Pro was dying. It was old, and there was no update in sight. I figured, "Well I'll buy this 27-inch iMac," with a Core i7 and I forget what else. "I can use it as a screen when I eventually buy my new Mac Pro." But the iMac was just fast enough, and it was awesome, and I kept using it. I'm not sure I would go back to a Pro.

Paul: It is fast enough, but once you're running with the old 12-core Mac Pros, which is what I run, and you stick a bunch of SSDs inside, and... [laughter]

Rene: Some racing stripes on the back.

Paul: Put a couple monitors to it. I don't necessarily need it, but I really like it and want the latest and greatest and even better version that comes out next year.

Guy: Can't blame you for being into hot rods. Rene : Jardine has the cars. You have the computers.

Paul: He definitely...I still drive a 10 year-old minivan. [laughter]

Paul: I'll [inaudible 01:27:41]

Rene: It's got the racing stripes though.

Paul: No, but I actually got a bunch of paint on it from the side where I scraped against the garage. [laughter]

Paul: I'll spend the money on cool toys and hardware, not car stuff.

Rene: [laughs] Car stuff. If people want to find out more about you and more about Tapbots, where can they reach you?

Paul: Go to tapbots.com or follow me on probably best App.net these days, and @pth is the user name.

Rene: You went for a different user name on App.net than Twitter.

Paul: Definitely shorter, and I like the pth.

Guy: Got to go with the three letter [inaudible 01:27:40] .

Rene: Guy's a huge fan of the three letter name.

Paul: It's much easier to type, and you can reply to more people with the shorter names. Longer reply tweet or post.

Rene: Guy, where can we find you?

Guy: I'm @gte on Twitter and App.net, and my website is kickingbear.com.

Rene: You can find me @reneritchie or you can find me on iMore or just look up Debug on iTunes and subscribe. Paul, thank you very much for joining us. That was awesome.

Paul: Sure, Renee.

Guy: Paul, it's been great. Thanks a lot.

Paul: Nice meeting you, Guy.

Guy: You too. Take care.

Loren Brichter of Atebits talks to Guy and Rene about working on the iPhone at Apple, Tweetie at Twitter, and now Letterpress on his own. OpenGL, Game Center API, in-app purchases, iOS 7 feature requests, and other assorted nerdery follows.

Here's the audio, again, in case you missed it. And now, for the first time, here's the full transcript!

• Subscribe in iTunes
• Subscribe in RSS
• Download Directly

Debug 1 transcript: Loren Brichter and Letterpress

Guy English: Hi my name is Guy English, and this is "Debug." A new, developer-centric conversation show. Rene?

Rene Richie: I'm Rene Richie, and I'm joining Guy for this new shindig. Quickly Guy, the reason for this is that there's a lot of fantastic developers out there and we wanted to talk to them.

Guy: Yeah, definitely. I like the idea of...I always loved WWDC, and getting to talk to people. This feels like a good excuse to carry that through the year a little bit.

Rene: Dub, dub all year round. I'm thrilled, our first guest is Loren Brichter of "Atebits " Fame, of the original "Tweetie" Fame, and now of "Letterpress" Fame. How are you Loren?

Loren: Good, thanks for having me.

Rene: Thank you for being here. Can you give us just a quick...I mean a lot of people already know you and who you are, but can you give us just a quick rundown on how you became an IOS developer?

Loren: Sure, back in high school I discovered OS10, the public beta, and I installed project builder, and I got into Cocoa programming. I played with that all through college, and when I graduated, Apple gave me my first job working on the original iPhone. After that, I went independent. I made "Tweetie," and the rest is history.

Guy: It's weird, I mean...so you've been internal at Apple. Did you find it weird when you started working outside, and how do you find it now, years later?

Loren: Man, when I left Apple I wasn't really sure what I was going to do. Then I had the idea for a MacPaint, a modern version of MacPaint, and I just…I don’t know, I just started working on it. I found that I loved working on my own. I guess it reminded me…back when I was in school, I would basically skip homework and just worked on my own stuff all the time and I don't know, I just loved working that way, and it hasn't worn off yet.

Guy: You left Apple shortly after the first iPhone shipped right? 1.0?

Loren: Yeah, it was right when it shipped.

Guy: Yeah, you’d left before the 2.0 API access.

Loren: Yeah, there was no app store. I didn't even own an iPhone when I left.

Guy: Really?

Loren: I still had my Motorola Razor.

Guy: I like those phones, they weren’t bad.

Loren: I loved the Razor.

Guy: Why did you leave? I don't know if you told this story before, but I'm certainly not aware of what it is?

Loren: Working at apple was probably the greatest thing that ever happened to me, but I was from the east coast, my whole family is on the east coast, my girlfriend wanted to move back to the east so we figured we would go back there. That was the impetus for the decision.

Guy: That's actually one reason that I would basically not consider working for Apple.

Loren: Yeah.

Guy: The second is I spent a lot of time in game studios and they work you like crazy and I don't want to go back to that kind of stuff.

Loren: [laughs]

Rene: A sixty watt bulb can only go a hundred and twenty for so long.

Loren: Pretty Much, yeah.

Guy: Would you consider rejoining another big company or any other company or are you now a one man band?

Loren: I really like working for myself. I say that now. I’ve had an app out for two weeks. I’ve only been answering email, support emails for two weeks. I don't know, maybe I’ll get tired of it, but I think I'm in this for the long haul at this point.

Guy: I think that makes sense I mean you left Twitter so it was clear that you wanted to just go and do your own thing, and I think the body of your work speaks to you wanting to experiment certainly in the user interface area and that's hard to do when there's a big investment beyond a product you are going to do so I think probably working for yourself is going to offer a greater opportunity to follow what you think is the best course of action or the least or most interesting course of action.

Loren: Putting it that way makes a lot of sense. Thank you for clarifying my thoughts.

[laughter]

Guy: That’s OK. You’re kind of in that…you’ve just released Letterpress which is another huge hit you are in the unfortunate situation that if you don't keep knocking them out of the park people are going to think that you’ve [laughs] lost your touch.

Loren: Yeah, two might still be a coincidence I don't know if I would call Letterpress for success yet. It's only been two weeks. I'm still pretty curious how it's all going to pan out.

Guy: Well, it's ridiculously popular.

[laughter]

Rene: What made you decide on Letterpress as your follow up to Tweetie and I think when we spoke previously you said you were playing word games with your wife, but it wasn't the word game you wanted to play.

Loren: Yeah, we just wanted a little multi-player word game to play against each other, turn-based, asynchronous, that kind of thing. Then there was Words with Friends, but we got tired of it.

Guy: You worked on it for about a year after leaving Twitter?

Loren: No, no, I didn't work on it for nearly that long. What happened was after I left Twitter I had this massive backlog of ideas going back five, six years. Stuff I was thinking about in college and I just didn't have time to work on it. When I left, I just plowed through my old to-do list. I ended up making a dozen or so things, most of which will never see the light of day, but Letterpress was one of those things.

I was actually working on a completely different game and then we had the idea of making a word game. I dropped that other game completely, and I picked this up. I'd say Letterpress took me about two months of solid work, plus a little extra, to get it out the door.

Guy: Do you think you're going to go back and revisit some of those ideas?

Loren: Oh, yeah, definitely. I'm still juggling a few. But most of my time is spent working on Letterpress now.

Guy: One thing that's totally crazy about Letterpress, which I don't think a lot of people realize, is that that isn't done with UI Kit. It's all done with custom OpenGL stuff.

Loren: Yeah, I wouldn't recommend doing it. I [indecipherable 6:23] insane for doing that.

Guy: Was that just for the fun of it or what? You had GL stuff for your previous game attempts and you just reused it or what?

Loren: I like to think of myself as a graphics programmer by trade. Through college I basically taught myself OpenGL. This was back in the dark ages when there was no such thing as shaders or anything like that. Then at Apple my job was on the embedded graphics and imaging team, so we did a lot of driver level stuff.

Guy: I have a similar background. I come from games. I was jealous that you did it because it basically it looked like you re-implemented the UI kit. You’ve cloned the scroll view and done a whole bunch of other stuff and it just looks like it'd be a really fun and crazy project to work on.

Loren: Yeah, it was crazy, but I had two inspirations for it. One, I wanted to just see if I could do it and there were a couple of things in the UI Kit that you can only appreciate if you do it yourself. Like [indecipherable 7:35] Jedi build their own light sabers kind of thing. There were some things about UI Kit that I didn't like. I wanted to experiment, “Hey, what if I did it this way?” There were a couple of thing in it that I do vastly differently than UI Kit. I think it worked out pretty well.

Guy: I'll tell you what worked out great. It's got a really great feel to it. It maintains a bit of the iOS feel, but it also seems to borrow from Windows Phone, or Metro. I don't know if that's intentional or not, but I've seen parallels drawn between them. It's a great, clean-looking interface, and it just seems to work perfectly.

Loren: Thanks, I don't know about you guys, but I'm a huge fan of the style of Windows Phone. From almost the technical perspective as much as the aesthetic perspective because it's doing things that the graphics hardware is naturally good at doing. You're not coercing it to doing something crazy.

Rene: When you sat down to make Letterpress, did you have a process? Did you make your own work order for this and go through it or, because you're a one man shop, you just do the parts that you want when you want to do it?

Loren: I don't even remember the order that I did it in. This whole UI Kit replacement thing was one of these many projects that I had started on when I left Twitter. When I decided to do Letterpress I took the covers off of that and dusted it off and started building a game with it.

[silence 9:03 to ]

Guy: I'm playing with it right now and I'm just amazed how smooth everything is.

Loren: I tried to target the 3GS. The 3GS and the iPad One were the bears to get working. But if it's fast on those, it's fast on everything.

Rene: It's not just that it's fast, it's that it's flawless. A lot of things appear fast, but then there's stutters, there's stammers, there's hiccups, it takes a second to realize what you're doing. When even on older hardware, this just seems very, very responsive.

Loren: Yeah, thanks. It's not perfect yet. There are a couple stutters because of the way GameCenter hands back data. I'm doing a little too much work on the main thread in a couple of cases, but I just haven't gotten around to fixing it.

Guy: Let's talk about GameCenter, since you segued into that. Sort of infamously, GameCenter fell down the same weekend that you released Letterpress. People are taking that as a sign that you managed to destroy their server somehow. [laughs] Is there a particular heavy-use case that you use, or do you think it's random scale of the game?

Loren: I don't know. As cool as it would be to take credit for it, I don't know if it's coincidental. [laughs]

Rene: Being as big an influx of nerds playing one almost-completely-dependent-on-GameCenter game at one time.

Loren: Right. What did Apple quote? Apple quoted something like 150, 160 million GameCenter accounts on the global system?

Rene: Yeah.

Loren: I feel there are a lot of GameCenter games, but they're all using it for achievements and [indecipherable 10:44] and that's basically it.

Guy: Right. I guess we can narrow it out a bit, since it's more developer-centric. You use GameCenter to do the turn-by-turn stuff?

Loren: Yeah.

Guy: The turn-based gaming. I can't think of another example, certainly not one that's as popular as how Letterpress seems to be.

Loren: I think Monkeys had it, like in its Lost Cities, I think?

Guy: OK. Is that big?

Loren: I don't know how popular it is.

Guy: How do you find that API?

Loren: I don't like it, but I think it has the potential to be really awesome. Using GameCenter is a mixed bag. On the one hand, I don't have to babysit servers, Apple handles everything for me. The game can get as big as I want and it's on Apple's shoulders to make the backend stay up. That's awesome.

The downsides are obvious. I have no visibility into the problems. Apple doesn't do post-mortems or anything. It's very opaque.

Rene: At one point along the process did you make the decision to go all-in on GameCenter, and did you spend a lot of time weighing the pros and cons?

Loren: It was never really a decision. It was obvious. There were these turn-based APIs. Apple said, "Hey, they're new on iOS 5," and I figured I could target iOS 5 and iOS 6 and up. It just seemed obvious. Why wouldn't I use the turn-based APIs to make a turn-based game for iOS?

Rene: Why re-invent the wheel?

Loren: Right.

Guy: Well, because he just did it for UIKit.

Rene: [laughs]

Loren: Yeah, that's definitely...I have to take small bites though.

Guy: Did you find yourself structuring the app around the GameCenter APIs?

Loren: Yeah, eventually. I completely misinterpreted the way the GameCenter APIs work. Because it's this weird...It's straddling the line between being stateless request-response-style APIs, versus stateful, I-have-these-objects-that-change-on-their-own, style. I don't think the API really knows what it wants to be.

If I were redesigning the GameCenter APIs, I would expose two levels. Level zero would be totally stateless, item-potent, request-response-style things. Don't even hand me model objects, just dictionaries back and forth or something. On top of that, I would build this stateful, nice object-oriented thing, where I have game objects, and you can observe them with KVO, or they fire off notifications when game state changes.

But right now, the way the API is designed, it's doing both, and it's inconsistent.

Guy: You don't have that solid level-zero basing that you can build your own stuff on.

Loren: Right, and I completely misinterpreted it as a level-one API, where it's like, "I have these objects, it's nice and easy," but no. I need to keep my game state in sync with GameCenter local state, in sync with GameCenter service state. There's lots of state that's really easy to get...

[crosstalk]

Guy: It's a three-layer stack.

Loren: Yes. It's very painful.

Guy: Do you regret using it? Would you change it?

Loren: No. As painful as...I guess at this point my interests and Apple's interests are aligned. Anything I can do to make GameCenter better, I would be more than happy to do. I don't know if I could have launched Letterpress without it. I would have had to invest a ton of time and energy into building my own backend. Who knows what Letterpress would have looked like if I had to do that?

Guy: I think that this is the way that a lot of the APIs that Apple puts out go. They save you so much work that using them is effectively a no-brainer, but earlier on in their life they were rough around the edges, and they end up causing some pain that you can't necessarily address yourself directly.

Loren: Yeah, totally.

Guy: I think Core Data is a little bit like that.

Loren: I still don't use Core Data.

Rene: [laughs]

Guy: Yeah, no I don't either. A bunch of people have sworn off it. But then there's a bunch of people who really love it, and know exactly what to do with it.

Rene: Is there a danger in...For GameCenter in particular, it strikes me that Apple doesn't have anything on the iPhone built in or in the App Store that uses GameCenter, so they don't particularly feel any pain when it's not working. It's always going to be people like you and other GameCenter developers that are going to find the problems first, or hit into the pain points first. Is that something that weighed into your decision?

Loren: Honestly, I think that's an awesome insight, and I didn't even think about it when I was originally making the game. Even Microsoft…I feel that the ultimate battle is going to be between Apple and Microsoft in the living room. That's when this gaming thing is going to come to a head. Microsoft has got a bit of a head start.

Rene: Microsoft, like Sony and like Nintendo, makes first-party titles, so in effect they're dog-fooding all of their APIs. They often make the most popular, most successful games on their platforms.

Loren: Yeah.

Guy: Having worked in that biz for a number of years, developing for the Xbox is a pleasure compared to developing for the PlayStation, or even Nintendo. They are easier to work with, but they're still harder to work with than just getting on the App Store. You've still got to jump through a lot of hoops.

But yeah, I think you're right, having the Xbox in the living room, playing Blu-Rays, or it doesn't play Blu-Rays, whatever, DVDs. Everything has Netflix now, but it's got a lot of functionality that iOS also has. Xbox Live is really impressive and connects a lot of people in a lot of interesting ways.

Rene: A lot of titles are being deployed on Xbox Live Arcade almost as fast as they are on iOS now.

Guy: Yeah, exactly. I think you're right. I think ultimately, for the living room stuff, that'll be where things come to a head. That said, that doesn't mean that Apple loses anything. I don't think they need to win that battle necessarily. They've still got...all the handheld devices are super-popular.

Loren: Yeah, I don't think, obviously, Microsoft doesn't have to lose for Apple to win, and that kind of thing. But GameCenter is going to be more and more important.

Rene: What kind of scared me is that Apple has this reputation for not getting social, and this reputation for not getting gaming. Now Apple's putting out something that's basically social gaming. It would behoove Apple to have, like a gaming and social Tzar. I noted in the press release they gave maps and Siri to Eddy Cue, for example. But there was no mention of giving Game Center to anybody.

Loren: Yeah, I don't know who owns Game Center. But, it is true. I just added a send friend request button into Leterpress 1.1. The way it works is you tap this button and then t brings up the standard Game Center sheet where you can type in an email address or a Game Center user name. You can send a friend request. Then you can play them on Letterpress.

The strangest thing about it is, if you type in an email address of someone who doesn't have a Game Center account it just throws back this really, like, obscure error. It’s the perfect opportunity to send them an email. Like and on board them into the Game Center ecosystem. It's like, "You're friend wants to play this game with you." It's a perfect way to get someone to play, but it doesn't do that. The person you send the invite to has to already be set up with Game Center.

Guy: I should introduce you to my friend.

[laughter]

Guy: Yeah, that's a good...exactly. It's exactly that thing that Apple really doesn't quite get all the time. Yeah, it's sort of unfortunate. On the other hand, they are way more game friendly now than they ever used to be, certainly since the introduction of iOS.

Loren: Yeah, games have totally taken over the app store.

Guy: Yeah. I'm sure you can speak to this, Loren…a lot of work on the Open GL stack goes towards improving performance in games, especially on the Mac. I don't know how true that is on iOS. But, I mean, I don't...it's not a second order thought, supporting games on iOS. I think it's...

Loren: Yeah. I guess I'm a little biased because that's my old team at Apple. But it's, without a doubt, the best, like, mobile open GL implementation on the planet.

Guy: Oh, by miles.

[crosstalk]

Loren: Yeah, It's not even close.

Guy: Did you see those, I mean I know you did, but the blending shaders?

Loren: No. I haven't seen that.

Guy: Yeah, you can, for, instead of just your blend mode you can actually put a shader in there.

Loren: When did this come out? [laughs]

Guy: iOS 6, I think.

Loren: No shit. Oh, I got to check that out.

Guy: It is crazy the amount, the stuff you can do with that it just... bananas.

Loren: Yeah. Oh my God that, like, the most exciting thing I've ever heard.

Rene: [laughs]

Guy: I know. I was like... because it was just on a couple of slides. I'm like, "What the fuck?" Oops, sorry.

Loren: Is it like a fragment shader style thing where you just get two inputs?

Guy: Exactly, yeah. I haven't looked into it that much because I...it's one of those things, it's like...I think that you probably are similar with this given how many projects you say you've got. But if you get excited about something you just go and do it.

Rene: [laughs]

Loren: Yeah.

Guy: To the exclusion of getting actual work done. I was so excited about that I'm like, "You know what? I don't want to look at this. I got to ship my app and do some work, you know?" But I will eventually get back to it.

Rene: I noticed that when you did do Game Center, for example, you did matchmaking. You did turn based. But, you stayed away from things like challenge. Challenges are almost like spam on Game Center for me. Was there a lot of stuff that you picked and choose from very carefully?

Loren: I think it was more of a function of time. I do still...I wanted to and I still want to do achievements and leader boards. But I'm not exactly sure what they look like. I honestly haven't seen challenges. I didn't read any of the documentation on it. What, exactly, is that?

Rene: You can challenge people to,, I think one of the biggest examples now is there's an extreme road game where I wake up in the morning and 20 people have challenged me to beat their road racing time.

Loren: Got it. It's like "Horse", almost?

Rene: Yeah. I guess so. I guess it's a way, because I don't have the app installed. I guess it's a way for Game Center to push you toward downloading or buying other apps.

Loren: Huh. Yeah, I guess that makes sense.

Guy: That would kind of annoy me.

Loren: [laughs]

Rene: Yeah, there's not filtering. For example, you can say only accept challenges from contacts. But, I play Letterpress with a lot of people who aren't in my contacts. Also if I turn off those notifications I don't get Letterpress notifications. There's no granularity to it yet.

Loren: Yeah, a lot of people have complained about the lack of granularity for notifications.

Guy: Yeah, notifications in general are a sore spot for the OS, I think. Especially if you get a lot of them.

Loren: Yeah.

Guy: I was curious when I saw the app, you have themes in there. Why?

Loren: Uh...

Guy: I know that's a silly question. I know it's reasonably easy to implement. But I thought it was interesting and a bit, um...I don't really want to say unnecessary, like it's pointless. But it was a curious decision.

Loren: I see it as a "cherry on top", for the in-app purchase. Because it's one in-app purchase to unlock the whole thing, I don't nickel and dime you with like a dozen different things or like, "It's $.99 per theme."

Guy: Oh, I hadn't realized the themes come with the purchase.

Loren: Yeah, you only get the default theme by default. Then you unlock it for more than two games at a time, and the ability to see play words and stuff.

Guy: Oh, OK, that's interesting. That's what I get for just buying it on the spot.

Loren: [laughs] Well, thank you.

Guy: Do you have any other pans for in-app purchase? It seems like word packs could be interesting.

Loren: Yeah. Someone had the idea for an urban dictionary word pack. Which I think would be so awesome.

Rene: That’d be great.

Guy: Yeah.

Rene: It's interesting the way that you went with in-app purchases. You said that you didn't choose...I think your language was you, "...didn't choose to optimize for in-app purchase." But, with regard to themes, when there's no themes in something people complain almost immediately. For some reason, mainstream users, love them their themes.

But, also, we've hear repeatedly that, for example, advertising. Turning off advertising is not something that incentives people to pay an in-app purchase. But, you seem to have found a good formula where you get enough functionality in the basic game. You, it's almost a no-brainier to pay for the upgrade.

Loren: Yeah. Letterpress was an experiment in a lot of ways. It was an experiment exactly in that regard. I had no experience in building a free app. I had no experience with in-app purchases before. I remember back in the Tweetie One days everyone wanted a dark theme. On Tweetie One I added a dark theme. That was one of things that actually helped it start to take off. I eventually removed the theme options in Tweetie Two. But, by that point, it was already a popular app.

Guy: Was that in reaction... were the users reacting to Craig's work? On Twitterific?

Loren: I bet, yeah. Because they were so used to the dark theme in Twitterific. They didn't like the light one in Tweetie.

Rene: A lot of people have angry spouses who get upset of the screen is bright in bed.

[laughter]

Loren: Yeah. Yeah.

Guy: Maybe you don't want to say this on the air but Rene can fix it. How do you feel about Twitter?

[silence 23:51 to 23:54]

Loren: I don't know. I'm conflicted about it, because, to me, I see apps like Tweet Bot doing awesome work and doing nothing but make Twitter better. Their market share is so small that it really doesn't affect Twitter in any way. It’s like a flea on their back. But it's a flea that actually making Twitter users happy. That analogy I've stretched it way too far.

[laughter]

Loren: I don't know. It confuses me that they're trying to shut it down. I guess it just confuses me.

Rene: They didn't think of a more creative way where they could both appeal to their advertisers that they want to bring on board but also keep something for the very small niche of original/hardcore users that value those kinds of apps.

Loren: Right, yeah. I don't think anyone would argue that it doesn't cost Twitter a ton of money to run the service. Third party developers absolutely should kick in if they're going to be making money off of it. At the same time if users are using an app they should be able to see Twitter ads if that's what Twitter wants to show them.

Rene: I always thought it would be a nice thing if Twitter just said, "All advertising belongs to us. We're serving it along with timelines. You cannot filter it out. But if you want to make money you can just charge for your app. Advertising is ours, charging for the app is yours. You're a miniscule part of our audience segment anyway. Just go on about your business."

Loren: Yeah, that seems like a creative and simple solution to me.

Rene: Which means it will never ever happen.

Loren: At the same time I've never built a billion dollar company. My opinion doesn't really mean much. Twitter might be doing exactly the right thing to ensure their future.

Guy: Yeah, that's what I always end up finding myself thinking if I'm ready to talk about Apple. It's just…

Loren: [laughs]

Guy: …it's not in my league. It's like I don't know. It's too big. It's not like any experience I have can help.

Rene: It's creeping decimalism, it's just the numbers are way too large.

Guy: Maybe.

Rene: It occurs to me, Loren, that you've made a bit of a practice of writing against very new, not really hard and not really tested APIs, because you had a very early Twitter client and now you've got a very early all-in on Game Center. Game Center's not new. But someone going all-in on it has not been that common. Is that a way to test yourself? Do you like those kinds of challenges?

Loren: [laughs] That's funny you brought that up, because I actually had that same realization a couple of days ago.

[laughter]

Loren: It’s like going into bad relationships with the same person over and over again. It just...No, this was totally unintentional. I'm realizing that about myself. I don't know if that's necessarily a good thing.

Guy: Well, I think you, like me, and like were saying about the open GL stuff...You get excited about something new. You just want to try it. Work against it. That often leads to building on something unreliable, because you're, I think...at least in my case my excitement can often outweigh a more rational decision making tree.

Loren: [laughs]

Rene: But you're doing disruptive work that way. You're really pushing the bleeding edge. A lot of Twitter apps follow Tweetie, and I'm sure a lot of Game Center apps are going to follow Letterpress. You get to be there on the frontier.

Loren: Yeah, yeah. No, there's definite pros.

Guy: Would you consider writing against another online service? Not necessarily doing a client like a Facebook client or something like that, But relying on an online service that's not under your control for the core functionality of your app.

Loren: Honestly, I think I'd like to end that phase of my life. I'd like to take inspiration from Apple, to a degree, and own the pieces of technology that I need to own to make successful products.

Guy: More like what Marco does with Insta-paper kind of thing. Where you’d run it like [indecipherable 27:41]

Loren: Yeah.

Guy: How are you at back end stuff? Because I'm pretty awful.

Loren: PHP was one of the first languages that I learned. I know that, I know Ruby, I know Python. I'm teaching myself Go. I can use Google app engine and EC2. Like, all of things I can do. It’s not my bread and butter, and unless you do it day to day you can't be an expert at it.

But the first thing I built when I left Twitter, this was my first side project, experiment, was basically Objective C server sides. I brought up LLVM, Lib Objective C2,and all that stuff on LINUX. I basically... think noJS, but compiled Objective C. It's the right architecture and it's also compiled in fast. You don't have to deal with a frigging JavaScript interpreter on the back end, which doesn't make any sense to me.

Guy: That's great. You can basically port code easily up to a server.

Loren: Right. I can have Objective C client side and server side that's shared. If I want to validate game state and stuff, I don't have to write all that stuff twice.

Guy: Right. That's great. That's a very good idea.

Loren: It's Web Objects. It's like a much better version of Web Objects if Web Objects was still around.

Guy: Right, well it is, but only internally. It drives the store...

Loren: Yeah. [laughs]

Guy: ...drives the store and all that kind of wacky stuff. Web Objects was really cool in its day, I got to say. Especially when the Objective C stuff?

Loren: Oh, yeah! That today would be killer.

Guy: I know. Yeah, it blew my mind back in the day. It's...I don't know. They "JAVA-ized," right? For Web Objects Six?

Loren: Yeah.

Guy: Then it was eight-hundred bucks, and they dropped it down to like $90 bucks or something like that?

Rene: It went on clearance.

Guy: Yeah, and then it just went away.

Loren: That was a weird rift, though. Why did that happen? Why did they take...why did they adopt Objective C, like...? They were going to drop Objective C client side also. They were going to go JAVA everywhere. I don't understand why they didn't just keep Objective C on the server side too.

Guy: I think the issue was that they wanted to be able to run on other servers. Like, with the JAVA one it would run on Sun servers a lot. In different...I'm trying to remember the terminology, but like basically an app server thing, would be like it would run a Java instance. If it was written in Java it was easier for them to get it supported on these other platforms.

Loren: But you could just compile the code. You just compile the code for Sun.

Guy: Look, I don't disagree with you.

[laughter]

Guy: I think the thing is that these app servers would clone. Like, it'd basically be little VMs, right?

Loren: Yeah, that makes sense.

Guy: I totally agree with you. I would do the same thing. But again, I don't run a billion dollar company. At the time, it really did look like...

Loren: [indecipherable 30:31].

Guy: Well, yeah. Things were weird for Apple at the time, right? They had the Java bridge client-side. I think WebObjects lasted longer than it should have because it's more or less what kept NeXT alive long enough to get bought. At a certain point they stopped effectively selling the operating system. It was way more focused on WebObjects stuff.

I don't know. It's had a weird, long life. But I think they're way too married to it now, which is disturbing.

Rene: It's kind of there, they kind of use it. It’s like an old battleship, not decommissioned.

Guy: But it's really hard to get new talent that knows what they're doing with it.

Loren: Nobody knows how to use it anymore. I just have visions of all this amazingly cool stuff you could do with like LVM server-side. VM, doing basically exactly that only making it good.

Guy: Well, so I figure that's your next project? You can do something crazy server-side.

Rene: The decision to go free with Letterpress is something that also fascinated me. Because you hear a lot of times that people will pay 99 cents for an app almost as much as they'll go for free, and that it reduces your tech support burden. It reduces the chances of bad ratings on the App Store because it's not just tire-kickers, it's actually people with an investment in the app. But you went right for the free price right away.

Loren: Yeah, I'm sure I could have made more money charging like 99 cents or $1.99 off the bat. I've no doubt that I could have made more money that way. But going free, again, it was an experiment.

I wanted to feel out what the free side of the charts looked like and that kind of thing. It's tough. The App Store has definitely changed since the Tweetie days.

Rene: Well, it's odd now, because when top grossing first came out, it was a bunch of apps like NAVIGON and like the iWork apps. Now, it's a lot of apps that are basically free, but with $99 Smurfberry purchases built in with them. It's not only a completely different environment, but a completely different metric by which these apps are measured.

Loren: Yeah, it's nuts. I mean, Tweetie Two topped the grossing charts, and it never would be able to do that today. Not in a million years.

Rene: Not unless you had a $99 Smurfberry purchase in it.

[laughter]

Guy: Do you find that it's more competitive, or just basically like a total blowout, like it's really hard to get anywhere? That's a poorly phrased question. The scale of the App Store is so much bigger. Does it feel like you can compete, or does it feel like you're just, it's always going to be a ripple in a pond?

Loren: I don't know. I guess the scale has changed. Apps are big nowadays and I feel like, thanks to Rene, I had a really good launch. The app is holding its own, but I mean companies like Zynga they just have so much push. They can do whatever they want.

Guy: Right. Yeah, and hopefully go out of business doing it.

Rene: Well, it's interesting though, because the App Store was really the first leveling of the playing field for independent developers. Because whether you were Loren Brichter making Tweetie or you were a giant company…whether you were a game developer like EA putting out an app, you were still…basically had the same rights and privileges on the App Store.

But now, just by sheer volume, it seems to have shifted to marketing, market awareness, and the ability to drive people to your apps. That gives the big, entrenched players again, I think, a bit of an advantage.

Loren: Yeah, I mean, Apple certainly helps. Apple featured Letterpress, which was huge and amazing. I think Apple is trying to level the playing field, and I think they're doing a good job of it. But, I don't know how Zynga does what they do. Like, how do they get so many people to download Words with Friends?

Rene: It's really an evil use of psychology. I don't know how deep you want to dive into it. If you remember the tulips a long time ago, tulips had more value than gold, and there's nothing about a tulip that's intrinsically valuable. But there's an ego investment on it. If you have something that your culture determines is valuable, you will spend a lot of money about it.

Games like Zynga, people will not spend 99 cents on a game, but they will spend $100 to have a better looking hut than their friend, because that gives them a huge ego payback, which is the foundation of gamification. All these games are very good. They do a ton of psychological mapping, they do a ton of behavioral analytics. There's a lot of big data work going in to analyzing when people stop playing, when they start playing, how their friends react to things that they do.

It's really a...I don't know if I should call it evil, but it's really an evil application of psychology that makes these games addictive. There are gambling games on the store where you can't win anything because that's illegal but you can pay a lot of money to play the game. These are routinely on top of the grossing charts.

Loren: Wait, it's legal as long as you don't win anything?

Rene: Yes. As long as you just give them money to play, it's fine. They have huge amounts of revenue.

Loren: You can win like coins, but as long as you...

Rene: You can win in-game coins, but you can never cash them out. You can put money in to get new in-game coins, but you can never remove that money again.

Guy: This seems like a bad investment, call me nuts. Call me nuts.

Loren: [laughs]

Rene: But you get to be the top player on this thing, and all your friends see that you're the best. It does provide humans with a big a gratification. It's something that we care about very desperately.

Guy: It's very cynical. I guess in a way, game design is that in general. Because the thing is, there's a purity to try to maximize for somebody's fun or enjoyment or challenge, rather than for the amount of money that you're going to get. But in the old days, the arcade games were pretty much designed like that, too. The cabinets were geared to keep taking your quarters. It's not that much different.

Rene: Loren's doing that differently, because you're letting us have a one-to-one relationship where I don't have to spend money. I just have to play that awesome curse word and totally destroy someone on Letterpress and I get an immediate…I immediately want to play again.

Loren: If I was trying to optimize for profit, the game would be totally different.

Guy: I'm not sure that's obvious to most people, but certainly when I play that game, I'm like you're just leaving money on the table somehow. I don't know how. But it feels very pure, it feels like a game that you wrote because you wanted to play it, and you shared it.

Loren: Yeah, and that's exactly where it came from.

Guy: Which I think is great. That's exactly…I wish more software came with that philosophy behind it.

Rene: I'm guessing because you were once bought by Twitter, there's no chance that Letterpress will get bought by Zynga.

Loren: No, no. I think that selling Tweetie to Twitter was a good move for all involved, definitely at the time. But I'm done selling companies.

Guy: Oh yeah? OK, that's good news.

Loren: [laughs]

Rene: Well, you did. If we look at it, with Tweetie, you made basically the client that everyone thought Apple would made if Apple ever made a built-in Twitter client. Then with the iPad version of Tweetie, you made one of the first true large-screen tablet interfaces that we saw on the iPad, because until then, a lot UIs were just stretched apps, or two-column versions of apps.

But you did sliding panels, you did a lot of innovative work. It seems like that goes back to the challenge. You're not content with making just an app. You always want to do something a little differently.

Loren: Yeah. Twitter for iPad was a ton of fun to make. I think if it had another two or three months in the oven, it would have stood the test of time. But it wasn't quite finished, it was never quite finished.

Guy: Atebits started on the Mac?

Loren: Yeah, with Scribbles.

Guy: Which I was...I remember when you released that and I was jealous. I'm like, man I wanted to write that app. Like a very basic scribbling app.

Loren: Everyone remembers MacPaint. How does MacPaint not exist anymore? It's such an obvious idea for an app. You want to doodle a little picture, and there's no built in apps for it.

MacPaint was my inspiration for Scribbles. It was also my first attempt at my own custom UI framework. Because Scribbles also was completely OpenGL and it was a mess. It was basically one big file that did all the drawing.

Guy: Oh my God.

Loren: It was a nightmare.

Guy: Oh my God. The very first version of Tap Tap Revenge was one file…

Loren: [laughs]

Guy: This guy, Nate True, who's a brilliant hacker, like he would tinker up his own watches and stuff. But man, it was his first, like My First Program. It was like one giant 5,000-6,000 line .AM file.

Loren: That's awesome.

Guy: Yeah, it was kind of awesome. We rewrote that pretty darn quick. But it was fun while it lasted. You've got a thing for doing your own custom UI frameworks. Which is funny because I, again like during when I was doing game work, I used to love writing the UI stuff, because you'd have to write your own UI framework in the games.

Loren: Sure, yeah. You had nothing to work with.

Guy: Yeah, and it was a blast. I don't know if I'd do it on the desktop so much.

Loren: Then there was TWUI which was basically the UI kit for Mac thing. I don't know what's going to happen with it.

Guy: Yeah, well, they own it now, right?

Loren: Yeah, but it's open source.

Guy: Does anybody use it?

Loren: Yeah actually, I think Clear for Mac uses it.

Guy: Oh, that's interesting. Now that's an interesting app to me. I don't like it.

Loren: [laughs]

Guy: But I mean that in the best possible way. Like, it's fascinating. I love that it exists. I just can't use it. It's just a little too out there for me.

Rene: Doesn't fit with your use-case.

Guy: Yeah, maybe it just says that I'm conservative or something. I don't know.

Loren: It's definitely very modern. I love the things that they're experimenting with, though.

Guy: Oh yeah, exactly. I love experimentation in any form. I love that it exists, I just can't deal with it.

Rene: It was an interesting experimenting in mapping an almost entirely gesture-based iOS app into a Mac app that requires the use of keyboards and touch pads and things.

Loren: I would love to see Clear with, have you guys seen the Leap?

Guy: No.

Rene: Yes.

Loren: I don't who said no and yes. It's where you can move your hand in front of your screen, and it's got like the cameras on the desk.

Guy: That is amazing, I love that thing.

Loren: I mean Clear, an app like Clear with a Leap I think would be really cool to use. Because it's all like hand gestures, "Minority Report" style stuff.

Guy: Yeah, I totally agree with you. That would be amazing. I want those to exist. Like as well, I mean, I want them to be a standard part of the system as soon as possible.

Loren: It seems like the Leap works really well, at least from the videos I've seen.

Guy: Yeah, exactly. It seems like it's relatively easy to incorporate into say a laptop with it, because they've got the big chin underneath the keyboard.

Loren: Yeah, it's true.

Guy: There's like, the technology matches common form factors, such that it's...I don't want to say it's not that much of a Leap.

[laughter]

Rene: Nice.

Guy: It's not that far of a stretch to incorporate the Leap technology.

Rene: It seems like a better solution than actually putting your fingers on a iMac or MacBook Pro screen.

Guy: I think so, yeah definitely. Yeah, I got a little off track, but would you ever consider going back to the Mac?

Loren: Letterpress runs on the Mac right now. I don't think I'm ever going to release it though. Because the market, I don't think it's big enough.

Guy: That's crazy talk, dude.

Loren: [laughs]

Guy: If it's running; I don't know, it seems like free money to me. But I guess you have to…there's all the support and all that pain in the ass stuff.

Loren: The Mac to some degree reminds me more of Android, where there's just so many configurations and so many ways for software to not work. It might be a little bit more effort, but it's going to be double the support costs, even if it’s only 10 percent of the market.

Guy: Yeah, since you're all GL based, there's variant, variations in the cards and the capabilities and all that. Although, you don't seem to do anything very...sorry, I don't mean it like that. But, you don't use a lot of multi-texturing, you use pretty much as far as I can tell, quads with just color verts.

Loren: Yeah, basically.

Guy: It relatively straight-forward, it seems like something that could be done in GL 1.2 kind of thing.

Loren: Yeah, no. It definitely could, definitely could.

Rene: You mentioned previously that you're working on the next version of Letterpress and there's a lot of things that people keep coming up with. For example, people want a button to instantly rematch the person who just beat them at Letterpress, and they want, you mentioned, achievements.

How do you start filtering what's going to go into the next version as opposed to what will never be in the product and what's going to wait for future versions?

Loren: I basically am going to put everything on the to-do list and then sort it. Then whatever I have time for, I'll do. Rematch is in 1.1, and I have a mysterious Apple engineer to thank for a workaround to get it to work in OS6. But you need OS6 and up for that button to show up.

After that, one thing I'm working on now is a way to share and replay games. When a game is over, you'll be able to tap a button and share a link. That link will take you to like an HTML5 version of Letterpress where you can scrub through the game or tap play and it will replay all the words.

Rene: That's a great idea.

Loren: Yeah, I think it will be popular, but it's reminding me how much I hate web development.

[laughter]

Rene: Was that an important factor? Because Instagram just put out Instagram profiles. They were resistant to anything that wasn't a mobile experience for a long time. Now they're reluctantly, I don't know if it's reluctantly, but they're finally adding web profiles. What was the decision-making process for doing the HTML5 version?

Loren: There's just no other way to share. I want people to be able to share their games with people who don't already have Letterpress installed. That's the only way people are going to learn about Letterpress.

They're like, “Oh, who made this game, how do I download it?” There's a big download link right beneath the game. You can't just share app to app. HTML is this perfect fallback. As much as it sucks it's perfect.

Rene: It’s terrible, but it's the best solution possible.

Loren: Yeah, like democracy.

Rene: Absolutely, or Skype.

[laughter]

Guy: Exactly…God…Do you feel guilty about not knowing much or being super comfortable with web development? Because I do, I feel it's a bit of a blind spot for me.

Loren: there's not really a ton to learn, HTML, CSS and JavaScript. It is what it is. The only things you need to learn are how to work around all of the issues in every single version of the popular browsers. It's not a skill I really care about. I'll just go to Stack Overflow and figure it out on the fly.

Guy: Right. Yeah, I know the basics, I know how to set everything up and do something. But I haven't actually really worked on a web project. I think that it's a false debate between the web and client code. I think that it's not a binary thing, there's always going to be some gradiation in between there. But I do feel like I'm developing a blind spot for web-based stuff that I should probably try to deal with.

Do you have any holes in your knowledge that you wish weren't there?

Loren: I'm sure I do. I guess my problem is I don't know what my holes are.

Guy: That's a polite way of saying that you know everything.

Rene: [laughs]

Loren: I know everything that I know.

Rene: I don't know what I don't know.

Loren: If I know about something that I don't know, then I'll make a point to learn it. Doing this HTML version of Letterpress, it's not the full game. It's just like a replay code. But it's nice circling back and learning about all the things that you can do. Because the last time I made a real website it was a couple of years ago.

Now you have reliable…you can kick it into hardware accelerated mode, with some janky CSS and canvas. Like the canvas element, I never used that before. It's nice.

Guy: Canvas makes me feel good, because that basically just drops me back down to all the graphics stuff that I'm very, very capable of doing.

Loren: Yeah, and it seems supported enough that I'm going to rely on it.

Guy: Actually, I didn't plan to go this direction. But you've worked on GL stacks, you're a very graphics-capable guy, WebGL seems like a bad idea to me.

Loren: Because of the security stuff, or for another…?

Guy: Yeah, exactly. I'm pretty aware of how badly you can lock up a machine by mis-abusing OpenGL. What are your thoughts on it?

Loren: I want it so desperately, because if you give me WebGL, I can take over the world.

Guy: Exactly, but you can also take over machines.

Loren: [indecipherable 47:59]

Guy: Sorry, say that last again.

Loren: I don't know how to fix those security issues.

Guy: That's exactly my thought. I want this so badly, but the ability for the developer to write a shader that can lock up somebody's graphics card is...I don't know how you can possibly guard against that.

Loren: Yeah, I know.

Guy: Even if you try to analyze the code and see if it's going to lock up in some way, I mean you're going to miss a case. It's a huge security problem.

Loren: How is native client going to do it? Because native client doesn't give you WebGL, but it lets you execute GL code through, what is it called, their Pepper API. I don't think they analyze your GL code there.

Guy: No, but a native client can basically do anything. I do think there is an issue with any time an app can access a shared computing resource that can possibly get locked up I think it's effectively a security problem, right? But at least a native client you've downloaded it's been, now these days through the App Store has been signed and all that.

Loren: The only way to use native client apps is through the Chrome Store?

Guy: Through the Chrome Store, is it? I don't know, do you know Rene?

Rene: To use Google's, yeah. I don't know if anyone else is deploying them.

Guy: OK, either way, I just think clicking a link and getting your computer locked up because of WebGL is a real possibility and it depresses me, because I think it would be amazing.

Rene: We've put up with that in Flash for so long that I think an average user, no, I’m just…

Loren: [laughs]

Guy: Well Flash is interesting, because at least they...here's the thing with the graphics lock-up. Flash is interesting because if you click a link and it freezes, well at least you can put Flash in a separate process. If WebGL locks up your graphics card, it is a component that is shared by the entire system. You can't wall that off as effectively, right?

Loren: Ultimately, the solution is to have drivers that are a little more robust.

Guy: Yeah, like the drivers...

Loren: The actual hardware, people might exploit real hardware issues, and there are still tons of those, so I guess you can't get around that.

Rene: There's also, Palm was working on Open, on WebGL. Now Research in Motion is working on WebGL. There's a lot of people trying to bring it to mobile because they're basing a lot of their development kit on HTML apps. I think maybe, cross the fingers, those are problems that will get fixed as development on Web GL it's self continues.

Guy: I hope so, I just don't see a way of fully safe guarding it. I don't know it's a bit weird. It's interesting. I would love to see that work out.

Rene: I guess we are just going to have to keep building native apps.

[laughing]

Loren: Exactly, Yeah, I mean I didn't write about it, I meant too, but when the Web GL stuff came out it was Microsoft just took a dump on it and said, “Look, this is just a bad idea, and we are not going to support it,” because of its security. Everybody was making fun of Microsoft like, “Oh, these guys are lame,” but I was actually, “No, they've got a point.” They been bitten by security issues for the past 15 years. I'm pretty sure they're sensitive to it. Anyways, hopefully it all works out.

Guy: Yeah, hopefully.

Rene: Loren you went from Tweetie to making a game, and you said you are working on other games. It sounds like you really consciously really want to do something as different as possible from Tweetie. Are games going to be the future or are you going to have a variety of projects?

Loren: Probably a variety. I have no interest in creating a game studio or anything like that. I just kind of wanted to feel out what the game side was like and I just wanted to make a game that I could play with my wife.

Guy: Don't get into the game studios, dude.

Loren: No. [laughs]

Guy: It's a lot of work and the money that you need, the amount of capital that you need, to do anything decent art work wise is immense. The business is pretty brutal.

Rene: It's like movie studios.

Guy: It's very much like move studios, yeah. It's pretty much a hit driven business.

Rene: Investment banking.

Guy: Yeah. Not that I don't want more games from you. I do, but...

[laughter]

Guy: …don't bank on getting hit games because it's just not going to happen no matter how good they are.

Rene: I want to actually ask the most impertinent question possible. Loren, who is better at Letterpress you or your wife?

Loren: Believe it or not, this is ironic, but we haven't been playing against each other all that much. I've been playing against a lot of other beta testers and she's been playing with all of her friends. Every now and then we will have a match. I think she's destroyed me the last couple games.

Rene: Is she tech savvy or is she someone that you beta test against as being a more mainstream user?

Loren: No, she's definitely tech savvy, but she's also more mainstream than me.

Guy: This week, well I think late last week, the word list for Letterpress got leaked. I haven’t actually looking at the package, maybe it's just a text file, I don’t know...

Loren: Yeah, just a bunch of text files.

Guy: Yeah, I figured. There's now a Letterpress solver app out there. How do you feel about that?

Loren: There are actually many of them.

Guy: Oh, OK. I know one, because somebody asked me to beta test it. I'm like, “No, I'm not going to.”

Loren: [laughs]

Guy: Do you have any thoughts on that?

Loren: Basically, it boils down to it's impossible to solve without having server-side verification of moves. I can think of a couple ways that Apple could cleverly let me verify words on the server, but I don't think that's going to happen any time soon. It seems to me that cheating is inevitable. Play your Game Center friends, stop playing random opponents, which sucks.

Rene: You can also tell they're cheating because it's words that have no semblance to reality coming up.

Loren: Right. Also there's no way to report cheaters. It would be cool if you could bucket cheaters into one Game Center-like auto-match sandbox thing, so they don't play regular...

Rene: I have a feature request. If somebody ever plays an unreal word, or even if they play something like irregardless. If they play something like irregardless or a made up word, the screen just explodes on them.

Loren: [laughs]

Rene: It's like the reverse of a fatality.

Guy: The phone just reboots. I had a bug years ago, when I was playing Wing Commander 2, on my PC. There was some bug, I don't know, on my PC's whatever. Every now and then, when my ship would get hit and explode, final damage, and it would go to change the camera to the outside view, so you could see it exploding, my computer would just reboot, which was awesome.

You'd get hit by a missile, and the screen would just go blank. The reboot prompt would come up. The old school IBM BIOS thing would display. That one counted. That really hit home.

Loren: It's one step away from Whopper asking you if you want to play a game.

Guy: Exactly. It brought my defeat into my real life, pretty much. Regarding cheating in Letterpress, one thing that's good about it is that I did a lot of work on tap tap revenge, and a couple other games, in order to block cheating, because those are the kind of games that kids play. They would figure out ways to cheat or hack the servers, so they could get rewards, so they could buy other tracks and stuff.

What I like about Letterpress is it's in that brainier category, where you're not targeting a market that's particularly interested in cheating. You're targeting a market that's interested in having a good game. You could cheat at the crossword puzzle in the "New York Times."

Loren: But you're cheating yourself.

Guy: Exactly. I wouldn't worry too much about it. I just find it...It's almost a weird tribute that these solvers are on the market.

Loren: Yeah. It seems like all the solvers that have popped up have been like, "We love Letterpress and we did this because it's fun to hack." Not because they like to cheat, just because they wanted to hack. I think that's a great spirit.

Rene: Although I'd check their win-loss ratio before you say that too loudly. Maybe they were just terrible at the game.

Loren: [laughs]

Guy: I have lost every single game I ever played. I swear to god I thought of writing a solver...

[laughter]

Guy: ...just as a joke. I'm terrible at this game. You make me feel stupid. I don't know why.

Rene: It's a strategy thing. Loren, you actually made a huge change to the game-play mechanics halfway through the beta when you created protected letters. Beginning it was all like random, you tried to make the coolest word that you could make. But now it really behooves you to protect letters and start coloring the board from one end to the other. Almost like a red zombie horde descending on the poor little blue squares that remain.

Loren: Yeah. Actually it was unintentional that that was halfway through the beta. That was actually at the end of the beta and I was a day away from shipping it to Apple. It was actually Marco Arment who brought up the fact that the game got a little tedious. That's what forced me to go back to the drawing board and come up with the new game mechanic.

Rene: Can you go into a little bit of the beta process because you had a smallish beta and then you increased the size. You had a fairly good sized group of beta testers towards the end.

Loren: Yeah, my beta testers were...you weren't in on it, but they were fantastic.

Guy: I was not, so...

Loren: I apologize.

Guy: Asshole.

[laughter]

Loren: I'm going to send you a hockey invite.

Rene: Everyone at Singleton was playing it under the table trying not to show anybody what they were playing but playing against each other at different tables.

Loren: [laughs] Yeah I heard that.

IGuy: You've got to come next year, man.

Loren: Yeah. I would love to.

Guy: OK. I'll make sure you get an invite.

Rene: Is there a size of beta group that you like? Do you need more beta testers for something like this than you did for maybe Tweetie?

Loren: This beta was actually I think a little smaller than Tweetie. I honestly think the beta testers have more to do with the success of the app than me. I ended up building a really great beta crew for Tweetie. Just the fact that they were beta-ing it and people found out that they were beta-ing it helped make the app popular. You guys did the same exact thing for Letterpress.

Rene: I noticed the words are interesting. For example, I've played "hobbit" and "Bilbo" which aren't normal dictionary terms, but "Vader" gets rejected. Is that a peek into your personal preferences?

Loren: No, I have not...The dictionary is about 270,000 words and I'll admit it, I haven't reviewed them all yet. But those sound sketchy and they might not go in the next version.

Rene: Well Atebits is in there. I have played Atebits to beat some people.

Loren: Yeah, that's my little secret.

Rene: [laughs] There's nothing better than playing someone's company name when you're actually playing a Letterpress game with them...

Loren: [laughs]

Rene: ...or their family name or something. It's just an added incentive.

Loren: Yeah.

Guy: Because I'm nerdy, you just mentioned that you may take out a couple of words. A lot of work that I end up doing is managing backwards and forwards compatibility so that old clients can play new tracks and all of that stuff. If 1.2 updates and it misses some words and you go look at a previous game, what rule set will be applied? Will it be included in the new words, will it not be included in the new words? Is that something you've even thought about?

Loren: I'm completely ignoring the issue.

[laughter]

Loren: Basically whatever version you have that's the dictionary that you can play. If you're playing someone with the newer app, and they have more words, or less words, then...yeah, that's that. In version 1.1 I'm adding more words than I removed, so it's...

Guy: That's good. That's backwards compatibility, right? But it's when you start removing words that things get weird.

Loren: Yeah.

Rene: You said previously that you weren't maximizing monetization for this, but I like the idea of paying developers because I believe the more money I throw at you the longer you'll be interested in making the game. I don't know if that's absolutely true but it feels to me like it's a good way to incentivize future development. Is this something that you're going to just always keep as like your personal project or do you see this becoming...I don't want to say a franchise but a bigger project down the road?

Loren: I don't know. I just want to see how it plays out. I definitely don't want to go sleazy with it, and start begging people for money, or get them to buy some coins or anything like that. I don’t think I’m ever going to make as much money as one of these giant sleazy game studios.

Rene: No buy a vowel for example.

Loren: [laughs] That's a great idea.

Rene: [laughs] Letter A ten bucks.

Guy: I would definitely do that.

Rene: Oh yeah, buy wild card letters. Yeah, it seems like there's a lot of potential for what seems like a simple concept.

Loren: Um yeah, yeah. I'm curious how it would potentially translate into the real world. It seems like it would be tedious to manage the states of the colors, and the state of protected tiles, but it could be a fun in real life board game.

Rene: Yeah. One of my favorite things to do, and I mentioned this to you on Twitter before, is I actually played on Airplay Mary on Apple TV and it's fantastic.

Loren: [laughs] That's awesome.

Rene: We mentioned working on the game center APIs and you're almost completely dependent on Apple for that. We had iOS6 last year, had some new things for game center. Presumably iOS7 will have game centers for, but Apple’s done something very interesting. They applied their standard product grid to their management team recently, and the long time head of iOS Scott Forrestal is now leaving the company, and his portfolio has been, Jonny Yi is now doing human interface, and Eddie Q is now doing maps in Siri, and Craig Frederique is now doing all of the OS. What do you think about those kinds of changes at Apple?

Loren: I'm most excited about Johnny Yi being head of HI, that has the potential to be so awesome, like I want to cry. Everything else, I don't think I have a particularly strong opinion about, but that is truly awesome.

Rene: You’re hoping he yanks attention to status bars immediately?

Loren: He’s the kind of guy who I think would appreciate bring true to hardware, just like he's true to aluminum, and true to glass. If you have an intuitive understanding of what graphics hardware is good at there's no reason why that shouldn't permeate all the way up through what it looks like.

Guy: I got to say that I think that is one of the things I love most about letter press. I saw on Twitter, or something, that you'd implemented all in OpenGL , I was like , “Well, yes it flows.” I could see how true to the capabilities of the device you were being. I think UI kit is similar, and a lot of those ways.

Loren: Yeah, absolutely, it gives you more surface area to jack it up.

Rene: Letterpress is incredibly digitally authentic, there's no real world analogues, there's no skins, things don't look like little gaming tiles, or corrugated cardboard gaming boards.

Guy: Yeah, as Loren just said, you can imagine it being a board game.

Rene: What would you like to see from the Apple management team for iOS? Is there specific things that you think that are still missing for you to make the kind of after you want to make question mark

Loren: XPC is right on the horizon, and I think that's going to be really, really exciting for iOS seven. It has to make it into IOS seven…

Guy: XPC is awesome, I love it

Loren: I don't know why it wasn't in iOS six. It's been on the Mac and it seems solid .

Guy: It's been on iOS since iOS five.

Loren: A really, they just haven't made it public.

Guy: Not exactly, yeah. Five beta, some headers, maybe Mac headers leaked…they do that macro declaration of when it's available.

Loren: Yeah.

Guy: And it had iOS five in it, so I wrote to an Apple fan being like, “You guys are leaking information here.” I heard back it would be public, but it's there. I think iOS seven is going to be very interesting, because one of the things is not well known about iOS six is that they broke spring board into two pieces. Springboard is the larger system.

Looking at the home screen basically. It used to be the springboard was in charge of doing all of the Window management, which meant that springboard itself would manage all the application windows and swap between them, and all of that. But it since in iOS six then broken into two pieces. There springboard, and there's backboard, and backboard is now basically the Windows server.

That is going to mean that there's a lot more opportunity to…a lot more flexible legitimately when does on the system, I think. Windows meaning basically the OpenGL context which all application draw into. I'm excited to see what that…

Rene: What the decoupling does for the...

Guy: Exactly, because between XPC and the ability to embed one window in another, one OpenGL contexts inside another, I think is going to be some interesting possibilities coming. Do you have any thoughts on that Loren?

Loren: Yeah you nailed it. Yeah I think it's going to usher in a whole new class of apps.

Guy: Right, I'm thinking not specifically but … The way that Siri does those plug ins, and all in that kind of way.

Loren: And also completely headless apps.

Guy: Exactly, yeah, which is weird to think about on iOS. Just all that battery stuff, and I don't know how they prioritize the cake and goodies over basically battery cost,

Loren: Think about it, let’s say you have six headless services that need to make a network connection, the OS could be smart...and when it spins up the radio, just like turns on all those for have a second each, or a couple seconds each and they all batch together.

Guy: Yeah I know that for their own stuff. There's basically one persistent connection that manages mail and I message and all that, it traveled through to the one place. Yeah, and actually Game Center notifications

Loren: Yeah open that to 3rd parties.

Guy: You think? I don't know

Loren: They have a review process in place. If someone's abusing the system, take him down. You can do interesting things

Guy: Yeah, I agree. One thing that I'm…I I don't think will appear anytime soon is a third party Siri API.

Loren: That upsets me, because Google search is so awesome.

Rene: I think they won't do a Siri API though because Apple seems to want to do that as a partnership play, where they sort of get Yelp or they get the movie ticket stuff, or they get open table and make a deal where the content get shipped to there, and if they do and API then they lose the ability to make specific content deals.

Guy: I think there's two things going on there, there's the inherent difficulty of disambiguation, wherein if you just say a sentence and apps claim certain keywords, applications can collide and you don't know which one necessarily to pass off the request to. I think that's a hard problem to solve.

The second thing is, given the that that's a hard problem to solve, maybe is better for Apple to just work with certain partners and because then they have the power relationship. They say to Open Table, “Well, we'll swap you for something else” or the can say to Yelp like, “You will do X or else you're off the phone.”

Rene: It's a brokerage deal.

Guy: Exactly and I Fear that Apple TV is going to maybe be the same way. I love to see a API for AppleTV. I imagine Loren you would love to work on something for the TV?

Loren: Oh yeah. Games would be a no-brainer. But I'm actually talking about a completely different, like, I'm sorry I totally misunderstood the Siri API question, but I'm looking at it completely differently. I want an API so when I press and hold the home button Google searches the thing that pops up.

Rene: Oh different default apps.

Guy: Yeah that, OK yeah, that would be pretty cool.

Rene: You could choose Chrome instead of Safari and you can choose Pharaoh instead of mail.app.

Loren: Right and I think, this is like bordering into anti-trust territory but you know there's no reason to Google search shouldn't be able to like hook into the native API for a set of timers and stuff like that.

Guy: Well something like setting a timer. It seems like you could do the classic implement the URL scheme.

Loren: Right.

Guy: So.

Loren: Yeah I guess they could do it.

Rene: Well that's like the problem that we don't have anything like intense or like contracts the way that Android or Windows phone have.

Guy: That's my biggest hope for iOS7 [indecipherable 69:54] and it goes back having these impeded windows from other processors and XBC but I don't know, I think they're just finally putting all the pieces in place to be able to implement something like that In the same manner.

Lore n: Yeah it's nice that they waited. They didn't hack some thing together Android style.

Guy: One thing that is nice about Apple is that they often come late but they come with a good game.

Loren: Yeah they did it right.

Guy: Like a well considered implementation.

Rene: They measured 10 times, fake cut three times and they make one slice.

[laughter]

Guy: Yeah. Or they just tell you no or they don't even tell you it's just no you never getting that. It's never going to happen.

Rene: Because is not really a computer it's a computing appliance and they want to, they now have the classic problem of dragging 100 million of my mother’s behind iOS who would get horribly confused at the mere thought of different browsers so, “Do they want to bury settings somewhere deeper only the nerds can go find them to swap out apps or do they want to just make a blanket statement that this is not a computer you can't do what you can do with the computer on it?”

Guy: Right. Loren you've been around since the beginning, I've always felt, well always is maybe not always but for a long time I felt that the springboard metaphor is limited, and I don't have a better suggestion but it feels like it's going to run out of leg room at some point soon.

Loren: Look at the alternatives. At least like Android's home screen it's just such a such a nightmare. I guess I like what Palm did where your main screen wasn't like a list of apps it was the things that you're working on right now in Cards.

Rene: yeah, and the stacks were very nice.

Loren: Yep.

Rene: You could group Cards together based on projects as well?

Loren: Yeah I think the Card metaphor is the closest thing I've seen to a perfect launch or home screen thing.

Rene: Which Apple did in Safari pages and just never made it prolific through the OS.

Loren: Right

Guy: Yeah that seems like a natural but who knows?

Rene: It's flabbergasting.

[laughter]

Rene: I mean it's interesting to see which way because Android again has all those widgets on the home screen but Apple just wants the home screen to just get you into apps. They don't want you to live in apps but then they don't have actionable notifications the way that web OS had either so you got to move between apps and I'm hoping that's the next big change is that I don't have to go hunt for data the way I do on Android and go look for widget.

I just want all that data to come to me and if they could put up an SMS notification that I can do a quick reply in or if they could put up an alarm notification I could quickly adjust without me having to switch apps. I'd be very happy.

Loren: Yeah

Guy: There's one thing that I thought about, when the phone was first introduced with iOS, everybody remarked at how simple and clean and direct that the user interface was which is correct but it's really hard to go out of those initial simple constraints. I'm not sure that just adding stuff like folders and newsstand is a great way to go forward.

Loren: Yeah. No, those are Band-Aids.

Guy: Yeah . Exactly and it feels like increasingly were going to get more and more Band-Aids and while initially the iPhone, or iOS, was allotted for simplicity eventually we're going to get to the point with iOS where it's like Mac OS 10, which is not complicated per say but there's a lot of just Band-Aids stuck in there like.

If you looking launchpad on OS 10 it's you know just hacked in there or what's it called? Mission Control. Kind of a similar thing, it's obviously a layer on top of this previous stuff.

Loren: Yeah, I think OS 9 is probably a closer analogy.

Guy: Right. Yeah. Exactly. Stuff gets convoluted what would you do? Because I don't know, maybe it's a design question but it's also a programming question because you need to…you need to consider everything that went before. In general when designing and working on software do you consider the possible paths for it? Like if I make this decision where can I go from here? I know it's a very high end vague question but I mean just…?

Loren: Yeah, I know I don't know if I necessarily at least this is how I work, I don't necessarily put a ton of thought before I start working. I always work, and it's like Fog of War when you play games. It’s like you can only see for some radius around you. Sometimes you just need to wander and then eventually you'll stumble on something, or something bad, and then you have to double back and try different route and, I don't know, I guess my process is pretty messy.

Guy: No I think we have a very similar process actually. I do the same thing. Increasingly I found myself worrying about compatibility issues so, because when you hit something that is…so one of the big titles I worked on I've mentioned already is Tap Tap Revenge and for Track and Tap Tap Revenge we download…I shouldn't say this but I'm going to anyway, we downloading an audio file, a bunch of image assets and a LUA script that controls the game play and the animations.

Loren: Dude, you're getting booted out of the store.

[laughter]

Guy: Don't have to say that directly dude

[laughter]

Loren: You can edit that out.

Guy: OK whatever it's the first episode, nobody's going to be listening…

[laughter]

Guy: Yeah so, and we've always done that. We skirted that issue well before that was an accepted thing to do because you're a game you get away with stuff when you're a game, and we were popular, and we were well-known, so it wasn't issue. Christ if you’re listening, please don't kick them out of the store.

[laughter]

Rene: They don't do it anymore anyway.

Guy: I know I know. It's fine. Nobody's stupid. People just look the other way. Please keep looking the other way.

[laughter]

Guy: The issue then becomes as the game engine evolves and this level of definition script that we have is expected to target the same, is expected to run across all of these versions. It becomes increasingly difficult to support older themes, but we must, because we've sold them to people and it's sitting on their phones. Backwards compatibility has become like a major, and forwards compatibility, has become like a major interest of mine and it is really boring and very detailed work.

But it is in many ways pretty essential to get right. Do you have…do you think about that? Do you have any strategies for that? Have you ever had to run up against that in your career or have you been fortunate enough to be able to dodge it?

Loren: No I don't think I've hit it quite to the same extent that you have, but yeah. Yeah, I've run into it and it's always been a nightmare, and I haven't come up with a general…I haven't generalized how to solve it.

Guy: Yeah. I don't know if it can be generalized. I just was hoping for something smart.

Loren: No. I think we’re all in the same boat.

Guy: I think that's like the design choices of the springboard and iOS in general, and these software tricks I see you make, I think a lot of choices get made that get set in stone.

Loren: Accidentally.

Guy: Exactly. Accidentally, and you have to keep working on them. You can be nimble and hope to overcome them or you can maybe hope to be smart and hope to plan for them but ultimately I think the longevity of software is something that is hard to think about at the moment but it ultimately one of the most important things to consider.

Loren: Yeah. Well put.

Rene: What's interesting to me Loren is that you're almost, I guess you were one of the first to do a new app for an update Tweetie Two was a whole new app on the App store, and others have done it sense and it seem whenever there's a big app that does it it's a little bit controversial. Did that work out the way that you wanted it, and would you do that again?

LOREN: I wouldn't do it again, but I think it was the right decision at the time. Knowing what I know now I would plan for something like this, and I would take a totally different approach to selling apps. I wouldn't charge to $ 2.99 upfront. Just, I wouldn't do it.

The free with an in-app purchase you know, like, pay for features style that seems like a good way to sell software and it's certainly the way Apple wants you to sell software. They don't want you to charge for a massive update. For technical reasons I couldn't go the in-app purchase route back in the Tweetie days because literally it was a whole new app.

[crosstalk]

Loren: Right. Yeah. No, I thought about it but it would've been interesting if I tried to like combine the two into one, and then just have a separate app delegate for each one and literally launch different app. But that seems like it would have been very gnarly.

Guy: That's crazy.

Rene: Fragile.

[crosstalk]

[laughter]

Loren: Don't do that.

Guy: Well I can understand why that would be an option that you would consider but I mean just from its development point of view you have to realize that at that point you are mauling your code base in order to support some weird App Store restriction.

Loren: App Store Restriction, yeah.

Guy: Yeah.

Rene: You're paying for past sins on future, future goods.

Guy: Would you say you embraced the race to the bottom, like you're OK with it?

Loren: Yeah maybe. See, I don't know. If Apple set the price floor any lower than $.99…What if they set a price floor at $.10, I'm sure there would be $.10 apps in the store, and I don't know at what point does it become the unsustainable?

Rene: I can't even get candy for $.10 anymore.

Loren: [laughs]

Guy: Your point of view is, not to projecting you, but it's basically, “Screw it, I'm going to give it away for free and charge for premium features”?

Loren: I like that approach only because it gives me flexibility in the future.

Guy: Now does that work…? That is a great model for games, certainly the games I've worked on, because you can always sell downloadable content effectively. Not just on iOS, but on any platform. They've even got an acronym for it, it's DLC.

That is a great model for games. Where you effectively have got an engine, and you just feed it goodies and they play for it. How does that work in the world of applications though? Not Letterpress, which I find it's half way between a game and an application, Letterpress. But actual applications, how would that work for say Tweetie?

Loren: For Tweetie, I put a little a little bit of thought into it. I came up with a dozen ideas. But the one I remember was it free for one account and if you wanted to put more than one account into it you paid a premium.

That was a very pro feature. It was a niche in the market, but that niche needed the feature. It was an absolute requirement.

Guy: Right.

Loren: I could have charged a decent amount of money for that upgrade I think.

Guy: Yeah, I think I would have paid 10 bucks for that. I have two accounts at least.

Loren: Right.

Rene: I think that was Twitterific’s model. You got rid of ads, and you got multiple accounts.

Loren: Oh was it?

Rene: Yeah, at least with one of the new versions of Titterific. The paper charges you per…Like you get the brush, you get the ink I think for free and then you get the brush and the other tools for in-app purchases.

Loren: Yeah, I love paper. Yeah, I guess that model works. I have no idea what their conversion rate is but the app is awesome.

Guy: Is it free? It is, yeah?

Loren: It is free, yeah.

Rene: Then I immediately bought every tool imaginable, and then I bought the mixer the day it came out.

[laughter]

Rene: Do you think there's a place still for time bombing. You’re not allow doing that on iOS, but do you think there's still a place where you get it for free for a certain amount of time and then you have to pay for it?

Loren: No, I think that's lame. Everyone’s different, I don't think you can say, “Oh, you can use it for an hour.” I can't get a sense. Or two weeks, I might use it once in two weeks. I like the idea of paying for something of value, and features have value.

Rene: Yeah.

Guy: I think that's an old school way of approaching things. Timing out an app is something that you'd do in 1998.

Rene: With a serial dongle on the computer to run it in the first place.

[laughter]

Guy: Yeah.

Loren: Yeah.

Rene: [laughs]

Guy: Oh man, that would be awesome. Loren, your next app…serial dongle, you'll mail it. Individually mail it to people.

Rene: It'd have to go into 3.5 because Apple locks down the lightning now, but you could still get away with.

Guy: Exactly. Yeah exactly, but that would be awesome.

Loren: That would be awesome.

Guy: You know what? I swear to God, I think you could sell, like you charge 50 bucks for an app with an actual dongle for it. You would sell. You would get at least 50 bucks.

Rene: Well Square's basically a dongle.

Guy: Yeah that would be good. Yes, Square is interesting. Square with that little dongle thing seems to be doing pretty well. Do you guys ever use that?

Loren: I want to. I wanted to use CardCase for so long but nobody takes it in Philadelphia. Level Up took over Philadelphia.

Guy: Oh yeah?

Loren: Yeah.

Guy: Interesting. I'm not sure if it's public, but they're coming to Canada.

Rene: They are, they’re in the Apple store now.

Guy: Oh OK, good. Yeah, I've got a dongle, but I’ve never used it.

Rene: [indecipherable 84:47].

Loren: I think I've use it, I’ve only used it to pay myself like a dollar to see if it would work and it did. It worked.

84:47: But if you sell the Letterpress board game you can run that through square.

Loren: [laughs]

Guy: Did you use the signing view? The signature view?

Loren: Yeah. I signed my own signature and everything.

Guy: Yeah, that was me, you're welcome.

Loren: It's stunning. How do you smooth the strokes? Do you do it on the fly, or do you like wait for...?

Guy: This is why I wanted to mentioned it. Holy crap, that was a pain in the ass to do.

Loren: Yeah.

Guy: I was doing [indecipherable 85:20] curves and then doing a bunch of math on them, totally failed.

Loren: Yeah.

Guy: I imagine that there is a correct way of doing it through math. I don't know about you, I’m bad at math.

[laughter]

Guy: Like I'm good at graphics, I'm good at a lot of things. I know what I'm good at. I'm good at making things work like they…so that they feel natural. Math is not in my tool bag too much, you know?

Loren: Yeah

Guy: I don't want to make myself sound stupid but…I'm sure as a graphics programmer you know where I'm going with it right? It's...

Loren: No, no, I know and I'm certainly way worse at math now than I used to be. In high school I think, maybe this is me misremembering, but I think I was pretty decent at it. I was deriving calculus things. I was trying to do it faster than my teacher could write it on the board. I was taking number theory classes from a community college. Now I can't even do long division anymore.

Guy: Yeah...

Loren: I'm so lazy.

Guy: Well you get laze, you get made lazy by constant access to a computer where you can just type in whatever you want. I know how to apply pretty high order math stuff to a problem. I can't remember exactly the details of how it works.

Loren: Yeah exactly. [laughs]

Guy: I'm just, “I need to do this to that and I can get X,” that's what I know, and I do it. Anyway…

[crosstalk]

Guy: I couldn't figure the signing thing out. What I ended up doing was a simulation. Depending on the distance between the points and the speed and the time I would make the brush thinner or thicker. If you were going slow then it got thick. If you were going fast it was, it became thinner.

Purely by just simulating it at each point, at each touch point and interpolating between the points, I managed to achieve a pretty decent looking line.

Loren: That's awesome.

Guy: Often in computer graphics, if you do the dumb way, you get the nice, natural result. That's what I chose to do, or at least that’s…

Loren: If you think about it, it's all physics, and physics is some of the simplest math there is, at least at the level we're working.

Guy: Right, yeah. No, I totally agree. It was a blast to do, and I ended up proud of it. What I liked best about it, is I spent most of my time trying to do this really complicated derivation of X number of input factors, and what ended up working well was a relatively simple simulation of the way a brush would work while dragged across a piece of paper. I don't know how we got from Letterpress to that, but we did.

Rene: It's our first show.

Loren: You have a lot of leeway.

Guy: We're learning.

Rene: Awesome. Loren, thank you very much for joining us for our debut episode. Where can people find out more about you, about Atebits and about Letterpress?

Loren: atebits.com

Rene: Very succinct. I also happen to know you have a Twitter account.

Loren: I do, @atebits, A-T-E-B-I-T-S.

Guy: I'm @gte on Twitter, and whatever they're calling that other thing, app.net. Hey, Loren, app.net client…Here's a brilliant idea for you.

Loren: No, I don't get app.net.

Guy: Are you on it?

Loren: No.

Guy: [pause] That's weird. Why not?

Loren: Well, this is a whole different topic.

Guy: Yeah, yeah, OK. We've already had an hour and a half, and I'm bored with you.

[laughter]

Guy: GTE on Twitter and app.net, and Kickingbear.com on the Internet’s. I'd like to really thank Loren for being the debut guest, because I think we got off on a really good foot. I had a lovely time talking to you Loren. Thank you.

Rene: It’s a heck of a way to come out of the gate.

Loren: It was an honor to be on this show. Thank you.