RWDevCon 2017 Inspiration Talk: Silver Bullets and Hype by Roy Marmelstein

Lessons

My learnings here were that RX is really good for simplifying data flows, but if you have a lot of complexity in your app, especially in UI and you expect to onboard a lot of new people, it could become an issue.

The general lesson here is that, even if you’re in a position to do it, you should not force new technologies on your teams, especially not with a broad mission like rewriting the entire app.

Again, most things are not silver bullets, they have limitations; in order to discover the limitations, it’s better to start with smaller tasks.

I think it’s really important to consider the future debt. I have a friend who worked on an app that went all-in on Reactive Cocoa and then changed their minds; it took them the best part of a year to remove Reactive Cocoa. So really try to consider if that’s something you’re willing to do before choosing to adopt a new technology.

Swift

The last thing that I want to talk about, which I guess is controversial for this kind of talk, is Swift itself.

Everyone loves Swift, I love Swift. It was sold to us as Objective-C without the C, which is pretty cool.

These are just a few of the things that I love about Swift; we have protocols and syntax and type safety, value types, it’s functional-ish. It’s a great language, it’s really fun to write, but I don’t think Swift is a silver bullet. I think it depends on your needs and the app that you’re working on.

Even in 2017, I don’t think every app needs to be written in Swift, and Objective-C still has a place.

Story Time: My Swift Experience

I have quite a few Swift frameworks, and I got to work on two apps that use a lot of Swift, both full Swift and transitioning from Objective-C to Swift. I encountered a lot of issues in that process.

The main one was compile times:

This dictionary could take eight hours to compile. Type inference is a big problem in Swift. You won’t really get this in your real app, but the worst it got for us was it took about eight minutes to compile the app. It really kills motivation when every time you run it you have to go and make some coffee. That was a big problem for us.

Another issue is basically having to do this ceremony each year where you have to convert your app every time there’s a new version of Swift. It’s nice that we have a converter, but it’s really not perfect. For me, the big issue is that the unit test broke as well. You can’t just trust that it works.

Talking to other developers, on average it seems to take about two to three weeks to update. If you can’t really afford to do that, maybe that’s something that you should consider.

The last issue is modularity, so if you’re working on an app with a lot of other people, it’s nice to keep things modular and break things into framework. I think there was a workshop about that as well. In Swift, that’s a bit difficult because we don’t have static libraries so everything needs to be dynamically linked.

Apple says we should have a maximum of six, which is not very realistic. What you end up with is quite significant launch times and that could be a problem as well.

Lessons

My experience was that for new projects, especially for open source Swift, it’s amazing. It’s great to learn Swift and it’s really fun.

I think it’s important to learn Swift now because you can influence the development and influence the future of iOS and the server, but consider the constraints of your project.

If you have a project with a lot of legacy code and a lot of contributors and dependencies, I would personally hold back with Swift right now.

The wider learning is to fully consider the constraints of your projects, even if it goes against the common beliefs in the industry right now.

Wrapping Up

The message of this talk is not that you should not try new things, and I think that should be quite explicit. We’re actually very fortunate to work in an industry where we get all these new ideas and we have all these new technologies coming in to solve our problems. We should stay excited and we should try them, but the message is more that:

• We shouldn’t follow trends just because they’re trends.
• We should not approach a new technology as a potential silver bullet.
• We should know that all technologies have limitations.
• We should try to figure out these limitations as quickly as possible and to focus on solving the specific problem in the app.

I know this is quite easy to say but quite hard to do, so I have some suggestions about how to do that.

I think, generally, hackdays and hackathons and side projects are great ways to experiment without the depth of doing it in your main app.

For me, though, the real solution is more of these story times. As a community, we’re very good at sharing excitement about new things and sharing success stories, but we’re not so good about sharing lessons from mistakes and sharing limitations of things. We need to get better at that, because we get excited about the same things and the more we learn from each other, the shorter that time to the plateau of productivity is.

I want to end on a really positive note and keep the excitement going: we should still stay excited about things and stay hungry and stay foolish.

Just try to have a slightly more critical appreciation of things as you’re excited about them. Thank you!