이런저런 이유로, 현재는 회사에서 iOS Platform에서의 업무를 하지 않고 있다. 언제까지 iOS Platform 업무를 하지 않을지는 모르지만, 한동안은 개인 프로젝트를 하면서 iOS 관련 포스트를 작성하려고 한다.

1. Intro

: alert을 나타낼 때, TextField가 포함되어 있으면 [LayoutConstraints] warning이 console에 노출되는 것을 확인하였다. SwiftUI에서 .alert에 TextField를 추가한 경우와, UIAlertController에서 addTextField를 호출하여 TextField를 추가한 경우 모두 warning이 노출되었다.

# console에 노출된 warning

[LayoutConstraints] Changing the translatesAutoresizingMaskIntoConstraints property of a UICollectionViewCell that is managed by a UICollectionView is not supported, and will result in incorrect self-sizing. View: <_UIAlertControllerTextFieldViewCollectionCell: 0x7fbb22d44700; frame = (0 0; 270 24); gestureRecognizers = <NSArray: 0x60000366b6c0>; layer = <CALayer: 0x60000383fa60>>

[LayoutConstraints] Changing the translatesAutoresizingMaskIntoConstraints property of a UICollectionViewCell that is managed by a UICollectionView is not supported, and will result in incorrect self-sizing. View: <_UIAlertControllerTextFieldViewCollectionCell: 0x7fbb22b36de0; frame = (0 30.6667; 270 30.6667); gestureRecognizers = <NSArray: 0x60000368d1a0>; layer = <CALayer: 0x60000387ebe0>>

2. Impact

1) 아직까진 UI가 흐트러지거나 찌그러지는 등의 문제는 발견하지 못했다.

2) iOS 15부터 발생하는 것으로 추측된다.

3. How to solve?

: 구글링도 해보고, 다양한 시도를 해보았지만 명확한 원인을 찾지 못했다. 별도로 Constraints를 조작하는 코드들을 작성하지 않고, SwiftUI에서 .alert에 TextField만 추가하거나 UIAlertController의 extension에서 addTextField를 호출하여 UITextField를 추가하기만 해도 alert을 나타낼 때 console에 warning이 표시된다. UIKit 차원에서의 버그일까? (더 좋은 해결 방법을 알게되면 게시글을 수정 하겠다)

 해결하고 싶다면, 아직까진 UIAlertController를 커스터마이징 하는 방법밖에 모르겠다. UIAlertController 인스턴스가 setValue(viewController, forKey: "contentViewController")를 호출하여 커스터마이징을 하돼, UITextField의 layout을 직접 추가하고 설정하자. 예제 코드를 작성해보면 아래와 같다.

 이때 주의할 점이 있는데, UIAlertController를 상속하지 않아야 한다는 것이다. Apple의 문서(Link)에 따르면... UIAlertController는 그대로 쓰이도록 의도된 클래스이며, 이 클래스의 View Hierarchy를 변경해선 안된다고 명시되어 있다.

1. Intro

: 올해 초, 개발한 Library(*.framework 파일)를 다른 팀에 전달했는데 정상적으로 Build가 되지 않아서 고생을 했던 적이 있었다. 우리 팀에서 개발했던 Library를 사용하는 Project에서, Build Setting 항목 중 Other Linker Flags가 -ObjC인 경우 symbol 충돌이 발생하는 것이었다. symbol이 충돌하지 않도록 노가다...를 해서 해결했는데, -ObjC는 대체 왜 넣은 것일까? -ObjC는 대체 어떤 역할을 하는 것일까?

2. Objective-C로 작성된 Library

: -ObjC를 Other Linker Flags에 넣는 것은, Objective-C로 개발된 특별한? *.framework 파일을 사용할 때 발생하는 문제를 해결하기 위함이다. 문제를 발생시키기 위해 Sample Project를 만들었고, Sample Project의 구조는 다음과 같다.

 그림1에 명시된 Sample Project의 주요 특징을 정리해보자.

1. LinkingTest라는 iOS Application은 SampleKit.framework를 link해서 쓰고 있다.
2. SampleKit에는 구현한 코드가 Sample.m와 Sample+AdditionalFeature.m(Category에 선언된 Method를 구현함)로 나누어져 있다.
3. SampleKit은 Static Library이고, Objective-C로 작성된 코드들이 있다.

  SampleKit의 헤더와 코드도 살펴보면 다음과 같다.

 Objective-C로 개발된 특별한? *.framework 파일을 사용할 때, 발생할 수 있는 문제를 확인하는 것이 주 목적이므로 작성한 코드는 아주 간단하다. SampleKit을 LinkingTest에서 다음과 같이 사용했다.

 정말 단순해보이는 그림4의 코드를 실행시키면, Runtime에 Crash가 발생한다. Console에는 다음과 같은 메세지가 출력된다.

=> LinkingTest[49929:5165739] -[Sample outputDescription]: unrecognized selector sent to instance 0x600003d341a0

 outputDescription은 Sample+AdditionalFeature.m(category)에 선언된 코드인데 왜 unrecognized selector로 취급받는 것일까?

3. Crash가 발생하는 이유

: Crash가 발생하는 이유를 찾아본 결과, UNIX static library와 Objective-C의 Dynamic한 특성간 충돌이 있어서 static library에 있는 category method들이 Application에 Link가 되지 않는 이슈가 있다고 한다. 그래서 Runtime에 method를 찾지 못해서, unrecognized selector라는 메세지와 함께 Crash가 발생하는 것이다.

 Dynamic한 특성을 제공하기 위해, Method가 호출되기 전까지 method를 구현한 코드가 결정되지 않는다(symbol로만 표시해두고, 나중에 Runtime에 실행할 코드가 결정된다). 그리고 Objective-C는 method를 위한 linker symbol은 정의하지 않고 class를 위한 linker symbol만 정의한다. 예를 들어보면, sample.outputDescription()에서 Sample이라는 class에 대한 symbol은 있지만, outputDescription이라는 method에 대한 symbol은 없는 것이다.

 Objective-C의 category는 method들을 모아놓은 것이므로, category의 method들은 symbol을 생성하지 않는다. 그래서 class가 이미 정의된 경우(class는 정의되어 있고, 해당 class에 대한 category를 구현한 코드가 다른 파일인 경우), linker에서는 category에 정의된 것들을 모른다(load하지 않는다)는 것이다.

 -ObjC라는 Linker Flag는 linker가 static library에 있는 모든 Objective-C로 작성된 class와 category를 load하도록 한다. 그래서 이 Flag를 사용하면, 이 문제를 해결할 수 있다. 다음과 같이 Flag를 추가할 수 있고, 실행시켜보면 정상동작 하는 것을 확인할 수 있다.

 static library에서만 발생하는 문제인 만큼, SampleKit의 Mach-O Type을 Dynamic Library로 변경하면 -ObjC Flag를 추가하지 않아도 문제가 해결된다. 아니면 Sample+AdditionalFeature.m에 구현된 코드들을 Sample.m으로 옮겨도(그러니까 category가 아닌 Sample class에 대한 implementation이 있는 파일과 category가 한 곳에 있을 때) 문제가 해결되지만, 한 파일에 너무 많은 코드가 담겨지게 될 것이다.

4. Reference

1) https://developer.apple.com/library/archive/qa/qa1490/_index.html

이전 포스트에 이어서, 작성되는 포스트이다.

1. Swift String에서의 Unicode

: é문자를 통해, Swift String에서 주의할 점들을 설명하고자 한다. é는 e에 acute accent를 붙인 것인데, 이를 표현하는 방법은 한가지 이상이다. 한 문자를 표현하는 방법이 한가지 이상이면, 비교는 어떻게 할 수 있을까? 표현하는 방법마다 문자의 크기는 같을까? 아래의 코드를 보고 하나씩 알아보자.

 firstString과 secondString은 lite를 제외한, 나머지 부분이 다르다. 그런데 출력시켜 보면, 둘 다 élite가 출력된다. count도 동일하다. 두 String을 비교한 결과는 true다. 하지만, code unit을 16bits로 하고 count를 보면 firstString과 secondString이 다르다.

 firstString과 secondString의 *.utf16.count는 다른데, 어째서 비교한 결과는 같은 것일까? Swift Language Guide에서 이유가 설명되어 있었다(링크).

 "Two String values (or two Character values) are considered equal if their extended grapheme clusters are canonically equivalent. Extended grapheme clusters are canonically equivalent if they have the same linguistic meaning and appearance, even if they’re composed from different Unicode scalars behind the scenes."

 대략 다음과 같이 해석할 수 있다.

 "Swift에서 두 String을 비교할 때 두 String의 Extended Grapheme Clusters가 canonically equivalent하면, 두 String은 equal하다. Extended Grapheme Clusters는 언어학적으로(linguistic) 의미와 형태가 같으면, Canonically Equivalent하다."

 Swift Language Guide에 나와있듯이, firstString과 secondString은 다른 Unicode Scalar들로 이루어져 있더라도 언어학적으로 의미와 형태가 같아서 비교한 결과가 True인 것이다.

2. NSString에서의 String 처리

: NSString은 조금 동작이 다르다. 확인을 위해 다음과 같은 코드를 작성했다.

 Swift Strig에서는 firstString과 secondString의 count는 같았는데, NSString으로 타입 캐스팅한 typecastedFirstString과 typecastedSecondString의 length는 왜 다른 것일까? NSString을 설명하는 Apple 문서에 이유가 설명되어 있었다(링크).

 "An NSString object encodes a Unicode-compliant text string, represented as a sequence of UTF-16 code units. All lengths, character indexes, and ranges are expressed in terms of 16-bit platform-endian values, with index values starting at 0."

 음... 그러니까 NSString은 UTF-16로 Text를 인코딩한다. NSString의 length와 index, range도 16bit로 인코딩한 값에 따라 계산이 된다.

 NSString을 비교하는 'isEqual(to aString: String) -> Bool' 메서드에 대한 설명에서도, 두 String의 Unicode가 동일한지를 비교한다고 설명되어 있다(링크).

3. 마무리 및 참고자료

: 이번 글에서는 String을 비교할 때 주의할 점과, Swift String과 NSString이 어떻게 다른지를 설명했다. 글 중간중간에 삽입한 링크들을 정리하는 것을 끝으로, 이번 글을 마무리하겠다.

- Swift 문서의 String Compare

https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID298

- NSString

https://developer.apple.com/documentation/foundation/nsstring

- NSString의 isEqual(to aString: String) -> Bool 메서드

https://developer.apple.com/documentation/foundation/nsstring/1407803-isequal

1. Intro

: C로 개발을 처음 공부했을때, 처음 접해본 문자열은 char *message = "hello world";와 같은 형태였다. message는 char들이 저장된 곳의 시작주소이고, 문자열의 맨 마지막은 null이었다. char charArray[4] = { 'a', 'b', 'c', '\0' }; 와 같이, char들의 배열을 선언하고 배열의 마지막 요소를 '\0'로 설정해서 문자열을 나타낼 수도 있었다.

 ASCII Code로 나타낼 수 없는 문자를 표현하기 위해 Unicode가 생겨났고 UTF-8, UTF-16, UTF-32 등의 Encoding이 있다는 것, 문자열에 대한 나의 이해는 이정도였다.

 어느 날 책에서 이런 내용을 보았다. 

"String의 n번째 Character에 접근하는 연산은 time complexity가 o(n)이다. 
String의 n번째 Character에 접근하는 것이 Random Access가 아니기 때문이다".

 부끄럽게도, String을 구성하는 Character들이 배열같은 Collection에 순서대로 저장되어 있을 것이라 생각해서 Array의 요소에 접근하는 것처럼, String의 Character에 접근하는 것도 Random Access로 접근할 것이라고 생각했었다.

 그동안 컴퓨터에서 문자를 어떻게 다루는지에 대한 별다른 고민없이 사용했다는게 조금은 부끄럽기도 해서, 다양한 문서들을 읽어보았다. 이런저런 문서들을 읽어보니 생각보다 알아야 할 것들이 많았고, 익힌 내용을 정리할 필요가 있다고 생각하여 글을 적어보고자 한다.

2. ASCII의 한계와 그것을 극복하기 위해 등장한 표준들

: ASCII는 매우 단순하다. ASCII 문자로 이루어진 문자열은, 구성하는 Character들이 모두 8bits로 크기가 일정하다. 그래서, 문자열의 Character에 Random Access로 접근할 수 있지만, 미국에서 쓰는 알파벳이 아닌 문자를 표현하는 데에 한계가 있다. 그래서 ISO/IEC 8859 표준이 등장했는데...

2-1. ISO/IEC 8859의 등장

: 컴퓨터에서 문자를 8bits로 나타내는 위한 표준. 8번째 비트를 이용해서, 기존의 ASCII보다 더 많은 문자를 표현하여 ASCII의 한계를 극복하려 하였다. ISO 8859-1,2,3, ..., 16까지 있다. 하지만 ISO/IEC 8859 표준도 문자의 크기가 고정되어 있어서 동아시아 국가의 문자를 표현하는 데에는 한계가 있었다. 그래서 등장한 표준이...

2-2. Unicode의 등장

: 초기의 Unicode도 2bytes로 크기가 고정되어 있었고, UCS-2 라고 불렀었다. 하지만 2bytes로도 많은 문자들을 표현하는 데에 한계가 있었고, 오늘날에는 Unicode는 문자의 크기가 고정되지 않고 각각 다른 크기를 가질 수 있게 되었다.
=> 이런 이유로, String의 Character에 접근하는 것은 Random Access가 될 수 없다. n번째 Character를 알기 위해선,
n-1까지의 Character들을 확인해야 하기 때문이다.

3. Unicode란 무엇일까?

※ 이제부터 문자는 Character, 문자열은 String이라고 표현하겠음.

: Charactrer를 Encoding하는 표준을 일컫는 Unicode Standard와 그를 주도하는 협회 Unicode Consortium 모두를 Unicode라고 불리지만, 이 글에서는 Unicode Standard만을 이야기하고자 한다.

3-1. Unicode가 등장하기 전 Character 처리

: 기본적으로 컴퓨터는 숫자를 다룬다. 컴퓨터는 각 Character마다 다른 숫자를 할당하여 저장한다. Unicode Standard가 탄생하기 전, 다양한 Character Encoding 방법들이 있었으나 전 세계의 모든 언어를 표현하기엔 한계가 있었다. 특히 동아시아 언어를 표현하는 데에 한계가 있었다(뭐, 한글이라던지).

 초기의 Character Encoding들은 서로간 충돌(Conflict)이 있었다(같은 숫자를 다른 Character로 처리하거나 한 Character를 각기 다른 숫자로 처리하는 것). 컴퓨터들은 다양한 Character Encoding들을 지원했지만, 컴퓨터간 통신시 Character Encoding이 다를 경우, 문제가 발생할 수 있었다.

3-2. Unicode 등장

: 바로 위에서 이런 문제들을 해결하기 위해, Unicode가 만들어졌다.
=> 간단한 Character Encoding을 제공하는 것을 넘어서, Unicode Consortium은 'locale data'에 대한 표준에도 관심을 두고 있다. 

3-3. Unicode와 관련된 용어 정리

1) Code Point - 표준문서의 D10
: Unicode code space에 속하는 값. 값의 범위는 0에서 0x10FFFF(10진수로 나타내면 1,114,111)까지이다. Code Point들은 하나의 Character로 표시될 수 있지만, 여러 Code Point들이 모여서 하나의 Character를 표시할 수도 있다.

2) Unicode Scalar - 표준문서의 D76

: Code Point중, High/Low Surrogate를 제외한 것.

3) Surrogate(High Surrogate, Low Surrogate) - 표준문서의 3.8
: Surrogate는, 미래를 위해 Code Point에서 따로 남겨둔 부분이다(Surrogate 개개별로는 Character로 나타내지 않는다). 범위에 따라 High Surrogate와 Low Surrogate로 나뉘어 진다. High Surrogate와 Low Surrogate는 범위가 다른데, 표로 나타내면 다음과 같다.

4) Surrogate Pair

: High Surrogate에 속하는 Code Point 하나와 Low Surrogate에 속하는 Code Point 하나의 Pair로 구성하여 Single Character를 나타내는 것. UTF-16에서만 사용된다.

5) Code Unit

: Encoded Text의 Unit을 나타낼 수 있는 최소 bit 조합. Unicode Standard는 UTF-8에서는 8bits Code Unit들을 사용하고, UTF-16에서는 16bits Code Unit들을 사용하고, UTF-32에서는 32bits Code Unit들을 사용한다.

※ 개인적으로 Code Unit과 Code Point가 조금 헷갈렸다. 비교해서 정리해보면,

" Single Code Point는 Single Code Unit일 수 있고, 여러 Code Unit들로 이루어질 수도 있다. "
=> ☃ 는 3개의 UTF-8 Code Unit들로 이루어질 수 있고, 1개의 UTF-16 Code Unit으로 이루어질 수 있다.

6) Code Unit Sequence
: 하나 이상의 Code Unit들로 구성된 Ordered Sequence.

 Programming Language에서 String Data의 값은 기본적으로 Code Unit Sequence로 구성된다. 공식적이진 않지만, Code Unit Sequence 자체를 String이라고 하기도 하고, Byte Sequence를 Byte String이라고 하기도 한다.
=> 공식적으로는 Programming Language에 따라, String은 요구사항이나 복잡성이 추가되기도 한다. 예를 들자면, C Language에서 String은 NULL Character로 끝나야 한다던지. 

 Unicode Encoding Form은 Unicode Scalar 값을 Unicode Code Unit Sequence에 할당한다. 역사적인 이유로, Unicode Encoding Form은 Unicode(또는 UCS) Transformation Format, UTF로 불리기도 한다.

 Unicode Encoding Form에서, Unicode Scalar 값의 Set을 Code Unit Sequence의 Set으로 Mapping할 때, One-To-One으로 Mapping된다.
=> Reverse Mapping시, Mapping되기 전의 값을 추론할 수 있도록 보장한다.

하지만, Onto로 Mapping되는 것은 아니라서 Code Unit Sequence와 연관된 Unicode Scalar 값이 없을 수도 있다.

Unicode Encoding Form이 One-To-One으로 Mapping하는 것을 보장하기 위해, 모든 Unicode Scalar 값은 반드시 Unicode Code Unit Sequence로 Mapping되어야 한다.
=> Surrogate는 예외이다.

7) Unicode String

: 특정한 Unicode Encoding Form의 Code Unit들을 포함하는 Code Unit Sequence. 가장 Raw한 형태의 Unicode String은 적절한 정수들의 배열로, 간단하게 구현될 수 있다.
 단일 Unicode String은 단일 Unicode Encoding Form의 Code Unit만 포함해야 한다. String 내에서 Form을 혼합하는 것은 허용되지 않는다. 따라서...

- Unicode 8bits String, UTF-8 Code Unit들로 이루어진다.
- Unicode 16bits String, UTF-16 Code Unit들로 이루어진다.
- Unicode 32bits String, UTF-32 Code Unit들로 이루어진다.

4. 마무리 및 참고자료

: 이번 글에서는 Unicode와 관련된 용어를 정리하는 것에 중점을 두었다. Unicode Scalar, Code Point, Code Unit 등 여러 용어가 나왔고 각각에 대해서 간략하게 정리했는데, 더 알고 싶은 분들을 위해 참고했던 자료의 링크를 소개하는 것을 끝으로 이번 글을 마무리하겠다.

- Unicode 

https://home.unicode.org/basic-info/

- Unicode 12.0 Standard Documents

https://www.unicode.org/versions/Unicode12.0.0/

https://www.unicode.org/versions/Unicode12.0.0/UnicodeStandard-12.0.pdf

- Programming with Unicode

https://unicodebook.readthedocs.io/index.html

1. Intro

: UIView의 bounds와 frame의 차이가 무엇이냐고 하면, 좌표계(Coordinate System)의 차이를 이야기하며 설명하는 분들이 많다. 그렇다면 좌표계가 다르면 어떤 차이가 있을까? origin만 다를까? 이번 포스트에서는 이에 대해 이야기를 해보고자 한다.

2. Apple 문서에 소개된 bounds과 frame

* bounds - Apple 문서 링크

: 본인 관점의 좌표계(Coordinate System) 기준으로 View의 크기와 위치를 나타낸다. default bounds는 origin 값이 (0, 0)이고 size 값은 frame의 것과 같다. Rectangle 일부의 size를 변경하면, View의 center를 기준으로 변경된다. Rectangle의 size가 변경되면, frame의 size도 변경된다. (이하 생략)

* frame - Apple 문서 링크

: 부모 뷰(Superview) 관점의 좌표계 기준으로 View의 크기와 위치를 나타낸다. 그 외에는 bounds에서 Rectangle의 size가 변경될때 frame의 size을 바꿧던 것과 같이, bounds의 size을 바꾼다. 대부분의 특성이 bounds와 비슷한데, 조금 특이한 경고문이 Apple 문서에 다음과 같이 적혀있는데...

Warning

: view의 transform이 identity(CGAffineTransform.identity)가 아니면, frame의 값은 정의되지 않는다. 따라서 이때의 frame 값은 무시하는게 좋다(should).

 frame의 값이 도대체 어떻게 되길래, 정의되지 않고 무시하는게 좋다고 적혀있는 것일까? 궁금하다.

3. view에 transform을 해보면서 비교하기

: 직사각형의 frame이 (x: 60, y: 60, width: 40, height: 100)인 초록색(UIColor.green, alpha: 0.7) view를 추가해보면 다음과 같다.

이 상황에서, 직사각형의 frame이 (x: 60, y: 60, width: 40, height: 100)인 파란색(UIColor.blue, alpha: 0.7) view를 추가하고, 파란색 View의 transform을 CGFloat.pi * 0.25만큼 회전(rotation)시키면 다음과 같다.

그림 2의 초록색 view와 파란색 view의 frame과 bounds를 출력시켜 보았다.

* 초록색 view와 파란색 view의 frame

초록색 view의 frame : (x: 60, y: 60, width: 40, height: 100)

파란색 view의 frame : (x: 30.502525316941686, y: 60.50252531694167, width: 98.99494936611664, height: 98.99494936611666)

파란색 view의 frame 값이 다르다. origin(x, y)은 물론이고, size(width, height)도 초록색 view와 많이 다르다.

* 초록색 view와 파란색 view의 bounds

초록색 view의 bounds : (x: 0, y: 0, width: 40, height: 100)

파란색 view의 bounds : (x: 0, y: 0, width: 40, height: 100)

이번에는 두 view의 bounds가 동일하다. 사실 생각해보면, bounds가 본인 관점의 좌표계 기준으로 보기 때문에... 회전 여부와 관계없이 같아야 하는게 당연해 보인다.

초록색 view와 파란색 view의 frame이 다른 것을 보고, 파란색 view의 frame가 어떤 값인지 궁금하였다. 그래서 파란색 view의 frame과 동일한 다른 view를 그려보았다.

* 파란색 view의 frame과 동일한 view

파란색 view의 frame과 동일한(x: 30.502525316941686, y: 60.50252531694167, width: 98.99494936611664, height: 98.99494936611666) 회색(UIColor.gray, alpha: 0.7) view를 그려보면 다음과 같다.

회색 view가 그려진 영역을 보고, frame을 다음과 같이 추론해보았다...

"frame은, transform을 한 다음의 (x: minX, y: minY, width: maxX - minX, height: maxY - minY)으로 추정된다."

* transform된 view에 CGAffineTransform.identity로 transform해보기

파란색 view는 이미 transform이 되었다. 이 상태에서 transform에 CGAffineTransform.identity를 넣어주면 어떻게 될까? 그림2의 파란색 view의 transform에 CGAffineTransform.identity을 넣어주면 다음과 같다.

 아무런 transform하기 전인, 초록색 view를 완전히 덮었다. CGAffineTransform.identity는 CGAffineTransform(rotationAngle: .pi * 0.25)의 Inverse Matrix가 아니다. 여기서 추론해보면...

"transform되기 전 view의 frame을 알 수 있도록, vector 같은게 저장되어 있을 것."

4. Conclusion

: view에 transform을 해보며 bounds와 frame의 특징과 관계를 추론해볼 수 있었다. 정리해보면 다음과 같다.

1. CGAffineTransform.identity으로 transform된 view의 frame을 알 수 있도록,

   vector 같은 것이 저장되어 있을 것.

2. bounds는 아마도, CGAffineTransform.identity으로 transform된 frame의 size를 출력해줄듯.

3. 우리가 접근하는 frame은 transform한 다음의

   (x: minX, y: minY, width: maxX - minX, height: maxY - minY)일 듯.

어디까지나 나의 추론이므로, 어쩌면 잘못된 부분이 있을지도 모른다. 그러니까 UIKit, CoreGraphic 코드좀 보여주세요 애플님.

여담이지만, view의 transform을 적용할 때... 조심할 점이 있다. CGAffineTransform문서를 보면, 3x3 matrix가 있는데... 여기에 UIView의 좌표를 이용하여 계산을 하면 무엇인가 계산결과가 이상하다는 것을 알 수 있다. Quartz 2D Programming Guide를 보면 그 이유를 알 수 있는데, Quartz가 CGAffineTransform의 matrix를 이용해서 계산을 한다. 하지만 Quartz와 UIKit은 Coordinate System이 안맞으니, 계산결과가 이상할 수 밖에.

아 그리고, 이런 고민을 할 수 있도록 소재를 던져주신 Sadarm님 감사합니다.

 함수내에서, 값(Value)으로 전달받은 인자(Argument)는 참조(Reference)로 전달받는 인자와 차이가 있다. 참조로 전달받은 인자는 변경이 일어났을 때 본래의 객체도 같이 변경되지만 값으로 전달받은 인자는 그렇지 않다.

 
 애초에 값으로 전달받은 인자는 상수라서 변경조차 불가능하다. 값으로 전달받은 인자를 함수 내에서 수정하려면, 함수의 매개변수(Parameter)에 'inout'이라는 키워드를 붙이면 가능하다.

 매개변수에 inout 키워드가 붙었으니, multiply에는 integer의 참조가 전달된 것일까? 

inout Parameter에 대한 Apple의 설명을 보면 이야기가 좀 다르다.

In-Out Parameters: In-out parameters는 다음과 같이 전달됩니다.
1) 함수가 호출됬을 때, 값으로 전달받은 인자는 복사(Copy)됩니다.

2) 함수 내에서는 복사본이 변경됩니다.

3) 함수가 반환(Return)될 때, 복사본의 값이 본래의 값에 할당(Assign)됩니다.

 Apple의 설명을 확인하기 위해, 간단한 코드를 작성하면...

 function 내에서 전달받은 인자를 5로 바꾸어도, number는 변하지 않는다. function이 호출된 다음 number의 didSet이 호출되는 것을 볼 수 있는데, 이것을 통해 function 반환 후 본래의 값에 새 값이 할당된다는 것을 확인할 수 있다.

 이것은 참조가 전달된 Call-By-Reference와 다르며, Copy-In Copy-Out 또는 Call-By-Value Result라고 불려진다.

※ 2023.01.24에 추가된 내용

 Swift Docs에 적혀있는, In-Out Parameters의 Optimization에 따르면 Physical Address에 위치한 변수를 In-Out Parameter의 arg로 전달하면 Call-By-Reference로 동작한다고 적혀있다(Call-By-Reference는 Copy로 인한 Overhead는 없지만 Copy-In Copy-Out의 결과와 동일하다).

 Compilier의 Optimization Level도 바꾸어 보고, 코드도 이리저리 수정해가며 테스트를 해보았지만... In-Out Parameter를 정의한 함수에서 Call-By-Reference로 동작하는 것을 확인하는 데에 실패했다. Compiler Optimization 결과에 따라 In-Out Parameter의 동작이 달라질 수 있는 것 같으니, 인위적으로 상황을 재현하는 것은 어려울 것 같다.

 Swift Docs에 적힌대로, In-Out Parameter를 사용한 함수를 작성할 때, Call-By-Reference를 고려하지 말고 Copy-In Copy-Out로 동작한다고 생각하고 작성하자.

 몇년전 코드 리뷰 날, 선배 개발자 한분이 새로운 것을 보여주셨었습니다.

Objective-C의 코드를 두 개 이상의 파일로 나누는 것이었는데요. 

지금은 Swift로만 개발해서 활용하고 있지 않지만, 기록 차원에서 글로 작성해보았습니다.

 샘플로 만든 프로젝트의 'Project Navigator'는 아래와 같습니다.

 특이하게도 ViewController+DiviedFile.m이라는 파일이 있는데요, ViewController.m에 

넣으려던 코드를 별도의 파일로 분리한 것입니다. 

어떤식으로 분리한 것인지 보기 위해 ViewController.m의 코드를 살펴보면 아래와 같습니다.

 FILE_DIVIDE_FLAG라는 상수가 선언되어 있고, 

마치 헤더 파일을 추가한 것처럼 ViewController+DiviedFile.m을 추가했습니다.

 ViewController+DiviedFile.m의 코드도 볼께요.

 매크로를 사용해서, 상수 존재 여부에 따라 @implementation과 @end를 해당위치에 삽입하는 코드가 있습니다. @implementation과 @end가 있어야 ViewController+DiviedFile.m을 정상적인 형태를 갖춘 코드로 인식하고, 컴파일이 될때는 @implementation과 @end가 없어야해서 지시자(Directive)를 저런 형태로 작성한 것입니다.

 여기까지 작업하고 빌드를 하면, 심볼이 중복된다는 에러를 볼 수 있습니다. 해결하려면 ViewController+DiviedFile.m를 컴파일 대상이 되지 않게 하면 됩니다(전처리 단계에서 ViewController.m에서 ViewController+DiviedFile.m의 내용을 해당 위치에 추가하기 

때문에 괜찮습니다.).

 Xcode에서는 Target -> Build Phases -> Compile Sources에서

ViewController+DiviedFile.m를 지워주면 됩니다.