Aws-sdk-ios: AWSMobileClient 2.12.0 causes hundreds of Swift compiler warnings

[sebsto]

Describe the bug
When compiling AWSMobileClient 2.12.0 with XCode 11 and Swift 5, hundreds of warnings are reported.

Pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)

To Reproduce
In your PodFile, add
pod 'AWSMobileClient', '~> 2.12.0'

Which AWS service(s) are affected?
AWSCore => AWSSignature.h line 18, line 19

Expected behavior
No warning when compiling the SDK

Screenshots
If applicable, add screenshots to help explain your problem.

Environment(please complete the following information):

• SDK Version: 2.12.0
• Dependency Manager: Cocoapods
• Swift Version : 5.x

Device Information (please complete the following information):

• Device: Simulator
• iOS Version: iOS 13
• Specific to simulators: n/a

Additional context
Add any other context about the problem here.

[palpatim]

@sebsto Thanks for reporting this. We need to audit nullability through the entire SDK, but AWSMobileClient is a particularly bad example. :( No ETA on a fix, but we'll chip away at it a little at a time.

[doctorcolinsmith]

In my projects, the file AWSignature.h seems to be a particularly bad offender for nullability warnings. Since it is included in many places through the SDK, the same few warnings get repeated a very large number of times. I suspect that there are only two or three declarations to fix in that file that would remove several dozen warnings for me.

[lukecharman]

Is there a way we can suppress the warnings in the meantime? inhibit_all_warnings in the Podfile doesn't seem to help here since it's in a header file?

[sebsto]

If you are not using AWSAppSync, you can try to silence the warning in AWSSignature.h as proposed by this PR : https://github.com/northwoodspd/aws-sdk-ios/pull/2

[nahung89]

@palpatim is there any update abt this issue? It is super annoying because it flushes away other warnings.

[sarperdag]

Would love to see this get fixed, it's super annoying

[UrK]

Regretfully, this is not only super-annoying but also prevents the upgrade for the project we are working as we have strict "treat warnings as errors" policy. While it is possible to omit warnings in pods, since this sits in the header file, the error does not occur in the pod but in our own project.

[backslash-f]

Regretfully, this is not only super-annoying but also prevents the upgrade for the project we are working as we have strict "treat warnings as errors" policy. While it is possible to omit warnings in pods, since this sits in the header file, the error does not occur in the pod but in our own project.

You could fork the project, made the change and update your Podfile to get the Pod from your fork. That's what we do to get rid of the warnings.

[UrK]

Regretfully, this is not only super-annoying but also prevents the upgrade for the project we are working as we have strict "treat warnings as errors" policy. While it is possible to omit warnings in pods, since this sits in the header file, the error does not occur in the pod but in our own project.

You could fork the project, made the change and update your Podfile to get the Pod from your fork. That's what we do to get rid of the warnings.

For now, downgrade to 2.11 solved it. Hopefully, there are no security bugs.

[sebsto]

@backslash-f can you send a pull request with your changes ? That might help the team to fix this quicker. Thanks

[backslash-f]

@sebsto Well, my "solution" is not very elegant...

In AWSCore/Authentication/AWSSignature.h, add the NS_ASSUME_NONNULL_BEGIN / NS_ASSUME_NONNULL_END flag around its content, as in:

Perhaps you guys would prefer this PR instead?
https://github.com/aws-amplify/aws-sdk-ios/pull/2235

[zackdotcomputer]

Agree with @backslash-f that #2235 looks like a better solution than marking the whole header as ASSUME_NONNULL. Would love to see either solution integrated, though, so that we could use AWS without this pile of warnings...

[idrougge]

Does it really make sense to trust code written by people who don't even notice hundreds of warnings coming from their own code?

To make matters worse, it obscures any warnings from one's own code.

[zackdotcomputer]

Oof so... I hope my comment wasn't responsible for the shift in the tone of the thread here. Sorry if so, @sebsto. Wanted to keep things low-key.

I read through PR #2235 more carefully and it still looks good to me. I added my approval but I obviously don't have actual approval or merge rights. So, I'm hoping we can get a more authoritative read-through from someone on the team soon.

Until we can get that merged, I did some investigation to see if there was a flag or setting that would truly suppress the nullability warnings in my build process. I found that adding the flags -Xcc -Wno-nullability-completeness to the Other Swift Flags setting under the Build Settings of my final target did so. At the very least, I'm hoping this finding will unblock upgrade and build for people who have strict treat-warnings-as-errors enabled. (Edit: Though FWIW this finding is specifically for people like me whose build target is in Swift. The path for disabling nullability-checks in Objective-C is different but also more well-documented.)

Hopeful we can get this moving forward soon.

[royjit]

Apologies for the delay in fixing this. We understand the developer frustration in seeing all these warnings. We wanted to make sure that the changes do not break anything and the signatures have the right Nullability flags. Since this code block is inside the core module of the SDK it can affect any other service that it uses. The PR has been merged now and will be available in the next release. It is marked as a breaking change since using the apis in these classes will have new signatures in Swift code, and may require code changes in your app to consume.

PR #2235

[royjit]

Released this in the new version 2.13.0. Closing this ticket, feel free to open another one if you find any other issue.

[sebsto]

Can not test because AppSync has a dependency on 2.12 and is not updated for 2.13 yet (https://github.com/awslabs/aws-mobile-appsync-sdk-ios/issues/357)

[sebsto]

I confirm the nullability warnings are gone now (tested on a fresh project)
I still have warnings, but for other reasons