// 이 파일이 하는 일: "iOS 앱의 구조" 코스 — 웹 개발자(React를 배운 눈)로서
// 애플 앱을 이해하는 지도. 애플 생태계 → 앱 구조(UIKit vs SwiftUI) → 뷰 계층
// → 생명주기 → Xcode·시뮬레이터 → 권한·심사 → 안드로이드 차이까지 7개 섹션으로
// 안내하는 정적 학습 페이지. 목표는 "2개월에 앱 전문가"가 아니라 "앱의 지형을
// 읽고, 내가 배운 React 지식을 다리 삼아 앱까지 가는 길을 아는" 수준이다.
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용한다 — 색을 여기서 하드코딩하지 않는다.
// 예제/다이어그램은 JSX 중괄호·백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

import { Link } from 'react-router-dom';

// ── 예제 코드 · 텍스트 다이어그램 상수들 ──

const CODE_ECOSYSTEM = `애플 생태계 = 하드웨어 + OS + 스토어를 한 회사가 '수직 통합'

   Apple 한 회사가 다 만든다               여러 회사가 나눠 만든다 (안드로이드)
 ┌────────────────────────┐          ┌────────────────────────┐
 │  기기   iPhone · iPad   │          │  기기   삼성 · 샤오미 · 구글…  │
 │  OS     iOS            │          │  OS     구글이 만든 안드로이드  │
 │  스토어  App Store 하나  │          │  스토어  Play · 갤럭시 · 기타… │
 │  칩     A · M 시리즈 자체칩 │        │  칩     퀄컴 · 삼성 · 미디어텍…│
 └────────────────────────┘          └────────────────────────┘
   → 조합이 적다 = 통일 · 예측 가능           → 조합이 많다 = 자유 · 파편화

장점: 테스트할 기기가 적고, 사용자 대부분이 최신 OS를 빠르게 올린다.
단점: 애플이 정한 규칙 안에서만 논다 — 맥 필수, 심사 통과 필수, 수수료 존재.`;

const CODE_UIKIT_SWIFTUI = `// 같은 '좋아요 버튼'을 두 방식으로 — React 배운 눈엔 한쪽이 익숙할 거예요

// ① UIKit (명령형) : 옛 DOM 조작과 닮음 — 내가 라벨을 직접 찾아 글자를 바꾼다
class LikeViewController: UIViewController {
    var count = 0
    let label = UILabel()

    @objc func tapped() {
        count += 1
        label.text = "좋아요 \\(count)"   // ← 내가 화면을 '직접' 수정
    }
}

// ② SwiftUI (선언형) : React와 판박이 — 상태만 바꾸면 화면이 알아서 따라온다
struct LikeView: View {
    @State private var count = 0        // React의 useState(0) 과 똑 닮음

    var body: some View {               // return 안의 JSX 자리
        Button("좋아요 \\(count)") {
            count += 1                  // 상태만 갱신 → 화면 자동 재렌더
        }
    }
}

// 핵심: SwiftUI도 결국 "화면 = f(상태)". React에서 외운 그 한 줄이 여기서도 통한다.`;

const CODE_VIEW_BODY = `// SwiftUI 화면 하나 = 뷰들을 '중첩'해 쌓은 트리 (JSX 컴포넌트 조립과 똑같음)
struct ProfileView: View {
    var body: some View {
        VStack {                     // 세로로 쌓는 컨테이너 (= <div>)
            Image("avatar")          //   프로필 사진
            Text("김미림")            //   이름
            HStack {                 //   가로로 쌓는 컨테이너
                Text("3학년")
                Text("프론트엔드")
            }
        }
    }
}

// 화면에 보이는 모든 것이 '뷰(View)'. 뷰가 뷰를 품어 트리가 된다.
// 브라우저의 DOM 트리, React의 컴포넌트 트리 — 이름만 다른 같은 뼈대예요.`;

const CODE_LIFECYCLE = `앱 생명주기 — 앱이 켜지고 · 가려지고 · 잠드는 상태들

  실행 안 됨 ──런치──▶ Active(화면에 떠서 조작 가능)
                          │  ▲
             홈으로 나가거나 │  │ 다시 앱으로 돌아옴
              전화가 걸려옴   ▼  │
                     Background(잠깐 뒤에서 정리) ──▶ Suspended(얼어붙어 대기)

React 훅으로 번역하면:
  화면이 처음 뜸     ≈  useEffect(() => {...}, [])   / SwiftUI  .onAppear
  화면에서 사라짐    ≈  useEffect의 cleanup 함수       / SwiftUI  .onDisappear
  앱이 백그라운드로   ≈  (웹엔 딱 맞는 짝이 없다 — '앱'만의 개념!)

UIKit  : 화면별 콜백 viewDidLoad · viewWillAppear · viewDidDisappear …
SwiftUI: @main App 구조체 + scenePhase (.active / .inactive / .background)`;

const CODE_XCODE = `iOS 앱을 만들려면 실제로 필요한 것 (미화·과장 없이)

 필수      Xcode          애플 공식 IDE — 오직 macOS에서만 돈다
 필수      맥(Mac)        Xcode가 맥 전용이라, 개발용 맥이 사실상 필수
 포함      시뮬레이터       맥 위에 iPhone 화면을 띄워 테스트
                         (카메라·GPS 등 일부 하드웨어는 실기기에서만 확인)
 무료      내 기기 테스트    애플 ID만 있으면 내 아이폰에 직접 설치 가능(7일마다 갱신)
 연 $99    개발자 프로그램   App Store에 '출시'하려면 유료 멤버십 필요

현실 체크
  · 윈도우 / 리눅스만으로는 공식 빌드가 안 된다. 회사 PC가 윈도우라면
    클라우드 맥(예: CI의 macOS 러너)을 빌려 빌드하는 우회로가 있다.
  · 우리 회사 제품은 React + Spring Boot '웹'이라 지금 iOS 네이티브를 직접
    만들진 않는다. 이 코스는 '앱의 지형을 읽는 지도'이지 출시 매뉴얼이 아니다.`;

const CODE_PERMISSIONS = `권한 — iOS는 '필요한 바로 그 순간'에 사용자에게 직접 묻는다

① Info.plist에 '왜 필요한지' 이유 문구를 미리 적어 둔다 (안 적으면 앱이 그냥 죽음)
     <key>NSCameraUsageDescription</key>
     <string>과제 사진을 찍어 올리려고 카메라를 사용합니다</string>

② 코드가 카메라를 '처음' 쓰는 순간, 시스템이 팝업을 띄운다
     ┌──────────────────────────────┐
     │  '미림앱'이 카메라 접근을 요청합니다 │
     │       [ 허용 안 함 ]   [ 허용 ]    │   ← 결정권은 100% 사용자
     └──────────────────────────────┘

③ 거부해도 앱은 그 기능 없이 동작하도록 만들어야 한다 (강요 불가)

특별 케이스: iOS 14.5+의 앱 추적 투명성(ATT) — 다른 앱·웹까지 추적하려면
반드시 별도 동의를 받아야 한다. '프라이버시'는 애플의 핵심 마케팅 포인트다.`;

const CODE_ANDROID_DIFF = `iOS vs 안드로이드 — 한눈 비교표

                iOS                          안드로이드
 언어           Swift (구: Objective-C)       Kotlin (구: Java)
 UI 툴킷        SwiftUI / UIKit               Jetpack Compose / XML 레이아웃
 IDE           Xcode (맥 전용)               Android Studio (윈도우·맥·리눅스)
 스토어         App Store 하나 · 심사 엄격      Play + 갤럭시 등 여러 곳 · APK 설치 가능
 개발자 등록     연 $99                        $25 1회
 기기           애플 소수 모델(통일)           제조사 수백 종(파편화)
 OS 업데이트     사용자 대부분 빠르게 최신으로     버전이 오래 갈라져 공존
 파일 접근       강한 샌드박스(밖에서 안 보임)    상대적으로 개방적

공통점: '화면 = 뷰의 트리', '생명주기', '런타임 권한 요청'이라는 뼈대는 같다.
한쪽을 제대로 이해하면 다른 쪽은 '방언'을 배우는 수준이다.`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용.
function Section({ n, title, sub, children }) {
  return (
    <section className="step-card" id={`sec-${n}`}>
      <div className="step-head">
        <span className="step-num">{n}</span>
        <div>
          <h3>{title}</h3>
          {sub && <span className="step-sub">{sub}</span>}
        </div>
      </div>
      <div className="step-body">{children}</div>
    </section>
  );
}

function Code({ children }) {
  return <pre className="code-block"><code>{children}</code></pre>;
}

const SECTIONS = [
  { n: 1, label: '애플 생태계' },
  { n: 2, label: 'UIKit vs SwiftUI' },
  { n: 3, label: '뷰 계층' },
  { n: 4, label: '생명주기' },
  { n: 5, label: 'Xcode·시뮬레이터' },
  { n: 6, label: '권한과 심사' },
  { n: 7, label: '안드로이드와 차이' },
];

export default function IosBasicsPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 어디서 출발해 어디까지 가는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 앱 개발</div>
        <h1>iOS 앱의 구조<br />— 웹 개발자의 눈으로 보는 애플 앱</h1>
        <p>
          우리 플랫폼은 React 웹앱이지만, 그 옆엔 늘 '앱'이라는 큰 세계가 있어요.
          이 코스는 <strong>여러분이 배운 React 지식을 다리 삼아</strong> iOS 앱의 뼈대를
          읽는 지도입니다. "2개월에 앱 전문가"가 목표가 아니라,{' '}
          <strong>지형을 읽고 내 실력으로 앱까지 가는 길을 아는 것</strong>이 목표예요.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 70분</span>
          <span className="chip">실습: 개념 확인 위주</span>
          <span className="chip">선수 지식: React 입문</span>
        </div>
      </div>

      {/* 섹션 바로가기 */}
      <nav className="pill-nav">
        {SECTIONS.map((s) => (
          <a key={s.n} href={`#sec-${s.n}`}>
            <b>{s.n}</b>
            {s.label}
          </a>
        ))}
      </nav>

      <Section n={1} title="애플 생태계" sub="한 회사가 다 만든다 — 그 통일의 빛과 그림자">
        <p>
          iOS 앱을 이해하려면 먼저 <strong>애플이라는 회사의 성격</strong>부터 알아야 해요.
          애플은 <strong>기기(iPhone)·운영체제(iOS)·앱 스토어·심지어 칩까지 한 회사가
          직접 만듭니다.</strong> 이걸 '수직 통합' 또는 '담장 친 정원(walled garden)'이라고
          불러요. 반대로 안드로이드는 구글이 OS를 만들고, 기기는 삼성·샤오미 등 수많은
          회사가 제각각 만들죠.
        </p>
        <Code>{CODE_ECOSYSTEM}</Code>
        <p>
          이 '폐쇄성'은 장점이자 단점이에요. <strong>기기 종류가 적으니</strong> 개발자는
          테스트할 화면 크기가 몇 개 안 되고, 사용자들도 새 iOS가 나오면 대부분 금방
          업데이트합니다. 반대로 <strong>애플이 정한 규칙 밖으로는 나갈 수 없어요</strong> —
          개발에 맥이 필요하고, 앱을 올리려면 애플의 심사를 통과해야 하며, 스토어 결제엔
          수수료가 붙습니다. 뒤 섹션에서 이 '규칙들'을 하나씩 만나게 돼요.
        </p>
        <div className="tip">
          <b>왜 이게 중요할까</b> "iPhone은 종류가 몇 개 없다"는 사실 하나가 개발 경험 전체를
          바꿔요. 안드로이드 개발자가 수백 종 기기의 파편화와 싸울 때, iOS 개발자는 통일된
          소수 모델만 챙기면 됩니다. 편함과 자유를 맞바꾼 셈이죠.
        </div>
      </Section>

      <Section n={2} title="앱의 구조 — UIKit vs SwiftUI" sub="명령형 옛 방식 vs 선언형 새 방식(= React를 닮은 쪽)">
        <p>
          iOS 앱은 <strong>Swift</strong>라는 언어로 만들고(예전엔 Objective-C), 화면을 그리는
          도구(UI 프레임워크)는 크게 두 가지가 공존해요. 오래된{' '}
          <span className="icode">UIKit</span>(2008~)과 새로운{' '}
          <span className="icode">SwiftUI</span>(2019~, iOS 13+)입니다. 둘의 차이는 여러분이
          React 코스에서 이미 배운 그 대비 — <strong>명령형 vs 선언형</strong> — 과 정확히
          같아요.
        </p>
        <Code>{CODE_UIKIT_SWIFTUI}</Code>
        <p>
          왼쪽 <span className="icode">UIKit</span>은 "내가 라벨을 찾아서 글자를 직접 바꾼다" —
          옛날 자바스크립트로 DOM을 손수 조작하던 방식과 똑같아요. 오른쪽{' '}
          <span className="icode">SwiftUI</span>는 <span className="icode">@State</span>로 상태를
          두고, <strong>상태만 바꾸면 화면이 알아서 다시 그려집니다</strong>. React의{' '}
          <span className="icode">useState</span>와 "화면 = 상태의 함수"가 그대로 재현되죠.
        </p>
        <div className="tip">
          <b>React를 배운 게 헛되지 않다</b> SwiftUI의 <span className="icode">@State</span> ≈
          React의 <span className="icode">useState</span>, <span className="icode">body</span> ≈
          컴포넌트의 <span className="icode">return</span>, 뷰 중첩 ≈ JSX 조립. 문법(Swift)만
          새로 익히면, <strong>사고방식은 이미 여러분 머릿속에 있어요.</strong> 새 앱은 대개
          SwiftUI로 시작하고, 기존 대형 앱엔 UIKit이 여전히 많다는 것만 기억해 두세요.
        </div>
      </Section>

      <Section n={3} title="화면과 뷰 — 뷰 계층" sub="화면 위 모든 것은 '뷰', 뷰는 트리로 쌓인다">
        <p>
          iOS에서 <strong>화면에 보이는 모든 것은 '뷰(View)'</strong>예요. 버튼도 뷰, 글자도
          뷰, 사진도 뷰, 그리고 그것들을 담는 상자도 뷰입니다. 뷰가 뷰를 품고, 그 뷰가 또
          다른 뷰를 품으면서 <strong>트리(나무) 구조</strong>가 만들어져요. 이걸{' '}
          <strong>뷰 계층(view hierarchy)</strong>이라고 부릅니다.
        </p>
        <Code>{CODE_VIEW_BODY}</Code>
        <p>
          이 그림이 낯설지 않을 거예요. 브라우저의 <strong>DOM 트리</strong>, React의{' '}
          <strong>컴포넌트 트리</strong> — 전부 "부모가 자식을 품는 트리"라는 같은 뼈대입니다.
          한 화면은 보통 하나의 <strong>뷰 컨트롤러(UIViewController)</strong>가 관리하고, 그
          컨트롤러가 뿌리 뷰를, 뿌리 뷰가 자식 뷰들을 거느리는 구조예요.
        </p>
        <svg className="diagram" viewBox="0 0 640 380" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="iOS 뷰 계층 트리: 기기 화면인 Window 아래에 화면 한 장을 담당하는 ViewController, 그 아래 뿌리 View, 다시 VStack과 Image로 갈라지고 VStack 아래에 Text와 Button 잎 뷰가 달린 나무 구조. 브라우저 DOM 트리와 같은 뼈대임을 보여준다">
          <line x1="320" y1="54" x2="320" y2="86" stroke="var(--line)" strokeWidth="2" />
          <line x1="320" y1="124" x2="320" y2="156" stroke="var(--line)" strokeWidth="2" />
          <line x1="320" y1="194" x2="185" y2="230" stroke="var(--line)" strokeWidth="2" />
          <line x1="320" y1="194" x2="455" y2="230" stroke="var(--line)" strokeWidth="2" />
          <line x1="185" y1="268" x2="120" y2="308" stroke="var(--line)" strokeWidth="2" />
          <line x1="185" y1="268" x2="250" y2="308" stroke="var(--line)" strokeWidth="2" />
          <rect x="260" y="16" width="120" height="38" rx="8" fill="var(--card)" stroke="var(--primary)" strokeWidth="2" />
          <text x="320" y="40" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">Window</text>
          <rect x="232" y="86" width="176" height="38" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="320" y="110" textAnchor="middle" fontSize="13" fill="var(--ink)">UIViewController</text>
          <rect x="250" y="156" width="140" height="38" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="320" y="180" textAnchor="middle" fontSize="13" fill="var(--ink)">root View</text>
          <rect x="115" y="230" width="140" height="38" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="185" y="254" textAnchor="middle" fontSize="13" fill="var(--ink)">VStack (상자)</text>
          <rect x="385" y="230" width="140" height="38" rx="8" fill="var(--card)" stroke="var(--teal)" />
          <text x="455" y="254" textAnchor="middle" fontSize="13" fill="var(--ink)">Image</text>
          <rect x="70" y="308" width="100" height="36" rx="8" fill="var(--card)" stroke="var(--teal)" />
          <text x="120" y="331" textAnchor="middle" fontSize="13" fill="var(--ink)">Text</text>
          <rect x="195" y="308" width="110" height="36" rx="8" fill="var(--card)" stroke="var(--teal)" />
          <text x="250" y="331" textAnchor="middle" fontSize="13" fill="var(--ink)">Button</text>
          <line x1="600" y1="44" x2="600" y2="326" stroke="var(--primary)" strokeWidth="2" strokeDasharray="5 4" />
          <path d="M600 338 L593 324 L607 324 Z" fill="var(--primary)" />
          <text x="600" y="32" textAnchor="middle" fontSize="13" fontWeight="600" fill="var(--primary)">부모</text>
          <text x="608" y="200" textAnchor="start" fontSize="12" fill="var(--muted)">품는</text>
          <text x="608" y="218" textAnchor="start" fontSize="12" fill="var(--muted)">방향</text>
          <text x="590" y="352" textAnchor="end" fontSize="12" fill="var(--muted)">자식</text>
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: iOS 뷰 계층 트리 — 화면 전체(Window)에서 잎 뷰(Text·Button)까지, 브라우저 DOM 트리와 똑같은 '부모가 자식을 품는' 뼈대</p>
        <div className="tip">
          <b>연결해서 기억하기</b> React 입문에서 본 컴포넌트 트리 다이어그램을 떠올려 보세요.
          <span className="icode">&lt;App&gt; → &lt;Layout&gt; → &lt;Card&gt; → &lt;Badge&gt;</span>{' '}
          와 위 그림의 <span className="icode">Window → View → VStack → Text</span>는 이름만
          다른 쌍둥이예요. 트리를 읽는 눈을 한 번 기르면, 웹이든 앱이든 화면 구조가 보입니다.
        </div>
      </Section>

      <Section n={4} title="앱·뷰 생명주기" sub="켜지고·가려지고·잠드는 순간마다 불리는 콜백">
        <p>
          웹 페이지는 대개 "열려 있거나 닫혀 있거나" 둘 중 하나예요. 그런데 앱은 상태가 더
          많아요. 화면에 <strong>떠 있고(Active)</strong>, 홈으로 나가면{' '}
          <strong>뒤로 가려지고(Background)</strong>, 한참 안 쓰면 시스템이{' '}
          <strong>얼려 버리기도(Suspended)</strong> 하죠. 이 상태 변화의 순간마다 iOS가
          "지금 이런 일이 일어났어!" 하고 우리 코드의 특정 함수를 불러 줘요. 이걸{' '}
          <strong>생명주기(lifecycle)</strong>라고 합니다.
        </p>
        <Code>{CODE_LIFECYCLE}</Code>
        <p>
          여기서도 React 지식이 다리가 돼요. 화면이 처음 뜰 때 하는 일은{' '}
          <span className="icode">useEffect(..., [])</span>와, 화면이 사라질 때 정리하는 일은
          그 <strong>cleanup 함수</strong>와 짝이 맞아요. SwiftUI에선 각각{' '}
          <span className="icode">.onAppear</span>·<span className="icode">.onDisappear</span>{' '}
          라는 이름으로 부릅니다. 다만 <strong>"앱이 백그라운드로 갔다"</strong> 같은 상태는
          웹엔 딱 맞는 짝이 없는 '앱만의 개념'이에요.
        </p>
        <div className="warn">
          <b>생명주기를 무시하면</b> 백그라운드로 간 앱에서 음악·위치추적·타이머를 계속
          돌리면 배터리를 잡아먹고, iOS가 앱을 강제로 잠재우거나 종료시킬 수 있어요. "화면이
          사라질 때 멈추고, 돌아올 때 다시 시작한다"를 챙기는 게 앱 개발의 기본기입니다 —
          React에서 cleanup으로 타이머를 정리하던 습관과 똑같아요.
        </div>
      </Section>

      <Section n={5} title="Xcode와 시뮬레이터" sub="iOS 개발에 맥이 필요한 현실">
        <p>
          이제 가장 현실적인 벽 이야기예요. iOS 앱을 만들려면 애플의 공식 개발 도구{' '}
          <strong>Xcode</strong>가 필요한데, <strong>Xcode는 오직 macOS에서만 돌아갑니다.</strong>{' '}
          즉 <strong>개발용 맥이 사실상 필수</strong>예요. Xcode 안에는 코드 편집기·컴파일러와
          함께 <strong>시뮬레이터(Simulator)</strong>가 들어 있어, 맥 화면 위에 iPhone을 띄워
          앱을 바로 테스트할 수 있습니다.
        </p>
        <Code>{CODE_XCODE}</Code>
        <p>
          시뮬레이터는 빠르고 편하지만 <strong>진짜 기기는 아니에요.</strong> 카메라·GPS·가속도
          센서·푸시 알림처럼 하드웨어가 걸린 기능은 결국 실제 아이폰에서 확인해야 합니다.
          내 아이폰에 설치해 보는 건 애플 ID만 있으면 무료지만(7일마다 다시 설치),{' '}
          <strong>App Store에 정식 출시</strong>하려면 연 $99의 개발자 프로그램이 필요해요.
        </p>
        <div className="warn">
          <b>윈도우만으론 공식 빌드가 안 된다</b> 이건 취향이 아니라 애플의 정책이에요. 회사
          PC가 윈도우라면 <strong>클라우드 맥</strong>(예: CI의 macOS 러너)을 빌려 빌드하는
          우회로가 있습니다. "맥이 없으면 iOS는 시작도 못 하나?"의 답은 "정석은 맥, 우회로는
          클라우드"입니다.
        </div>
        <div className="tip">
          <b>솔직하게</b> 우리 회사 제품은 React + Spring Boot <strong>웹</strong>이라 지금
          iOS 네이티브 앱을 직접 만들진 않아요. 그러니 이 섹션은 "당장 맥을 사라"가 아니라,
          앱 개발의 진입 장벽이 어디에 있는지 <strong>지형을 파악</strong>하는 것으로 충분합니다.
        </div>
      </Section>

      <Section n={6} title="권한과 앱 심사 문화" sub="사용자에게 묻고, 애플에게 검사받는다">
        <p>
          iOS의 성격을 가장 잘 보여주는 두 가지가 <strong>권한(permission)</strong>과{' '}
          <strong>앱 심사(review)</strong>예요. 먼저 권한. iOS는 카메라·사진·위치·마이크·연락처
          같은 민감한 자원을 <strong>앱이 실제로 쓰려는 그 순간, 사용자에게 직접 물어봅니다.</strong>{' '}
          그리고 앱은 <span className="icode">Info.plist</span>에 <strong>"왜 이게 필요한지"</strong>{' '}
          이유 문구를 미리 적어 둬야 해요 — 안 적으면 앱이 그 자리에서 꺼져 버립니다.
        </p>
        <Code>{CODE_PERMISSIONS}</Code>
        <p>
          두 번째는 <strong>심사 문화</strong>예요. 안드로이드가 상대적으로 자동 검사에 기대는
          것과 달리, App Store는 <strong>사람이 직접 앱을 검토</strong>합니다. 개인정보 처리,
          디지털 상품의 인앱 결제 규정, 오해를 부르는 설명, 비공개 API 사용 등에서 걸리면
          <strong>가차 없이 반려(reject)</strong>돼요. 통과에 보통 하루이틀이 걸리고, 규칙이
          까다로운 만큼 스토어의 품질·안전 신뢰도가 높다는 게 애플의 논리입니다.
        </p>
        <div className="warn">
          <b>이유 문구 누락 = 즉시 크래시</b> <span className="icode">NSCameraUsageDescription</span>{' '}
          같은 문구 없이 카메라를 켜면 앱이 바로 죽어요. iOS의 규칙은 "권한은 사용자 것이고,
          앱은 이유를 밝혀야 한다"입니다. 사용자가 거부해도 앱은 그 기능 없이 굴러가도록
          만들어야 하고요.
        </div>
        <div className="tip">
          <b>우리 보안 코스와 이어진다</b> "필요한 최소한만, 이유를 밝히고 요청한다"는 iOS의
          권한 철학은 우리{' '}
          <Link to="/learn/firewall"><strong>방화벽·보안</strong></Link> 코스에서 배운{' '}
          <strong>최소 권한 원칙</strong>과 정확히 같은 사고방식이에요. 플랫폼만 다를 뿐,
          "함부로 열지 않는다"는 원칙은 웹·서버·앱 어디서나 통합니다.
        </div>
      </Section>

      <Section n={7} title="안드로이드와 다른 점 정리" sub="언어·IDE·스토어·기기 — 그리고 똑같은 뼈대">
        <p>
          마지막으로 지금까지의 조각을 안드로이드와 나란히 놓고 정리해 봅시다. 표를 보면
          "다른 점"이 잔뜩 보이지만, <strong>정말 중요한 건 맨 아래 한 줄</strong>이에요 —
          <strong>뼈대는 같다.</strong>
        </p>
        <Code>{CODE_ANDROID_DIFF}</Code>
        <p>
          언어(Swift vs Kotlin), 도구(Xcode vs Android Studio), 스토어 정책은 서로 다릅니다.
          하지만 <strong>"화면은 뷰의 트리다", "화면엔 생명주기가 있다", "권한은 실행 중에
          사용자에게 묻는다"</strong>는 근본 개념은 양쪽이 똑같아요. 심지어 안드로이드의
          최신 UI 도구 <span className="icode">Jetpack Compose</span>는 SwiftUI·React처럼{' '}
          <strong>선언형</strong>입니다. 결국 세 세계가 같은 방향으로 수렴하고 있는 거죠.
        </p>
        <div className="tip">
          <b>지도를 다 읽었다면</b> 한쪽 플랫폼을 제대로 이해하면 다른 쪽은 '방언'을 배우는
          수준이에요. 그리고 여러분은 이미 React로 <strong>선언형 UI라는 표준어</strong>를
          익혔습니다. iOS든 안드로이드든, 남은 건 각 지역의 사투리(문법)를 얹는 일이에요.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🍎 여기까지 왔다면</h3>
          <p className="muted">
            이제 iOS 앱을 이루는 단어들 — 애플 생태계·UIKit/SwiftUI·뷰 계층·생명주기·Xcode·권한·심사
            — 을 <strong>여러분이 배운 React 언어로 설명</strong>할 수 있게 됐어요. 화면은 뷰의
            트리이고, 상태가 바뀌면 다시 그려지며, 권한은 최소한만 이유를 밝혀 요청한다는 것.
            지도를 다 읽었으니, 다음은 이 땅에서 쓰는 실제 언어 차례예요 —{' '}
            <Link to="/learn/swift-intro"><strong>Swift 입문</strong></Link> 코스에서 SwiftUI를
            움직이는 문법을, 여러분이 아는 JavaScript와 나란히 놓고 익혀 봅시다.
          </p>
        </div>
      </div>
    </div>
  );
}
