Not doubt that the trend is coding Swift. In my corporation, some colleagues said they’ve phone screened several decent candidates who indicated they weren’t particularly interested in starting a new job that was ObjC.
In our corporation, we give green lights on coding Swift for apps without restrictions. However, Swift for SDKs is not a good idea by default now, as long as Swift 5.x isn’t available and ABI stability isn’t available.
Our reasons are
- Currently the SDK written by Swift 4 can’t be distributed as binary SDK due to lack of “ABI Stability”. Moreover, this mean these SDKs of Swift shouldn’t be distributed to 3rd party that we don’t trust with source code.
- For those SDK owners, they have to maintain multi versions of their SDKs for each clients, even internal ones, in order to deal with varying versions of Xcode, of Swift, and of other parameters. It’s actually harder if the apps that integrate the SDK also use Swift.
For us, using Swift for SDKs requires to have a strong reason, and to be willing to deal with some constraints.
Maybe we write SDKs in swift today, make them work in our all apps right now. But it also means we’d expose ourselves to a risk in June, where some app teams want to use iOS 13 features, where those features require Xcode 11, where Xcode 11 doesn’t compile existing swift code, and the SDKs written in swift don’t have resources to update to Xcode 11. Without ABI compatibility, we’re out of luck.
Apple has announced that Swift 5.0 will have “ABI Stability”, coming in “early 2019”, but Apple has also failed to deliver on ABI Stability after making promises before. With swift 5.x coming up, we expect that we’ll be able to use swift in SDKs.
