objc.io

00:06 Welcome to episode 100 — yay! We didn't set out to make this many episodes, but here we are, nearly two years after 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 asked why playgrounds always work so well in our videos. Contrary to their suspicions, there's not a lot of video editing involved. It really depends on the version of Xcode, along with 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: 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 asked if 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 the most time is spent on the preparations: working out the code, thinking about how to present a topic, and deciding 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 and more understandable, and mentioning 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 Spee, who writes the transcript for the website. Finally, the transcript is sent to Natalye Childress, who does all our copy editing.

All in all, it takes quite a few steps from the first idea until the episode is online, along 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. His question is about how we would show and hide sections and generate new content based on a user's input. More 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 Now we'll 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 given 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. 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 Our 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 pattern similar to 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 doing the initial view construction and applying updates separately, 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 the same 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. We also can't predict the future, but we know there are some interesting developments with TensorFlow and Swift. Without an obvious reason to switch, it's probably unlikely that Swift will suddenly play a major role in the big ecosystem of AI.

What Are the Best-Kept Secrets of Top App Store Publishers?

16:45 In a second question, Iklil asks what the best-kept secrets of iOS development used by top App Store publishers are. 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 asked if we think about how it would scale in real-world apps when we demonstrate a high-level technique. Also, do we have tips on keeping an entire project clean?

We definitely don't discuss anything in our book if we think it would break as soon as, say, your project exceeds 5,000 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, like The Elm Architecture, enforce a stricter style than others, 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 Florian always looks 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 asked if 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. When that happens it's a good moment to close our laptops and do some hard thinking about what it is we're trying to do.

What Do You Need to Know to Publish an Indie App?

23:56 Prathamesh asked 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 not worry about whether to use a for-loop or a flatMap. If your app becomes larger, or if you get a bigger team, the quality of your code starts to matter more. But as long as it's just you, you should build an app the way it works well for you.

Personally, we're always driven to keep figuring out other, perhaps better solutions to the same problems. 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 asked if we have any third-party frameworks we tend to go to or if 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 asked us, as veterans of iOS development, if 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, in which we discuss each architectural pattern, to accompany the book. 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 asked which is more mature: Vapour, Perfect, or Kitura? We want to give a shout out to Point-Free. They 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 asked if there are any plans to do outdoor episodes again. Absolutely! We've been quite busy with the book, and our setup for recording has become rather large, so it's been easiest to simply use our studio, as going outside takes some more planning. But now that Chris has moved outside Berlin and has been exploring his surroundings when running, we might find some pretty locations to shoot future episodes.

How Are You Keeping It Fun?

34:07 Norman asked how 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 other conferences later this year. Hopefully there'll be a Functional Swift. We're also talking to some other conferences, 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 asked what features from other programming languages we would like to see in Swift and why. There are so many! The ability to write more precise types, like in Haskell, 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 vs. 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 asked if we ever used SSS for simple server scripting. We're not sure what this means, so probably not.

Three Things for Swift Beginners?

40:52 Roland asked about 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 was knowing how to work with generics, which can really pay off. And the third thing was 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 learning 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, we did, 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 asked if we have 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 asked if 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. Either way, it'll never be as hard as the update to Swift 3 was.

Core Data or Realm?

46:48 Ina asked if 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 100 more! Let us know if you liked this live Q&A, and maybe we can do it again sometime. Next week, we'll continue with a regular episode.