search

heremaps / here-ios-sdk-examples

Objective-C and Swift projects using the HERE SDK for iOS.
MIT License
60 stars 56 forks source link

XCFramework and Swift Package distribution using binary target #179

Open fahlout opened 4 years ago

fahlout commented 4 years ago

Hi,

I'm using the premium iOS SDK and would like to use it as a Swift package instead of CocoaPods. This is only possible using a binary target within a swift package that was just announced at WWDC. Is there a plan to distribute the NMAKit binary through a swift package this fall? It would make things a lot easier and using an XCFramework it would be able to support simulator and device without having to strip anything from the framework.

Is there already an XCFramework I can download or only the framework file in the developer portal? It really is less than ideal as I cannot build my own swift packages currently that rely on HERE Maps. I see references to "heresdk.xcframework" in some of the docs but it only says that you can download it on developer.here.com, which is not very helpful. I really wish the documentation was more clear.

References: https://developer.apple.com/documentation/swift_packages/distributing_binary_frameworks_as_swift_packages https://developer.apple.com/videos/play/wwdc2020/10147

dashchak commented 4 years ago

Hi, thanks for pointing this out. Currently, HERE SDK 3.x does not support Swift packages. We will investigate it.

fahlout commented 4 years ago

That only answers half of my issues. How come every SDK version except for the Premium one is distributed as a xcframework? Why is the premium one not distributed as a xcframework. Instead it is a fat framework that requires stripping the simulator architecture before pushing an app to the App Store. This creates unnecessary work for us using the HERE SDK.

dashchak commented 4 years ago

Since none of our customers/users have requested .xcframework distribution and no one has complained about current NMAKit.framework way, we still do not support it. Note, our team is responsible only for HERE SDK 3.x versions.

Swift packaging was not applicable to HERE SDK 3.x, as we can not reveal our source code. We will investigate Xcode 12 close-source Swift packaging. In order to strip Simulator arches, you can use _stripsim.sh which is distributed with framework. Simply run: $sh strip_sim.sh

fahlout commented 4 years ago

Why does someone have to complain first for HERE to use the latest technologies? Fat frameworks were never officially supported by Apple and since XCFrameworks were introduced last year the only logical thing to do would be to use this technology.

It seems like the other teams that are responsible for the Lite and Navigation SDKs have a better grasp on this as they do distribute via xcframework. It shouldn't be an issue for HERE to generate an xcframework for the current SDK version and to make it available to developers. There's no need to wait around.

Since closed source distribution will be available going forward please do consider offering this to your customers as SPM is the way to go with projects going forward. Only supporting CocoaPods is less than ideal.

dashchak commented 4 years ago

Why does someone have to complain first for HERE to use the latest technologies?

Found issues and feature requests are high priority for us. I do not see much benefit of changing distribution format since we don't distribute packages for tvOS, macOS, or watchOS. Fat frameworks are still not deprecated.

Fat frameworks were never officially supported by Apple

Indeed, but it was the only way of distributing one package for all architectures until Xcode 11 xcframework appearance. All of our customers adopted it.

It seems like the other teams that are responsible for the Lite and Navigation SDKs have a better grasp on this as they do distribute via xcframework.

Those SDKs are new ones and do not have any historical reasons to keep .framework format. Making even a small change in our distribution package will require hundreds of our customers to make it too.

It shouldn't be an issue for HERE to generate an xcframework for the current SDK version and to make it available to developers.

True, it is not an issue. But it still requires many internal changes. i.e. CI build jobs, test service providers, security analysing changes, etc. The same should be done on customers side.

Since closed source distribution will be available going forward please do consider offering this to your customers as SPM is the way to go with projects going forward

Again, we will definitely consider it as starting from Xcode 12 xcframeworks can be wrapped in Swift packages. Thanks for sharing it.

Next release is planned on the mid of October when Xcode 12 and iOS 14 are expected to be available in public release.

fahlout commented 4 years ago

Found issues and feature requests are high priority for us. I do not see much benefit of changing distribution format since we don't distribute packages for tvOS, macOS, or watchOS. Fat frameworks are still not deprecated.

The benefit is not having to strip the simulator architecture, which in my mind makes it worth it just for that. The other big benefit is being able to distribute using SPM as that is certainly the future for package management on iOS. It's also a shame that macOS is not supported at this time as more and more iOS apps make their way to the Mac.

Looking forward to the next release in October. Hoping to be able to integrate HERE using SPM then. Thanks.