fix: lower iOS deployment target to match the one of the iOS app
What's new in this PR
wireapp/wire-ios uses iOS 16.4 as minimum deployment target. Since wireapp/core-crypto specifies 16.6 a warning is displayed when integrating the framework.
This PR lowers the deployment target so that it matches the one from the iOS app.
PR Submission Checklist for internal contributors
- The PR Title
- [ ] conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
- [ ] contains a reference JIRA issue number like
SQPIT-764 - [ ] answers the question: If merged, this PR will: ... ³
- https://sparkbox.com/foundry/semantic_commit_messages
- https://github.com/wireapp/.github#usage
- E.g.
feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.
Bencher Report
| Branch | fix/ios-deployment-target |
| Testbed | ubuntu-latest |
⚠️ WARNING: No Threshold found!
Without a Threshold, no Alerts will ever be generated.
Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the--ci-only-thresholdsflag.
Click to view all benchmark results
Thanks @caldrian the CI error doesn't seem related to your change. We'll look into it.
I think this is not complete. We have
Makefile:207: IPHONEOS_DEPLOYMENT_TARGET=16.0 \
interop/src/clients/InteropClient/InteropClient.xcodeproj/project.pbxproj:245: IPHONEOS_DEPLOYMENT_TARGET = 18.0;
interop/src/clients/InteropClient/InteropClient.xcodeproj/project.pbxproj:302: IPHONEOS_DEPLOYMENT_TARGET = 18.0;
crypto-ffi/bindings/swift/WireCoreCryptoUniffi/WireCoreCryptoUniffi.xcodeproj/project.pbxproj:282: IPHONEOS_DEPLOYMENT_TARGET = 16.6;
crypto-ffi/bindings/swift/WireCoreCryptoUniffi/WireCoreCryptoUniffi.xcodeproj/project.pbxproj:324: IPHONEOS_DEPLOYMENT_TARGET = 16.6;
crypto-ffi/bindings/swift/WireCoreCrypto/WireCoreCrypto.xcodeproj/project.pbxproj:467: IPHONEOS_DEPLOYMENT_TARGET = 16.6;
crypto-ffi/bindings/swift/WireCoreCrypto/WireCoreCrypto.xcodeproj/project.pbxproj:527: IPHONEOS_DEPLOYMENT_TARGET = 16.6;
Note in particular the Makefile one. We should be consistent and use the same deployment target everywhere.
I think this is not complete. We have
Makefile:207: IPHONEOS_DEPLOYMENT_TARGET=16.0 \ interop/src/clients/InteropClient/InteropClient.xcodeproj/project.pbxproj:245: IPHONEOS_DEPLOYMENT_TARGET = 18.0; interop/src/clients/InteropClient/InteropClient.xcodeproj/project.pbxproj:302: IPHONEOS_DEPLOYMENT_TARGET = 18.0; crypto-ffi/bindings/swift/WireCoreCryptoUniffi/WireCoreCryptoUniffi.xcodeproj/project.pbxproj:282: IPHONEOS_DEPLOYMENT_TARGET = 16.6; crypto-ffi/bindings/swift/WireCoreCryptoUniffi/WireCoreCryptoUniffi.xcodeproj/project.pbxproj:324: IPHONEOS_DEPLOYMENT_TARGET = 16.6; crypto-ffi/bindings/swift/WireCoreCrypto/WireCoreCrypto.xcodeproj/project.pbxproj:467: IPHONEOS_DEPLOYMENT_TARGET = 16.6; crypto-ffi/bindings/swift/WireCoreCrypto/WireCoreCrypto.xcodeproj/project.pbxproj:527: IPHONEOS_DEPLOYMENT_TARGET = 16.6;Note in particular the
Makefileone. We should be consistent and use the same deployment target everywhere.
That's only the interop client which we don't ship. All other places have been changed to 16.4.
I'd say this OK. It'll be nicer when we switch to xcodegen.
I think this is not complete. We have
Makefile:207: IPHONEOS_DEPLOYMENT_TARGET=16.0 \ interop/src/clients/InteropClient/InteropClient.xcodeproj/project.pbxproj:245: IPHONEOS_DEPLOYMENT_TARGET = 18.0; interop/src/clients/InteropClient/InteropClient.xcodeproj/project.pbxproj:302: IPHONEOS_DEPLOYMENT_TARGET = 18.0; crypto-ffi/bindings/swift/WireCoreCryptoUniffi/WireCoreCryptoUniffi.xcodeproj/project.pbxproj:282: IPHONEOS_DEPLOYMENT_TARGET = 16.6; crypto-ffi/bindings/swift/WireCoreCryptoUniffi/WireCoreCryptoUniffi.xcodeproj/project.pbxproj:324: IPHONEOS_DEPLOYMENT_TARGET = 16.6; crypto-ffi/bindings/swift/WireCoreCrypto/WireCoreCrypto.xcodeproj/project.pbxproj:467: IPHONEOS_DEPLOYMENT_TARGET = 16.6; crypto-ffi/bindings/swift/WireCoreCrypto/WireCoreCrypto.xcodeproj/project.pbxproj:527: IPHONEOS_DEPLOYMENT_TARGET = 16.6;Note in particular the
Makefileone. We should be consistent and use the same deployment target everywhere.That's only the interop client which we don't ship. All other places have been changed to 16.4.
I'd say this OK. It'll be nicer when we switch to xcodegen.
Ah missed the part where the Makefile was using 16.0, yes we should also align that.
That's only the interop client which we don't ship.
We don't ship interop, true, but we use it for testing and I think it makes sense to test with the same configuration used by the artifacts we're shipping. Otherwise we increase the risk that the interop tests pass, while the shipped artifacts are somehow broken.
@typfel @istankovic Thank you, I adjusted the deployment version on the other places, see https://github.com/wireapp/core-crypto/pull/1619/commits/d0604d8d94f0eca6c7e0f18ce69f3c16f765371a
I noticed that the Makefile has set 14 as minimum target for simulators. Not sure if that should be adjusted as well: https://github.com/wireapp/core-crypto/blob/main/Makefile#L222-L223
For us the only important thing is that your minimum deployment target is not hight than ours, which was the case until now (us 16.4, you: 16.6)
@caldrian why do we have merge commit f4120281ea19783cf031255d2be75675e3a10ba2?
Please note that we don't use merges in general, and especially not from main into any of the PR branches.
If a PR branch is not up-to-date with main, we simply rebase it on top of main.
@caldrian why do we have merge commit f412028?
Please note that we don't use merges in general, and especially not from
maininto any of the PR branches. If a PR branch is not up-to-date withmain, we simply rebase it on top ofmain.
@istankovic doesn't GitHub do this automatically?
@caldrian why do we have merge commit f412028? Please note that we don't use merges in general, and especially not from
maininto any of the PR branches. If a PR branch is not up-to-date withmain, we simply rebase it on top ofmain.@istankovic doesn't GitHub do this automatically?
If you mean the rebase button in github, yes, but we're not using it as it completely breaks commit signatures. See https://github.com/orgs/community/discussions/4618.