ios17.6 앱튕김

함민혁·2025년 11월 12일

문제 발생 확인

ios17.6 앱튕김으로 원인 좁힘

ios 17이하에서 지속적으로 앱 크러쉬 발생.

버전을 낮춰서 빌드를 해봐도 계속 빌드 실패

빌드 성공해도 16이하는 애플쪽에서 submit 막아둠

동생의 실기기가 ios 17.6버전이라 내부 테스터로 등록 후 개발자에게 로그 제출하도록 함.

문제 확인

iOS 내부 프레임워크인 SwiftUICore.framework를 찾을 수 없어서 앱이 바로 종료
Expo로 빌드를 하더라도, 내부에 iOS 네이티브 코드(모듈)가 포함되고 그중 일부가 SwiftUI 기반일 수 있음
Xcode 16(2024~25)로 빌드 시 iOS 18 SDK가 적용됨, 그러면 SwiftUICore가 자동 의존되어 iOS 17 기기에서는 못 찾고 크러시가 나는 상황.

구글링을 통해 사례를 한번 쭉 정리해보기로 결정

같은 사례로 보인글들과 그 글의 댓글, 대댓글을 모두 직접 스크랩해서 사례별로 중복제거없이 쭉 정리

🧩 사례 1 – Jaxter2024 (첫 번째 글 본문: Capacitor Version…)

🔹 문제 상황

Capacitor 6, Xcode 16을 사용하는 꽤 복잡한 SwiftUI + UIKit 프로젝트.
iOS 18 시뮬레이터에서는 정상 실행.
iOS 17 및 그 이하에서 앱이 런치 직후 크래시.
크래시 이유: 앱이 SwiftUICore 라이브러리를 로드하려 하지만, SwiftUICore는 iOS 18에서 새로 도입된 프레임워크라 예전 iOS에는 없어 크래시가 난다고 설명함.
UIViewRepresentable 같은 SwiftUI 컴포넌트를 사용하면 이 크래시가 재현됨.
exyte/SVGView 같은 SPM 패키지도 같은 방식으로 크래시를 유발한다고 적음.

🔹 문제를 유발한 부분

글에서는 “UIViewRepresentable 등 SwiftUICore를 필요로 하는 SwiftUI 컴포넌트 사용”과
“Xcode 16이 SwiftUICore가 런타임에 있을 것이라고 가정하고 빌드한다”는 점을 문제의 근원으로 적고 있음.

🔹 바꾸니 해결된 것 / 해결책

글에서 제시한 임시 해결책:
- 앱 타깃의 Build Settings → Other Linker Flags (OTHER_LDFLAGS) 에
  - weak_framework SwiftUICore 를 추가.
- 이렇게 하면 SwiftUICore에 약한 링크(weak link) 를 걸어, 해당 프레임워크가 없는 iOS에서도 크래시 없이 실행 가능하다고 설명.

🔹 글에서 말한 원인

SwiftUICore는 iOS 18부터 존재하는데,
Xcode 16이 앱을 빌드할 때 SwiftUICore가 iOS 17 이하에도 존재한다고 잘못 가정하고,
이 때문에 iOS 17 기기에서 SwiftUICore가 없어서 크래시가 발생한다고 글에서 설명함.
또한 이 현상이 Capacitor를 사용할 때만 재현되고, 순수 Swift 프로젝트에서는 재현되지 않는다고 적어, Capacitor가 문제를 악화시키는 것 같다고 쓰여 있음.

🧩 사례 2 – netural-philipp-gabriel (첫 번째 글 댓글 1)

🔹 문제 상황

“우리는 같은 문제를 겪고 있다”고 명시.
즉, Jaxter2024가 보고한 것과 동일한 크래시를 경험 중이라고 말함.

🔹 문제를 유발한 부분

별도 기술 없음. “같은 문제(same problem)”라고만 언급.

🔹 바꾸니 해결된 것 / 해결책

댓글에서 직접 한 말:
- “워크어라운드 제공한 @Jaxter2017(=2024)에게 감사”
즉, Jaxter가 제시한 weak_framework SwiftUICore 워크어라운드를 사용했다는 의미로 적혀 있음. (댓글 안에서 다른 해결책은 언급하지 않음.)

🔹 글에서 말한 원인

별도로 원인을 설명하지 않고, “이건 진짜 나쁘다(심각하다)” 정도만 언급.

🧩 사례 3 – jcesarmobile (첫 번째 글 댓글 2)

🔹 문제 상황

같은 이슈에 대해 코멘트하면서, 이 문제는 Apple/Xcode 버그라고 말함.

🔹 문제를 유발한 부분

“Capacitor 앱들이 사용하는 것처럼 scheme 이름을 App으로 설정할 때 어떤 네이밍 충돌이 있는 것 같다”고 적음. (scheme = Xcode에서 실행/빌드에 사용되는 스킴 이름.)

🔹 바꾸니 해결된 것 / 해결책

해결책으로 제시한 것:
- Capacitor 문서의 “Renaming your app” 섹션을 따라 스킴 이름을 변경하라고 안내.
  - 링크: https://capacitorjs.com/docs/v5/ios/configuration#renaming-your-app
또 하나의 관찰:
- “이 문제는 디버그 빌드에서만 발생하고, 릴리즈 빌드에서는 앱이 크래시하지 않았다”고 적음.

🔹 글에서 말한 원인

“Apple/Xcode 버그”라고 명시.
구체적으로는 스킴 이름이 App일 때 이름 충돌(name conflict) 이 일어나는 것 같다고 적혀 있음.

🧩 사례 4 – netural-philipp-gabriel (첫 번째 글 댓글 3)

🔹 문제 상황

jcesarmobile에게 재질문:
- “이게 정말 알려진 Apple 버그인가?”
- “이미 피드백이 제출된 상태인가?”

🔹 문제를 유발한 부분 / 해결책 / 원인

별도의 새로운 문제, 해결책, 원인은 제시하지 않음.
단순 질문 댓글.

🧩 사례 5 – mattsbennett (첫 번째 글 댓글 4)

🔹 문제 상황

“이 문제는 우리의 릴리즈 빌드에도 영향을 미쳤다”고 말함.
즉, 어떤 프로젝트에서는 릴리즈 빌드도 크래시했다고 언급.

🔹 문제를 유발한 부분 / 해결책 / 원인

댓글 안에서 구체적인 원인이나 해결책은 언급하지 않음.
“릴리즈 빌드도 영향을 받았다”는 사실만 말함.

🧩 사례 6 – ionitron-bot (첫 번째 글 댓글 5)

🔹 내용 요약

이슈를 잠그고, 최신 Capacitor 버전에서 동일 문제가 있으면 새 이슈를 만들라고 안내하는 봇 메시지.

🔹 문제 상황 / 해결책 / 원인

실제 크래시 사례나 해결책, 원인을 서술하지 않음.
관리용 안내만 있음.

🧩 사례 7 – zer0X (두 번째 글 본문: UIKit/Swift + SwiftUI 혼합 프로젝트)

🔹 문제 상황

대부분 UIKit/Swift 코드 + 일부 SwiftUI가 얹힌 복잡한 프로젝트.
여러 SPM 모듈과 내부 CocoaPods 라이브러리도 링크되어 있음.
Xcode 15에서는 문제 없이 빌드되고, iOS 17.4 시뮬레이터에서 정상 실행.
Xcode 16.0 Beta에서:
- iOS 18 시뮬레이터에서는 정상 실행.
- iOS 17.4 시뮬레이터에서 앱 시작 시 크래시.
크래시 로그:
- Library not loaded: /System/Library/Frameworks/SwiftUICore.framework/SwiftUICore
- SwiftUI_Common.framework에서 SwiftUICore를 참조하려다 실패.
- iOS 17.4 런타임 루트에도 SwiftUICore가 없다는 메시지.

🔹 문제를 유발한 부분

글 작성자는
- “Xcode가 앱을 빌드할 때 SwiftUICore.framework가 디바이스에 있을 것이라고 생각하는 것 같다”
- 그러나 SwiftUICore는 iOS 18에서 새로 생긴 프레임워크라 iOS 17.4에는 없다고 설명.

🔹 바꾸니 해결된 것 / 해결책

이 본문 글에서는 구체적인 해결책을 아직 제시하지 않음.
“어떤 빌드 설정을 확인해야 할지 조언을 구한다”고만 되어 있음.

🔹 글에서 말한 원인

명시적으로:
- “Xcode가 SwiftUICore가 런타임에 존재할 것이라고 잘못 가정하기 때문에, iOS 17.4에는 없어서 크래시가 발생한다”고 추정.
또한 깨끗한 신규 Xcode 16 프로젝트에서는 재현되지 않는다고 밝힘.

🧩 사례 8 – tbaigner (두 번째 글 댓글 1, Aug ’24)

🔹 문제 상황

“우리도 같은 크래시 로그를 가진 유사한 문제를 겪었다”고 말함.

🔹 문제를 유발한 부분

자기 경우 문제의 원인은
- 어떤 모듈 안에서 UIViewControllerRepresentable 구현을 사용한 것이라고 작성.

🔹 바꾸니 해결된 것 / 해결책

해당 코드를 메인 앱 소스 트리로 옮기자 문제는 ‘해결됐다’고 말함.
다만, 코드 분리 관점에서는 바람직하지 않지만, 현재로서는 이 워크어라운드로 버티고 있다고 적음.

🔹 글에서 말한 원인

“우리의 경우 문제의 근원은 모듈에서 사용된 UIViewControllerRepresentable 구현이었다”고 명시.

🧩 사례 9 – tbaigner (두 번째 글 댓글 2, Sep ’24)

🔹 문제 상황

다시 같은 스레드에서 zer0X에게 추가 정보 제공.

🔹 문제를 유발한 부분

“우리 쪽에서 크래시를 일으킨 모듈 이름에 언더스코어(_)가 들어 있었다”고 적음.

🔹 바꾸니 해결된 것 / 해결책

해당 모듈 이름에서 언더스코어를 제거하여 이름을 바꾸자 문제가 해결되었다고 명시.

🔹 글에서 말한 원인

“크래시를 일으킨 모듈 이름에 언더스코어가 있었다”는 점을 원인으로 적고 있음.

🧩 사례 10 – GravityBytes (두 번째 글 댓글, Sep ’24)

🔹 문제 상황

자신의 팀도 같은 문제를 겪었다고 말함.
Xcode 16에서 런타임 ‘library not found’ 에러를 해결하기 위해 여러 모듈 이름을 바꿔야 했다고 설명.

🔹 문제를 유발한 부분

문제가 발생했을 때 모듈 이름:
- UIKit_Core
- SwiftUI_Core
- UI_Charts

🔹 바꾸니 해결된 것 / 해결책

이 모듈들을 다음과 같이 이름 변경:
- UIKit_Core → CoreUIKit
- SwiftUI_Core → CoreSwiftUI
- UI_Charts → ChartsUI
이렇게 바꾸고 나서 “우리 앱은 이제 iOS 17에서 실행된다”고 적음.

🔹 글에서 말한 원인

글 안에서 “원인”을 따로 정의하진 않고,
“이 모듈들을 저렇게 이름 바꾸자 문제가 해결되었다”고만 서술.

🧩 사례 11 – Jaxter2024 (두 번째 글 댓글, Sep ’24)

🔹 문제 상황

tbaigner와 GravityBytes가 말한 언더스코어 관련 워크어라운드는 자신의 경우에는 해당되지 않았다고 밝힘.

🔹 문제를 유발한 부분

구체적인 새 원인은 언급하지 않음.
다만 동일한 SwiftUICore 관련 크래시 케이스라는 전제.

🔹 바꾸니 해결된 것 / 해결책

자신의 경우에는
- 앱 타깃의 Build Settings → Other Linker Flags (OTHER_LDFLAGS) 에
  - weak_framework SwiftUICore 를 추가해야만 문제를 해결했다고 명시.

🔹 글에서 말한 원인

“언더스코어 워크어라운드와 달리, 나의 경우는 weak framework 설정이 필요했다”는 점만 적어 둠.
Capacitor도 사용 중이라고 밝히고, Capacitor에 공식 버그 리포트를 올렸다고 링크로 안내.

🧩 사례 12 – SurendraK11 (두 번째 글 댓글 대댓글 1, Feb 25)

🔹 문제 상황

Jaxter2024가 말한 해결책을 적용하려다 문제를 겪음.
weak_framework SwiftUICore 를 추가하면
- “Unknown argument: '-weak_framework SwiftUICore'”라는 컴파일 에러가 난다고 말함.

🔹 문제를 유발한 부분

Other Linker Flags에 weak_framework SwiftUICore 를 한 줄로 넣은 구성.

🔹 바꾸니 해결된 것 / 해결책

이 첫 번째 댓글에는 아직 해결책이 없음.
“뭐가 빠졌는지 모르겠다”고만 말함.

🔹 글에서 말한 원인

컴파일러가 weak_framework SwiftUICore 를 인식하지 못한 것처럼 보인다는 사실만 언급.

🧩 사례 13 – SurendraK11 (두 번째 글 댓글 대댓글 2, 같은 날)

🔹 문제 상황

위에서 말한 컴파일 에러를 해결했다고 후속 댓글로 알림.

🔹 문제를 유발한 부분

weak_framework SwiftUICore 를 한 줄에 통째로 넣은 방식.

🔹 바꾸니 해결된 것 / 해결책

해결 방법:
- Other Linker Flags에서 명령 전체를 두 줄로 나누어 입력해야 했다고 설명.
  - 1번째 줄: weak_framework
  - 2번째 줄: SwiftUICore
이렇게 나누어 넣으니 weak framework 설정이 성공했다고 말함.

🔹 글에서 말한 원인

“전체 명령을 두 줄로 나누어야 한다”는 점을 깨닫고 해결했다고만 서술.

🧩 사례 14 – Vlad Lytyvnenko (두 번째 글 댓글, Sep ’24)

🔹 문제 상황

자신의 경우에는 앱 타깃 이름이 문제의 원인이었다고 설명.
타깃 이름이 그냥 "App" 이었다고 밝힘.
이 이름 때문에 문제가 발생했고, 타깃 이름을 바꾸자 문제가 해결되었다고 함.
증상: .zIndex(1) modifier를 사용할 때 앱이 크래시했다고 적음.

🔹 문제를 유발한 부분

앱 타깃 이름이 App 인 것.
그리고 .zIndex(1) modifier 사용 시 크래시가 나는 현상이 있었다고 설명.

🔹 바꾸니 해결된 것 / 해결책

앱 타깃 이름을 다른 이름으로 변경하자 문제가 해결되었다고 명시.

🔹 글에서 말한 원인

“이것은 어떤 이름 충돌(name collision)인 것 같다”고 적음.
.zIndex(1) 뿐만 아니라 다른 modifier도 문제를 일으킬 수 있을 것 같다고 덧붙임.

🧩 사례 15 – adrian_dev78 (Vlad 댓글에 대한 대댓글, Sep 24)

🔹 문제 상황

“이게 오늘 나를 살렸다. 우리 문제도 정확히 이것이었다”고 말함.
즉, 같은 문제, 같은 증상.

🔹 문제를 유발한 부분

자신의 프로젝트에서도 타깃 이름이 문제였다고 언급. (Vlad의 케이스와 동일하다고만 말함.)

🔹 바꾸니 해결된 것 / 해결책

그래서 타깃 이름을 변경했고, 그것이 해결책이었다고 말함.

🔹 글에서 말한 원인

“타깃 이름이 문제였고, App이라는 이름이 좋은 접근이라고 생각했는데 놀랍다”고만 언급.

🧩 사례 16 – Khusainova (Vlad 댓글 대댓글, Oct 24)

🔹 문제 상황

“나도 해결됐다! 정말 고맙다”고 말함.
Vlad의 방법을 그대로 쓴 것으로 보인다고 언급.

🔹 문제를 유발한 부분 / 해결책 / 원인

별도로 구체화하지 않고, Vlad의 해결책이 자신에게도 통했다고만 말함.
즉, 앱 타깃 이름 변경이 자신의 문제도 해결했다는 의미.

🧩 사례 17 – sayaleepote (Vlad 댓글 대댓글, Oct 24)

🔹 문제 상황

“이것이 우리 쪽의 해결책이기도 했다. 고맙다”고 말함.

🔹 문제를 유발한 부분 / 해결책 / 원인

역시 Vlad의 방법을 사용했다고만 언급.
구체적으로는, 타깃 이름 변경이 해결책이었다는 의미로 읽힌다.

🧩 사례 18 – ggiri (Vlad 댓글 대댓글, Mar 25)

🔹 문제 상황

“이것이 우리 문제의 해결책이기도 했다. 고맙다”고 말함.

🔹 문제를 유발한 부분 / 해결책 / 원인

동일하게, Vlad가 말한 앱 타깃 이름 변경이 자신들의 문제도 해결했다고만 서술.

🧩 사례 19 – AurelienLajoinie (Vlad 댓글 대댓글, Apr 25)

🔹 문제 상황

“정말 고맙다, Vlad! Xcode 16으로 업그레이드한 후 Capacitor 앱에서 같은 오류가 났다”고 말함.
크래시 원인을 찾기 힘들었다고 덧붙임.

🔹 문제를 유발한 부분 / 해결책 / 원인

구체적인 표현은 없지만, Vlad에게 특별히 감사하고 있으므로 Vlad가 말한 앱 타깃 이름 변경이 자신의 Capacitor 앱에서도 문제를 해결해 줬다는 내용을 밝힘.

🧩 사례 20 – anton-ogarkov (두 번째 글 댓글, Oct ’24)

🔹 문제 상황

“SwiftUI를 사용하는 프레임워크가 있는 모든 모듈형(modular) 프로젝트에서 이 문제가 재현된다”고 말함.
“새 프로젝트에서도 이 문제를 재현할 수 있었다”고 적음.

🔹 문제를 유발한 부분

“SwiftUI를 사용하는 Framework가 있는 모듈형 프로젝트”라는 구조 자체를 문제를 재현시키는 조건으로 적음.

🔹 바꾸니 해결된 것 / 해결책

해결책은 제시하지 않고, “피드백 티켓을 제출했다”고만 밝힘.

🔹 글에서 말한 원인

별도의 원인 분석은 없이, “이 구조에서 재현된다”고만 서술.

🧩 사례 21 – michaelfromtempleton (anton 댓글 대댓글, Oct 24)

🔹 내용

“피드백 티켓 제출 후 업데이트된 내용 있느냐, 나도 같은 문제를 겪고 있다”고 묻는 댓글.

🔹 문제 / 해결책 / 원인

자신의 문제가 동일하다고만 말하고,
별도의 해결책이나 원인 설명은 없음.

🧩 사례 22 – gregios (두 번째 글 댓글, Oct ’24)

🔹 문제 상황

“우리도 같은 문제를 겪고 있다”고 말함.
환경: Xcode 16.0, 앱은 iOS 18과 iOS 16에서는 잘 작동하지만, iOS 17에서만 크래시.

🔹 문제를 유발한 부분

자신의 경우, 문제를 일으킨 프레임워크 이름은 UI.framework 였다고 밝힘.

🔹 바꾸니 해결된 것 / 해결책

UI.framework 의 이름을 CoreUI 로 변경하자 앱이 정상적으로 동작했다고 말함.
또한, 2년 전에 Settings.framework 를 프로젝트에 포함했을 때도 비슷한 문제를 겪었다고 언급.

🔹 글에서 말한 원인

“SwiftUI와 UI 둘 다 프레임워크 이름의 접두사(prefix)가 될 수 없는 것 같다”고 적음.
구체적인 내부 원인은 설명하지 않고, 이름이 문제라고만 서술.

여기에서 말한 모든 문제를 체크

weak_framework말고는 나한테 해당하는 문제는 없었음

weak_framework을 app.json에 아무리 넣어도 빌드 후 ios17환경에서 키면 바로 튕김

Xcode를 직접 열어보기로 결정

EAS prebuild로 ios폴더 생성후 ios폴더 내부 D.xcworkspace를 XCode로 열음

그리고 ios17버전 기기 시뮬레이터로 실행해봄. crashlog와 함께 튕김.(실제 기기랑 같은 오류)

보다시피 app.json에 추가를 했는데도 불구하고 아래 두개가 안들어가있음.

-weak_framework
SwiftUICore

Debug, Release에 각각 넣음

넣고 Xcode에서 ios17버전 기기 시뮬레이터로 실행해봄.

잘 실행됨

이제 내가 해야하는건

Xcode에서 + 버튼 눌러 넣은 것처럼, prebuild 후에도 자동으로 동일하게 Other Linker Flags에 -weak_framework SwiftUICore가 들어가도록 만들어야함

즉: app.json / plugins 설정만으로 Xcode가 동일한 설정을 자동 생성하게 하고 싶은 것.

플러그인 파일을 하나 만듦
빌드된 iOS 앱이 특정 프레임워크를 선택적(weakly)으로 링크하도록 Xcode 프로젝트 설정을 수정하는 역할

const { withXcodeProject } = require('@expo/config-plugins');

const WEAK_FLAG = '-weak_framework';
const FRAMEWORK_NAME = 'SwiftUICore';

function addWeakSwiftUICoreFlag(project) {
  const configurations = project.pbxXCBuildConfigurationSection();

  for (const key in configurations) {
    const cfg = configurations[key];
    if (typeof cfg !== 'object') continue;
    const buildSettings = cfg.buildSettings;
    if (!buildSettings) continue;

    let flags = buildSettings.OTHER_LDFLAGS;

    // 기존에 아무 플래그가 없으면 새로 세팅
    if (!flags) {
      buildSettings.OTHER_LDFLAGS = [WEAK_FLAG, FRAMEWORK_NAME];
      continue;
    }

    // string일 수도 있고 array일 수도 있어서 정규화
    if (typeof flags === 'string') {
      flags = [flags];
    }

    const joined = flags.join(' ');
    // 이미 SwiftUICore 관련 플래그가 있으면 스킵
    if (joined.includes('SwiftUICore')) {
      continue;
    }

    flags.push(WEAK_FLAG, FRAMEWORK_NAME);
    buildSettings.OTHER_LDFLAGS = flags;
  }

  return project;
}

module.exports = function withWeakSwiftUICore(config) {
  return withXcodeProject(config, (config) => {
    config.modResults = addWeakSwiftUICoreFlag(config.modResults);
    return config;
  });
};

app.json을 아래처럼 수정

{
  "expo": {
    "name": "마켓:D",
    "slug": "marketd",
    "version": "1.0.14",
    "orientation": "portrait",
    "scheme": "com.byuckchon.marketd",
    "userInterfaceStyle": "automatic",
    "newArchEnabled": true,
    "icon": "./assets/images/app-icon-512.png",

....

    "plugins": [
      "./plugins/withFirebaseModularPods",
      "./plugins/withWeakSwiftUICore", // 해당 줄 추가
      "expo-router",
      "@react-native-firebase/app",
      "@react-native-firebase/crashlytics",
      [
        "expo-splash-screen",
        {
          "image": "./assets/images/splash-image.png",
          "imageWidth": 300,
          "resizeMode": "contain",
          "backgroundColor": "#ED6D01"
        }
      ],
      [
        "@react-native-seoul/naver-login",
        {
          "urlScheme": "com.byuckchon.marketd"
        }
      ],
....

}