Swift in production

Our five panelists discuss using Swift in Production apps

Transcript (lightly edited):

Nick: We’re talking about Swift in production, and these are people who have various amounts of experience with Swift in production. So, you know everyone's name- everyone spoke at this point, right? Alright, that's great. So let's start off with; to what extent are we using Swift in production, from each of you? We'll start at the end.

Chris: Sure. I shipped one app and two books that use Swift in production. So, the app we shipped about half a year ago, it's a Mac app, so it's not an iOS app, and in that sense, it was much, much easier for us to ship it, because we had no problems with beta versions or whatsoever, we could just use whatever and just upload it and it's not even on the Mac App Store, so we have all the freedom and it's very, very easy in that sense, and...

Nick: 100% Swift?

Chris: Yeah. Except for some pods I think.

Veronica: I'm working on a new team at LinkedIn, working on a new iOS app, so it's not released yet, but it's all in Swift and we just kind of finished our first version, so we're testing it internally at the company.

Nikita: Okay. So, Facebook scale of Swift is really hard. The thing is we have a huge Objective-C codebase, as well as C++ and C codebase. And we have tons of amazing tooling behind it and moving all of that and losing this tooling when we use Swift is not really the best approach to this, because the cost is really high. Though, if we go and look into new projects that we are working on and cooking somewhere, we use Swift sometimes.

At Parse, we’ve shipped simple projects in Swift. There’s AnyPhone which is available on GitHub and there is two more coming up. Also, Parse SDK makes a good approach to be good in Objective-C - Swift interoperability and benefit from generic types for object collections, nullability annotations and all those things, which are actually coming to Facebook SDK, I think in the next or two versions from now.

Keith: I work at Lyft, and the entire Lyft app is written in Swift.

Nick: This is familiar, did you just give a talk on this?


Keith: No, no, that must have been someone else.

Andy: My team at Khan Academy has been using only Swift in production for the iOS side of things, for little over a year now.

Nick: So your new app is entirely Swift?

Andy: Yeah. Well, I mean, I don't know. It's not really new, it's just like, lots of new features on an old app that existed. No new Objective-C.

Nick: Okay. Let's go back to what you were talking about with the Parse SDKs, and I know that you have to support a lot of other apps written in both Objective-C and Swift, so what's that like for you? I mean, is anyone here shipping stuff that other people are using in production, say third party-SDKs for other people? What has that experience been like for you?

Nikita: Experience is tough and it actually is really tough. So, we're supporting iOS 7 and up and OS 10.9 and up. Which means we cannot really ship dynamic libraries and we cannot ship dynamic frameworks all the time, so we need to support that use case, since we want to be a good resident of the platform and don't over blow the binary size for all the applications, as well as want to give people the ability to reuse the same framework between, say an app and app extension. We support iOS 8 and 9 with dynamic frameworks. On top of that, we want to support CocoaPods and we don't yet support Carthage, which I'm sad about, but it's tough to get there, but, so that's coming. The crazy part about all of this on top, is that we support multiple versions of Xcode, which is not really nice.

And we shot ourselves in the foot doing it, when nullability annotations were in beta, because Apple decided, "Hey, let's change nullability annotations", and they actually changed not the qualifier style but the specifier. They enforced the __nonnull to be in a different place, which broke a lot of people and a lot of people were angry about that. So we decided, "Hey, why don't we use macros?", and we  use Objective-C macros to support all of that and that actually works great in Swift, because the SourceKit converter, between Objective-C uses macros and uses all the macros to process you Objective-C code and convert that into Swift.

So, your Swift interface looks great. Though, if you want to support old versions of Xcode, like we do, you'll run into the things, where you can actually add more macros than the name of your function. And I remember one precise case from this, where I have a function that returns a promise with a generic type of an array, with a generic type of a string that is not available in Swift, that is not available to app extensions and that never returns a null. So we have about four or five macros here, which are all long and they're are all PF_nullable_return, or PF_generic and the name of that function is just 'find objects'.

Nick: Yeah, but you've written a lot of Objective-C before, so you are used to methods names that long.


Nick: Andy, you are nodding your head furiously, do you have anything to add?

Andy: Just really briefly, I mean Khan Academy doesn't publish much in the way of frameworks that you all can use right now, we're not... We're only sort of a tech company, but my colleague Nacho and I do contribute to ReactiveCocoa, which is like a big complicated Swift framework. ReactiveCocoa has dealt with this set of problems by completely ignoring the Objective-C side and that has been very freeing let me tell you, that's very lovely. We've also completely ignored iOS 7 as a deployment target because it's terrible for these reasons.

Nick: Yeah, it's a good point, yeah.


Nick: You brought up something interesting in terms of supporting beta software, essentially beta versions of Swift in your products. What are your approaches when Swift 2.0 comes out or Swift 3.0 comes out? Do you jump on the bandwagon as soon beta 1 is out? Do you wait? I think everyone probably has some sort of opinion on this.

Chris: I just try to switch immediately but I have very nice constraints in a way because our Mac App, like I can just build it and push it and if it compiles, then, that's fine. And the books that we write, we also wrote them in such a way that all the code in the book compiles, so I can just run it and fix the issues and then, I'm done. So in that sense it's very, very easy for me. I really wanna make an iOS app again and I'm very afraid of what problems actually exist there. But yeah. So, I'm in a very luxurious position and almost never have to think about it and just run with the latest stuff... Sorry.


Veronica: Yeah. Our project is similar in the sense that it's... We're a small team of like three iOS developers and we're pretty independent of the main LinkedIn app. So, we basically just talk amongst ourselves. The size of the app is… I could read the whole source code on my flight from New York to San Francisco. So, usually we divvy up the work. If we went to 2.0 and we generally stayed up on the latest we just talk amongst ourselves and divvy up the work for updating.

Nick: You can basically guarantee that everyone on the team is running two separate versions of Xcode and one of them is up-to-date. I mean for updating through all the betas, right? Like you are all… You're always on beta-2 together, you're always on beta-3 together.

Veronica: Exactly, yeah. And it's only three of us. So, you know, we all know.

Nikita: We develop usually in open source if we are talking about Parse and Parse SDK is open source. So let me give you a history example; When we switched from Xcode 6.4 to 7.0, we started testing that, from the first beta or actually the first day to see if it compiles or not. And then we got some Travis CI guys to help us with that by shipping Xcode 7.0 beta support which was amazing. Then later when 2.1 came out, we tried to get them exited about shipping Travis CI faster for that and now they actually shipped three days later with 7.2, which is an amazing thing. So, we usually go into- automate all the things, or rather go and add new Xcode support and see what breaks and then go fix it and try to fix it in a way that's also backward compatible. That's our approach to supporting the latest Swift.

Keith: So, yeah, at Lyft we went through a few Swift conversions and especially in the beta period like the biggest one, I guess was beta 2, because at this point everyone was working on the project at once. The switch to 1.1, 1.2 were smaller scale, so everyone switched immediately. But with the 2.0 beta since we ship every week, we can't really push the latest beta support to master. So what we did was, we kind of went through the conversion process with the first beta, just to see about how much work it would be to get it to compile since its a lot of changes.

Then we maintained a Swift 2.0 branch separate, and I’d rebase that every once in a while on master and when a new beta would come out we'd push the new fixes and stuff to that, which helped because there was a lot more incremental at that point. And then, with Xcode 7 we wanted to ship for iOS 9 immediately. So, as soon as the GM hit, we fixed all those bugs and merged Swift 2 support to master and shipped that, but we also kind of feel delayed sometimes on CI support, like Nikita was mentioning because we want all of our builds to work on PRs and everything but... Yeah, that's kind of how we do it.

Andy: That's a super happy story of the Swift 2.0 transition. Ours was really rough man, I mean, it was really invasive there were tons and tons of changes, I don't know why, I don't know, the converter didn't work very well for us. There was probably a week and a half of just hand-tuned work and we did that at the start with the first beta like you and then we realized "There is no way we're gonna be able to re-base on top of this". And, when we did it again later it was basically completely repeated work and because it was a week and a half long it was awful.

Everybody else was trying to move forward and kind of couldn't or it was very difficult. Yeah, it was just kind of a nightmare. We planned for it at least, so we had some other people doing like, "Oh, you know, a little polish and fix up stuff", instead of anything that would be kind of architectural. But Swift 2.0 migration was rough.

Nick: So, going in this direction of like; how are you using Swift with your team? Would you say Swift is a good language for small teams, large teams, medium-sized teams? Is it easy to work with other people? Anybody?

Chris: So for us, the experience has been really nice but we're a super small team. Basically two developers working on the Mac app, so, that was very easy. We sit next to each other and if there's something that doesn't work, we make it work and it's...

Nick: And you just have the other person's style on your mind and you agree on… There's no tabs versus spaces?

Chris: So, I do all my work with Florian, and Florian had never done any functional programming when we started and when Swift came out, I knew that we could do all the functional stuff and… So, I'm a bit embarrassed about this, I don't know if I actually told him. So, one of the reasons why I wanted to write this book, "Functional Programming in Swift", is because I could then convince Florian to write it with me, so that he could see how awesome it was and that we could have this functional style.

Nick: It's a little passive aggressive to be like, "Hey, I'm referencing this chapter in my book. Could you please amend this commit?"


Chris: No. Yeah. So, I managed to convince him to write this book with me and say that it's really, really cool and he didn't know anything about functional programming but that's when he's at his best. So, it was sort of a large elaborate way of getting him into functional programming without me having to convince him too much.

Nick: Okay. So, to convince everyone of you to use functional programming, all you have to do is find someone who can write a book for you and then join them on a team and write a whole app with them, so, that's my tip.

Veronica: Yeah. So, it's gone fairly well for us, SlideShare at LinkedIn, also rewrote onto Swift, and so there's some shared knowledge at LinkedIn. We have like a general style guide, nothing automated to follow. And I've noticed that we kind of... This is part of Swift being a fairly opinionated language but we have... Our individual styles as developers don't clash a lot and generally we have code reviews and they're generally like; we're asking good questions, we're learning from each other but we're not really fighting over a lot of the technical decisions we make.

Nikita: We are a two-person team, at Parse, doing iOS stuff and OS 10 stuff. So, it was really easy to, say if we run into the question of, "Hey, should we use this style or that style?". We just decide, "Hey, what makes it look best or what makes it explicit?". Say in functions, like in Map, we always use return to indicate our intention that, "Hey, this should actually return there." So, if you have a closure with a single statement on it and you intend to return the value from that statement, just return there. That's a basic example. But other than that, we also agreed on a few things that I talked about in the Compile-time Guaranteed talk. Like use final and use private all the time and that actually extended our style guide that we have not written down but more in talks.

Keith: I think we've had actually a decent amount of trouble with this. So our team is about 10 people and with varying levels of programming experience outside of iOS and stuff like that, and a lot of people who wrote Objective-C for a really long time really liked the way that they wrote Objective-C, and so you see a lot of Swift that's written in a very Objective-C like way. I feel like we have a ton of conversations in code review about that, like; "Hey, you know, this could be immutable and that would help a lot." Going on the private point, one thing that we've done is enforce that all internal and public interfaces have documentation strings, so, because that's kind of a pain, it's gotten a lot of people to write more private stuff, which I think is nice.


Nick: Well, you said earlier that you had a couple of people, like one or two people working on your app and then everyone else sort of jumped on to it later on. Did these two first people sort of define the style guide for you, or when other people came on, were they able to amend that, or was it just handed down iron fist- "We've done it this way with two people so everyone else is gonna do it too"?

Keith: Yeah. They came up with the style guide and that was good. I think we still have debates about a lot of this stuff and as new Swift versions come out, we see new debates, right? So you talk about how you should indent guard statements or whether we should use guard all the time if you wanna return out of something and stuff like that. I think we still have a ton of those debates but I think everyone's on the same page with a lot of like the general style stuff. I think that the bigger problems come with, like thinking in a more Swift-like way or whatever you wanna say, especially about like immutability.

Nick: Do you think we'd benefit from something, something from Apple saying like, "Hey, this is the style that you should use"?

Keith: I'm not sure if that's gone well enough in the past that I think that's worth it… But I don't think it would hurt. But, there's... You can find so much stuff about Objective-C and at some point maybe it came from the Apple example code or something. I prefer that we come up with the stuff as a community who could move a little faster, and update. And come up with different standards... Maybe Andy had some thoughts on that too.

Andy: Yeah. I mean… There's a ton of stuff about syntax, right? There's people arguing about like, "Oh, where does the whitespace go?" and like, “Where does the whatever go?" One thing that's nice about Swift is that it's much clearer than ever but I also don't really care about syntax and I don't really care about any of that stuff. So, what's more interesting to me is the architectural practices as you start to allude to with mutability versus immutability. I mean, yeah, so that's now a discussion.

Even beyond that, now we can talk about, “We're gonna model this thing with the sum type now, or with an enum now” instead of something that used to be a class, or “We're gonna model this now, we're gonna create our own notion of identity now” because that's like, that's something that makes sense in Swift, that didn't make sense in Objective-C. So there's a whole lot of stuff that makes sense in Swift, doesn't make sense in Objective-C, which allows you to further define your own practices.

That possibility is also a liability, because now you have to agree and that may be challenging on a team. So, I don't know, we've debated in code review for about a year. We've made some progress. We do not have consistent style among the team, architecturally speaking. You can see the style that I'm using in general if you watch my talk, "Refactoring the Mega-Controller."

Nick: That's a good one, I would highly recommend it.

Andy: Thanks.

Nick: So actually, that's really interesting, not only in terms of syntax, but in terms of like, do you break up things into a million different protocols? Or do you try and keep your files, you know, a reasonable length as opposed to... You know, if you have a million different protocols and each one does a single definite thing, then you have a million different files and each one has one function and a one line set of code that it does. So, where's that balance? Is there some sort of guide that helps you come up with how long your files should be or is there something else that's helping you out there?

Andy: We'll go the other way. Yeah, I prefer small types. I prefer decomposition. There's kind of two questions in your one question, which is, the first is like, how far do you decompose? And the second is, to what extent does the file system reflect the decomposition? So, in the first part, I say decompose heavily, and with lots of docstrings listing examples. This has not always been super popular among my teammates, so I think there's a question of taste there, that's just mine. And the question of files, I don't care. I use open quickly. I mix things in multiple files.

Keith: Yeah, I pretty much agree with Andy. I think it's kind of hard to figure out sometimes. We have a lot of stuff where it's more about modelling based on what the server has modelled for us and what other information we need to show relative to that, so... Yeah.

Nick: Does that make you more “Swifty" if you're going more in that like many, many protocols area, or is Swifty something different than that?

Keith: I mean, I think there's definitely a balance and that's... I don't know. I mean, having like one protocol with just a very small sub-set of stuff sounds really nice until you have like a million protocols, right? So finding something in between I think is pretty nice.

Nikita: Yes, I agree. The approach that I've seen being used a lot is either plugging everything into one source file, which is not the really great thing, or plugging everything into multiple source files. I actually took that further, I moved not only different source files, but in different packages or libraries. There was a really great talk from Justin Spahr-Summers at Pragma Conf this year about library oriented programming. He expands on how to package yourself and what is a library. So if we decompose a single application into a lot of libraries, and every library is setup to do exactly one small thing, or just one thing, solve one problem, that's our intention to use in Swift.

Nick: Do you get a build bonus from that, or has that been killed in Swift 2.0 with incremental compilation, if you separate things out into libraries?

Nikita: I believe that's been killed. When you have dependencies on frameworks and you build from frameworks, it does incremental build also.

21:52: Alright, we can move on. So, we talk about doing Swift in production, there's a lot that comes after the code, right? You write all the code, you get everything working, and I'm not talking about provisioning profiles, because I'm sure we could fill up a whole hour with just complaining about provisioning profiles, but what are the other difficulties you find in... I don't do a whole lot of work with continuous integration servers, but it seems like a lot of people do. So, is that easy to work with? Do you make builds for the App Store strictly from that? Do you tend to just use it for testing?

Chris: So we had exactly the same problem as Nikita just described with Facebook or with Parse. We used to use CI and it worked just fine, for example, for compiling the book, but it wasn't possible for the longest time. So, being a small team it's not as important to have CI if you have other ways to do the quality control and if you always build everything all the time, but I think it was very, very painful, and it's slowly getting better, everything that comes after writing the code. But I gave up on a lot of good practices just because they didn't work anymore. I even at some point rented a Mac mini in the cloud and setup my own, tried to setup my own CI server because nothing was working and it was very painful.

Now, I sort of accept the status quo and if something really bothers me I try to fix it, but this is... Basically we're at the very, very beginning of Swift and at the very, very beginning of a new language and a new platform and I think we have to keep that in mind, and this means that things are broken and it also means that if you get frustrated with this, you either need to sort of vent that and complain on Twitter or do something productive with that frustration and fix it, fix the things. Or you need to do it like the way I've been doing recently and it's trying not to get too upset with all the brokenness. Sorry, it was not really an answer to specifically to your question but, anything after the coding sort of is broken a little bit, more or less and different people are trying to fix it. Yeah.

Nick: Does anyone use Swift as a scripting language to do any pre or post build things?

Chris: Yeah, all the time. So…

Nick: Why I am not surprised?

Chris: Sorry, I don't wanna take up all the space...


Chris: So, our book, for example, we wrote it in Markdown and all the Swift parts are grabbed from source files and some of the Swift code is in Markdown. To do this we wrapped a C-library in Swift, so we wrapped CommonMark and we wrapped it in a Swift kind of way. The whole book is compiled using Swift and translates to Markdown and checks all the Swift code. This stuff is a pleasure to use because we can use all these existing frameworks that we know and all the existing Cocoa tools that we know. This stuff is really, really powerful. It just doesn't run on CI, which is very painful but other than that, it's actually very nice, it's a really good scripting language. Yeah.

Veronica: Yeah, we just don't do continuous integration.


Nikita: Okay. Continuous integration by Apple is... I don't have a good word, it's really broken.


Nick: Really broken? Okay.

Nikita: Really broken. So, they shipped watchOS 2, great. They did not ship XCTest for it. There is no XCTest available for watchOS 2. Maybe makes sense, maybe not. tvOS- there is no way you can run tests on the device, because I think they forgot to ship the bitcode slice for one of the internal frameworks, like IDEBundleInjection something. The part here is, since we are building SDK and it's more platform and systems approached to things, we use CI extensively. And CI is our main source of guarantees other than sticking our framework into a playground and trying to break it.

So we use the hell out of Travis CI for it, we have five builds which take altogether about 40 minutes, but they're parallelized, so that's great. One of the biggest challenges, and this is sort of the first part of your question. The biggest challenges that we've seen in Swift is that there is so many ways of doing the same thing, that you sometimes get into the way where, "Oh, I don't really know which way to take here." You can use this as an enum or you can make a protocol out of it or you can use a value type or sometimes it may use a class. There's a lot of questions there but as the language evolves I think they will be answered. The main problem right now is that there is a lot of ways to do the same one thing. Objective-C was easy, it's like, "Okay. We're gonna use this Promise or this block and that's it!" In Swift...

Nick: Well, a certain amount of that, must be just getting used to the language though, right? I think there's a lot of ways to do things in Objective-C as well.

Nikita: There is more ways to do things in Swift than in Objective-C.

Nick: Okay. Have you gotten closer to some sort of agreement on which way to do things in Swift as you have been working on it more, though?

Nikita: Yes, absolutely. But there's still questions that remain unanswered and the questions that we can structure our code in multiple different ways and we provide a guarantee this way, we provide a guarantee that way. So we actually spend a lot of time discussing about how to structure code, whether it's an enum or value-type or a class or a protocol. And whether we want to extend it later.

Keith: On the CI side of things, we use continuous integration for pretty much everything, we use Travis and Circle for different things. We have a ton of unit tests that run on pull requests and all that stuff. And then we also do deploys straight from CI. When someone creates a tag that's in a certain format for releases or betas, we fire off a build and then those get sent to Fabric or whatever. And then we ship the beta which is really nice. Like I mentioned a little bit in my talk, the VMs from Travis and Circle are super slow, so our builds take way longer than they do on local machines. But I think that's just a matter of time to...

NickIs that a habbit you got into with Objective-C and then it just carried over to the Swift side? 

Keith: Yeah yeah. That's kind of something we've done forever. It works really well for our QA team as well. So we fire off a build on every pull request that generates a build that they can download and test on a device, which is really nice.

Nick: Okay. So, let's change subjects a little bit. Let's say you're writing your own thing, you're writing something totally unrelated to work. We're all using code from other people. What is, let's say, one third party library that you would not be able to live without? Or would you write everything from scratch? No favourite third party libraries? Come on.

Andy: This is just for Swift?

Nick: Absolutely for Swift. No, I mean, you don't have to... It has to work in Swift, it doesn't have to be written in Swift.

Andy: Sure. I think ReactiveCocoa is really good.



Veronica: Yeah. For testing I've used Quick and Nimble and there's a lot of good Swift testing frameworks to check out.

Nick: Chris, you just write all your own Swift, I'm sure.

Chris: Well, no. Well, yeah, I... In the beginning with...


Chris: So, with Scenery, the Mac app that I was talking about earlier, we... I think CocoaPods support was completely broken. This was just in the beginning, just after the announcement, they couldn't do anything about this in the beginning. It was fine. I'm not trying to complain about CocoaPods. So, nothing was working and we just... The only option we had was submodules, so copying stuff in. So we basically wrote almost everything ourselves and it wasn't very dependent on other stuff and if you use like Apple's Library. So that's, I guess, the one thing I couldn't work without. I think the only thing we included was our RNCryptor, which was great for dealing with cryptography stuff. Yeah.

Nick: This is definitely... Don't write your own cryptography, people. Good? We can take some questions if you want.

Nikita: Not Swift, but Objective-C, it's called Bolts, we wrote it, it’s sort of a Promise framework. It makes sense in Swift. I just love it actually.

Andy: How do you write a Promise framework for Objective-C that makes sense in Swift?

Nikita: It's not as nice as it could be, but it sort of makes sense still.

Andy: How can a Promise framework work without generics?

Nikita: Everything is ID.


Nick: There you go. Questions, anybody?


Q1: Hi everyone. So, Keith, you kind of touched on this in your talk, but I'd like to hear everyone's suggestions for those of us that are working in fairly large code bases that have started adding Swift over time. What do you kind of see as the point where you just kind of pull the band-aid off and like finally just get rid of all your Objective-C?

Keith: I mean, I guess I can address that in our case at least. For us, like I mentioned a little bit in the talk, there was just such a large architectural problem that trying to incrementally pull stuff in would've been fine, but the main problem needed to be addressed and actually I think that we still got out of that easier by rewriting than dealing with that huge singleton...

Andy: Sure, yeah. I think it's much more continuous. It kind of depends on the state of the Objective-C that you're dealing with, whether it's worth kind of saving. Is it really complicated? Is it really error prone? Has it failed a lot in the past? How Swifty is the Swift that you're trying to interact with it? Things like that. As I mentioned in my talk, transliterating Objective-C to Swift isn't that bad, what's harder is kind of re-imagining it and the things it touches in a Swift-like style.

Q2: Hey guys, great panel, it is a really great, insightful discussion. First, I wanna express solidarity with all of you guys that have upgraded from Xcode 6.0 and Swift 1.0 to Xcode 7.0 and Swift 2.0. I commented on Twitter to Orta about how the Wikipedia project upgraded. It was a very long painful road 'cause we also were using PromiseKit in the Objective-C, Swift 1.0 version, and then with the keyword conflicts in the Swift 2.0 syntax it was very painful, so, right there with you. The other thing I wanna ask is a question about, in your experience, have you found that it's... What is your approach to either adopting new technologies gradually over time or just kind of waiting, sticking with your stable thing, and then once you find it hits a mature point, and then kind of biting the bullet all at once?

Nick: Give us an example. What is a new technology? Are you talking like Swift 2.0 or something like a new library that you just really wanna use?

Q2 continuing: It could be in either case, so both with external dependencies or with the platform itself. So yeah, I'm gonna stick on Xcode 6.4 until we get to at least Swift 2.0, or like, no, stay on bleeding edge and paying the cost gradually over time.

Veronica: So, since our project is new and small we can kind of make the rules and we don't already have a lot of dependencies. So one thing we've been very careful about is adopting new dependencies. Like, if we don't really need a dependency, we'd rather do without it. And, so for example, I had some code that I found online and it used like AFNetworking...

Nick: From Stack Overflow, right? Stack Overflow? Yeah.

Veronica continuing: Yeah, yeah. And it was like, rewriting it to not use AFNetworking was possible, it just maybe would've taken a little bit of time and it was like, "Yeah, we don't need this dependency." We look very carefully at our dependencies because yeah, we don't wanna have an issue where the dependency upgrades and we have to deal with that, yeah.

Chris: I have maybe a little bit of a non answer, but I really try to use my intuition which I've built up over the years I guess. I'm not sure if it's any good, but I just try to, for example with Swift, I could obviously see all the benefits coming from functional programming, I was like, "Oh my God, this is beautiful, I wanna use this." And I didn't... And it was a very emotional decision. Like I didn't even really consider all the implications, so I just started using it.

And I guess the same with libraries, if I feel, based on my intuition, this is something I would wanna use, I would use it. But, for example, things like AFNetworking, I wouldn't use in Swift or like Alamofire because I had the feeling that I could do it in a very different way which was much simpler for me. So, I think, for me, a lot of these decisions are based on intuition and based on sort of, immediately trying to judge whether you think it's a good idea or not. But that's... Yeah. It's not very rational.

Q3: Yeah, I had a question about mix and match basically. Using some Swift code in a big Objective-C project, so I guess this is directed to people who have done that, but I'd love to hear everybody's opinions. The question I have about it is; What would you say to the realism of saying that, it seemed like a lot of the examples that you gave for example, Andy, in your talk yesterday, are trying to use Swift from Objective-C and the pain therein. What would you say to the hope and aspiration that you could pick and choose the things that you do in Swift such that it's all only new stuff, kind of things that you're not gonna have to try to use again from Objective-C? Or is that kind of a pipe dream that in real life wouldn't happen?

Andy: You gotta be real disciplined. So, a practice that we used that did help with that a little bit is to do code review on interfaces before doing implementation. So if you... You're gonna think through all your function stems, you're gonna think through everything, then you can reason about, "Oh shit! You used that one thing that's gonna virally make this whole thing not usable from Objective-C." It's very difficult and error prone. You should plan on not being able to do that and be delighted when it works.


Nick: I think unfortunately that's all the time we have for questions because we have to get back to the talks. So, thank you to our panelists.