Get Up & Code, MacKin Talk

일부 뷰를 구현하는 중 상위 뷰에도 Spacer()이 존재하고, 하위 뷰에도 Spacer()이 존재하는 상황에서하위뷰의 Spacer()이 우선되는 것을 확인했다.1. 상위/하위에 Spacer()가 공존할 경우• SwiftUI는 자식 뷰들이 최대한 크기를 확장하고 나서, 남는 공간을 Spacer()에 분배.• 기본적으로 자식 뷰의 Spacer()가 먼저 공간을 가져가면, 상위 뷰의 Spacer()는 남은 공간만 가질 수 있다.상위 뷰의 Spacer()이 우선되도록 하는 방안을 고려하면 다음과 같은 방안들을 고려할 수 있다.방법 1VStack { Spacer() // 상위 Spacer HStack { Text("하위 뷰") Spacer() // 하위 Spac..

@State, @Binding, @Environment, @StateObject, @EnvironmentObject에 대한 리뷰. value 타입, 구조체 @State : Source of truth //  @Binding : values come from a parent view // 부모 뷰로부터 전달 받은 value (read, write 모두 가능)- read-only로 전달할 경우, 바인딩 없이 전달 가능@Environment : environment value persists within the subtree of the view 그림으로 표현했을 때 다음과 같이 생각됨. reference 타입, 클래스 @StateObject - @ObservedObject의 관계는 구조체의 @State와 @..

Swift로 작성된 함수를 기본적으로 C 인터페이스에서 동작하는 Unity 나 Unreal 등의 게임엔진 또는 직접 C 코드에서 호출하게 되는 상황에서 네임 멩글링(Name Mangling)으로 인한 경고 또는 에러를 경험할 수 있다.C 인터페이스에서 동작하는 이유는 다양한 언어 간 상호 운용이 가능하기 때문. C++ 및 Swift는 함수 오버로딩과 네임스페이스를 지원하기 위해 함수 이름을 내부적으로 변경하는 "네임 맹글링"을 사용한다.Swift에서는 특히 Objective-C에서 사용할 수 있도록 @objc, @objcMember 와 같은 애트리뷰트(attribute)를 사용하는 것과 관련이 있다.  좀 더 자세히 설명한다면 네임 맹글링(Name Mangling)은 컴파일러가 함수와 변수의 이름을 고유..

Xcode의 Build Options에 포함되어 있다. "User Script Sandboxing"사용자 정의 스크립트가 실행되는 환경을 제한하여, 보안과 안정성을 높이기 위해 도입된 기능이라고 함.  Xcode의 "Run Script" 빌드 단계에서 사용자 스크립트가 실행될 때 사용된다.이 옵션을 활성화하면 스크립트는 제한된 권한 내에서 실행되며, 시스템에 대한 무제한적인 접근을 막게 된다.  제한된 권한:스크립트가 파일 시스템에 접근할 수 있는 범위를 제한네트워크 접근을 제한하여 외부로 데이터를 전송하거나 외부에서 데이터를 받는 것을 방지리소스 제어:스크립트가 사용할 수 있는 CPU 및 메모리 리소스를 제한하여, 시스템 과부하를 방지보안 강화:시스템에 치명적인 명령어 실행을 차단하여 악의적인 코드..

1. 프로젝트 네비게이터(Xcode 좌측 메뉴바, 단축키 : cmd + 1) 에서 main.storyboard 파일 제거2. 해당 타겟의 build settings에서 info.plist Values에서 UIKit Main Storyboard File Base Name 제거(키-값 모두 제거) 3. 프로젝트 네비게이터의 info.plist에서 Storyboard Name 키-값 모두 제거 위 상태에서 실행 시 Bundle에서 Main의 이름을 가진 스토리 보드를 찾을 수 없다는 에러 반환. 4. Scene delegate에 root viewcontroller 설정을 위한 코드 추가.import UIKitclass SceneDelegate: UIResponder, UIWindowSceneDelegate {..

일부 Delegate 등 시스템 제공 API를 몇 가지만 둘러보더라도 @available 과 같은 속성이 정의된 메소드들을 많이 접할 수 있습니다. Xcode를 통해 개발을 하는 경우, @available 속성을 통해 특정 클래스, 메서드, 프로퍼티 또는 기타 코드 구성 요소의 사용 가능한 플랫폼 버전을 명시적으로 표시할 수 있으며, API의 버전 관리를 보다 세밀하게 제어하고, 버전 호환성을 지켜줄 수 있습니다. 함수 위에서 @available을 작성하면, Xcode IDE의 도움을 받아 선택적으로 해당 속성을 지정할 수 있습니다. @available(, introduced: , deprecated: , message: ) 플랫폼, 도입 버전, 폐지 버전, 등 여러 가지를 나타낼 수 있습니다. //..

일반적인 iOS App을 개발할 때, SPM이나, Cocoapod 등의 의존성 관리도구를 많이 사용하듯 게임 엔진도 비슷합니다. 기능 중 일부 기능을 3rd나 오픈 소스 등 외부 소스를 사용해 기능 구현에 사용합니다. 라이브러리 또는 프레임워크라 불리는 형태로 타겟 앱에 추가하죠. Unreal Engine을 통해서 나오는 ipa 파일도 결국은 Xcode를 통해 나오는 결과물과 별반 다르지 않다는 점에서 결과물이 비슷하다는 건 인풋도 비슷하다는 거 아닐까요. 물론 내부의 실행파일의 구조 등은 일부 다르지만요. 일반 Swift로 작성된 iOS 앱과 다른 점이라고 한다면 Unreal Engine에서는 iOS Framework를 적용하기 위해서 Framework를 적용하기 위한 Build.cs 를 작성하고, i..

프로토콜과 그 기본 구현을 활용해 중복을 피할 수 있다. Swift에서는 프로토콜의 익스텐션을 활용할 때 where 절을 사용해 타입 지정 방법을 제공 해당 익스텐션이 적용될 수 있는 타입의 범위를 제한할 수 있도록 해준다. 예시로 extension AProtocol { // methods... } 프로토콜을 정의할 때 특별한 타입 제약을 지정하지 않은 경우, 그 프로토콜은 어떤 타입에서든 채택할 수 있음. - 클래스, 구조체, 열거형 등 extension AProtocol where Self: UIView { // methods... } 특정 타입에만 프로토콜을 적용하고 싶은 경우 where Self: UIView Aprotocol을 확장하되, 그 확장의 범위는 UIView의 서브 클래스인 타입에만 ..