Migrate iOS Sdk to Swift

[JulianBissekkou]

The iOS sdk is written in objective C, however most (if not all) iOS Apps use Swift and therefore having a Swift library would be nice. It would also reduce the code that we need to write for the sdk itself.
Some APIs would also benefit from new swift features such as swift concurrency with async await. Imaging running a await mapView.flyTo(camera), wouldn't that be nice? 😉

We should be able to call C directly from Swift, right?

However, I am not a Swift or iOS pro so I would love to get your feedback and thoughts about this!

[louwers]

Related: #1248

We should be able to call C directly from Swift

Do you mean Objective-C?

Swift also has some C++ interop, didn't look into it too much yet. https://www.swift.org/documentation/cxx-interop/

[JulianBissekkou]

C should also be possible if I understand this correctly.
https://developer.apple.com/documentation/swift/using-imported-c-functions-in-swift

[louwers]

Yes but we don't have a C API right now.

[JulianBissekkou]

Of course 🤦🏽 sorry I confused this with another project where I was doing similar research.
The link you shared looks promising! :D

[1ec5]

Yes, it should be a lot more feasible to migrate this library to Swift now that it officially supports C++ interop and most phones would benefit from Swift ABI stability. These changes basically obviate the entire MapboxCoreMaps project that Mapbox stood up.

It wouldn’t be necessary to port everything over at once; you could start with new types or extend existing types in Swift. To maintain backwards compatibility, you could add @objc annotations and strive to use only Objective-C-expressible types. However, this gets painful very fast – especially if you need something like a Swift struct. Perhaps the core MGLMapView functionality continues to be available in Objective-C while other functionality supports only Swift. But eventually, you’ll have to decide whether you want to reap the full benefits of Swift by dropping support for application code written in Objective-C. Regardless, you’d still want to avoid exposing any C++ types as part of the public API, to keep downstream applications from having to fiddle with C++ build system complexity.

In mapbox-gl-native-ios, it would’ve been extremely simple to introduce Swift gradually, by just adding a new Swift file to the project in Xcode’s Project navigator and eliminating the package.sh option to build a static framework. However, I’m unsure what else would be involved in making it work with Bazel.