Number: 029, Date: 2024-07-22

2024.07.15 ~ 2024.07.21

🌏 Handling JSON


When writing a Codable model for a JSON response from the server, if there is a data type mismatch or a missing key, you can extend KeyedDecodingContainer to replace it with a predefined default value instead of causing the app to crash.

However, in specific requests where you want to distinguish between null and default values, the extension may still replace null with the default value. To solve this, I modified the code by adding a property to the Decoder object, which allows differentiating between cases based on the property value.

While modifying this code, I used the 🔗 Insomnia tool to create a mock API, and it was very convenient—definitely a tool I’ll be using more often.

I’ve also added the relevant code for 🔗 KeyedDecodingContainer+Extension.swift as a gist for future reference.

⚙️ Private CocoaPod Deployment


During the development of a SwiftUI project, I thought it would be convenient to create a reusable Design System, so I created a SwiftUI DesignSystem repository.

Since it’s for personal use, I decided not to release it as an open-source project but rather as a private pod. To achieve this, I modified the podspec and deployed it.

For private pod deployment, two repositories are required: one for the library and one for the spec. The library code resides in the library repository, and the pod is added by accessing the spec repository.

Deploying to a public repository was simpler. You just need to register an account with CocoaPod and publish the podspec.

While the pod was successfully deployed, there were still issues with the bundle not being found for resource files. I’ll need to address these issues while also modifying the project to support SPM alongside CocoaPods.

🙋🏻‍♂️ Other Notes


  1. An issue occurred when multiple tab bar items were touched simultaneously in UITabBarControllerDelegate’s animation method. I realized that multi-touch should be restricted when implementing a tab bar to prevent such issues.
  2. During a WebView code review, I came across 🔗 customAgent and 🔗 applicationNameForUserAgent. I researched the difference between the two and found that customAgent completely overrides the user agent, while applicationNameForUserAgent simply appends to the existing user agent. However, depending on the website, applicationNameForUserAgent may not work correctly, so setting the user agent with customAgent is generally the safer option.