01:47 - Justin Spahr-Summers Introduction

02:04 - Carthage

02:30 - CocoaPods vs Carthage

04:09 - Motivation for Creating Carthage

06:38 - Support and Getting Started with Carthage

08:19 - Working with Other Custom Build Tools like RubyMotion or Xamarin

09:50 - Static Libraries?

10:58 - The Implementation of Carthage

11:53 - Using This Tool: Mac vs iOS Projects

13:24 - Keeping Carthage Working

14:23 - Naming Carthage

14:51 - Choosing CocoaPods or Carthage

16:54 - Carthage and Swift

19:02 - Challenges

21:02 - Working with Private Repositories

21:56 - Support for Other Version Control Systems

22:58 - The Future of Carthage

30:25 - Forward Compatability

31:44 - ReactiveCocoa

Picks

Welcome to Macintosh Podcast (Andrew)
Appalachian Jerky Company (Andrew)
The Wizard of Earthsea Trilogy by Ursula K. Le Guin (Chuck)
Traction by Gino Wickman (Chuck)
Few.swift (Justin)

 

JAIM: iPhreaks now in stereo!

If it’s not on your good ear, just switch ear buds.

Hey everybody and welcome to episode 98 of the iPhreaks Show. This week on our panel, we have Andrew Madsen.

Hello, from Salt Lake City.

Jaim Zuber.

Hello from Minneapolis.

I’m Charles Max Wood from devchat.tv. I just want to remind you to go check out my Kickstarter campaign; it’s at devchat.tv/kickstarter. It’s a good way to support the shows, and if you like Rails well, bonus for that.

We also have a special guest this week and that is Justin Spahr-Summers.

Hey everyone.

Do you want to introduce yourself really quickly?

Yeah, so I am a desktop, primarily Mac developer at Github, and I’ve also worked on several open source projects like [inaudible 02:01], ReactiveCocoa, Carthage, etc.

Very cool. We got you on the show today to talk about Carthage. Do you want to give a brief overview of what that is?

Yeah, so Carthage is our attempt to create a decentralized, simple dependency manager. So the goal really is the simplest thing possible that build frameworks and give them to you. So it integrates all the things you’re familiar with and doesn’t try to do a whole lot more than just the basic act of resolving some dependencies.

So when I look – went and looked at the readme, it was explaining what the difference was between CocoaPods and Carthage. So do they do the same thing then and what are the differences?

So CocoaPods and Carthage, they still have the same problem space but in different ways and to different degrees. So both Carthage and CocoaPods are used to bring dependencies into your application or framework. So if you have a library out there like Alamofire and you want to bring it in, both Carthage and CocoaPods can do that.

But they differ in their approach, Carthage is very much, “I’ll bring this down for you, I’ll build it, give it to you then get out of your way.” Then CocoaPods are very much helping you discover libraries and helping integrate them into your own project, if you want that, that’s an option. It’s also centralized which is one of the key difference in the approaches. CocoaPods has an official list of the libraries available whereas Carthage just depends on Git repositories from wherever.

So similar to CocoaPods, you’re creating a Carthage file, a Cartfile, you saying cart update that brings down the source, builds it, does that add into your projects? Are you ready to go at that point, does it create a workspace?

No, all that would do, like you said, it would bring down the dependency, it would build them in their own projects and then it will give you built binary frameworks then you can integrate those however you chose. You can just drag them into your Escrow project if you want or maybe you’re trying to just do a binary distribution thing. You can upload those to a Github release. So it can really be used for any kind of – it really just gets you ready to go however you want to use them.

So what was your motivation on this? You started on this obviously you knew CocoaPods was out there, you knew that there was the manual way of doing things where you don’t have a dependency manager at all. What was your motivation for creating a new system that did have these different goals and different design decisions, compared to CocoaPods, in particular?

That’s a great question. Also, historically Github for Mac, which is the primary code base that are working day to day, has had what I’ve been calling excessively nested submodules. So we have submodules with many levels of recursion even, and we’re using Xcodes some projects to bring into our dependencies.

But the problem is if you ever have two dependencies that both share a dependency of their own. So in our case we have mantle and ReactiveCocoa, and those are used by several other libraries that we’ve built. If those other libraries depend on incompatible versions of mantle and ReactiveCocoa, you may not have any idea if that’s happening with Gits and modules because it doesn’t really have that version information built in.

So Carthage was really our time to solve that specific problem by resolving version across all our dependencies and giving us one compatible version for each thing. And as to why we haven’t used CocoaPods, I mean there are several reasons. Fundamentally, we believe in the simplicity of what Carthage does; we think that a simpler tool that solves this exact problem and gets out of our way is preferable to how we work.

We’re coming from a team of – we know how to integrate dependencies, we know how to use Git submodules like I mentioned. So we really just wanted this one additional edge case almost solved for us. We don’t want to bring in this whole new world of dependency management that was outside of the scope of what we’re trying to achieve.

And we forgot to – the library author side of it as well. We’ve released several open source projects like I mentioned. We were frustrated with the requirement to add pod specs to all of our projects. Because from our point of view, we were creating projects that invent frameworks, people can include them through Xcode and did normal officially supported work flow.

All the built in information – all the information that you need to incorporate it is right there in the project file, so why would we want to have this maintenance burden of duplicating that in this custom pod spec format. So Carthage made our lives, as library authors, easier too, because we can solve this versioning problem while using standard machinery to do so.

That’s an interesting point that I hadn’t actually considered. As a library author myself, I was certainly quite impressed when I went to add Carthage support, and I didn’t actually have to do anything. I ran – I can’t remember exactly but I ran your command for checking the Carthage would work and it worked because I already had a framework project, and it found it and it built it and it was literally nothing to do. Whereas when I first added a pod spec and tried to get my library into CocoaPods – it wasn’t horrible but it took some time. I have to remember to update that every single time I push a new release. So I do appreciate that.

Great. I’m glad to hear it worked without much tinkering.

So if I wanted to use your project, Andrew, what do I have to do? I just realize it’s out there, it’s on Github, so I point Carthage to the project and just grabs it and goes, you don’t need to do anything?

Yeah, so I actually have a documentation to tell people how to install the library using various methods because you can still use a sub module or you can even if you want just include the source in your project. For Carthage it’s really simple, you create a Cartfile, you add and align from ilibrary to your Cartfile which is Github and then the path to the project and then you run Carthage update and it builds the framework. Then you have this framework that Carthage puts in its built folder then you drag the framework into your project then you add that like you would any binary framework to Xcode. At that point it’s not Carthage doing anything for you but it’s really quite a simple process, simpler than CocoaPods. It doesn’t take over you Xcode project/workspace. Just like Justin said.

I’m curious, does this work with systems like Ruby motion or Xamarin?

To be honest, I’m not sure. If those custom build tools can be used binary frameworks, just arbitrary binary frameworks then it should work flawlessly but I haven’t looked into it or tried.

I believe they can.

I think from the library author’s point of view, the only thing that the library needs to do is to have a

framework project which is just an Xcode project that builds a framework as its target. And it just needs to be able to build out of the box right? I don’t know, I mean maybe Carthage will – I’m assuming Carthage just runs Xcode build fundamentally, right?

Yeah, pretty much. There are a few complications in there to actually discover which targets are frameworks and to avoid building any sub projects that you might have. But the basic idea, is it just shells out that Xcode build.

Okay, so a library author may have no idea what Carthage is who can still grab their stuff using Carthage?

Yeah, generally that’s the case. There are some requirements that are not really because of Carthage but just anytime you want to do command-line builds, you need to show your schemes.

But if you have your project on a CI service you would need to do that anyways.

Yeah, and I guess the thing that I would add to that frameworks, for iOS in particular, frameworks are new as of iOS 8 and so people have to have added a framework project, it’s maybe not as common to have done it to an iOS library as it would be in a Mac library where frameworks have been around forever but hopefully that becomes more common. Can Carthage deal with static library, I guess I don’t know the answer to that.

No, that’s a great point, it can’t. That was a deliberate design decision because although static libraries are very common in iOS programming today. We were building this app before iOS 8 had even been released, of course it doesn’t have the great market penetration that everyone’s been hoping for it yet. It’s a forward thinking approach, we’re hoping that more and more projects will just use frameworks by default because soon enough there will be no reason not to.

Then they offer several advantages as well like it bundles resources easily. You can deal with diamond to dependency really easily like the example I was talking about. If two libraries are both dependent on ReactiveCocoa, they can both dynamically link it, then you only need one copy at one time, and you avoid duplicate symbol errors or what have you with static libraries.

And it’s interesting because this is a long standing problem that CocoaPods have been solving because it ensures that only one copy of ReactiveCocoa in this example get included as source.

But also using binary frameworks and dynamic linking solves that same problem in a different way.

I actually want to talk to you about the implementation of Carthage. I want to make sure that usage, design and decision questions are all out of the way before we get into that because I assume it’s somewhat a deep topic.

Yeah, I can go on at length about it. I will say one of the other major reasons we wanted to make this simpler tool is not just for our own workflow but in line with Linux philosophy and doing as little as possible in modular components that you can plug and play however you want. So we hope that by making it so simple, by giving it so few responsibilities really, it becomes easier to integrate in larger, more custom, more edge case-y workflows. It’s easier to put, bend a simple tool to your will than to bend a very complex opinionated tool to whatever you're trying to do.

Is there a difference in using this tool in an iOS project versus a Mac project?

Today, there is a difference. Unfortunately, there is an App Store submission bug for which radar has been filed where you can’t submit an iOS app to the App Store if it contains universal frameworks. So if the frameworks included in the bundle contains simulator and device slices, your submission will actually be rejected. In my opinion they should let it through or strip the symbols that are unnecessary. But as of today, that’s a bug. For iOS projects specifically, there’s a Build Phase that we ask you to add but it hopefully not too burdensome.

So we’re adding a Build Phase to our Xcode project, then what does that Build Phase do that runs the Carthage tool?

Yeah, so this would be at the application project level. So this is again something that library authors don’t need to worry about, but at the application project level, you’re adding a Build Phase that’s responsible for doing what I just described like stripping out the simulator slices and all the frameworks that are going with your app to the App Store.

Do they have some automated system there that looks at it and rejects it before it gets to a reviewer?

The reason I think it’s a bug because the errors are cryptic and not really related to the actual problem. It’s complaining about the use of private symbols which isn’t really the problem. So it seems like it’s just an unintentional block.

Has it been acknowledged by Apple as a bug?

No, I haven’t got any response on the rate, positive or negative.

Okay, I use Carthage on a project and we ran into the same thing. What are some patterns to keep this working say you have build server, now the build server needs to have Carthage, how do you handle this? Does everyone on your team have Carthage installed on their dev boxes?

Yeah, so there are a few different ways. Our team certainly does, but one of the advantages of having just plain binary frameworks is that you don’t necessarily need to do that if people are uncomfortable with it or you want it on CI. You could, for example, just check in the built binary after their done, just check into your repository. And then it’s ready to go you can just clone and build it. You shouldn’t need any special tooling.

If you want you can also use Carthage to manage your Git submodules so then it just becomes a plain Git problem almost, and we did that in the past before migrating into the current set up. There are a few different ways to do it, and this has been keeping with the philosophy of it’s simple, it stays out of your way, you can depend on it or not, it’s fine either way.

I have a really important question. Why did you call it Carthage?

[Chuckles] That’s a good question. So Rob Rix came up with that name. He said, “Carthage because it sounds like package. We can change it later.” We never did.

“We can change it later,” famous last words, right?

There’s nothing more permanent than a temporary name.

It worked out great for me because I’m terrible at naming and it sounds vaguely cool.

Yeah, I think it works.

Yep.

So if we’re starting a new project and we have to add a dependency management and we’re sold on the idea that you should use some dependency management which not everyone’s bought into. Carthage, CocoaPods are the two options. When would you use CocoaPods, when would you use Carthage?

And can you use both?

You can absolutely use both. And, I mean I’m unbiased obviously, but from my perspective, one of the great things about Carthage is that in order to add “Carthage support” really you’re just adding an Xcode project and a framework target which is something that people who are including manually will probably want anyways. So one of the great benefits of releasing Carthage has actually been more and more projects including just regular old framework targets. So it’s had this externality benefits where projects are just getting better configured in the first place.

Then if you want to add CocoaPods support on top of that, super easy, just add a pod spec next to your Xcode project, you could have both on parallel.

I'm not sure I followed that giving that real good answer to Jaim’s question. When do you pick one over the other?

In my opinion, it really just comes down to which you personally prefer. There are advantages to CocoaPods. Unique advantages, like it makes discovering library easier because the main CocoaPods repository, and list of packages. It also comes with tools like CocoaDocs for automatically generating documentation and hosting it. But if you’re looking for the least amount of effort that you as a library author have to do, for me that would be Carthage, that would be a plain Xcode project rather than dealing with the pod spec format and submit again. So it really comes down to do you really want to be in the CocoaPods ecosystem or you just want to put something out there and make sure people can include it?

Can you include Objective-C projects in Carthage?

Yeah, it works with Objective-C or swift.

Okay.

Jaim, I haven’t used it – I’ve only used it with Objective-C. Which is the swift business.

I think it’s [inaudible 16:51] we can’t talk about it, right?

That’s actually a pretty good segue into something that I want to ask about which is that Carthage itself the tool itself is implemented in swift, right? Justin?

Yep, a hundred percent.

I’m curious to know how that’s gone because I think this is actually pretty – I mean swift’s been out long enough now that there are plenty of apps that are using it. People that have done fairly big projects and stuff, but Carthage seems like one of the first big open source projects that’s actually been getting traction it’s all written in swift. So I’m first curious to know about your experience using swift.

Yeah, we’ve certainly encountered our share of bugs. I think one of the interesting benefits, if I can call it a benefit is that going all in with swift has forced us to find work around for common bugs. It helps us gain an understanding of what the compiler means when it give you a cryptic type error. So in that sense it’s equipped us with tools to start using swift on other projects and know how to work around these things that might be otherwise be blockers.

But as far as the positives of using it, it’s just been excellent. I think it’s allowed us to develop Carthage a lot more quickly than we’d be able to in Objective-C. And we get the benefits of value types and parameterized types which has been huge with our use of ReactiveCocoa. Because in Objective-C, everything is just cracked signal; you have no idea what it does. In Carthage, you get to see, this is the signal of projects, and this is the signal of Build Phase, whatever the case might be. Overall I think its increased clarity a lot, increased stability and safety of Carthage code. And it’s definitely introduced its share of bugs, but probably not as many as you would see in a GUI application.

Are you still for the main development branch; I assume you’re still using swift 1.1 and not the beta 1.2? Is that true?

That is correct. It’s because of Carthage’s dependencies. So ReactiveCocoa is – I think it just finished getting upgraded to swift 1.2, and until that happened it’s impossible to upgrade Carthage because you can’t mix the swift versions. So now that that’s happened, there’s a working progress branch to upgrade Carthage as well.

Cool, so I’m curious as well to know about challenges that you’ve encountered, not with swift, but with writing Carthage. I know that the people who have worked on and written CocoaPods have plenty of stories to tell about reverse engineering Xcodes and projects and workspace files and working around all kinds of odd behavior and edge cases and related to having to write Xcode projects. And of course they have the Xcodeproj gem that they use. Anyway, are there things along those lines that you’ve run into that are interesting that you’ve had to solve in working on Carthage?

Yeah, not nearly as many as CocoaPods because we avoid project writing and direct project reading. Our entire interface Xcode is the Xcode build. But we definitely encountered a few bugs in Xcode build itself. There are cases where the Xcode build-list command will just hang indefinitely, it’ll print out its output and it’ll never finish which is bizarre.

Separate from Xcode even there are some Git oddities because Carthage uses Git to pull down dependencies to check them out. I don’t know, checking repository that has some modules but making sure that’s not checked out as a submodule itself. It's kind of a tricky problem; we figured out a work around for it. There are a lot of interesting quirks like that, I suppose.

To be honest, the biggest abstract challenge or technical challenge almost has been the dependency resolving itself because it’s very interesting and difficult to create a dependency resolver that is decentralized. Because whereas tools like CocoaPods and RubyGem or other package manager. They have lists of every project in every version that is available for every project. Carthage has to actually find that information out on the fly by going to the Git repository and seeing what are the tags available. Go on to this tag, see what dependencies it uses on that tag and so on and so forth. So it’s very crazy.

So this requires access to the Git repository. What if you’re working with a prior repository, something that you’re doing in-house, in-house framework, is that an option with Carthage?

Yep, absolutely. So it will just use whatever Git credentials you have saved on the command-line and it does that through a standard Git command know as Git credential.

I think the thing Jaim is also getting at is that your library repositories do not have to be Github repositories. In your Cartfile you can just give the complete URL for the Git repository on any server including a local server, or I assume even a local repository that’s on the local Machine right.

Yeah, absolutely, sorry for missing that. You can do that if you’re talking about GitHub enterprise specifically, there’s no first class support for but it is something we have an issue filed for. And the first class support would just mean the ability to download binaries instead of source when available.

Okay, so if you’re going to [inaudible 21:51], you can add it. That’s very cool.

Yep, pretty much.

Is there any plan or any thought that you might add support for other version control systems? The reason I ask because at my day job we use Mercurial for everything and so it keeps us from using Carthage.

To be honest, we haven’t put a lot of thought into it. The simplicity of Carthage, including its implementation, is one of the huge advantages of it. And every different thing that we want to support adds some kind of complexity, so it’s always a case of weighing the complexity against what we would gain. With Mercurial it’s a little tough because there are so many Git Mercurial bridges that I don’t know if it would be worth it. I don’t know, it’s something we have to consider more.

I think we probably could use it. We do our hosting on Kiln and they have a feature called Kiln harmony where repositories can be accessed using either Git or Mercurial. Semi-seamlessly, there are some pretty serious problems with that related to sub repositories but something for a library project, it should work just fine. I haven’t tried that. We also use internal library very extensively.

You were saying that you were trying to keep things simple, and everything you add, adds some complexity, I very much appreciate that I actually admire that that’s one of your guiding principles in working on Carthage.

But I am curious to know what the future is. I know development on Carthage has been really active. I first found it several months ago and I know it’s a whole lot of stuff and a lot of commits have made it into the repositories since then. So I’m curious what the future for Carthage is, what is it that you’re still working on and planning to add into that kind of thing.

It’s funny you should ask this because I actually gave a lightning talk at GitHub very recently about how to start an open source project. One of the [inaudible 23:41] that I brought up was plan your 1.0. Figure out what 1.0 means, what your minimum viable product for 1.0 can be and set up miles stones to get you there. So that’s really been the goal of Carthage from the beginning, it was like we want to get 1.0 because in my mind it’s not really real until there’s a 1.0 release. People are using it, which is excellent, but I want it to be a real thing, I want it to be stable, I want it to be dependable.

So to answer your question, we have a few things remaining before we hit 1.0. The primary one is the ability to save command-line flags per project almost. So right now, you can use Carthage in a way where it checks out some modules for you or you tell Carthage that you don’t want it to build the frameworks automatically. You just want to check them out and go integrate them however you want instead of using the binary’s feature. So settings like that are annoying to specify every time on the command-line, people on your project may not know that they need to specify that many – run into – annoyances.

One of the features we’re trying to add is the syntax to the Cartfile that allows you to specify these kinds of flags just for the application project. So in your application project you want to say, “Yes I want to always use submodules and just put that in your configuration file.” After that, there might be one or two other issues, but that’s really the big remaining thing before the 1.0 is ready to go. And of course we want to review the APIs that we’re exposing to make sure that those are good for a 1.0 release. Because it’s not just Carthage the application but also Carthage kit the framework.

I guess I don’t know how big that job is, but it actually sounds that like you’re getting close-ish to 1.0.

Yeah, absolutely that’s the whole main – so we’re – the per project settings thing that I mentioned is going to be 0.7, version 0.7 and after that, we’re aiming for 1.0. Something may come up we might need to do another intermediate release but it should be 0.7, 1.0 as it stands right now. The only difference between those two is that API review that I mentioned and fixing any last minute bugs.

Cool, this kit’s really hard for any project but what about further into the future? What’s Carthage 2.0 going to be like?

I’ll be honest, I haven’t thought about it too much. Since its inception I had the idea of what 1.0 is in my head. I think it’s a funny question because I feel like if you know what 2.0 is, that should just be your first major version instead. Because to me every major version is the opportunity to make breaking changes where you realize you've made mistakes the first time around.

I guess with every successful release of ReactiveCocoa has been honestly like – we put out 1.0, we’ve been using it in practice for a while and it’s like, “Oh, there are all these problems but we can’t break backwards compatibility, let’s do 2.0.” I don’t know what the comparable example for Carthage would be, but anything that we’re realizing ahead of time is going to be this breaking change problem; we’re just going to try and fix on 1.0 instead.

As far as feature set, I really don’t have many goals for features beyond what Carthage offers today. I mean there are enhancements in the backlog, but I don’t know if there’s anything – the comparable scope to that 1.0 release.

Those are the type of things that come out when people start using it in large numbers, “Oh, we like this case, this didn’t do this.” They refactor your approach and bump you versions. It’s hard to have that crystal ball to look that far forward.

Yeah, absolutely. In some sense, if we never need a 2.0 release, we’ve succeeded. Now, I don’t think that’s likely but that would be my ideal.

So I guess the other question I have, and this is something I see with a lot of open source software is they get something out there, they get something that works. And then some small subset of the community adopts but reaching that wider community and helping them understand how this can help them out is hard. Are there specific things that you’re doing with Carthage to get the word out? Other than coming on podcasts, I guess?

[Chuckles] Well, I will also be giving a talk at the Swift Language user group in SF in the Second of April. Just about the philosophy and the stuff we’ve been talking about. To your larger point, I think a lot of the evangelism is going to wait until after the 1.0. I found that in the past that going out and explaining something that isn’t actually “released” yet. There are people in the audience that are like, “Oh, that sounds awesome, but I’ll wait for 1.0 or what have you.” So after 1.0 I think we can definitely devote more time to making sure that there’s good material out there, maybe a good website doing more talks, and that sort of thing.

This is incidentally one of the things I mentioned in my lightning talk is that when you’re starting an open source project, there are a lot of things that you want. You want a great marketing website, you want great documentation besides what is just available on the code or demand page or whatever. But all that stuff can wait. You can do a 1.0 release and you can add all that and that’s fine. You don’t need to do a break in version or any of that.

In my opinion it’s about getting to 1.0 as quickly as possible without cutting any corners and then adding all that on top; that's a nice bonus.

It’s good to have an end point. A lot of projects are never official. I’ve never gotten to 1.0 and still widely used, but it’s good to draw a line in the sand and just do it.

Yeah, absolutely. I think it’s very similar to shipping an app. At some point you have to decide what your scope is. As programmers we’re all familiar with the problem of scope creep. We really wanted to avoid that from the start with Carthage so it’s been very defined.

Yeah, I think you’ve done a very good job. I actually opened an issue quite a while ago about an enhancement and you said, “Well, we’re not going to do that.” In one sense I was a little disappointed because I would have like the enhancement but I actually think it’s a good thing that you’re keeping things simple and actively trying to avoid scope creep. CocoaPods is not at version 1.0; it’s been around for a long time. I don’t think a lot of people realize that it’s still pre-release.

Yeah, and that’s definitely – I’ve actually seen the CocoaPods contributors express a little bit of concern about that too because it’s, if 1.0 CocoaPods breaks all the expectations that the user have today, people are going to be really upset and not realize that it was this pre-released version.

08] it was justified.

Yeah, it was being able to put the output of Carthage in a different folder other that Carthage.build so for example, put it in some framework folder that you already using in your project. But it’s really not a big deal [chuckles].

So with Carthage, so it’s developed in swift, you’re creating a binary that lives on your Machine. Is there a concept of having different version of Carthage when that day comes with CocoaPods. You can do that by managing the ruby environment things like that, RVM. Is there any though to how you can do that in the case where a project is relying on an older version of Carthage?

Our hope should be that everything has forward compatible, so far that has been 98% true. Because the format – the Cartfile format for example, is so very simple; it doesn’t really do much at all, and it’s very easy for us to maintain compatibility with that going forward. So there shouldn’t be some any ill effect from using a newer version of Carthage. Now the one exception to this so far has been around version 0.4, we changed the structure of Carthage projects on discs but it included an automatic migration and stuff. So this is like this one breaking chain that we decided was really important to make before 1.0 and so we just did it. But especially after 1.0 that sort of stuff won’t happen so it’ll just be forward compatible and the latest version should just work.

That’s the benefit of the simple approach with CocoaPods. It’s so invasive what you’re doing to the project, to the workspace, the different versions just don’t play well together.

Yeah, that makes sense.

So I have a question about the ReactiveCocoa. This is all done using the ReactiveCocoa extensions, I was in San Francisco last year for WW and you held the proactive CocoaConf in about the same time. So I was there, right after Swiftware was announced. At that point we weren’t really sure what direction you were going to take but you have gone and you have created the ReactiveCocoa in swift?

Yeah, that’s correct.

Okay, what happened?

It’s funny because Carthage was, in some sense – this wasn’t why it was created but a big part in technology choices made in Carthage is that it’s a great test bed for a ReactiveCocoa swift API. Because we can’t go in and refactor all of GitHub for Mac tomorrow to see if the swift API is worth using. So Carthage being on that swift API before it’s been released has been really helpful in terms of determining what works, what doesn’t and it’s helping us get to ReactiveCocoa 3.0 a lot faster.

Very cool.

Anything else we should talk about before we go to picks? Alright.

Thanks for all the questions.

Definitely. Andrew, what are your picks?

I got two picks today, my first is a competing podcast – no, it's really competing but it’s a new podcast. It’s called Welcome to Macintosh and it’s by a guy name Mark Bramhill. It’s only two episodes in so far but going by the two episodes he’s done so far, it’s sort of a historically focused podcast about Apple. First episode was about the pre-iOS 7 UI design in iOS and how that was really actually tied to Steve Jobs and it was quite interesting, and the newest episode as of this recording which was episode two is all about iOS development before the App Store came out. So it’s called Sweet Solution, it’s pretty good. It’s got interview with Neven Mrgan and Craig Hockenberry. I just love this historical stuff and he’s doing a great job with it. So that’s Welcome to Macintosh and its Macintosh.fm.

My second pick is some beef jerky that I’ve been enjoying lately. I was in Massachusetts six months ago and found this in a store there, I really liked it. So I found their website and ordered a bunch of it. It’s called the Appalachian Jerky Company. The reason I like it is they don’t use a bunch of extra sugar and I get really tired of food that shouldn’t have a ton of sugar in it having a ton of sugar in it. Its good non-sweet jerky and they’ll ship it anywhere. So that’s Appalachian Jerky Company. Those are my picks.

Alright. Jaim, what are your picks?

You know I’ve just decided that everything is terrible. I don’t have picks I’m just thinking about Andrew’s beef jerky. That sounds delicious.

Everything is awful.

Alright. I’ve been listening to a bunch of books lately so I’ll just share some of those. I just finished book three or the Earthsea books by Ursula K. Le Guin. I really enjoyed that, it’s called the Farthest Shore. The first one’s called the Wizard of Earthsea. They’re kind of early on fantasy books but they’re pretty good. So I’ve been enjoying that.

I’m also going to pick a book called Traction and it’s a book. If you’re trying to get adoption of different things, it talks about different strategies and things that you can use to gain adoption or build your business. So those are my picks.

Justin, do you have some picks for us?

I have one pick. It’s actually a product of a friend of mine, Josh Abernathy. Helped create, basically started ReactiveCocoa actually. So he’s started project now called Few.swift which is a swift implementation of the principles behind Facebook’s React Native. So it’s all about treating views as pure function of their state so you can describe you UI ahead of time. Do functional transformation out of it and at some later point convert it into UI view or ASCII. It’s really cool, it’s very much in development right now, so not ready for production use but definitely worth a look and I’ll be keeping a very close eye on that as it develops further.

That looks cool. I haven’t heard about that yet. Definitely have to check it out.

Yeah, I’m really excited. It’s an awesome principle.

I’m not too excited about the React Native just because of the JavaScript thing and I realize that JavaScript is just the implementation language and the concepts or what’s important and all that but I’d really rather not actually work in JavaScript, so swift sounds cool.

Very cool. Alright, well thanks for coming Justin. It was fun to talk and hopefully some folks can find Carthage and get some good use out of it.

Yeah, well thank you very much for having me.

If people want to learn more about the project or about you, what are the best ways to do that?

The primary was right now is the Carthage repository on GitHub, but I’ve also written a couple of core answers just explaining some of the philosophy behind Carthage and maybe how you would use it but other than that just on Twitter on @jspahrsummers is a great way to get in touch too.

Thanks Justin.

Thank you.