안녕하세요, 루피입니다. 오늘은 캡스톤 작품인, 효도르 프로젝트를 진행하면서, 직접 구현했던 ImageCache를 KingFisher로 변경한 내용에 대해 글을 적어보려합니다. 바로 시작합니다.1. 왜 ImageCahe가 필요했는가?현재 Hyodor 앱은 가족 공유 앨범이라는 기능이 있습니다. 서버에서 이미지 URL 목록을 받아와 화면에 효율적으로 뿌려줘야 했기 때문에 캐시 구현이 필수로 요구 되었습니다. 캐시가 필요했던 가장 큰 이유는 한번 받아온 이미지 URL을 사용할때, 반복해서 서버에 API 호출하는 것이 아닌 메모리에 캐싱해 빠르게 접근해서 사용하기 위해서였습니다.2. 왜 직접 구현을 먼저 했는가?이거는 제가 생각하는 고집이자 공부의 방향성이긴 한데요. 저는 학습을 하는 과정에서는 제가 생각하는..

안녕하세요, 루피입니다!! 오늘은 제가 SwiftUI로 개발한 Hyodor 앱에서 공유 앨범의 이미지 로딩 성능을 개선하기 위해 이미지 캐싱을 활용한 경험을 공유하려 합니다. 특히, 반복적인 API 호출로 인한 로딩 지연 문제를 해결하기 위해 ImageCache를 구현하고 트러블슈팅한 과정을 중심으로 포스팅해 보겠습니다.문제 상황: 반복적인 API 호출과 로딩 지연Hyodor 앱의 핵심 기능 중 하나는 공유 앨범입니다. 사용자가 공유 앨범 뷰에서 사진을 볼 때, 각 사진의 이미지를 서버에서 가져오기 위해 API를 호출합니다. 하지만 동일한 이미지에 대해 매번 네트워크 요청을 보내다 보니 다음과 같은 문제가 발생했습니다:로딩 시간 증가: 네트워크 요청과 데이터 다운로드로 인해 이미지 표시가 느려짐.데이터..

안녕하세요, 루피입니다!! 오늘은 제가 SwiftUI로 개발한 Hyodor 앱에서 공유 앨범 데이터 로딩 문제를 해결한 경험을 공유하려 합니다. 특히, 앱 실행 시 서버에서 데이터를 가져오는 동안 UX를 개선하기 위해 Splash View 를 활용한 과정에 대해 포스팅해보려합니다.문제 상황: 데이터 로딩과 UX의 충돌Hyodor 앱의 핵심 기능 중 하나는 공유 앨범입니다. 사용자가 HomeView에서 공유 앨범 뷰로 진입하면 서버에서 공유된 사진 데이터를 가져오는 API를 호출합니다. 이 과정은 필수적이지만, 네트워크 요청과 데이터 파싱에 시간이 걸리면서 사용자에게 대기 시간이라는 불편함을 줄 것이라는 생각을 했습니다.이미 로드한 사진은 ImageCache을 통해 빠르게 표시했지만, 앱을 처음 실행할 때..

안녕하세요, iOS 개발하는 루피입니다.오늘은 SwiftUI의 근간을 이루는 핵심 개념인 뷰와 모디파이어에 대해 깊이 있게 알아보려고 합니다.바로 시작합니다.1. SwiftUI가 View에 Struct를 사용하는 이유UIKit이나 AppKit을 사용해 보셨다면, 두 프레임워크에서는 뷰를 클래스로 구현한다는 것을 알고 계실 겁니다. 그러나 SwiftUI는 다른 접근 방식을 취합니다. SwiftUI에서는 뷰를 구조체로 구현하며, 여기에는 몇 가지 중요한 이유가 있습니다.1) 성능적 이점구조체는 클래스보다 단순하고 빠릅니다.UIKit에서는 모든 뷰가 UIView라는 클래스에서 파생되며, 이 클래스는 배경색, 위치 제약조건, 렌더링 레이어 등 수많은 속성과 메서드를 포함하고 있습니다. 상속의 특성상 UIView..

안녕하세요, iOS 개발하는 루피입니다. 오늘은 최근 SwiftUI를 기반으로 컴퓨터종합설계 프로젝트를 진행 중인데, 느린 사진 업로드 문제를 해결했던 트러블 슈팅 경험을 정리해보려 합니다. 바로 시작합니다.1. 문제 발생 배경최근 SwiftUI 기반 사진 공유 앱의 사진 업로드 기능에 성능 문제가 발생했습니다. 사용자가 사진첩에서 사진을 선택해 S3 버킷에 업로드하는 기능이었는데, 10장의 사진을 업로드하는 데 12초 이상 걸렸습니다. 이렇게 될 경우 사용성이 많이 떨어질 것으로 판단하여, 기능 개선을 위해 노력했습니다. 느린 업로드 문제를 진단하고, 최적화 과정을 통해 업로드 시간을 단축한 트러블슈팅 과정을 공유합니다.2. 문제 상황 : 느린 사진 업로드앱의 PhotoListViewModel은 사용..

안녕하세요, iOS 개발하는 루피입니다! 오늘은 공식문서를 바탕으로 StateObject에 대해 정리해 보는 시간을 가져보려 합니다. 바로 시작합니다.StateObject란?StateObject는 SwiftUI에서 참조 타입 객체를 관리하기 위한 프로퍼티 래퍼로, iOS 14부터 도입되었습니다.(iOS 17 이후부터는 참조 타입도 @Observable 매크로와 함께 @State로 관리하는 것을 Apple이 권장하고 있습니다.) ObservableObject 프로토콜을 준수하는 참조 타입 객체의 생명주기를 관리하고, 뷰가 업데이트될 때도 객체의 상태를 안정적으로 유지하는 역할을 합니다.@MainActor @frozen @propertyWrapper @preconcurrencystruct StateObjec..

안녕하세요, iOS 개발하는 루피입니다. 오늘은 공식문서를 바탕으로 Bindable에 대해 정리해보는 시간을 갖겠습니다. 바로 시작합니다.Bindable이란?@Bindable은 Observable 객체의 변경 가능한 속성들에 바인딩을 생성할 수 있게 해주는 프로퍼티 래퍼입니다.이 프로퍼티 래퍼를 사용하면 Observable 프로토콜을 준수하는 데이터 모델 객체의 변경 가능한 속성에 바인딩을 만들 수 있습니다. 예를 들어, 아래 코드에서는 @Bindable로 book 입력을 감싸고 있습니다. 그런 다음 TextField를 사용해 책의 title 속성을 변경하고, Toggle을 사용해 isAvailable 속성을 변경합니다. 이때 $ 문법을 사용하여 각 속성에 대한 바인딩을 컨트롤에 전달합니다.@Observ..

안녕하세요, iOS 개발하는 루피입니다!이전 글에서 SwiftUI의 상태 관리 기본 개념과 특징에 대해 알아보았습니다. 이번 글에서는 상태를 하위 뷰와 공유하는 방법, Observable 객체와의 활용, 그리고 성능 최적화와 일반적인 실수에 대해 알아보겠습니다.바로 시작합니다.하위 뷰와 상태 공유하기 (Share state with subviews)상태 프로퍼티를 하위 뷰로 전달하면, 상위 뷰에서 해당 값이 변경될 때마다 SwiftUI는 하위 뷰를 자동으로 업데이트합니다. 하지만 하위 뷰는 이 값을 수정할 수 없습니다. 하위 뷰가 상태 값을 수정할 수 있게 하려면, 상태 대신 바인딩을 전달해야 합니다. 예를 들어, PlayButton에서 isPlaying 상태를 제거하고, 대신 바인딩을 받도록 변경할 수..

안녕하세요, iOS 개발하는 루피입니다! 오늘은 SwiftUI의 선언적 UI 패러다임의 핵심인 상태 관리에 대해 알아보겠습니다. 특히 가장 기본이 되는 State 프로퍼티 래퍼를 중심으로 공식 문서를 바탕으로 정리해보았습니다. 바로 시작합니다.@State란 무엇인가?@State는 SwiftUI에서 제공하는 Property Wrapper 타입의 하나로, 변수 앞에 위치하며 해당 프로퍼티 데이터 값에 접근할 수 있고 또한 최신 값을 반영합니다. 이름 그대로 상태(State) 자체를 나타내며, 상태가 변하면 UI도 이에 맞게 변합니다.struct ContentView: View { @State private var name = "World" var body: some View { VSt..

안녕하세요, iOS 개발하는 루피입니다! 오늘은 SwiftUI의 UI 상태 관리에 대해 공식 문서를 바탕으로 정리해 보겠습니다. 바로 시작합니다.OverviewSwiftUI에서 상태 관리의 핵심은 각 뷰가 필요한 데이터를 캡슐화하여 독립적이고 재사용 가능한 컴포넌트로 만드는 것입니다.캡슐화란?여기서 캡슐화란 뷰가 데이터(@State)와 동작(UI 렌더링)을 내부에 정리하고, 외부에는 간단한 인터페이스(@Binding, 읽기 전용 속성)만 노출하는 것을 의미합니다. 이렇게 하면 뷰는 복잡한 내부 로직을 숨기고, 다른 화면이나 앱에서 쉽게 재사용할 수 있습니다.하지만 여기서 한 가지 오해가 생길 수 있습니다."아 그러면.... 모든 데이터들을 딱 뷰에 맞게 분산시키는 게 포인트구나???"아니요. 데이터를 뷰..