Number: 002, Date: 2025-01-14

2025.01.06 ~ 2025.01.13

🌈 SwiftUI Login Refactoring

To transition an existing UIKit project to SwiftUI, I attempted to implement the login step first.

As of 2025, there are roughly ten advantages that SwiftUI has over UIKit:

  1. Declarative Syntax: SwiftUI uses declarative syntax to define UIs, making the code easier to read and maintain.
  2. Preview Functionality: SwiftUI allows you to preview changes without running the app. Although UIKit also supports previews, they feel slower to apply compared to SwiftUI.
  3. Cross-Platform Support: SwiftUI enables the development of apps for iOS, macOS, watchOS, and tvOS, whereas UIKit is primarily designed for iOS.
  4. State Management: SwiftUI offers state management tools such as @State, @Binding, and @Environment, which simplify data flow. In contrast, UIKit requires more boilerplate code and manual intervention through mechanisms like NSNotificationCenter, delegates, and KVO.
  5. Animation and Transitions: SwiftUI provides a more intuitive API for animations and transitions, simplifying implementation compared to UIKit.
  6. Code Conciseness: SwiftUI eliminates much of the boilerplate code present in UIKit, resulting in more concise code.
  7. Automatic Dark Mode Support: SwiftUI includes automatic support for dark mode.
  8. Integration with Modern Swift Features: UIKit, originally designed for Objective-C, doesn’t integrate as seamlessly with modern Swift as SwiftUI does.
  9. Accessibility: SwiftUI automatically includes many accessibility features.
  10. Learning Curve: With its declarative syntax, SwiftUI has a gentler learning curve compared to UIKit.

On the other hand, there are three scenarios where UIKit is still necessary:

  1. Resource Availability: UIKit has been around longer, offering a wealth of community resources and documentation.
  2. Backward Compatibility: SwiftUI requires iOS 13 or later, making UIKit essential for supporting older versions.
  3. Complex Requirements: UIKit provides finer control for complex requirements.

⇒ Implementing the login step helped me experience the advantages of SwiftUI firsthand, improving development productivity. However, I noticed limitations in precise controls, such as those related to lineBreakMode and lineBreakStrategy for Korean wording in UIKit.

⚡️ Flutter

I completed about one-third of the course Intro to Flutter 3.0 App Development. Inspired by this, I began developing a pilot Flutter app using Cursor.AI, based on the login step project implemented in SwiftUI.

Both SwiftUI and Flutter use declarative syntax, which allowed Cursor.AI to perform better with SwiftUI than UIKit. Although some aspects, such as Flutter build settings, asset management, and detailed UI tweaks, needed manual adjustment, it took less than a day to transition the project from SwiftUI to Flutter.

🔔 Development Team Seminar Presentation - Understanding iOS Notifications

To facilitate knowledge sharing within the development team, I conducted a seminar presentation during my turn. The topic, “Understanding iOS Notifications,” was chosen to highlight the differences between iOS and Android notifications, particularly the use of APNs and the need for payload formatting on the server side.

The presentation covered:

I also demonstrated these concepts through a sample app. This experience is expected to enhance collaboration during notification-related development.

🙋🏻‍♂️ Other Notes

  1. I stumbled upon an article on Medium explaining a roadmap for iOS developers interested in AI development. Even without fully transitioning to AI development, gradually incorporating CoreML into side projects seems like a good approach.
  2. Performance evaluation season.