Update docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx

Co-authored-by: Karl Heinz Struggl <[email protected]>

Author: supervacuus

docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx

@@ -45,7 +45,7 @@ Both backends are comparable in how they differ from `crashpad`. However, there
 * `inproc`, on the other hand, uses signal handling on Linux and macOS (meaning you only get a `POSIX` compatibility layer over mach exception ports) and `UnhandledExceptionFilter` on Windows (solely errors registered by SEH)
 * as a result of choosing signal handling on macOS, `inproc` is currently broken on macOS since Apple eliminated unwinding from signal handlers
 * `inproc` is exceptionally lightweight and written entirely in C, meaning it does not rely on a weighty C++ runtime library, which is also more often affected by ABI incompatibilities
-* `breakpad` generates minidumps (like `crashpad` does), whereas `inproc` follows the sentry event structure and primarily defers to the OS-provided unwinder and symbolication capabilities. Sentry can potentially extract more information from the provided minidump than simply a stack trace and registers. However, it also means that the crash context inside the minidump will be opaque until processed in the backend, whereas a local `relay`  instance could process an entire `inproc`-event if required.
+* `breakpad` generates minidumps (like `crashpad` does), whereas `inproc` follows the Sentry event structure and primarily defers to the OS-provided unwinder and symbolication capabilities. Sentry can potentially extract more information from the provided minidump than simply a stack trace and registers. However, it also means that the crash context inside the minidump will be opaque until processed in the backend, whereas a local `relay`  instance could process an entire `inproc`-event if required.
 
 ### So when do I choose `inproc`?