Taking too long during archiving with Airship SDK 16.9.2 Cocoapods

[Sivakrishna-Dyaram-Tcs]

❗For how-to inquiries involving Airship functionality or use cases, please contact (support)[https://support.airship.com/].

Preliminary Info

What Airship dependencies are you using?

Airship 16.9.2

What are the versions of any relevant development tools you are using?

Report

Xcode 13.4.1, Swift Language

What unexpected behavior are you seeing?

CI Builds are taking too ling during archiving with 16.9.2. Everything is working fine with the existing version 14.4.0 but when I upgraded to 16.9.2 I am seeing too long.

What is the expected behavior?

CI builds should finish archiving with in the time.

What are the steps to reproduce the unexpected behavior?

Create a Sample App, use Cocopods for integrating Airship, then archive the build.

Do you have logging for the issue?

No Logs

[rlepinski]

Could you provide more info? How long is the build? What modules are you using?

You can switch to xcframeworks instead of pods if it continues to be an issue. We are working towards rewriting more of the SDK in swift which will hopefully speed up the build if we are not mixing as much obj-c with swift.

[Sivakrishna-Dyaram-Tcs]

It is taking more than 2 hours but still building only, Also my project is built with Swift and no objective C.

[rwbutler]

@rlepinski We've been experiencing this issue as well v16.9.4 of the Airship SDK integrated via SPM. When archiving it takes longer to compile the AirshipCore framework than the rest of the app and frameworks combined currently. It currently takes at least 3 mins to compile the AirshipCore framework alone.

[rlepinski]

We believe its due to our SDK being mixed source. We have a lot of swift code that we have to expose to obj-c for our modules that are still in obj-c. We are currently working on getting everything in swift as a first step to see if that reduces our build times. If that still does not move the needle, we will look into other options such as swift only SDK with an obj-c wrapper, so swift users will not be affected by obj-c apps.

I don't think there is much else we can do for now unfortunately. We do have xcframeworks that you could use instead of pods. They are precompiled so it should reduce the build times.

[toddthomas]

@rlepinski We've been experiencing this issue as well v16.9.4 of the Airship SDK integrated via SPM. When archiving it takes longer to compile the AirshipCore framework than the rest of the app and frameworks

Seeing this with 16.10.0 via Swift Package Manager as well. Xcode 14's new build timeline makes this clear:

[toddthomas]

We have another project using 16.5.1, which archives in less than 30 seconds.

Probably a lot of change between 16.5.1 and 16.9.4, but that's a start on the binary search.

[rlepinski]

Thanks! Ill take a look

[rlepinski]

I was able to narrow it down to this commit - https://github.com/urbanairship/ios-library/commit/16634407b62406a007936531be569b2dfa9f8e17

Still looking for a fix

[rlepinski]

I have the build times back down to ~30 seconds for the swift phase. I just need to get the changes validated by QA. I hope to have a release on Thursday.

[toddthomas]

That's great news @rlepinski! Thank you so much for looking into this! I was considering converting our projects to use the xcframeworks, but you've saved me some work. I appreciate it.

[rwbutler]

Thanks @rlepinski - appreciate it as well 🙏

[rlepinski]

QA is looking good, I should have the release started soon.

If you are curious what happened: I made a change to add new view modifiers to our scene & survey features. These view modifiers interact with an environment object that may or may not be there, so I had to break them out into separate modifiers since if you try to access an environment object that is not there swiftui will crash. I was chaining the view modifiers with an applyIf(_:transform) block since they are optional, and it was not obvious how to concat an unknown array of modifiers together. This worked fine and even with the compiler warnings enabled nothing seemed out of place. This long chain of optional view modifiers (5ish in a row) was the cause. I switched to a resultbuilder that concats the view modifiers and applies it once to the view and that brought the build times back down. I also added some type hints to some of the longer methods (had a few over 150ms), but that had almost no effect on total build time.

Our CI took much longer with that change, but I assumed that was from the bump of macOS version from 11 to 12 in our github actions.

~30 still seems too long to me but it's at least reasonable. I believe we can further reduce build times soon once we get everything into swift and better limit what we expose to obj-c.

[toddthomas]

Thanks again @rlepinski. ~30s is fine for my team's projects because are other dependencies building in parallel at that stage that take at least that long, so Airship wouldn't be the long pole anymore.

[rlepinski]

Partially out, hitting this issue while deploying - https://github.com/CocoaPods/CocoaPods/issues/11621

[rlepinski]

Looks like they published even though the command failed. Closing as fixed in 16.10.1

[toddthomas]

I updated to 16.10.1 and can confirm the fix. Thank you very much.