00:00:00 ◼ ► Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment.
00:00:05 ◼ ► And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.
00:00:25 ◼ ► And in the, I think it's about 15 months since then, much has changed, much has happened,
00:00:36 ◼ ► but I think we are now both in a place that we can actually talk with some experience about Swift,
00:00:45 ◼ ► If there's anything that can go on my tombstone, it's like, waffles purely speculatively.
00:00:56 ◼ ► But yes, we have now both used it, and I think it is an interesting time in the life cycle of Swift,
00:01:03 ◼ ► I think, to talk about, because I think it is hitting a point now where if you aren't using Swift on a regular basis,
00:01:15 ◼ ► there may have been a period, I mean, this is largely what we were arguing back in 2015,
00:01:20 ◼ ► that back then, if you were adopting it, you may be setting yourself up for a future hurt,
00:01:40 ◼ ► And I thought it would be interesting for us to unpack it a little bit and just talk about our experiences,
00:01:45 ◼ ► because I've been doing Objective-C for so long that doing anything else is always going to feel weird,
00:01:51 ◼ ► and I think it's been interesting. So I wrote all of Workouts++, the last major app I launched in Swift.
00:01:59 ◼ ► There's not a line of Objective-C in it. There were a few areas where I could have cheated a little bit,
00:02:04 ◼ ► where I had some existing functions or library code that I could have pulled in from another project,
00:02:12 ◼ ► and I said, "No, I want this all to be in Swift," and so I translated those over and made them work.
00:02:27 ◼ ► but I think the process of learning something feels like more of a mountain to climb now,
00:02:40 ◼ ► But now that I've done it, I think I'm glad that I did, and I certainly have no regrets.
00:02:44 ◼ ► But we'll get into this as we go on. But it is definitely not without its trade-offs to be getting into now.
00:03:00 ◼ ► I had a need for a new extension for Overcast 3.0, and it was going to be a pretty small extension,
00:03:17 ◼ ► And I did it in a day, or less than a day, actually, because it was the same day that ATB recorded with Chris Lattner,
00:03:25 ◼ ► To just suggest you wouldn't have to sheepishly look at your feet when he started talking about Swift.
00:03:34 ◼ ► But yeah, so I started with it that day, and I've since written a little bit more of Overcast 3.0 using it.
00:03:48 ◼ ► And I have written new code since then that is an Objective-C, partly because of just the simplicity of
00:03:55 ◼ ► "I know how to do this really fast in Objective-C, and this is going to be a constant battle for me."
00:03:59 ◼ ► Trying to balance, do I take the extra time and hassle to learn how to do this in Swift,
00:04:14 ◼ ► "Well, I know how to do this really quickly, and I don't want to take the time to learn."
00:04:37 ◼ ► We live in a different world, different conditions, but we can kind of compare it back to when OS X launched,
00:04:46 ◼ ► And Mac developers have been writing in this other way, using C instead of Objective-C and C++,
00:05:13 ◼ ► And eventually, Apple started making new capabilities and new frameworks that could only be accessed through Cocoa.
00:05:36 ◼ ► Basically, any time now, we could hit a point where Apple launches some new framework or capability,
00:06:43 ◼ ► And you can do it at a more opportune time, you can do it over a more gradual period if you want to,
00:06:48 ◼ ► and so you can choose when to take that productivity hit, when to learn this new language,
00:06:54 ◼ ► So that way, when the inevitable happens, when Apple does something that either forces you
00:07:55 ◼ ► which was certainly something that has happened, and I guess theoretically could still happen,
00:08:30 ◼ ► so that you have a good Swift API should look like, seems to be fairly buttoned down now.
00:08:56 ◼ ► where it's like, actually, we tried that and that's not really a good way to structure things,
00:09:01 ◼ ► or to name things, because it's a bit of a joke, but one of the hardest things in programming is naming,
00:09:23 ◼ ► and it's very much something that seems to be settling in, and that kind of style side of it,
00:09:33 ◼ ► And I think also, the style they've chosen, it seems reasonable and it makes more sense to me
00:10:00 ◼ ► Because I was a bit surprised, honestly, that it was easier to learn than I thought it would be.
00:10:11 ◼ ► versus I've written dozens of apps in Objective-C, but going to it, it helps, certainly,
00:10:23 ◼ ► And so that part didn't change. I know how UIKit works, and I know how all the frameworks work,
00:10:31 ◼ ► But I also like the one thing that's kind of nice with Swift that I wasn't sure how much this would be true,
00:10:39 ◼ ► and maybe nervous, was you don't have to go all in on kind of the more, I guess I'd call it esoteric features of Swift.
00:10:53 ◼ ► Yeah, like where you can do these really clever, complicated things with closures and generics and types,
00:11:26 ◼ ► that my code was going to, in order to write good Swift, it was going to have to be this kind of very esoteric,
00:11:31 ◼ ► this kind of very crazy version of code that just isn't the way that I tend to think about problems.
00:11:37 ◼ ► I tend to think very straightforwardly and pragmatically, and that works well in Objective-C,
00:11:44 ◼ ► And maybe my Swift isn't taking advantage of some of these cool features that I could be taking advantage of,
00:11:50 ◼ ► but it still works well, it still flows nicely, and isn't like I'm kind of fighting against the grain on that.
00:12:00 ◼ ► when you start to do things where you have a function that takes a closure that you can use to process data,
00:12:07 ◼ ► and so you can ask for, like I use this in a bunch of my, like in Workhouse++, there's a bunch of graphs, for example.
00:12:22 ◼ ► it needs it in a different, like the end result is just going to be numbers on an xy plot,
00:12:29 ◼ ► but the input can be different, and so I have a nice little, like, swifty thing where you can,
00:12:33 ◼ ► when you're setting up the graph, you also give it a little transform to take the data from whatever form you have it on the input side into the expected output side.
00:12:42 ◼ ► And that makes that graph code look really cool and clever, and I feel kind of cool about myself that,
00:12:48 ◼ ► "Hey, I wrote this very swifty thing, but if I didn't do it that way, and I just did it in kind of a more procedural, direct way, that would have been fine too."
00:12:57 ◼ ► And I like having that flexibility and not feeling like I'm totally having to buy into this just super esoteric version of things that is possible in Swift.
00:13:07 ◼ ► Yeah, exactly. I mean, I think one of the advantages that we get as indies, especially as like literally one person shops,
00:13:15 ◼ ► is that we only write this code for ourselves. We are probably the only people who will ever even see this code.
00:13:22 ◼ ► Like, there's the slight chance that you might down the road sell the app or hire somebody,
00:13:27 ◼ ► but for most of the apps that you and I, and I think most people like us, write, that's usually not the outcome.
00:13:32 ◼ ► So you can basically write your code in whatever style you want, in whatever language you want that works on the platform,
00:13:45 ◼ ► And so if you are the kind of person, like you're a real language nerd who really likes all those really clever things that languages can do
00:13:52 ◼ ► with some of these kind of esoteric constructs and little complexities throughout, then you can do that.
00:13:59 ◼ ► And you can be incredibly personally satisfied that you can do that, because there's no style manager at your company telling you that you aren't allowed to use that.
00:14:07 ◼ ► You can use the latest versions of all the languages and all the coolest things that come with the latest versions of all the languages.
00:14:11 ◼ ► You can make those decisions yourself, and if you want to be clever, you can be clever.
00:14:19 ◼ ► And you can alternate whatever you want, depending on how you feel that day, and whatever the code is that you're writing.
00:14:29 ◼ ► And it's something that, like, if you're working with a lot of other people, if you're working at a company, or possibly even doing consulting.
00:14:37 ◼ ► You know better than I would how often this actually comes up in consulting, where you have a lot of other programmers looking at your code.
00:14:42 ◼ ► But if you're working with other people, then you have to deal with everyone having to either not follow the same complexity level,
00:14:50 ◼ ► and have code that varies wildly in cleverness and complexity being merged into the same app and worked on by a team of people.
00:14:57 ◼ ► Or you have to enforce some kind of style guide, which is never easy, but to enforce some kind of style guide on people,
00:15:03 ◼ ► makes them miserable, that says, "Alright, well this is the way we do this, this is too clever, this hurts readability or whatever else."
00:15:10 ◼ ► And so it is kind of nice to be in our position where we can pretty much write code however we want,
00:15:15 ◼ ► and the only people that will ever see it are us, so we're just writing to make ourselves happy with it,
00:15:23 ◼ ► Yeah, and I think that speaks to also the sense that I see in Swift, too, something that I can see how many of the choices that it has made
00:15:33 ◼ ► are about addressing problems that I think would come up in a situation that doesn't really directly apply to us,
00:15:40 ◼ ► that does speak to the situation, like the large codebase with lots and lots of people potentially coming in and out of a project,
00:15:47 ◼ ► or this was built by these consultants and then it was passed over to these consultants, and now we've taken it internally.
00:15:54 ◼ ► And this is something that I struggle with still, is Swift encourages very strongly a certain level of formalism in what you're doing,
00:16:12 ◼ ► Perhaps the most straightforward example of this is optionals, where you have to be very clear about should this value have a value or does it not,
00:16:22 ◼ ► and you have to be very upfront and clear about that, and there's no way, if you have something that isn't an optional,
00:16:33 ◼ ► And I can see that those types of features would be incredibly useful in that kind of varied, mismatched codebase,
00:16:44 ◼ ► where you're just removing ambiguities from the code. Everything has to be very upfront, everything has to be very explicit.
00:16:52 ◼ ► I mean, the other thing that drives me, that still drives me crazy, is the number of times I have to cast ints to doubles and doubles to cg floats,
00:16:59 ◼ ► and doing all this kind of work to move around, which all being very precise and very formalized, which is not a bad thing.
00:17:07 ◼ ► The code is still definitely better as a result of it in the sense of it is clearer, but it takes more work to do.
00:17:14 ◼ ► In Objective-C, I haven't been doing that and things have been fine, and that's easy for me to say because I'm a one-man team,
00:17:27 ◼ ► And every now and then I'll probably run into a problem with that, but in general it works out okay.
00:17:38 ◼ ► I wouldn't want to say that I don't like that they're there, but I find them inconvenient sometimes.
00:17:44 ◼ ► And it's probably getting better now that I've done more of it, that things become a bit more automatic.
00:17:50 ◼ ► But there's a lot of features in it that I think work well for these structural, big picture issues that you might encounter in a complex codebase
00:18:02 ◼ ► that don't directly apply to me, but are definitely something that I just have to wade through anyway.
00:18:09 ◼ ► We are sponsored this week by Pingdom. Start monitoring your websites and servers today at pingdom.com/radar.
00:18:16 ◼ ► You get a 14-day free trial, and when you enter offer code RADAR at checkout, you get 20% off your first invoice.
00:18:21 ◼ ► Pingdom is an awesome monitoring service. I use it, Dave uses it, I've used it for a very, very long time,
00:18:29 ◼ ► I think something like eight or nine years now. It is ridiculous how long I've used Pingdom because they're just good.
00:18:33 ◼ ► We used them all the way back at Tumblr, the whole lifetime at Tumblr, all the way up through all of Instapaper.
00:18:43 ◼ ► Dave even uses it to monitor sites that aren't even his, like when the WWDC was announced and things like that.
00:18:49 ◼ ► So with Pingdom, they offer easy to use, powerful, and incredibly effective monitoring tools and services.
00:18:57 ◼ ► So you can monitor the availability of your site, your database, your server, any kind of key interactions like a login or a search or anything like that.
00:19:05 ◼ ► You can monitor all of these things, whether it's like the front end or a backend service, all of these things.
00:19:10 ◼ ► You can have them checked as often as once every minute if you want to. And of course everything's customizable.
00:19:20 ◼ ► One of the tricks I do with Pingdom is I have two checks, I have two levels of failure, one of which is called the vitals check.
00:19:28 ◼ ► And that checks a special page on my site that runs a whole bunch of tests and tests things like low memory, very high CPU usage on any of the servers, low disk space, stuff like that.
00:19:38 ◼ ► Long replication lag on a MySQL slave for instance. There's so many possible conditions that you're like, "I want to be notified when that is in this warning zone."
00:19:49 ◼ ► However, I don't need to be high alert, text messaged, phone called, faxed, woofed. I don't need all of those things to all happen at once for that kind of condition.
00:19:57 ◼ ► So you make two tests. One of them you have that kind of low error condition and you can set entirely different alert parameters for that one.
00:20:04 ◼ ► And then you can have like a high alert situation of like it is down, the site is down, something critical is not working, it is down.
00:20:11 ◼ ► That's the one that you set to all the high alerts. Because you have all these independent options you can set for different alerts, you can be alerted all different kinds of ways.
00:20:18 ◼ ► Text message, app push notifications, there's so much emails, so much you can do there.
00:20:27 ◼ ► All you need to do is give them a URL to monitor whether it's yours or somebody else's.
00:20:31 ◼ ► And you can search for changes, downtime, conditions, whatever you want and they take care of the rest.
00:20:36 ◼ ► You'll be immediately alerted to any failures that happen so that way you can go fix them before like the entire internet sees it and tweets you that, "Hey, your site's down."
00:20:45 ◼ ► Like you should know before Twitter knows and then you should be the one that can go then start fixing it before too many people see it.
00:20:52 ◼ ► So check it out today at Pingdom.com/Radar. You get a 14-day free trial and use code radar at checkout to get 20% off your first invoice.
00:21:08 ◼ ► Some of the last few things that I think it seemed like it might be worth talking into were some of the things that we wish were slightly different in Swift or problems we ran into just to kind of wrap this out.
00:21:22 ◼ ► Because I think overall I have a fairly positive view on it, but I think there are still some issues that I ran into that make it a bit more sort of awkward.
00:21:31 ◼ ► And like the ones I was just touching on I think is like the easy example to like the things that won't change going forward probably, like some of the structural approaches and the formalism that the app has like isn't my favorite, but that's more of a personality issue.
00:21:44 ◼ ► But I did, one thing that I did run into many times that was definitely, probably in some ways was the biggest change for me coming from Objective-C was that it felt like the tooling for Swift still hasn't quite caught up to the level that I'm used to when I'm working with Objective-C.
00:22:00 ◼ ► Things like the documentation viewer being appropriate, coming up as you would expect it to and knowing what I mean when I'm option clicking on a method name, or how long it takes for things to compile, or probably even moreover it's the time it takes for the compiler to adapt to a change I make where it reports an error, I fix the error, and then I recompile and it's like sometimes it picks it up right away, sometimes it doesn't quite.
00:22:27 ◼ ► There's a lot of these little issues that I'm sure will get better, and I'm sure that whatever it is when we get the next version of Xcode this summer they'll continue to get better, but that was one area that I was coming to Swift was like, hmm.
00:22:42 ◼ ► The language issues aside, that is an area that I'm very hopeful that Apple is putting a lot of effort into to making sure that that catches up because it definitely makes me realize how spoiled we are in Objective-C land.
00:22:54 ◼ ► Xcode for Objective-C is just perfect. It does such a good job, it is so responsive and performant. Obviously, Xcode has its issues. I talked to Mia three or four years ago and I'm sure I was complaining about Xcode crashing and things happening, but by and large the actual day-to-day editing of code and things in Objective-C was one of the areas where I felt like I wish Swift could catch up to this and just be a little bit better and a bit more efficient.
00:23:25 ◼ ► Yeah, and I think the good thing is that every time there's a new Xcode beta or a new major release in the summertime, they actually do make major progress in that area.
00:23:35 ◼ ► So it's not like they're standing still on that. They had a lot of progress to make, however they do seem to be making it on a regular basis. And it's to a point now where in my admittedly still very early and light usage of Swift, I didn't really run into a lot of problems.
00:23:54 ◼ ► There are certain little annoyances of things like figuring out the bridging and everything because none of the automatic stuff did it for me, but for the most part it was pretty good. And I've actually found it very useful.
00:24:06 ◼ ► One of the things that I commended the Microsoft development stack for a long time ago is that you can basically start coding in C# as long as you know that it looks kind of like Java.
00:24:18 ◼ ► And so all you need to do is type a method name and a dot. Or type an object dot and then it will autocomplete and offer you every possible method that that option can do.
00:24:29 ◼ ► And it makes it so easy that you can kind of fumble through while barely knowing the language at all.
00:24:37 ◼ ► And that is kind of how I've been using Swift so far. I still haven't read the Swift book. I haven't actually learned Swift, I just started using it.
00:24:48 ◼ ► And I just kind of stumbled through because as you mentioned earlier, I know the frameworks really well and I know some general ideas of what Swift is.
00:24:57 ◼ ► There were a few times where I had to look up syntax for things like the guard let block and everything else, but for the most part I just kind of figured it out and stumbled through.
00:25:07 ◼ ► And a lot of times I will do something wrong, but then the autocorrect suggestion warning that comes up is almost always what I wanted and so I just let that do what it thinks it needs to do.
00:25:19 ◼ ► And it works. And at some point I'm going to have to read that Swift book and I just keep putting it off, but the tools are so good now that you can stumble through the way I do now.
00:25:31 ◼ ► You can, like if you are a reasonably experienced programmer and you know the frameworks, like most people listening to the show in all likelihood, if you haven't used Swift yet, it is surprisingly easy to just start using it without doing a whole bunch of research and learning up front.
00:25:46 ◼ ► You just start plowing through and the tools help you along the way. And that's great for, I mean it's probably great for novices also, but certainly from our point of view and from my point of view, that's been invaluable.
00:25:56 ◼ ► And the tools, there is still a lot of room for improvement, but they are, after hearing all the horror stories from people about source kit crashes in the early days and bad compile times and everything, I'm actually quite happy with the state of the tools right now.
00:26:11 ◼ ► Obviously yes, it can be improved, but they were better than I expected them to be given what I've heard. And the only thing that really bugs me about using Swift is that now my binary is going to be more than seven megs.
00:26:23 ◼ ► That's the one thing that, like, I know nobody cares. I know that you're using Overcast to download podcasts that are like 50 or 100 megs per episode.
00:26:33 ◼ ► I'm very aware of this fact, and so the fact that my app is like seven megs and that now that I'm shipping Swift code it's going to go up to like 25 megs, I shouldn't care about that, but I do.
00:26:43 ◼ ► And I wish that wasn't the case for a long time. That's why I didn't use Swift, was that I didn't want to bloat the size of my app.
00:26:50 ◼ ► Hopefully down the road they can build in the frameworks and the OS level when things stabilize so that that's less of a problem.
00:26:56 ◼ ► Or I'll just have to accept a 25 meg app for the rest of time and I'll just deal with it.
00:27:01 ◼ ► Yeah, and I will say, there's all those little things like that. App size is a minor point.
00:27:23 ◼ ► It's not quite like they've gone 180 degrees, but they've made a fairly substantial course correction and done it in a way that makes sense.
00:27:32 ◼ ► I think I had a similar experience to you of learning. I read the first section or the first chapter of the Swift book.
00:27:40 ◼ ► I didn't read the whole thing, I just read the basic syntax part, which I think is probably all most Objective-C developers would need to do to get started.
00:27:53 ◼ ► And then it's familiar but different in a way that makes it very approachable and reasonable.
00:28:02 ◼ ► It's a great little trick they pulled to get everybody off something that they wanted everyone to get off, but did it in a way that hasn't been quite so painful.
00:28:14 ◼ ► And I think certainly some of that is because we waited until Swift 3 to get onto it, and so a lot of the teething issues are done,
00:28:29 ◼ ► I admire the people who were really excited about being part of Swift's creation and part of its evolution, and were really excited about that process,
00:28:37 ◼ ► whereas I had no interest in that. That just sounds like something I would not enjoy. I love being able to just arrive now,
00:28:45 ◼ ► benefit from all that work and the thoughtfulness that went into it, and pick it up pretty quickly.
00:28:52 ◼ ► It's kind of remarkable in some ways that you wrote an extension in Swift without ever knowing really more about Swift
00:29:01 ◼ ► than just probably seeing the example code on slides at WWDC and a few little bits and pieces there,
00:29:08 ◼ ► and you just kind of can work it out and make it happen. I think that says a lot to the language design and how far things have come.