Seorenn SIGSEGV

Xcode 를 9.3 으로 업데이트 하기 전만 해도 별 문제 없던 프로젝트가 갑자기 아래와 같은 경고를 내뿜기 시작 했습니다. Block implicitly retains 'self'; explicitly mention 'self' to indicate this is intended behavior 블록이 self 를 잡아 물고 가버릴 수도 있는데 명확하지 않다는 식으로 이해가 됩니다. 그런데 경고가 발생한 위치를 보면 위 경고 메시지가 뭘 원하는 것인지 도통 이해 할 수가 없었습니다. 경고라 가볍게 넘어 갈 수도 있겠지만 일단 해결하는 방법을 알아봅시다.

Xcode 9 이전에 개발했던 프로젝트를 Xcode 9 에서 Swift 4 기반으로 변경한 적이 있다. 이 과정에서 단 한줄의 코드 변경도 없었고, 당연하게도 해당 프로젝트는 별 문제는 없이 잘 동작하였다. 다만 약간 찝찝하게도 빌드 도중 아래와 같은 색다른(?) 경고를 보게 되었다. The use of Swift 3 @objc inference in Swift 4 mode is deprecated. Please address deprecated @objc inference warnings, test your code with “Use of deprecated Swift 3 @objc inference” logging enabled, and then disable inference by changing the "Swift 3 @objc Inference" build setting to "Default" for the "TARGET NAME" target. 해석하자면 뭐라고 할까... 그냥 구버전 방식의 @objc 를 사용하는 것이 Swift 4 에선 호환이 안되니 무슨무슨 설정을 바꿔라 이런 의미로 해석된다. 하여간, 이 글은 이 경고를 해결하는 방법을 설명한다.

Xcode 9 을 제대로 찝적거릴(?) 기회가 생겨서 신기능을 조금씩 느껴보고 있다. 이왕 이렇게 된거 이런 기능들을 영상으로 한번 찍어보자 해서 녹화해서 편집해 봤다.

오랫만에 옛날에 만들어 둔 iOS용 앱 프로젝트를 수정할 일이 생겼다. 그런데 문제를 수정하고 디버그 모드로 디바이스에 넣어서 실행시켜보니 괴상한 오류메시지가 로그 창에 찍히기 시작했다.

편의성 측면도 있겠지만 애플에서 Swift 를 강력하게 밀고 있기에 아무래도 macOS나 iOS용 개발 언어는 Swift 가 주류가 될 가능성이 높다. 하지만 그렇더라도 한동안은 Objective-C 와의 동거를 끝낼 수는 없을 것이다. 그 증거로 애플에서는 Xcode 나 Swift 가 업데이트 될 때 마다 Objective-C 코드와의 공존에 대한 기능을 계속 발전시키고 있다. 이번 글은 Objective-C 코드가 Swift 에서 어떻게 읽혀지는지 혹은 Swift 용 별명을 지어서 언어간 차이를 완화시키는 방법이 있는지를 간단히(?) 적어볼까 한다.

앞서 살펴본 내용에서 소스 코드 문서화의 기초 적인(것 같지만 거의 대부분인 -_-) 내용을 살펴 봤다. 이번 글에서는 좀 더 다양한 예제를 통해 어떻게 하면 문서화가 되는지를 간략히 살펴보자.

제목을 뭘로 표현하면 좋을까 고민했는데 최대한 직설적으로 적었다. 이번 주제는 코드 자동 문서화인데 별도의 레퍼런스 매뉴얼로 만들어 내는 것 보다는 Xcode 내에서 참조 할 때 표시되는 도움말 팝업 위주이다.

AppKit 을 활용해 만든 macOS 용 앱 윈도우의 크기와 위치를 보존하려면 autosave 이름을 지정해 주면 된다.

풀스크린에 대한 글을 써 보려 했는데 사실 쓸 내용이 없다. 이제 모든 앱 프로젝트는 기본적으로 라이언 스타일 풀스크린이 기본 옵션이다. ... ?!! 응? 뭐? 끝이야?! 물론 이 글을 뜬금없이 끝낼 순 없으니 한가지 팁을 소개해 본다. 만약 윈도우가 툴바를 가지고 있다면, 그리고 풀스크린 환경에서 툴바를 숨기고 싶은 경우가 있을 수 있다. 예를 들어, 사파리는 풀스크린을 표시하면 메뉴바만 사라지는데, 사진(Photos)앱은 뷰어 모드에서는 툴바가 메뉴바와 동일하게 표시되지 않다가 마우스 커서를 상단에 가져가야 나타난다.

Xcode 의 유닛테스트 기능은 동기(Sync)코드 테스트에 최적화 되어있다. 당연하게도 비동기 루틴의 경우 해당 테스트 컨텍스트가 종료된 뒤에 비동기 결과가 들어오니 쉽게 판단할 수는 없을 것이다. 다행히도 Xcode 의 XCTest 모듈은 이런 비동기 콜(Asynchronous Call)에 대비하기 위한 약간의(?) 기능이 제공되고 있어서 소개해 본다.

Xcode 8이 드디어 베타 딱지를 떼고 GM 마크를 박고 올라왔다. 이제 기능 면에서 바뀔 일은 없을 것 같으니 마지막으로 마무리 하는 겸으로 무엇이 바뀌었는지에 대한 경험담을 이어서 적어본다. 이 글은 ' Xcode 8 Beta 로 겪어보는 Swift 3 의 변화들 ' 글에서 정리한 내용을 제외하고 GM 버전에서 추가로 발견한 사항들을 정리한다. 이 글을 올리는 오늘 Xcode 8 이 정식 릴리즈 되었다는 것은 참 거시기하다

이 글은 튜토리얼이나 API소개글이 아니라 실제로 겪었던 일을 토로(?)하기 위한 글이다. 내용은 제목 처럼 릴리즈 모드로 빌드한 앱을 돌려보면 죽는다는 것이고 이를 해결하기 위해 거친 고난과 해결법에 대해 소개한다.

뭔가 제목이 좀 복잡한 감이 있는데, 영문으로 적으면 Unified Title and Toolbar 라는 형식의 윈도우를 만드는 방법에 대한 글이다. 내용 자체는 매우 간단한데 이번엔 영상으로 (콩글리쉬와 함께 -_-) 만들어봤다.

assert() 라는 함수는 C언어 시절 부터 예기치 못한 에러를 잡기 위한 무기(?)로써 활용되어 왔다. 문제가 생길 것 같으면 일부러 자살(?)하기 위한 무기가 바로 assert()이다.

Xcode 7.3과 함께 Swift 2.2도 함께 정식으로 릴리즈 되었다. 요즘엔 공식사이트도 생기고 오픈소스화 되면서 변경 내역을 접하기가 쉬워지고 정리도 잘 되어 있어서 이런 글을 적는게 의미가 있나 고민되기는 하지만, 그래도 복습하는 겸 정리해본다.

제목이 좀 뜬구름 잡기인 듯 한데 좀 더 쉽게 풀자면 이렇다: 프로젝트에 스토리보드가 두 개다. 이 중 하나는 튜토리얼용으로 앱 시작 시 한번만 보여줄 것이다. 이걸 스토리보드 하나로 만드면 너무 복잡해서 나눈 것이다. 앱 시작 시 특정 조건의 경우에는 튜토리얼용 스토리보드의 UI로 시작해야 한다. 그런데 어떻게 해야하지? 그냥 딱딱하게 설명할까 했지만 이번엔 좀 수고를 들여서 메모를 만들어 본다 -_-;

간밤에 애플이 Swift가 오픈소스화 되었다고 공식 발표하였다. 공식사이트는 이제 아래 사이트이다.

iOS 9과 OS X 10.11 에 앱 네트워크 보안(App Transport Security) 이라는 정책이 새롭게 추가되었다. 이로 인해서 구글에서도 애드센스 관련해서 뭔가 말이 많았던것 같은데, 나도 개발 도중에 문제를 겪었기에 메모하는 겸 블로그로 정리해 본다. 아 참고로 이 내용은 애플에서도 개발중인 내용이라 추후에 변경될 가능성 이 있다고 한다.

Xcode 6 하에서 Swift 코드로 만들어진 프로젝트의 유닛테스트를 하려면 해당 모듈을 public으로 선언해야만 가능했다. (관련글: Swift 프로젝트의 유닛테스트(Unit Test) ) 이는 Swift의 엑세스 컨트롤의 구현 의도와 Xcode에서 테스트 코드가 구성되는 방식의 의도가 다르다는 차이 때문에 발생하는 문제였다.

Swift 2.0 에서 드디어 예외처리 - 공식 블로그에는 Error Handling Model 이라고 표현하고 있다 - 이라는 OOP 언어라면 누구나(?) 다들 가지고 있는 기능(?)이 추가되었다. 그런데 기존 다른 언어들과는 조금 다른 모습이긴 하다