02:09 - Apple Music

03:12 - Metal for OSX

05:04 - The New Swift Features

07:15 - Value Types

09:32 - Error Handling

16:02 - Support for Function Pointers from C

20:04 - Lightweight Generics

22:42 - Guard and Defer

27:27 - Xcode Improvements, Autolayout

29:55 - New Core Audio and Core Image Features

34:01 - Testing

38:15 - The Address Sanitizer

51:07 - Crash Logs Addition in Xcode7

54:43 - Installing Apps Without a Subscription to the Developer Program

Picks

Owen Williams: Apple’s biggest developer news at WWDC that nobody’s talking about: Bitcode (Alondo)
neo-Style Lightning Charge & Sync Cable (Alondo)
Hardcore History Podcast (Jaim)
WebAssembly (Mike)
ASCIIwwdc (Andrew)

 

Well, somebody drive before we crash into something.

Hi everybody and welcome to iPhreaks episode 111. This week on our panel we have Alondo Brewington.

Hello from North Carolina.

Jaim Zuber

Hello from Minneapolis.

Mike Ash.

Howdy from Fairfax, Virginia.

And I'm Andrew Madsen, Salt Lake City. This week we are going to talk about some of the new stuff that we heard about at WWDC just – for us, it was last week. There was a lot of new stuff to digest. We're all still going through it but we want to talk about some of the things that were impressive to us and exciting and what they mean for developers going forward.

I wonder what everybody was most excited about that was announced last week.

Apple Music?

Apple Music. [Chuckles]

That's all of us. That's the whole thing. That's the whole episode.

You were the one just enthralled by Eddy Cue’s demo, right? Alondo?

Well, I was mesmerized by Jimmy Iovine so.

[Chuckles] Yeah. I don't know. That made me think this keynote is not for developers but there was good stuff before that. I just ignore it. I just pretended like it never happened.

I wonder if they just had a lot of time to fill from the lack of Apple TV.

[crosstalk] I get the feeling that's exactly what happened and the thing is –

I don't know. I think they might have been serious about it.

Well.

I think they might think this stuff is cooler than we do – at least than I do. I don't want to speak for anybody else.

That was pretty much the take-away I got. There wasn't a lot of excitement about it. There were a few people that thought as a service it would maybe interesting because it use something like Spotify or Rdio. It wasn't something that developers are super keen on.

Except for Alondo.

Well, yeah, Drake was there. What do you want me to do? [Chuckles]

I don't know.

That was my favorite segment of the whole keynote. Drake's great and all but he came out and said just like “I like Apple, I'm glad I'm here.”

[Chuckles] I will say the one thing that I do think was interesting but it did not affect me personally was that the announcement that Metal was being ported to OSX. I know of some people were excited about that although not as many as probably the bulk of the developers in the room.

Yup.

I know what you're saying. I'm not a huge Metal person but the people I know they're into the Metal are very excited about it.

We have Warren Moore on the show a couple of weeks ago and I remember asking him about this and he said “Well, I don't really know anything about whether it's coming or not but there's no reason it can't.” Then a couple weeks later –

Well, he actually – we had drinks on Sunday. He actually predicted. He said he thinks it's coming.

Ah, good. Okay.

Sounds pretty cool.

I'm sure he's happy about it, right?

Yeah. He's quite excited about it.

It's even a bigger audience for what he's doing if nothing else. Hearing about Metal on OSX, I'm a Mac developer so that does sort of matter to me. I'm not a game developer but I thought it was interesting. They said they rewrote portions of Core Graphics and Core Animation on top of Metal. There's also integration between Core Image in Metal. I don't quite understand if that means that Core Image will benefit from performance improvements. They talked in the Core Image session about you being able to pull Metal textures into your Core Image filters and get them out – not exactly sure if it meant performance improvements.

Anyway, it seems like Metal is more than just a good thing for game developers if they're using it to improve performance of graphics APIs that even regular app developers use.

Yeah, it seems – I'm not much of a graphics guy but it seems like OpenGL is getting a little long and the Tooth it's not matching the hardware anymore. There are other replacements out there like Metal which aren't very far along. It seems everything that just touches on graphics is ultimately going to be affected by this. I think it ought to be good for everybody.

Yup. Sounds like a good thing. Anything they can do to give us performance improvements free, I'm happy with. I think I was probably most interested in the new Swift stuff even though I'm not really using Swift for my everyday work and my job right now. It just seems it continues to mature and become something that actually seems like a language I want to write apps in.

Yeah. I think this – with the new features they have announced, it's finally crossed its threshold into – before it was like you could definitely do stuff with it. Obviously people shipped apps with it but it was a little bit not quite there. You were using it because you were hopeful for the future. I think that's arrived now. I think it's now finally really solid.

Mike, do you want to summarize the changes that they announced for Swift?

There are several big features. In no particular order, we've got error handling which looks a lot like exception handling from other languages but it's not quite the same. It interoperates very nicely with Cocoas and its error stuff. I think it solves that whole problem pretty nicely.

Finally, we have support for function pointers from C. That's was the big hole in bridging two C APIs before is it function pointers basically weren't supported. You just couldn't really use any APIs that did function pointers. Now that's essentially solved. You can pass a lot of Swift functions in and out. For function pointers, you just use them naturally.

Protocol extensions are another huge deal. These let you implement methods in protocols themselves so that when you implement a protocol, you get some code along for free which allows a whole lot of nice behaviors. You can basically – protocol now is not only just an interface but also a collection of default behavior which really helps reduce duplication and make code a lot more natural.

Let's see. We got guard statements which is an upside down if statement. It's a simple thing but it helps make code a lot clearer for the cases where you're doing things like checking a bunch of conditions of front and bailing out of a method before you run the real code.

We got a defer statement which is a like a finally clause except you can put it anywhere and basically lets you aggregate your clean up code wherever you – it's most natural instead of trying to put it next to every return statement in your code. Those are the big ones off my list.

I have a question. I went to a value type session. I wasn't sure because I didn't really make a dive into Swift initially but I was really impressed with the talk in value types in Swift. It was one of the things, along with some of the other features that you mentioned, that made us reconsider when we were going to go ahead and start using Swift. We decided now that we're just going to work and start writing new code in Swift. But I think if you could just speak about value types a little bit?

Yeah, that's been a thing with Swift from the beginning. It's getting nicer and nicer to use especially with things like protocol extensions. Basically, what it comes down to is Swift has first-class support for structs. A value type essentially is when you're doing equals then you get a new version of it whereas with the reference type, like with a class, you pass around references to it. Everybody shares one. If one bit of code changes it, then another bit of code sees that change and it can be a big mess.

Objective-C has that same dichotomy there with structs and classes but Objective-C structs aren't very useful. They can't contain methods with arch it's very difficult to even put objects in them. You don't really see them very much except for things like CGPoint. In Swift, structs are full first-class citizens. You can put methods on them. They can adopt protocols and they work really nicely. That lets you do nice things with your own code where you implement your model as value types. You don't have to worry about who has a reference to them and things like that because they can't get changed behind your back because value type semantics prohibit that.

Yeah. In Objective-C, we try to get some of the same benefits by having – especially for foundation classes having immutable and mutable variants where it's a reference type but because it’s immutable, you don't have to worry about somebody changing it. But that can be a pretty hairy and you have to check to know if something's mutable or not or explicitly make a copy. I think the fact that we have really nice first class types that are value types in Swift is a pretty big win.

I think so. Apple also did a really good job of explaining why and how to use value types in their demonstrations, their presentations.

Yeah, they’ve got some really good sessions on that. Definitely, if anybody is confused about this stuff and why it matters, go watch those.

Yeah. We've all been saying “Yeah, you should do it this way. Value types, structs, do it, let.” But the why has been a little confusing sometimes.

I want to talk about this new error handling. For some reason, among people that I know, there's been a lot of discussion about this. In particular, there seems to have been some complaint that Apple did things the way they did which is it looks a lot like exception handling where functions can throw and when you call a function that throws, you use try and you have a catch block. You have to do a catch block. If the function throws an error, the code in your catch block runs. Also the compiler enforces that so can't not have a catch block. You can't just ignore the error.

The other way that they could have done things that a lot of people seem to think they should have done things is to use a result type where you have a tuple that can either have the return value or has an error. One of the elements of the tuple has an error that might be filled in. I wonder if you guys have seen this debate and have any thoughts on it. I don't have a really formed opinion. I think partly because I haven't really been writing a lot of Swift yet.

We've been using the tuple return pattern for things that can fail in our Swift code. You just create a quick tuple; you can name it or not. That works out pretty well. I haven't really given much thought to the try-catch thing. I did it pretty heavily doing in C# work. I know that a lot groans when it was announced. Probably by people that have a core doing Java with it but I'm not sure. But this does seem like an improvement. It's a good model for things like in break pretty spectacularly like pointing to a file system and things like that.

You will have to see how it works out. So much of the stuff is really difficult to evaluate until you spent like a good couple of months working with it in the real world. So far, I think it’s pretty solid. It's not quite exception handling. It looks like it a lot but it's not. Importantly, you can't throw through a bunch of arbitrary code like you can with a difficult exception handling system.

So when you're writing in other languages that do support exceptions and use them, you have to be paranoid all the time like – whenever you're writing code, what happens if an exception gets thrown here, through here? Swift restricts it a lot more so that you definitely tell exactly when it’s happening. I think it's a really interesting feature with syntax that they chose where, typically in an exceptions language, you have a try block. Then anything within that try block if it throws, it goes to the catch clause.

In Swift you have do block and then you have to write try in front of every single statement that can potentially throw. What happens a lot of times in a language like Java, you end up with a try block that's 20 lines long. And of those 20 lines, three of them can actually throw and the rest just happen to be in there. There's no easy way to figure out which are which. You have to actually know the APIs or look them all up. The way Swift makes it work is you have a try keyword in front of every statement that can actually throw. It might have 20 lines within a do block but you can just visually see “This could throw, this could throw or this could throw.” I think that'll reduce confusion a lot.

As far as – I've heard the complaint from people as well that it forces you to handle errors; you have to put everything in a do block or something like that. All I can say to that is “Too bad, you should be doing that anyway.”

Yeah. I think – I mean I think that was one of the whole points, right? They, in Objective-C or in other languages, it's just really easy to ignore an error. In Objective-C, you just pass in null for your error pointer and completely ignore even checking. So they want it to make it so that was not such an easy thing to do.

I think it's good to point out that there is an escape patch if you ever have a case where you're certain that you're never going to have an error. Something's marked as throws but you know that it's only in certain circumstances and you're not going to hit those, you can write try with an exclamation point which is the universal Swift shut-up-I-know-what I'm-doing command. So if you are in a situation like that, you're not going to find yourself writing useless catch blocks that never happen. You can just hit the exclamation point to get on with your life.

That's a good point. This whole error you mentioned this error handling that they added to Swift and it operates really well with the existing Objective-C Cocoa convention for doing error handling with NSError.

Yeah. It's really cool. Anytime there's a method on the Cocoa and it has an NSError **pointer to return an error, the Swift compiler knows what that means and automatically translates it to a throws method which does not have that error parameter. It all just happens the way you'd want it to. Anything that uses the old style Cocoa NSError stuff just also uses the new style Swift error handling without any changes.

There was one detail about that that I'd thought of but I haven't checked into it and I wasn't clear on which is that in Objective-C, the convention is actually that the return value of the method that can produce an error is what tells you if an error happened or not. So you don't check the return by reference error. You check to see if the return value was yes or no or perhaps nil for something that returns an object. Then, from that, you can tell if an error occurred. That's when you go use the error. To Swift, I know this bridging is done by the compiler but – does Swift follow that convention or are they checking the return by reference error? How are they handling that? Because the question is you don't actually necessarily know what return means there was an error.

Yeah, that's a really good point. What happens is in actual use – like 99% of the time – it's either this method returns an object to pointer and nil signals in error; or this method returns a bool and no signals in error. What happens is Swift compiler sees if there's an object pointer return type or a bool return type. It goes to those cases. It's checking the return value – not the error pointer just like you're supposed to. And it doesn't try to bridge other cases. If there's any weird case where it's returning an integer and you know an error is indicated by returning 3, it's not going to try to guess that and get it wrong. I just won't do the work for you. But that case almost never happens in the frameworks. It's almost always an object pointer or a boolean return.

Okay.

It handles almost everything for you.

That answers that question. I assumed they had done something like that because that's a pretty strong convention. Especially in Cocoa, the frameworks themselves, it's followed well. Of course, other people can write whatever code they want.

Yeah, that was pretty much one of my first thoughts to when they talked about the bridging was how is that going to work. If you happen to be writing Objective-C code that has a boolean return, and yes means error and no means it succeeded, then don't do that. You're not going to be happy bridging to Swift. I'm hoping that won't actually turn up in the real world.

I hope not. The second thing you mentioned is C pointer interop for Swift.

Yeah, function pointers.

Sorry. Yeah, C function pointer interop. This is actually something that has prevented me from using Swift because I do a fair amount with Core Audio and Core MIDI and actually have some IOKit code and a few things I work on. A lot of those C APIs like that, they take function pointers as arguments to API methods. Function – pointer to functions that you provide. I think core audio is a really good example of that where you have render callbacks and you pass in a pointer to your callback or whatever. That was just impossible to write with Swift.

Yeah, a lot of those APIs are growing block variants where there's one that takes a function pointer and then there's the same basic thing that takes a block instead but they're definitely it's not universal coverage yet.

And some of that is new. I know core midi got some new block-based API where previously had passing function pointers. But it was new as of this newest release that was just announced. It coincides with Swift getting a function pointer capability. It's nice to have but it didn't fix my problems a year ago. Anyways, have you looked into the way that works at all? I haven't – I think they talked about it a little in one session I watched but no details.

Yeah. It's very nicely done. First, I think, back up real quick and talk about why this is even a problem. The issue is basically that C function pointers are too simple and a C function pointer is literally just like the address of the code that implements the function. If you have a function that does something and it's got some code in memory, if you pass a pointer to that function, it's literally just saying “When you call this, jump here.”

The problem is that there's no extra data associated with it. So when you have something like an Objective-C block, then you're potentially capturing variables from the enclosing scope. That's all supplemental data. So when you call a block, then you're not only saying “Jump here” but you're also saying “Jump here and when you call it, give it this extra data that goes along with it so it knows how to access all these captures or what not.”

Swift functions often do that as well. Fundamentally, they all do that or at least they all can. You can write a nested name to function in Swift that captures variables from the enclosing scope. When you write methods in a Swift class, it's fundamentally a curried function which means that it has extra state going along with it. That's fundamentally incompatible with C function pointers. The way they solve this is essentially they broke the idea of a function type into variants. So there's a Swift variant which is the normal user function and there's the C variant which is – this is a function that is compatible with C function pointers because it doesn't capture anything. It doesn't have any supplemental data. You can just refer to it by address of its code.

From Swift, those are first-class function types in both cases. So what happens is when you have a parameter like that, you try to pass a function in. The compiler looks at what you’re passing in and says “Is this actually compatible? Is it capturing any data? Or is it standalone?” And if it's standalone, it just lets it happen. It does all the work for you so you can have a global function that you pass in just like you would in C or you can even have a local closure as long as it doesn't capture anything and just put your code right there in-line. That's very nice.

That sounds good. I was worried before the conference last week. I was worried that whatever API or whatever system they came up with was going to be like some of the existing C pointer API where there are lots of casting back and forth between unsafe mutable pointer and this and that.

Sounds like they've made something that actually works without a bunch of ugliness.

Yeah, it's really nice. I think it seems like one of those solutions where, in retrospect, it looks obvious and it's – of course this is what they did. What else would they have done? I don't think it really was obvious but it's one of those nice solutions that just fit right once you see it.

Those are the best kind. Some of these things we've talked about – error handling, C function pointers – there were actually areas where, in some sense, Swift was missing something that Objective-C already had or at least something that it needed to bridge to Objective-C. Then another thing that you did not mention is that they actually added generics to Objective-C. It's a pretty lightweight – they call it lightweight generics not like a full on – well, Objective-C makes that pretty hard because so much stuff is deferred until runtime.

Yeah, they are kind of Java-style generics where it's all just like in the compiler when you're building stuff and it goes away at runtime. But just little bits help like that. It's very nice to have an array where the compiler knows what's in it even if it's not doing anything at runtime. It's still nice to just – you get code completion and you can just look at it; see what it is instead of having to look up the documentation.

Yeah, I played around with a little on. It's very, very easy to – I don't know if you’d say fool it – but do things at runtime that completely violate whatever you've declared. But they have added –

If you have an array of strings, you can easily put a number in it.

Yeah.

Right.

Yup. But they have added some compile time checking even to the Objective-C compiler so that it will warn you about some common error cases. It seems nice. Of course, that was mainly to bridge to Swift I think. The whole idea is that you get a lot of these – a lot of – well, all Objective-C APIs that return collections. In particular, we'll say return and NSArray and you know because you know by looking at the API or reading the documentation exactly what types are going to be in the array but the Swift compiler doesn't know that at all. So it would get bridged to an array of any objects and then you have to downcast it yourself. Now you don't have to do that if the APIs have been redone in Objective-C. I think they've done that with a lot of the system APIs, right?

Yeah, I believe so. They've been doing that all along as they add features to Objective-C to help support Swift bridging as go through the frameworks and make sure they're up to date with ABSA.

I guess it's sad for an Objective-C programmer to see that now the only reason they improve Objective-C is if it helps Swift. [Chuckles] But I guess we get the benefits anyway.

Well, I think your right but, on the other hand, there was a great stagnation for a very long time back before the LLVM days when we're still using GCC and Objective-C didn't change. When it did change, it was little stuff or it was crazy stuff like garbage collection. Now we have clang; we have LLVM. We’re getting lots of cool new stuff. I wouldn't fret too much.

I guess the funny thing is that some of the stuff that we got during the time when Objective-C was improving really quickly, that was directly or indirectly because Swift work was going on and we didn't even know about it.

Yeah. It seems like if you look, Swift is what – five years old now from when it was first started being worked on? That's when Objective-C started getting cool stuff like ARC.

Yup. Well, anyway, where I was going with all that is that there are a couple of things – I'm particularly thinking of guard and defer – that have no analog, really – I mean guard, kind of because some of that stuff is just easier in Objective-C than it was in Swift. Particularly, defer has no analog in Objective-C as far as I know unless you roll your own somehow where you define a block at the top of a method and then just call that to –

Yeah, there's a couple of ways you could do the equivalent. The most obvious, I'd say, would be if you use a try with a finally block. You can use try even if you're not handling exceptions. You can just do like @try; put in some code; then you do you @finally; have your clean up code. No matter how you get out of the try block, that clean up code will still fire. So it's kind of like that really. I've never seen anyone actually write Objective-C code that way so you shouldn't count it.

I was just going to say – and then I guess there are people will put a label at the bottom of a method and then use go to drop down the bottom.

Yeah, you could do that. There's a GCC extension that clang also supports that lets you define clean up function on a variable. You could use that as well. There's really nothing exactly like it. It's pretty cool. Just to elaborate on exactly what it is, you just write anywhere in the code; you just write defer and then you put a block of code. Then what happens is when you leave that enclosing scope whether you fall off the end or you do a return or you do a break or anything like that, that code that you have deferred will run right before you exit. The idea is you can allocate a resource somewhere at the top of block of code and right after that you can write defer and then you write the clean-up for that resource. You know it's going to happen.

This is something that I – in code that I've written, I immediately saw how this is a pretty nice thing to have because there are certainly times where I write code where there are multiple early exits because you're checking error conditions as you go. But you have clean up like resources you need to release or state that you need to put back in the write state. You end up duplicating code pretty quickly.

Yeah. You end up with this clean up code all over the place and it's so easy to forget a spot because maybe you're returning early like three different places and you forget one of them. It's a nice way to solve that.

How that it know when to run a deferred work?

Well, its basically whenever you leave the enclosing block however it happens. If you hit a return statement, then the compiler will generate code that executes your deferred stuff right before the return. If you fall off the end, then it runs right before you return to whatever is enclosing it. If you hit a continue or a break, it'll just – it'll run that. So it's however you get out or even if you throw an error. That's an important case to mention since that's another big new thing here.

Okay, just whenever you exit, defer is called. It doesn't do [inaudible] magic.

Nope. It's all compile time really. It's basically – you're just telling the compiler “Hey, whatever – for all the pass out of this, run this code first.”

Okay. Can you chain them together? Have in multiple voices?

Yeah. If you have more than one defer block in the same chunk of code, then what happens they just run in reverse order. You can have Defer A, Defer B, Defer C and when you exit that block, it'll do C-B-A. I believe – I should probably test this but I believe if you have Defer A and then you return there like a conditional return, and then afterwards you have Defer B, then in that early return, only A will run. So you can use defer in combination with an early check and return to allocate a bunch of different resources and clean them up individually properly. I think it all pretty much works the way you'd want it too.

Is there anything else about Swift that they announced that's important that we should talk about?

The only thing that I had with the guard statement which is a pretty minor thing. It's like an upside down if. It's not a huge thing but it makes code nicer to write. If your writing code that has one of those early checks and returns; if things are bad, it just cleans that up; stops you from having a bunch of nested things. I don't think it's going to fundamentally change anything. It's not like error handling where this is a really huge change to the language. But I think it ought to make things nicer.

Yeah. I think in Swift 1, it's easy to get into a situation particularly, I think, with optionals where you have if let. Before they added the multiple conditions – I guess they're conditions multiple pattern matching, you could get long nested if lets. It was gross and ugly.

Yeah. You get the pyramid of doom where it's just nested, nested, nested, nested, nested and then here's your real code and then you come back out. Guard just lets you avoid all that. Combining conditions into a single if helps a lot with that but this makes it even better. That's great.

What else made you guys happy that was announced?

Actually, I liked some of the improvements in Xcode, particularly with regards to storyboards. The StackView is pretty nice. We've had some issues trying to get particular layouts to work. It's been a big pain in the butt. StackView has a nice new control that we can use to get these layouts. I know it behaves a little bit like the Android – I want to say RelativeLayout maybe if that's the right comparison. We're really pleased to see that. There was a lot of excitement from a lot of people they hear about that as well.

Yeah, I felt this was interesting. This – it's a class called UIStackView. There's also a class on the Mac called NSStackView which actually was introduced in 10.9 a couple of years ago. I think they went so far as to say, in a session, that you should use a StackView first. Your first choice should be to use one of those and then only drop down and do your own autolayout stuff with constraints if you have to which I thought was interesting because I'm not actually – I'm not the world's biggest fan of the autolayout API.

I wonder if this was planned all along or if it was a little bit of a like “Yeah, we know this autolayout stuff is not exactly the best thing in the world especially for simple layouts.” So we've come up with this way now where you guys don't have to worry about it so much because we've realized our mistake or whatever. I'm not sure that's really true but either way I'm glad to see some support for this more sophisticated layouts than what you can do with Springs & Struts without having get your hands dirty with NSLayoutConstraint which is not my favorite class in the frameworks.

Definitely not. It's good to have a reasonable default that'll work for a lot of cases. I'm looking forward to that even though I've gotten fairly good with all the layout. But it's nice to not to deal with it in every case.

I guess we should clarify that NS/UI StackView – they're basically a view that you can use to create a horizontal or a vertical list or stack of views. They take care of laying them out and spacing them. You can hide views in the stack and it'll automatically re-layout the other ones. You can nest StackViews so you can actually do some relatively complex common layouts with StackViews and they completely hide – they're implemented using autolayout but they hide that from you so you don't have to actually deal with the layout constraints yourself.

It's some cool stuff that hopefully will make some common UI layout tasks easier. I've actually spent the morning today working on autolayout in a pretty complex Mac app and it's fresh in my mind that I'm tired of it.

I thought that they announced some new stuff for both Core Audio and Core Image which are lower-level APIs that looked really cool, particularly Core Audio which is something that I work with a fair amount. They have improved on some things that were introduced last year. They've moved a lot of functionality that was in the Core Audio C APIs into AV Foundation so that their Objective-C APIs – they're increasing the number of things you can do without having to drop down to the Core Audio C APIs.

One really big thing that I think is really cool is that they introduced a version 3 of the audio unit API. At least they're calling it version 3. I didn't know we were at version 2. Version 3 is Objective-C instead of being C. They've made it now so you can write custom audio units for iOS which is, I think, a big deal. You can ship those in-app extensions so other apps can use your custom audio units that you shipped with your app on the App Store. This means you can write your own synthesizers and effects and things like that that then users can use in Garage Band and whatever app. It works on OSX and iOS which is cool. That's important to me.

They've also added some midi stuff to AV Foundation which – I have a big midi framework that I

maintain. Hopefully, it obsoletes some of my code. I would be happy about that. But I suppose that's a little bit nerdy and isoteric because not everybody is an audio app programmer.

Well, the audio unit stuff sounds really nice. We've had pluggable audio units since the dawn of time but very few people have actually use them. It's sounds like a really nice idea if we can get more developers doing that stuff. I think that'd be great.

Yeah. Well, and specially being able to ship for some reason that I don't 100% understand. I'm not a musician. IOS is actually about to become a fairly popular platform for music apps. There are a lot of people using it for music. They've steadily improved the capabilities of iOS for audio, for music. This is just one more step on that path but just even being able to ship audio units at all for iOS, custom audio units is pretty cool – at least I think. You could do things like ship custom guitar effects and then your iPad is a guitar effects box. That kind of thing.

Skype supports it. I can show up next week with a Darth Vader voice.

[Chuckles] Yeah. [Chuckles]

Nice.

I haven't dug in and used any of these yet because, of course, they are new. You have to target the new version of the OS. I can't do that with the stuff that I'm working on for real but I'm excited to start playing with them as soon as I can and learn them. Of course, I think part of these improvements are also, again, so that things are easier with Swift because API written in Objective-C that's part of AV Foundation is easier to interface with in Swift than an ancient C-only Core Audio API.

To be fair, those were not the easiest to use from Objective-C either.

No. Not even close. Unless you just like obscure error codes that tell you very little about what you actually did wrong.

Hey, your format was wrong. I can't tell you which of the 20 parameters is wrong but it's wrong.

Yup. Negative 50 is – error number -50 is a Core Audio programmer's worst enemy. Hopefully they've improved that too. I haven't really seen if they've improved error handling. For all I know, they're just wrapping those in an NSError and returning them. Let's hope not.

Then, as far as Core Image goes, I think the big news was that they brought a whole bunch of the filters that were previously only on OSX to iOS. I think now they're at parity so both platforms have the same set of filters. It's pretty big set. I think something like 200. They added custom Core Image filters or CI kernels to iOS last year. Now they've improved the language you use to write Core Image filters with some new stuff that's enabled by improvements in LLVM. Then, of course, added integration with Metal; added integration with AV Foundation.

So if you're doing anything with image processing, video processing, that kind of thing; Core Image has always been really cool but it's getting even better, especially on iOS. I've worked on some apps that used Core Image very heavily so I was excited to see this.

One of the things that they moved pretty far forward was the ability to test, especially UI testing. I thought they introduced some really new approach where you can actually replay clicking on your app which everyone says that's how they want to test things. And random as part of unit tests.

Yeah. Jaim, have you looked into that? Have you used it all? Did you go to the sessions?

I didn't check out the sessions but I'm pretty excited about it. I don't know the real details but it does [inaudible] test that I know what to do [inaudible] and make sure that's cracked in; make sure something happens when a button happens. Those things that I frequently do two test for that. Now I do that with one test.

It's pretty clean. It actually test the button and test the nib instead of [inaudible] or however else it's setup. I think that's pretty powerful. Pete Hudson mentioned there is lot of room for abuse on it. It's a lot of repeated code. We'll have to work through that and find cleaner ways of doing it. But I think it's to me really powerful. [Inaudible] pretty excited about it.

One thing that didn't get a lot of notice but I saw in the state of the union was that you can unit tests on different devices simultaneously – not simultaneously but as part of one test run because it's very common to change your nib in your iPad app and forget your iPhone. Your test passed because you're running the iPad the simulator but not as in other case where you just broke something. That's very valuable.

Yeah, it is cool.

Yeah. I don't know I like what I saw there. I was able to attend the second half of that session. I didn't catch everything. The old way is which is using the UI Automation tool. You could – you're recording but it would spit all of the test data in the steps in Javascript. Now, it's actually generating Swift code. You can actually implement directly inside of your UI unit tests .

Or Objective-C.

Or Objective-C?

Yeah. I planted this out to a few people because they're saying it's like the first Swift-only feature. As far as I remember that they actually announced that it will work in Objective-C as well.

It doesn't matter because nobody uses Objective-C only.

No, nobody at all. I great. I wouldn't actually be sad if it were only in Swift. I just – I thought it was interesting more than anything that they did not introduce a Swift-only API here.

Speaking of Swift-only APIs and being surprised, they did replace the address book format with a new context framework. I was actually – [inaudible] session, I was actually surprised that that was also written in Objective-C. I was fully expecting to see that written in Swift.

Yeah, that's interesting. To my knowledge, they have not written any of the system APIs in Swift yet. Or at least, if they have, nobody knows about it.

I don't think they can expose that stuff until they finally figure out the binary compatibility storing –

Oh, right.

Which they still really haven't.

Yeah. Right now, they still are shipping the Swift libraries inside your app.

Exactly.

Getting back to the testing stuff, when I saw this, I thought, well, we do already have UI Automation and I thought the biggest improvements were that it uses Swift or Objective-C instead of JavaScript which is nice for developers because those are the languages we're using anyway – not JavaScript. The recording looked like it actually worked fairly well. I've seen things that do that before and they're not – they're okay but they have limitations. I'm sure this does too but it seem like it did pretty well.

They showed some cool stuff like where it would automatically factor your code as you went. So like if it saw that the same object was being used multiple times, it would factor that out into a local variable to make the code read a little nicer.

Another thing for me that is as important as UI automation was iOS Only. This new UI testing stuff also works on OSX which is cool.

I think it all sounds great. I'm looking forward to trying it out. That's always been a big hold for me. I think for most developers is we write – a lot of us write tests pretty heavily for most of our code. But as soon as it touches the UI, we just say “Well, good luck.” [Chuckles] So I'm really hoping that this whole help push me over the edge.

I hope so too.

For our workflow, it's actually going to work really well because QA usually will send a recording of bugs that they find and so we can also help the regression. We can also capture all those scenarios; create tests for them; add them into the test suite. We can make sure that when we do make feature change [inaudible] blowing things up as we record.

There's one other big new developer tool feature that I wanted to talk about. I know Mike is happy about it. That is the Address Sanitizer.

I think I can talk about the watch.

Well. [Chuckles] That's actually something we announced, right? It's watchOS 2 and native watch apps. The reason I've avoided bringing that up is because I haven't tried writing a WatchKit 1 apps so I don't really know what –

Well, it's fine. We all know Mike is the number one watch evangelist.

I think he – you wear one on each wrist, right Mike?

I still think it's a practical joke. I think it's gotten away from them a little bit. [Chuckles] They seem to have actually gotten to the point where they're shipping products. It's probably pretty awkward to come forward. [Chuckles] This is all a joke now but I'm pretty sure that's what it is. They just got to find the right moment to tell everybody.

Surprise.

Yeah, well, it's quite the joke. It's actually a pretty nice Polish joke on my wrist but I agree that –

I don't think that it's for me but definitely a lot of people are really enjoying it. It certainly looks slick.

Yeah, it has not changed my life the way the iPhone did or certainly the way having a computer – a Mac – did.

I've seen a lot of my friends just spontaneously standing up all of a sudden. It's seems they have a pretty big effect on some people.

Yeah. Kind of skeptic; kind of tries to run your life.

Actually, the most hilarious part of the keynote was that I was sitting in a row and several of the timers went off. It was just people looking around to see if anybody was going to sting in.

Nice. I guess everybody stayed seated.

Yes. [Chuckles]

In one of the other sessions for the release notes showing people actually got up and setup a little bit; stretched around and sat back down.

I feel like, in any other case, that would be incredibly rude but if it's at WWDC, it's like “You know guys, this is your fault.”

Yeah. They're the ones that did this to us.

Address Sanitizer.

Yeah, Address Sanitizer. Mike, do you want to tell us what this means?

I think I describe this as the best thing since the invention of the wheel but there might be a couple other things. I don't know. Penicillin or whatever. Anyway, I'm sure everybody knows about Valgrind which is this crazy tool that runs your program and does tons of checks on it every time you overstep an array or something like that. It tells you what's going on. It's really cool but there are two major disadvantages with Valgrind. One is that it slows down you app a lot to the point where it's hard to use interactive app with it and especially something like a game. The other one is it never really work very well on the Mac so most people haven't really used it.

Address Sanitizer is a Valgrind Lite. It's basically – it's built into the compiler essentially annotates your code with a lot of checks. Something really common in C code and, by extension Objective-C code, is you allocate an array and it's slightly too short. You write one byte off the end. 99% of the time, your code works just fine doing that because of a little bit of padding or something like that. But then that one little chance comes along and blows up you app. Then it's impossible to figure out what's going on because you can't make it happen again. It's the worst part about programming in a C-based language.

What Address Sanitizer does is it has basically – behind your back, you don't have to really do anything besides turn it on. But the compiler goes through and puts in all these stuff that makes sure that your playing within the rules, essentially. So when you write off the end of that array, instead of crashing every so often, it immediately stops and say “Hey, you stepped off the end of this array. It is this long. You wrote in this spot which is off the end. It was allocated over here.” It basically just gives everything you need to fix the bug to you on a plate, essentially. It's really nice. Xcode [inaudible] just makes it a single check box.

You can just flip that on; run your code; and notice all the bugs that you've had in there for years and never knew about.

I felt this looked really cool when I saw it. Anybody who's done app development and has had apps in the wild that users are using has probably gotten – if you're getting crash reports at all, you get some crash reports where you look at it and you think “Well, yes, I can see this is crashing but I cannot tell anything from the stack trace that helps me figure out where this crash is happening.” A lot of times the problem is because the real bug was actually far away from where the crash happened. For some, hopefully, fairly large set of those crashes, this will help you actually track them down finally. They tend to be really subtle, right?

Yeah, yeah. They're often very rare. You could to the same thing a thousand times in a row and hit the crash once or it's not clear. You perform some action over here and it crashes over there. You don't know what caused it so you can never figure how to reproduce it. I definitely encourage anybody who has a little free time: download the Xcode 7 Beta, run your app in it; turn on Address Sanitizer; and see. I bet you will be surprised. There are probably things lurking in your code right now.

I was just going to ask if you actually tried this out yet.

Yes I did. Not extensively but a little bit. I put some of my code in there and ran it and I found a couple of legitimate bugs and fixed them. It was wonderful. It's very easy to use; clear output and it's great. So far, it's excellent.

There's a – I haven't actually watched it yet but they did a whole session on this. The reason I haven't watched is because I think there were some technical problem with the session video where the audio and video where out of sync. So they pulled it down; fixed that. It took them a few days. I think as of light night, it's up now. So I'm excited to watch that. I think it's worth watching. It's the advanced debugging in Address Sanitizer. I think they also talked about some other debugging features that you can use. I don't know if any of them are actually new or not but other than Address Sanitizer. I'm eager to watch that and learn more about this.

Xcode has had the ability to run a stack analysis on your code for a while. I haven't used it in a while. I remember Xcode 5, I could run a stack analysis on the Objective-C code. What does Address Santizer add on to that?

It's like a complement to it, really. They would really work very nicely together. The static analyzer is looking for problems in your code that can be found just by inspecting the source, right? You do something – you allocate an array here, for example, and then you do something with it right next to it. If the compiler can draw a line between these and say “If your code follows this path and this path and this is a problem.” That's works great especially because you don't actually have to figure out a path that hits that code. As long as the compiler sees it, it doesn't really have to run to find problems in it. So you don't have problems with things like test coverage where you forget to press a certain button in your app so that code never runs, you never find problems with it.

The other side is static analysis can only find so much. From just looking at the code, there are problems that maybe spam, a lot of different files or just involves calculations that are too complicated for the compiler to follow or something like that. There are a lot of cases where static analyzer just cannot find certain types of bugs. What Address Sanitizer does is it fills in a lot of those gaps by looking at how your program runs as it runs instead of just looking at the source code. It can find problems where you're stepping over the bounds at runtime where it actually happens instead of trying to figure out that it will happen.

There are cases that it won't find either. If you don't run the code or if you do run the code but you never hit the error case, then Address Sanitizer is never going to notice a problem where static analyzer might. So they definitely complement each other very well.

Correct me if I'm wrong, Mike, but I also think that the static analyzer in clang is a lot of what it checks is the Objective-C code. I think previous to ARC – it's been a while since I've written any code that was not ARC. Previous to ARC, it would find a lot of memory management bugs like over-releases or leaks, that kind of thing. It seems like the stat or the Address Sanitizer is likely to find problems that tend to be more common in code where you're actually using C or C++ or interpolating with those from Objective-C or Swift, that kind of thing.

Yeah, I think so. The static analyzer does analyze certain C problems as well. It can tell if you have a variable here and you have some conditionals here which initialize it and you forgot a spot. If you follow this path, you access that variable uninitialized. It'll find things like that. It can find certain memory accesses that are illegal but the memory management stuff definitely was the big advantage before. That's been made obsolete with ARC.

In fact, ARC is essentially them saying “Well, the static analyzer knows if you've made this mistake so why don't we just have the static analyzer [crosstalk]?”

Yeah, that's an interesting special case because for something like an uninitialized variable, how do you fix that? The compiler can't know because who knows what it should be set to. But with memory management, there's always a right answer, right? The static analyzer was basically saying “Okay, you forgot a release here.” Instead of saying that, like “Okay, why don't you just do it for me please?” I think the static analyzer is still useful. I run it on my code occasionally. It does every so often pop up with something that I've missed.

I was actually going to scold Jaim a little because the team I work on, we tease each other if somebody checks in a problem that the static analyzer flags. We don't set – you can set it up to run every time you build your app. We don't do that because it annoys me because it makes builds take longer but we do run it very frequently. It doesn't often catch anything and often when it does catch something, it's not really a big deal. Still, it makes you feel better about your code to see no static analyzer errors. It will catch some that are fairly common. Jaim, you should use it again.

I should be doing it more often. Thank you.

All the time.

Thank you sensei. [Chuckles]

And turn on Address Sanitizer and I'm sure everything that way too.

Right.

Have perfect code everywhere.

No more bugs.

Right. Bug free from now on.

You mentioned that Valgrind has – and you talked about this a little bit – you mentioned that a tool like Valgrind has a pretty bad performance impact. I have seen that before. I've tried to use it. You end up with an app that is barely usable because there's so much overhead. I know Apple mentioned that Address Sanitizer had very small performance overhead. Do you know if they quantified that all? Was it –.

I seem to recall that Address Sanitizer is, on average, something like two to five times slow down which is significant, obviously, but not a show stopper for most code. It's going to depend on exactly what your code is doing but I think that's what they said was typical.

Well, two to five times sounds scary. You certainly wouldn't want to ship an app that was two to five times slower than it should be but it doesn't mean that you can't click a button and get a response or something without making yourself coffee.

Right. The thing with Valgrind – I don't remember exactly but I think it's more like 50 times. What would happen there is if you had anything real-time like game or something like that, you basically just couldn't use it. I remember I got it up and running on the Mac ages ago when I had a game I was fiddling with. I ran it in Valgrind and it was just – it was no longer real-time. You couldn't play it. I could get through it by: I press a key and wait a little bit and a new frame would arrive and things like that. It wasn't practical for a lot of things. I think with Address Sanitizer, even if you're running a game and it's real-time and it slows your code down by a factor of 3. Maybe you get 10 frames per seconds instead of 30. That's obviously not ideal for a gamer but it should be okay for testing it.

I'm curious to know there are some tools that have been in Xcode for a long time that are along these lines. There's Guard Malloc which I think will try to tell you if you've gone beyond the end of a mallocked block of memory; beyond the end of an array or something. Or if you – I think it will tell you if you tried to use memory after you freed it. Then, there's NSZombie, of course, that Objective-C – especially pre-ARC Objective-C – programmers are very familiar with which helps you catch bugs where you've released an Objective-C object and then tried to message it or do something with it later. Does this obsolete those? Are they still useful? Do they do things that Address Sanitizer does not do?

I think it may actually obsolete them. I'm not sure about zombies. Those might still be useful. I'd have to check out what Address Sanitizer does with freed memory. For something like Guard Malloc, I think Address Sanitizer basically is doing everything that does and more. The one thing that Address Sanitizer does that's a little worse basically is it has to be – it's a compile option. It has to annotate your code. So a lot of these other tools can work on existing binaries. That doesn't come up that much but if it ever did, you can turn on Guard Malloc with a binary already has [inaudible] on disk and run it and see what happens. You can't really do that with Address Sanitizer because it has to go through and insert code at build time.

Oh, right. That's interesting because Guard Malloc just does something different at runtime when malloc is called, right?

Exactly. It's just a replacement implementation of malloc. It can – you can just wedge it in there anywhere. Other than that which I don't think that really comes up much in reality, Address Sanitizer seems to super set of what something like Guard Malloc does.

Cool. Anything else anybody wants to talk about? I think we're getting close to the end.

There are a couple of quick things I just figured we wouldn't have time to go in depth to but I saw the crash logs addition in Xcode 7. We are currently using Crashlytics. I'm really curious as to how long that's going to be in place. If we can get some poll, get a crash information. If I'm not mistaken, though, I think is dependent on user opt-ins that may actually affect whether or not we pull our Crashlytics integration out of the apps that we're using.

The other thing was deep linking in iOS 9 which we'll use quite a bit which I think is a great feature. One of the things that we've always had trouble doing is providing us a really simple way of getting users view links into our apps. In particular, locations within the app without going through Safari. With iOS 9, the ability to implement deep linking allows to bypass Safari. We can actually have some pretty informative links to allow users, particularly new signups or information about current games and things of that nature. So I'm pretty excited about that. I think a lot of users are as well; a lot of developers are as well.

Yeah, that sounds like something where the users will really benefit clearly and immediately.

Definitely looking forward to having my – the apps that I use for that kind of thing.

Yeah, I am too. Regarding crash logs in Xcode, I assume that – they actually announce this last year. They announced that iTunes Connect – I think it was at WWDC last year – they announced that iTunes Connect would have crash logs. And not just aggregated crash logs like they had before where they bubble up the most common ones or something. Like actual every crash log would get submitted. I [inaudible] the impression I am assuming that the new thing they announced is not so much new capability in that sense. It was simply that Xcode will pull those for you from iTunes Connect and give you a nice UI for dealing with them.

It will symbolicate them for you – not sure if they were doing that in iTunes connect or not but it'll symbolicate them; add some UI so you can mark them as resolved and figure out which crashes you already handled or not and fixed or not. I don't know if that's really going to give us something that we don't already have but it may make that easier. If it gets more developers to not ignore their crash reports, I think that's definitely a good thing. The opt-in thing worries me a little because I'm not sure the opt-in rates will be. Presumably, if you've got a big enough user base only, as long as some percentage of them have opted in, you're going to get the crashes that actually matter, right?

It will help. Every time – we always fear anytime we present any alert view to get users to click yes to sign in to give us access. It's just by default, we're just going to get – a number of people are just going to say no and they won't read. [Chuckles]

Well, they have the app analytics stuff in iTunes Connect which is opt in. I think I've seen opt-in rates as something like 25% which is pretty low really. I don't know. It seem slow. It means only 25% of people clicked yes.

Correct. I think it's a [inaudible].

If I can – I don't use Crashlytics but I've worked on a few contract projects where people used it. It's not my favorite. Somebody need to deprecate the menu bar API just for Crashlytics. I hate that menu bar app. Or have they got rid of that Alondo?

I don't see it.

It's the thing that has to run up. It's a Mac app that runs in your menu bar.

Oh, it is but I don't interact with that.

Oh.

I almost never interact with that. It's still there though.

At least when I used it, it would periodically download a new version of the Crashlytics framework and install it, replace the Crashlytics framework in you Xcode project folder on disk. So you'd have – the main thing the bug me is then source control would be dirtied.

Oh, yeah.

I didn't even do anything. Crashlytics is doing stuff behind my back.

Now, we haven't had that problem for quite some time. I think they've improved that. You just have to new builds and push things up but it's been pretty seamless now.

That's good.

One more thing if I can just – real quick.

Yeah.

With Xcode 7 and iOS 9, apparently, they now let you install your own apps on you own device without subscription to the developer program which I think is really cool and deserves to be pointed out.

I think that's a big deal that has not gotten – certainly didn't get a lot of press if any press from Apple – I'm not sure if they even announced it on stage.

It's quiet.

I think that's a big deal because it's not quite the same as the side loading that everybody asks or has said that Android has and whatever because you have to download Xcode. That's somewhat of a barrier of entry. Just this idea that it's making your device more yours is a big deal to me. I like that.

Yes. Step in the right direction definitely.

I don't know. I think their motivation was more like it would help bring developers to the platform but that doesn't really matter to me. It's a good thing.

Merging the app developer accounts as well too. The ability to only have one account being able to develop for both Mac and iOS app. That was a nice small step.

Yup. I'm saving $100 a year.

Yeah.

I'm not going to complain about that. Alright guys. Well, there was a ton of stuff actually. I didn't – I felt like this WWDC was a little bit light compared to last year. In some ways it was. It's hard to top the announcement of Swift as a brand new language but there's actually a fairly large number of cool things that Apple announced. They tend to – they're more on the incremental improvement category but I'm excited –

[Crosstalk] a lot like 10.6 back in the day when it was a little bit underwhelming when they [inaudible] all the user phasing stuff. But then they gotten underneath and there was suddenly a lot of really great things.

I think that can only be seen as a good thing.

Definitely.

Considering some of the stuff that has happened recently on both platforms. I have high hopes for the next year. Well, thanks for talking about all these stuff. I learned some things and have some new things to go check out and some sessions that I want to watch.

I could have just stayed home.

[Chuckles] Yeah, because you wasted the money on the ticket, right?

I know. I did.

As for our listeners, I would encourage everyone to – if you don't already which I'm sure most everyone does – watch the videos for the sessions as you can because there's a lot of good information in there. Some of the stuff is stuff that you don't really find anywhere else. It's not necessarily going to be in the documentation. You'll get little tips and have things pointed out that are difficult to discover otherwise. It's a very valuable thing to watch these sessions even if you couldn't make it in person.

Alright, shall we get to the picks?

Yup.

Let's do it.

Alondo, do you want to start?

Sure. I have two picks. The first pick is actually an article that talks about some really good chance to talk about briefly. That was Bitcode that was mentioned briefly. I think it was in a keynote or the state of the platform. Basically, the idea that you won't have to make so many drastic change in the future if the rumored processor changes come forth. There's an article on the next web that delves into little bit. I think that was worth reading. It doesn't [inaudible] to dig detail but it does give developers understanding of what's happening there.

My second pick is actually charge and sync cable. I go through lightning cables like crazy. I don't know about other users. One of the things that I picked up is a sturdier lightning charger cable that has actually lasted for months now. Actually, I'm pretty pleased with it so i'll include a link to the lightning cable there. It's at Sam's Club but you might be able to get it at another location as well.

Cool. Thanks. Jaim, do you have some picks for us?

Okay, I've got one pick. If you're listening to this, I'm going to make a conjecture that you like podcasts. It comes with a lot of podcasts. At one point I was like “You know what? I wonder if people that aren't programmers have podcasts.” because that's all I listen to. A number of people recommended Dan Carlin's Hardcore History which is a very extensive view on the topics it covers. I'm going through its Blueprints for Armageddon which is talking about World War I. By extensive, I mean he talks for 2 hours before he gets to any invasion. I think it's at least 20 hours long. I'm quite a bit into it; maybe half way but it's good stuff. If you [inaudible] history World War I. That was the big war that skimmed over growing up. World War II [inaudible] but very interesting. So Dan Carlin's Hardcore History podcast.

Sounds good. I have to check that out. Thanks Jaim. Mike, do you have some picks?

Yeah. My pick this week is WebAssembly which just got announced this morning I think. It's essentially an attempt at replacing or supplanting or augmenting Javascript on the web with a byte code executable. Currently, if you want to run code in a web browser, you either write Javascript or you write something that compiles to Javascript. Javascript is not the greatest language in the world. Everybody has been wondering for ages why doesn't anybody use something like Java byte code or some sort of Assembly language. There's asm.js which is an attempt to make that happen but it was weird. So now, all of the big browser makers have all come together and decided that they are going to make this happen. WebAssembly, it's a new, essentially, Assembly language byte code level thing that will run code next to Javascript as a first-class citizen. It looks really exciting.

It's the biggest thing to happen on the web in a long time. I think it's going to be a huge deal.

Cool. Thanks Mike. I've just got one pick today. I'm sure this has been picked before – probably multiple times on past episodes but I think it's really relevant today. That is asciiwwdc.com. This is just a website. I think it's my Mattt Thompson that has plain text transcripts of all the WWDC sessions going back to 2010 actually. The reason I really like this is because you can't search a video. Often I'll have this thought – I am working with these new APIs or something or even an API that's not new that was released a few years ago. I know that it was mentioned. I remember hearing something mentioned in a session but I don't know where to find it. This way, you can search through all the sessions.

And it also makes it so you can read – you can just read the transcripts if you don't want to watch the video for some reason. I believe the text is actually pulled from the annotation or the subtitle track on the videos. The 2015 videos are not actually up yet. I don't know if that's because Apple hasn't posted those – the videos with subtitles or it's just they're just waiting for somebody to do some manual process to generate them or what. Anyway, I'm sure that will happen soon.

We were far from covering everything new that was announced at the conference this year. There's a lot more to learn and this gives you a good way to get a brief overview too, in addition to all the searching and fast reading that it enables. It's a pretty good tool. That's ASCIIwwdc. That's my pick.

Alright guys. Thanks for being on.

My pleasure.

If nobody has anything else, I guess we'll see everyone next week.