This episode is freely available thanks to the support of our subscribers

Subscribers get exclusive access to new and all previous subscriber-only episodes, video downloads, and 30% discount for team members. Become a Subscriber

In our 100th episode we take questions from our viewers!

00:06 Welcome to the 100th episode — yay! We didn't expect to make this many episodes, but here we are, two years since the very first one. Time went by pretty fast. And to celebrate, we're doing a live Q&A this week.

Why do your Playgrounds always work?

01:47 Let's start with an easy question. Ricardo and Bart both ask, how come Playgrounds always work so well in our videos? There's not a lot of video editing involved, contrary to their suspicions. It really depends on the version of Xcode, and a bit of luck, but Playgrounds generally work pretty well for what we do. The recording of the episode we did at Kickstarter with Brandon was a big exception. Then we wasted a lot of time waiting for the Playground to work, because we were doing some pretty heavy stuff.

03:09 People might also be surprised that our Playgrounds run so well on the Macbook Air they see us using, but we actually work remotely through screen sharing on a Macbook Pro, that's at the other end of the studio. We have to work this way, because recording the screen with Quicktime causes the fan to spin up, which is picked up by our microphones.

What's the process of a Swift Talk episode?

04:09 Mustapha asks, do we write a full script, or just shoot rushes from an idea and edit them into a video? Usually we start with a topic to talk about, and then most time is spent on the preparations: working out the code, thinking about how to present a topic, how to break it up into multiple episodes.

Once we're done preparing and we've done a couple of dry runs, we send a rough version of the video to Ole Begemann. He does a technical review for us, giving us pointers about how to make the episode better, more understandable, and stuff we might have forgotten. After Ole's review, we record and edit the episode. When the edit is done, we send the video to Juul, who writes the transcript for the website. Finally, the transcript is sent to Natalye, who does all our copy editing.

All in all, it takes quite a few steps from the first idea until the episode is online, and with the help of people who make everything we send to them better.

Using our forms library, how would we hide a section?

07:24 Chris has a question about our forms library, which we've been building over the last six episodes. He asks, how would we show and hide sections, and generate new content, based on the user's input? Specifically, how do we show/hide the password section when we toggle the hotspot on and off.

We prepared some code for this question. We added a new property, isVisible, to each section and we bound it to isEnabled:

let hotspotForm: Form<Hotspot> =
    sections([
        section([
            controlCell(title: "Personal Hotspot", control: uiSwitch(keyPath: \.isEnabled))
        ], footer: \.enabledSectionTitle),
        section([
            detailTextCell(title: "Notification", keyPath: \.showPreview.text, form: showPreviewForm)
        ], isVisible: \.isEnabled),
        section([
            nestedTextField(title: "Password", keyPath: \.password),
            nestedTextField(title: "Network Name", keyPath: \.networkName)
        ], isVisible: \.isEnabled)
    ])

08:53 Whenever isEnabled changes, the password section changes as well. We kept the API simple by using key paths to bind properties to each other.

09:21 The implementation inside the library makes a diff between the old and new sections when the state changes, in order to show or hide the correct table sections. It can be tricky to get this logic right, but it's hidden inside the library, so users of the library don't have to worry about it:

class Section {
    let cells: [FormCell]
    var footerTitle: String?
    var visible: Bool
    // ...
}

class FormViewController: UITableViewController {
    let sections: [Section]
    var visibleSections: [Section] = []
    // ...
    var previousSectionVisibility: [Bool]

    func reloadSections() {
        var deleted: IndexSet = []
        var inserted: IndexSet = []
        var deletes: Int = 0
        var previousDeletes: Int = 0
        for i in sections.indices {
            if previousSectionVisibility[i] && !sections[i].visible {
                deleted.insert(i-previousDeletes)
            }
            if !previousSectionVisibility[i] && sections[i].visible {
                inserted.insert(i-deletes)
            }

            if !sections[i].visible { deletes += 1 }
            if !previousSectionVisibility[i] { previousDeletes += 1 }
        }

        visibleSections = sections.filter { $0.visible }
        previousSectionVisibility = sections.map { $0.visible }

        // ...
    }

    // ...
}

10:27 We look at another example: a form that lets us select a country and a region. When we select a country, the list of regions is updated to the regions of that country. This form works the same way as the first example: we observe a key path to know which country is selected and which regions should be visible. The form is still laid out statically: there are sections with regions for every country, but only one of them is visible at any time:

let regionForm: Form<LanguageAndRegion> = sections(
    provinces.map { (country, regions) in
        section(
        regions.map { region in
            optionCell(title: region.name, option: region, keyPath: \LanguageAndRegion.region)
        }
        , isVisible: \LanguageAndRegion.[visible: country])
    }
)

Here we're using a key path subscript to compute whether or not to show a section. We'll definitely come back to this in a future episode, because these features are very useful additions to the forms library.

Supporting old platforms?

12:18 The next question is, how to use the latest and greatest from the iOS SDK and support old platforms at the same time? First, we have to insert a disclaimer that we haven't had to do this for some time, so our experience with this challenge is quite limited. And there's no single answer to this question. One option is to use wrappers to hide implementation differences in different iOS versions. Alternatively, you can rebuild new features for older platforms yourself.

What's your opinion on React Native?

13:39 We don't have any informed opinions on React Native, because we haven't really worked with it beyond trying it out. Conceptually, it follows a similar pattern as the Elm architecture, which we discuss in our book App Architecture; a virtual view hierarchy is computed from the state, and the framework takes care of updating the UI. That's pretty cool, because instead of separately doing the initial view construction and applying updates, we just have to write a single code path. We don't know if React Native is the future — there are definitely good use cases for it, but that also goes for Swift and native development.

Swift and AI?

15:39 Next question: is Swift ever going to compete with Python in AI and machine learning? This covers another area in which we don't have any expertise, nor can we predict the future, but we know there are some interesting developments with TensorFlow and Swift. Without some obvious reason to switch, it's probably unlikely that Swift will suddenly play a major role in the big ecosystem of AI.

Best-kept secrets of top App Store publishers?

16:45 In a second question Iklil asks, what are the best-kept secrets of iOS development used by top App Store publishers? Neither of us is a top publisher, so maybe we just don't know the secrets, but we believe there really aren't any. To become successful with an app, it takes a lot of hard work, and a lot of luck. In our experience, most developers are happy to share their knowledge, especially the ones at smaller companies. And they'll confirm that the "secret" is putting in the time and effort. The Swift developer community feels very open: most people are happy to share how they solve problems.

Do we think about scaling when we discuss app architecture?

18:45 Mustapha asks, when we demonstrate a high level technique, do we think about how it would scale in real world apps? And whether we have tips to keep a whole project clean?

We definitely don't discuss anything in our book if we think it would break as soon as, say, your project exceeds 5000 lines of code. But other than that, the scaling question is difficult to answer. As your project or team grows, you need good processes and conventions in order to not let things get out of hand. Some architectural patterns enforce a stricter style than others, like the Elm architecture, but if you follow a looser system, you could end up with view controllers written in different styles within a single project. How strictly you should follow a pattern depends on your team. For one team it can work to leave a lot of freedom to developers to implement something how they see fit, but for another team that might be a bad idea. Theoretically, every example we cover in our book can be taken and applied to a real world app.

Why does Florian look so happy?

21:19 Mustapha also wonders, why does Florian always look like he's on the brink of laughing? The truth is, we always have a lot of fun when we're recording an episode. At that point, everything is prepared, and we can just enjoy it.

Do we ever get stuck in refactoring?

21:50 Yera asks, do we remember cases where we got stuck in refactoring and ended up with not so clean code? Yes, both of us have gotten stuck while refactoring. Most of the times while refactoring, we're learning and understanding the code more and more, and if that's the case, we can end up with nice code. But sometimes, it can also become clear that we don't yet understand the problem, because the refactoring isn't working out. That's a good moment to close our laptop and do some good thinking about what it is we're trying to do.

What do you we need to know to publish an indie app?

23:56 Prathamesh asks, how many of the advanced Swift topics we cover in our videos are realistically needed to write and publish an indie app that's more capable than a calculator? If you want to make an indie app, you should just build it, and don't worry whether to use a for-loop or a flatMap. If your app becomes larger, or you get a bigger team, the quality of your code starts to matter more. As long as it's just you, you should build an app the way it works well for you.

For us, it's a personal interest and ambition to always figure out new solutions to the same problems, and to learn better ways to write our code. That's why we make our videos and books.

Also, you shouldn't underestimate writing a calculator. It's quite interesting to think about how it should work and definitely not straightforward, at least to us — especially if you want to make the code beautiful.

Third-party frameworks or coding from scratch?

26:49 Oliver asks, do we have any 3rd party frameworks we tend to go to, or do we write everything from scratch? Since we started using Swift, we haven't relied on frameworks that much. We prefer to have most code under our own control.

Swift or Objective-C?

28:09 Jack asks, as veterans of iOS development, do we prefer Swift or Objective-C? We haven't written Objective-C for quite a while now, so it's definitely Swift for both of us.

Is the Elm Architecture ready for production?

28:33 People are already successfully using the Elm Architecture in the Elm language. We've been using our own library in Swift, but we don't have the time to maintain an open-source library. Whether something is production-ready depends largely on what you do with it. It can be useful to create a side project and play around with it, to test the waters.

If you're interested in this topic, we recommend watching our video about the Elm Architecture. We just wrote a book called App Architecture, and we made videos to accompany the book, in which we discuss each architectural pattern. In one video we show what it takes to implement the Elm Architecture, and it demonstrates the hurdles to overcome in order to use it in production.

Server-side Swift: Vapour, Perfect, or Kitura?

31:03 Lars asks, which is more mature: Vapour, Perfect, or Kitura? We want to shout out to Point-Free, who wrote their own stack and were able to swap it out very easily when SwiftNIO came out. We're still planning to do some server-side stuff, and it's likely we'll also write everything ourselves, if only just to experiment.

Outdoor episodes?

32:26 Kevin asks, any plans to do outdoor episodes again? Absolutely! We've been quite busy with the book, and our setup for recording has become quite big, so it's been easiest to simply use our studio. Going outside takes some more planning. But now that Chris has moved outside Berlin, and he's exploring by running, we soon might find some pretty locations to shoot future episodes.

How are you keeping it fun?

34:07 Norman asks, how do we keep it fun? Well, we don't really know, except we're actually having fun. It certainly helps if you can take the time to do things right. This past year we've been writing App Architecture, and it gave us the opportunity to create a simple app and play around with six different architectures. In doing so, we learned so much from writing the MVC version of the app, for example. MVC doesn't sound very exciting to most people, but if you have the time to do it right, you can have fun with it.

Conferences?

35:12 Will we attend any conferences this year, like UIKonf, maybe to promote the book? We won't be at UIKonf this year, but we'll definitely be at some conferences later this year. Hopefully there'll be a Functional Swift. We're also talking to some others, but nothing is confirmed yet.

Is App Architecture done?

35:54 The next question is about App Architecture; is it in a final version? If not, when do we plan to make a final release? We're really, really close to the release! The project has been in early-access for a few months and we just finished incorporating feedback from the technical review and the copy editing.

Features from other languages?

37:40 Rui asks, what features from other programming languages would we like to see in Swift and why? There are so many! Like in Haskell, the ability to write more precise types would be good. Swift is already really good at this, but there's still room for improvement. Swift could also take some features from Elm, which has really good type-level errors. If you make a type error in Swift, you can get some pretty obscure errors. It would also be cool to have coroutines, as a way to do asynchronous programming. It always feels like Christmas when a new version of Swift comes out and we get to play with new features.

Child view controllers versus subviews?

39:17 What do we think about child view controllers? Would we compose a screen with them, or do we prefer simple subviews? We've definitely used child view controllers, they're great for composition. Writing custom views is also a great way to delegate responsibilities, but child view controllers work better for coordination, or integration with a model.

SSS?

40:23 Allen asks, did we ever use SSS for simple server scripting? We're not sure what this means, so probably not.

Three things for Swift beginners?

40:52 Roland asks, what are three things we wished we knew when we started using Swift? Our first big hurdle was learning how value types like structs and enums work — how Swift handles inout parameters, and how the mutating keyword works. The second big thing is knowing how to work with generics, which can really pay off. And the third thing is working with functions — it would've been really useful to know more early on about how to compose functions and pass them around. Spending some time to learn about functional programming is definitely a good investment.

Do we miss Objective-C?

43:53 Are there situations where we miss, or even prefer Objective-C? In the beginning with Swift 1.0 and 2.0, yes, because there were so many crashes and it was painful to write a full app. By now, we don't miss or prefer Objective-C at all anymore. The only aspect is maybe the build time. Opening up and building an Objective-C project feels super fast right now. But other than that, we believe Swift is better in every way.

Bundling with Point-Free?

45:24 Lars asks, have we considered offering a discounted bundle with Point-Free videos? We haven't, and we don't know if it makes any sense for us as separate companies.

Planning for Swift updates?

45:41 Monica asks, do we plan our own projects around Swift updates? Not really, it's hard to plan for Swift releases, and by now the compiler should be helpful enough to update our code. It'll never be as hard as the update to Swift 3 was.

Core Data or Realm?

46:48 Ina asks, do we prefer Core Data or Realm? We don't have any production experience with Realm. You should try both. Core Data is definitely the bigger beast, with so many features tacked on throughout the years. But we don't really know enough about Realm to make a good comparison.

47:42 That's it for today. We're going to celebrate our first 100 episodes, and we hope to make a 100 more! Let us know if you liked this live Q&A. Maybe we can do it again sometime. Next week, we'll continue with a regular episode.