CB-10071: (ios) Proposal swift support

[knight9999]

The purpose of this proposal is to support iOS plugin written by Swift.
I propose introducing two functions.

• The first function will edit the Bridging-Header.h according to the settings defined in plugin.xml.

• The second is setting the application’s Swift version according to the settings defined in config.xml.

Note that we can specify the Swift version for the application. Plugins with different Swift version can not be imported simultaneously. This is contrary with CocoaPod libraries in which Swift version can be specified for each.

[dpogue]

This seems good, and should remove the need for people to fiddle with hook scripts or extra plugins just to get Swift working.

Regarding plugins written in Swift, how do you envision they would specify the compatible Swift version? I guess they could inject it into the platform's config.xml and let the app's config.xml override it?

Plugin specifies Swift 4.0 in its plugin.xml:

<!-- plugin.xml -->
<plugin ...>
  <platform name="ios">
    <config-file parent="/*" target="config.xml">
      <preference name="SwiftVersion" value="4.0" />
    </config-file>
  </platform>
</plugin>

Application config.xml specifies Swift 4.1:

<!-- config.xml -->
<widget ...>
  <platform name="ios">
    <preference name="SwiftVersion" value="4.1." />
  </platform>
</widget>

Result: Swift 4.1

[knight9999]

Thanks @dpogue

I did not assume that the plugin specifies its own swift version.
I thought that the developer should specify the swift version by his application config.xml,
like a NSCameraUsageDescription in cordova-camera-plugin where the developer
should specify the 'NSCameraUsageDescription' in his application config.xml.

However, as you said that, the application config.xml can override plugin's preferences.

It is a good rule that the plugin has its own default swift version and the developer
overrides it by using application config.xml if necessary.

Anyway choosing swift version is totally developer's responsibility.
There is no guarantee that will work for different swift version.

[shazron]

Sounds good. Are you planning to do this for cordova-ios@5, the next major version?

[dpogue]

I think we should try to get this in for cordova-ios@5

[knight9999]

Thanks @shazron @dpogue ..
I think so.

[knight9999]

I have found one difficulty.

Assuming that there are two plugins, pluginA and pluginB.

• pluginA is written in pure Obj-C plugin with the header file pluginA.h.

pluginB is written in pure Swift but depends on pluginA.

pluginB's methods need to call onto pluginA's methods.

In this use case, our specification is not enough.

To solve this issue, pluginB would be required to have an additional obj-c header file

pluginB.h

#import 'pluginA.h'

and in pluginB's plugin.xml file, specify this file as BridgingHeader.

<header-file src="src/ios/pluginB.h" type="BridgingHeader" />

[dpogue]

That still seems acceptable. It makes sense that pluginB would be required to define its dependency on pluginA, even if the process for doing that involves an extra header file.

[knight9999]

I have just sent two PRs.

PR for cordova-ios
apache/cordova-ios#395
This cordova-ios PR will require the following cordova-common PR to be merged first.

PR for cordova-common
apache/cordova-common#42

[knight9999]

I have just sent a PR for cordova-doc.

apache/cordova-docs#880