Apply suggestions from code review

Co-authored-by: Philipp Hofmann <philipp.hofmann@sentry.io>
getsentry · Oct 25, 2022 · 097f3d1 · 097f3d1
1 parent 7d5e7d1
commit 097f3d1
Show file tree

Hide file tree

Showing 2 changed files with 7 additions and 7 deletions.
diff --git a/Sources/Sentry/include/SentrySwift.h b/Sources/Sentry/include/SentrySwift.h
@@ -2,15 +2,15 @@
 #define SentrySwift_h
 
 /*
- * This is a header to expose Swift code to Objective-c
+ * This is a header to expose Swift code to Objective-C.
  *
  * Because we use three different package managers
- * we need to target the swift module in different ways.
+ * we need to target the Swift module in different ways.
  *
- * If the project is being used through SPM, Swift and Objective-c are compiled into separated
+ * If the project is being used through SPM, Swift and Objective-C are compiled into separated
  * targets, then we use "@import SentrySwift".
  *
- * Cocoapods combines everything into one target, if the user enable USE_FRAMEWORKS,
+ * CocoaPods combines everything into one target, if the user enables USE_FRAMEWORKS,
  * Swift will be available through "#import <Sentry/Sentry-Swift.h>" otherwise "#import
  * "Sentry-Swift.h"".
  */

diff --git a/develop-docs/README.md b/develop-docs/README.md
@@ -134,8 +134,8 @@ Related to [GH-2218](https://github.com/getsentry/sentry-cocoa/issues/2218)
 Date: October 1st 2022
 Contributors: @brustolin
 
-A Sentry SDK started to be [written in Swift once,](https://github.com/getsentry/raven-swift) but due to ABI not being stable at that time, it got dropped. Since then Swift 5.1 landed and we got ABI stability. We’ve considered adding Swift to our sentry.cocoa SDK since then, but because of some of the trade offs, we’ve postponed that decision.
+A Sentry SDK started to be [written in Swift once,](https://github.com/getsentry/raven-swift) but due to ABI not being stable at that time, it got dropped. Since then Swift 5.0 landed and we got ABI stability. We’ve considered adding Swift to our sentry.cocoa SDK since then, but because of some of the trade offs, we’ve postponed that decision.
 This changed with our goal to better support SwiftUI. It’s growing in popularity and we need to write code in Swift in order to support it.
-SwiftUI support will be available through an adicional library, but in order to support it we need to be able to demangle Swift class names in Sentry SDK, which can be done by using Swift API.
-Since we support SPM, and SPM don't support multi language projects, we need to create two different targets, one with Swift and another with Objective-c code, because of that our Swift code in SPM resides in a different module, which requires a different import in projects, and for now, this is the reason we should avoid writing public API in Swift. But, everything written in Swift will be public if users import Sentry via CocoaPods or Carthage.
+SwiftUI support will be available through an additional library, but to support it, we need to be able to demangle Swift class names in Sentry SDK, which can be done by using Swift API.
+Since we support SPM, and SPM doesn't support multi-language projects, we need to create two different targets, one with Swift and another with Objective-C code. Because of that, our Swift code in SPM resides in a different module, which requires a different import in projects, and for now, this is the reason we should avoid writing public API in Swift. But everything written in Swift will be public if users import Sentry via CocoaPods or Carthage.