fix typos

_posts/2023-06-16-my-ios-development_journey.md

@@ -10,14 +10,14 @@ I started becoming interested in iOS development in 2021 as a way to learn a com
 
 <details><summary>NOTE ON SHARING APP</summary>
 <mark>
-It is possible to share Apps with just Swift Playgrounds. It involves getting the other user to download the Swift Playground App, and then sharing each project with iCloud or as a copy. Then, they can build the code locally on their iPad. Xcode works without a developer subscription, but I found it very difficult to share my Apps without physically building the binary on their device. On the other hand, purchasing a developer subscription gives you access to TestFlight (https://developer.apple.com/testflight/ sharing your beta App with 10,000 people (more or less seamlessly after the testers download the TestFlight App themselves). To me, the $100 a year (or whatever it costs now) is worthc it at the point where you *may* want the option of shipping your app to the App Store. If you never plan to ship, then the pain of manually sharing Apps with friends didn't justify the price.
+It is possible to share Apps with just Swift Playgrounds. It involves getting the other user to download the Swift Playground App, and then sharing each project with iCloud or as a copy. Then, they can build the code locally on their iPad. Xcode works without a developer subscription, but I found it very difficult to share my Apps without physically building the binary on their device. On the other hand, purchasing a developer subscription gives you access to TestFlight (https://developer.apple.com/testflight/ sharing your beta App with 10,000 people (more or less seamlessly after the testers download the TestFlight App themselves). To me, the $100 a year (or whatever it costs now) is worth it at the point where you *may* want the option of shipping your app to the App Store. If you never plan to ship, then the pain of manually sharing Apps with friends didn't justify the price.
 </mark>
 </details>
 \\
 After 2+ years of iOS development, I shipped 3 apps to the App Store, each one building on the lessons I learned from the previous. At first, I strictly used SwiftUI which is a beginner friendly, declarative UI language. I gradually gained the confidence to take on UIKit for features not supported by SwiftUI. I used a ton of resources, but [Hacking With Swift](https://www.hackingwithswift.com/) was by far the most reliable source of high quality instruction. Below, I recount the lessons I learned from the experience.
 
 ## [Rail Yard](https://apps.apple.com/us/app/rail-yard/id1664043785)
-I had already started [a project](https://github.com/jakee417/Pico-Train-Switching) that used a Raspberry Pi Pico W to host a web server that allowed him to interact with hobby train switches through the pico's GPIO pins. The problem was that, the web interface was really bad. Rather than be limited to what the pico could serve, I decided to convert the web server to a REST API and create an iOS App that can interact with the service.
+I had already started [a project](https://github.com/jakee417/Pico-Train-Switching) that used a Raspberry Pi Pico W to host a web server for interacting with hobby train switches through the pico's GPIO pins. The problem was that, the web interface was really bad. Rather than be limited to what the pico could serve, I decided to convert the web server to a REST API and create an iOS App that can interact with the service.
 
 Home Screen | Yard Devices | Yard Settings
 - | - | -
@@ -283,7 +283,7 @@ Text-to-Text | Text-to-Image | Image Editing
 
 ### Highlights
 - We used [Firebase](https://firebase.google.com/?gad_source=1&gclid=CjwKCAiA2pyuBhBKEiwApLaIO-ejX3SIKtt0T2jcdFnvnoyMaP93ymfRxGwlfWL2jSovJ3GDdjolQxoC7twQAvD_BwE&gclsrc=aw.ds)
- and as such, took on a dependency to use TypeScript. [@Luke Carani](https://github.com/lwcarani) handled the backend development, doing things like: keeping a history of chat conversations, managing the credit balance for users, making requests to vendor APIs, managing image storage, and more. I would say the experience on Firebase was pretty good, its a low friction platform that allows you to share state pretty easily between a backend database (Firestore db in our case). We also extensively used [Cloud Functions](https://firebase.google.com/docs/functions) for custom logic of how the front end communicates with the backend service. He has a full post on the backend service, [here](https://github.com/lwcarani).
+ and as such, took on a dependency to use TypeScript. [@Luke Carani](https://github.com/lwcarani) handled the backend development, doing things like: keeping a history of chat conversations, managing the credit balance for users, making requests to vendor APIs, managing image storage, and more. I would say the experience on Firebase was pretty good, it's a low friction platform that allows you to share state pretty easily between a backend database (Firestore db in our case). We also extensively used [Cloud Functions](https://firebase.google.com/docs/functions) for custom logic of how the front end communicates with the backend service. He has a full post on the backend service, [here](https://github.com/lwcarani).
 
 - For purchases & payments, we opted for [Revenue Cat](https://www.revenuecat.com/). This dramatically simplifies using the `StoreKit` API, which at the time of authoring was overly complicated to learn. Also, it allows us to specify webhooks which integrates with Firebase pretty nicely. Thus, when a purchase was made, the customer's balance could be increased automatically in Firestore, which then synchronizes with the App.