test: share sdk wrapper

[armcknight]

Creates a new project delivering a library target that contains SentrySDKWrapper, SentrySDKOverrides, and a couple other basic things that all the sample apps use. This allows us to use one unified SDK configuration among each sample app instead of having duplicated versions that may drift apart. Long term, this is another step towards us being able to generate sample apps from centralized source code using XcodeGen.

Currently targeting iOS swift apps, as the other platforms will requires various changes to source code in the shared files, and this was mainly targeted to change project settings to integrate the shared lib into sample apps, and to have those sample apps use the shared SDK configuration.

More can be moved into here but that is also left as future work, as some things are complicated (for instance, we have some ObjC files in iOS-Swift, and you can't have a lib/fw target with mixed swift/objc code). So, we can move those over one piece at a time in later PRs.

#skip-changelog

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1224.85 ms	1244.98 ms	20.13 ms
Size	22.30 KiB	848.26 KiB	825.96 KiB

[philprime]

Referencing this comment as it seems we will be discussing the same topic in multiple threads starting with this.

Creates a new project delivering a library target that contains SentrySDKWrapper, SentrySDKOverrides, and a couple other basic things that all the sample apps use.

I am actually questioning if all sample apps should use the exact same code in the SentrySDKWrapper and not have SentrySDKOverrides defined as a utility that can be used by all of the sample apps.

Managing all sample apps at once brings in other complexity, because "fixing one breaks the other". I had the same issue working on #5055 trying to replace xcodebuild in the build.yml with sentry-xcodebuild.sh but could not get it to work properly due to the requirement of CODE_SIGNING_ALLOWED=NO for building apps, which is not required to be set for ui tests.

Long term, this is another step towards us being able to generate sample apps from centralized source code using XcodeGen.

I am not sure if this is applicable. When using Xcodegen or similar we don't necessarily need to merge code into shared targets, as we can have shared configuration files that are merged with the sample project config files to directly include source files from different repositories.

More can be moved into here but that is also left as future work, as some things are complicated (for instance, we have some ObjC files in iOS-Swift, and you can't have a lib/fw target with mixed swift/objc code). So, we can move those over one piece at a time in later PRs.

I agree with this, we should start to clean up the project structure and move .h, .m and .swift for the SDK and tests into a separate folder structures, but this might also be a subjective opinion, as e.g. @philipphofmann does not rely on the directory structure but instead uses Xcode file explorer.

[philipphofmann]

I agree with most points of @philprime. I don't mind a bit of duplication in the sample apps. I would like to keep the sample apps simple and stupid. IMO, we already have enough logic in there, and I would rather remove parts of that logic and not spread it across all the sample apps. The duplication isn't a problem for me.

but this might also be a subjective opinion, as e.g. @philipphofmann does not rely on the directory structure but instead uses Xcode file explorer.

I don't mind relying on the directory structure. I only use Xcode file explorer for convenience.

[armcknight]

I would like to keep the sample apps simple and stupid

This is my goal as well.

We release this SDK to work on all these platforms and versions. We can't set up our sample apps "just so" so that it works a certain way on certain setups, everything needs to work everywhere, and we won't find problems if we can only test specific contrived setups per environment.

That's why we need the overrides available to all apps.

We can still let the apps set up default SDK configurations by parameterizing the SDK wrapper. But it makes zero sense to me that you wouldn't want to be able to share this stuff amongst the sample apps. We need to be able to quickly and easily simulate any setup our customers might throw at us; having to commit and PR each one, or throw it away after reproing something, is a big waste.

[armcknight]

We need to stop thinking about these as "separate sample apps" and more like one app that is deployed across a variety of platform versions (so, at most we'd have one sample app for each platform) and with a mix of technologies, like UIKit/SwiftUI/Swift5/6 (yes, real world apps can even mix different versions of swift together in the same app build!)

This is the reality our customers face. We'll never be able to meet them where they're at if we can't even emulate their experience.

They aren't deploying separate feature sets of our SDK per platform to work around our own shortcomings. Or at least, they shouldn't have to. Best way to ensure this is for us to get ahead of the curve.

[philipphofmann]

OK, now I get your point. The goal is to have sample apps with the same functionality on all different platforms, which we can test easily. Did I get this right? If yes, then all good. Let's get there step by step.

[armcknight]

Exactly @philipphofmann! 🎯

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.850%. Comparing base (8a21e27) to head (f1f54b0).

Additional details and impacted files

@@              Coverage Diff              @@
##              main     #5077       +/-   ##
=============================================
+ Coverage   92.694%   92.850%   +0.155%     
=============================================
  Files          676       669        -7     
  Lines        83874     83589      -285     
  Branches     29458     30420      +962     
=============================================
- Hits         77747     77613      -134     
+ Misses        6031      5878      -153     
- Partials        96        98        +2     

see 31 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8a21e27...f1f54b0. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[armcknight]

If we're ok with moving sample projects to XcodeGen as in #5106, then I'll wait to do this work until afterwards, because it will become much simpler. There are conflicts with things like which version of Xcode originally created each project that causes crashes in the build chain in CI:

And generally the diffs will just be much smaller. There won't even be a need for e.g. #5086

[armcknight]

This will significantly change after moving to xcodegen, so will redo in a new PR when the time comes.