Airbnb's Swift 3 Migration Blog

Using Swift
1

Hi all,

At Airbnb we recently migrated to Swift 3, just in time for Xcode 8.3. We
waited as long as possible because our codebase is massive. We have
hundreds thousands lines of Swift.

In the end we were able to migrate without a code freeze. 3 engineers
worked on it for 3 weeks without disrupting the normal development.

We shared our experience in this blog post:

<https://medium.com/airbnb-engineering/getting-to-swift-3-at-airbnb-79a257d2b656&gt;

Feel free to reach out if you have any questions!

···

--
Chengyin

2

Comments:

Since the Swift ABI changed between versions 2 and 3, even correct Swift 3 code that imports Swift 2 libraries will not compile. This incompatibility made it difficult to parallelize code conversion.

This is probably source-compatibility that you want, not necessarily ABI compatibility. Even if the ABI was stable, you still want to use the decls from the other module, and thus you’d still be in a rough spot. But, with source compatibility in Swift 4, the other modules could remain written in an older syntax/semantics while being compiled with the new compiler (and thus the new ABI). This would mean a gentle module-by-module incremental conversion regardless of the ABI for a Swift 3 to Swift 4 conversion.

Debug Build Time

BTW, are you mixed-source? If so, were you able to try out PCH for bridging headers as identified here: Swift.org - Faster Mix-and-Match Builds with Precompiled Bridging Headers?

However, we did find a function...

If you can produce a test case that repros the blowup, can you put that in a JIRA?

So, to complete the Swift 3 migration we strongly encouraged the entire team (minus the ones doing the migration) to really, truly take a Saturday off work :smile:.

Sounds like some good came of it after all!

“Near misses” on Optional Protocol Method Implementations

These are great JIRA fodder too!

···

On Feb 7, 2017, at 1:35 PM, Chengyin Liu via swift-users <swift-users@swift.org> wrote:

Hi all,

At Airbnb we recently migrated to Swift 3, just in time for Xcode 8.3. We waited as long as possible because our codebase is massive. We have hundreds thousands lines of Swift.

In the end we were able to migrate without a code freeze. 3 engineers worked on it for 3 weeks without disrupting the normal development.

We shared our experience in this blog post: Getting to Swift 3. By Chengyin Liu, Paul Kompfner, and… | by Chengyin Liu | The Airbnb Tech Blog | Medium <Medium;

Feel free to reach out if you have any questions!
--
Chengyin
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

3

Thanks for the feedback!

This is probably source-compatibility that you want, not necessarily ABI

compatibility.

You are right. Thank you for the correction.

BTW, are you mixed-source? If so, were you able to try out PCH for

bridging headers as identified here: Swift.org - Faster Mix-and-Match Builds with Precompiled Bridging Headers?

We are. We are excited with PCH but currently compiler fails with segfault
using Xcode 8.3b2 for us. We are still investigating to provide the best
info there.

If you can produce a test case that repros the blowup, can you put that

in a JIRA?

Filed: http://bugs.swift.org/browse/SR-3892\. Notably this function builds
even slower with 3.1. (2.3: 0.6s → 3.0: 12s → 3.1: 22s)

“Near misses” on Optional Protocol Method Implementations

I don't think those are actual bugs. From a compiler standpoint, the code
is fine. We did hit another issue with protocol near miss that may count as
a compiler issue. I will try to create a reproducible case.

···

On Tue, Feb 7, 2017 at 2:44 PM Michael Ilseman <milseman@apple.com> wrote:

Comments:

> Since the Swift ABI changed between versions 2 and 3, even correct Swift
3 code that imports Swift 2 libraries will not compile. This
incompatibility made it difficult to parallelize code conversion.

This is probably source-compatibility that you want, not necessarily ABI
compatibility. Even if the ABI was stable, you still want to use the decls
from the other module, and thus you’d still be in a rough spot. But, with
source compatibility in Swift 4, the other modules could remain written in
an older syntax/semantics while being compiled with the new compiler (and
thus the new ABI). This would mean a gentle module-by-module incremental
conversion regardless of the ABI for a Swift 3 to Swift 4 conversion.

> Debug Build Time

BTW, are you mixed-source? If so, were you able to try out PCH for
bridging headers as identified here: Swift.org - Faster Mix-and-Match Builds with Precompiled Bridging Headers?

> However, we did find a function...

If you can produce a test case that repros the blowup, can you put that in
a JIRA?

> So, to complete the Swift 3 migration we strongly encouraged the entire
team (minus the ones doing the migration) to really, truly take a Saturday
off work :smile:.

Sounds like some good came of it after all!

> “Near misses” on Optional Protocol Method Implementations

These are great JIRA fodder too!

On Feb 7, 2017, at 1:35 PM, Chengyin Liu via swift-users < > swift-users@swift.org> wrote:

Hi all,

At Airbnb we recently migrated to Swift 3, just in time for Xcode 8.3. We
waited as long as possible because our codebase is massive. We have
hundreds thousands lines of Swift.

In the end we were able to migrate without a code freeze. 3 engineers
worked on it for 3 weeks without disrupting the normal development.

We shared our experience in this blog post:
Getting to Swift 3. By Chengyin Liu, Paul Kompfner, and… | by Chengyin Liu | The Airbnb Tech Blog | Medium
<Medium;

Feel free to reach out if you have any questions!
--
Chengyin

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

--

Chengyin

4

Thanks for the feedback!

> This is probably source-compatibility that you want, not necessarily ABI compatibility.

You are right. Thank you for the correction.

> BTW, are you mixed-source? If so, were you able to try out PCH for bridging headers as identified here: Swift.org - Faster Mix-and-Match Builds with Precompiled Bridging Headers? <Swift.org - Faster Mix-and-Match Builds with Precompiled Bridging Headers;

We are. We are excited with PCH but currently compiler fails with segfault using Xcode 8.3b2 for us. We are still investigating to provide the best info there.

> If you can produce a test case that repros the blowup, can you put that in a JIRA?

Filed: http://bugs.swift.org/browse/SR-3892\. Notably this function builds even slower with 3.1. (2.3: 0.6s → 3.0: 12s → 3.1: 22s)

Thanks. It seems like it’s the closure argument to map specifically that needs an annotation (see comment in SR).

> “Near misses” on Optional Protocol Method Implementations

I don't think those are actual bugs. From a compiler standpoint, the code is fine. We did hit another issue with protocol near miss that may count as a compiler issue. I will try to create a reproducible case.

They’re not bugs, but near-miss detection is a major quality-of-life improvement that the compiler should be better at. It falls under the general category of having better and more helpful diagnostics.

···

On Feb 7, 2017, at 4:58 PM, Chengyin Liu <chengyin.liu@gmail.com> wrote:

On Tue, Feb 7, 2017 at 2:44 PM Michael Ilseman <milseman@apple.com <mailto:milseman@apple.com>> wrote:
Comments:

> Since the Swift ABI changed between versions 2 and 3, even correct Swift 3 code that imports Swift 2 libraries will not compile. This incompatibility made it difficult to parallelize code conversion.

This is probably source-compatibility that you want, not necessarily ABI compatibility. Even if the ABI was stable, you still want to use the decls from the other module, and thus you’d still be in a rough spot. But, with source compatibility in Swift 4, the other modules could remain written in an older syntax/semantics while being compiled with the new compiler (and thus the new ABI). This would mean a gentle module-by-module incremental conversion regardless of the ABI for a Swift 3 to Swift 4 conversion.

> Debug Build Time

BTW, are you mixed-source? If so, were you able to try out PCH for bridging headers as identified here: Swift.org - Faster Mix-and-Match Builds with Precompiled Bridging Headers? <Swift.org - Faster Mix-and-Match Builds with Precompiled Bridging Headers;

> However, we did find a function...

If you can produce a test case that repros the blowup, can you put that in a JIRA?

> So, to complete the Swift 3 migration we strongly encouraged the entire team (minus the ones doing the migration) to really, truly take a Saturday off work :smile:.

Sounds like some good came of it after all!

> “Near misses” on Optional Protocol Method Implementations

These are great JIRA fodder too!

On Feb 7, 2017, at 1:35 PM, Chengyin Liu via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

Hi all,

At Airbnb we recently migrated to Swift 3, just in time for Xcode 8.3. We waited as long as possible because our codebase is massive. We have hundreds thousands lines of Swift.

In the end we were able to migrate without a code freeze. 3 engineers worked on it for 3 weeks without disrupting the normal development.

We shared our experience in this blog post: https://medium.com/airbnb-engineering/getting-to-swift-3-at-airbnb-79a257d2b656#.j800yp6l8 <Medium;

Feel free to reach out if you have any questions!
--
Chengyin

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

--
Chengyin