ImageForge 1.3.1: 창 하나, 목록 하나

사용자 제보 하나, 운영체제 둘, 공통점이 전혀 없는 근본 원인 둘. Mac에서는 Dock 아이콘에 이미지 네 장을 놓으면 창이 네 개 열리고 묶음은 그중 하나에만 들어갔습니다. Windows에서는 “ImageForge로 열기”를 골라도, 파일을 몇 개 건네든 앱이 빈 목록으로 열렸습니다. 1.3.1은 둘 다 고칩니다. 그리고 각각이 어떻게 망가져 있었는지는 이야기할 만합니다.

Mac은 이미지마다 창을 하나씩 열었습니다

Dock 아이콘에 이미지 네 장을 놓으면 각자 빈 목록을 가진 창이 네 개 열렸고, 서로 그 묶음을 받으려 경쟁했습니다. 원인은 우리 코드가 아니었습니다. 메인 창이 SwiftUI의 WindowGroup이었기 때문입니다. WindowGroup은 macOS가 문서 열기 Apple Event를 전달하면 문서마다 창을 하나씩 엽니다. 시스템 추적 기록은 명확했습니다. 파일 네 개를 담은 이벤트 하나, 그리고 곧바로 만들어진 창 네 개 — 모두 우리 코드가 경로를 하나도 보기 전에 벌어진 일입니다. 묶음은 그중 한 창에 들어갔고 어떤 창이 앞으로 나올지는 통제할 수 없었습니다. 그래서 앱이 아무것도 없이 열린 것처럼 보였고, 다시 시도해도 빈 창만 늘어났습니다.

해결책은 문제를 방어적인 코드로 감싸는 것이 아니라, 이 앱이 원래 무엇이었는지를 선언하는 것이었습니다. 창 하나에 목록 하나. 이제 장면은 SwiftUI의 Window이며, Apple Event도 그 무엇도 복제할 수 없는 단일 인스턴스입니다. 같은 이유로 파일 메뉴의 “새로운 윈도우”도 없어졌습니다. 창을 닫았다면 윈도우 ▸ ImageForge 윈도우(⌘0), Dock 아이콘 클릭, 또는 메뉴 막대 항목으로 다시 열 수 있습니다.

Windows는 파일을 아예 읽지 않았습니다

Windows 앱은 첫 릴리스부터 파일 형식 연결을 선언하고 있었습니다. 그래서 Windows는 “ImageForge로 열기”를 제공했고 아이콘에 놓는 것도 받아들였습니다. 다만 한 번도 읽지 않았을 뿐입니다. WinUI는 모든 활성화를 하나의 시작 메서드로 모으는데, 우리 쪽은 창을 만들고 인자를 버리고 있었습니다. 연결은 장식이었고, 이미지를 한 장 건네든 스무 장 건네든 앱은 빈 목록으로 열렸습니다.

고치는 과정에서 우리가 잘못 가정하고 있던 것도 드러났습니다. 패키지된 데스크톱 앱의 경우, Windows 셸은 선택 항목을 하나의 활성화로 넘기지 않습니다. 파일마다 프로세스를 하나씩 시작하고, 각 프로세스의 명령줄에는 경로가 하나만 실립니다. 이미지 네 장은 곧 네 개의 프로세스였던 것입니다. 그래서 수정은 두 부분입니다. 명령줄에서 경로를 읽는 것, 그리고 주 프로세스를 하나 뽑아 나머지가 종료하기 전에 자기 파일을 넘기는 것. 결과는 처음부터 그랬어야 할 모습입니다. 몇 개를 선택하든 창 하나, 목록 하나.

두 개의 버그, 하나의 교훈

두 버그 모두 앱과 운영체제의 경계에 있었습니다. 단위 테스트로는 덮을 수 없는 영역이죠. 셸이 실제로 무엇을 하는지는 직접 시켜서 지켜보는 수밖에 없으니까요. 둘 다 코드를 따져서가 아니라 시스템 추적 기록을 읽어서 찾았고, 두 경우 모두 코드는 우리가 시킨 그대로 하고 있었습니다. 1.3.1은 Mac App Store와 Microsoft Store에서 이용할 수 있습니다. 늘 그렇듯 모든 처리는 여러분의 기기에서 이루어지며, 업로드되는 것은 없습니다.