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.
Show notes
- Debug 39: Nitin Ganatra episode I: System 7 to Carbon
- Debug 40: Nitin Ganatra episode II: OS X to iOS
Guests
Hosts
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.
