# React Native 0.87 และ SwiftPM ในปี 2026: การ Build iOS สมัยใหม่และคำถามสัมภาษณ์

> คู่มือฉบับสมบูรณ์ React Native 0.87 พร้อมการรองรับ Swift Package Manager สำหรับ build iOS เรียนรู้การย้ายจาก CocoaPods, Strict TypeScript API และคำถามสัมภาษณ์ทางเทคนิค

- Published: 2026-09-03
- Updated: 2026-09-03
- Author: Anthony Fillion-Maillet
- Reading time: 5 min

---

React Native 0.87 ที่เปิดตัวเมื่อวันที่ 11 สิงหาคม 2026 นำการรองรับ Swift Package Manager (SwiftPM) แบบทดลองมาสู่การ build iOS ซึ่งเป็นก้าวแรกสู่การกำจัด CocoaPods ออกจากโปรเจกต์ React Native รุ่นนี้ยังทำให้ Strict TypeScript API เป็นค่าเริ่มต้น รวม Metro 0.87 ที่สร้าง source map เร็วขึ้น 2 เท่า และเพิ่มความต้องการ toolchain ขั้นต่ำเป็น Node.js 22, Kotlin 2.0 และ Android compileSdk 37

> **ตั้งค่า SwiftPM ด้วยคำสั่งเดียว**
>
> หลังจากถอดการติดตั้ง CocoaPods ให้รัน `npx react-native spm --deintegrate` หนึ่งครั้ง โปรเจกต์จะ autolink dependency native ในทุกการ build โดยไม่ต้อง `pod install`

## Swift Package Manager แทนที่ CocoaPods สำหรับ Dependency iOS

การรองรับ SwiftPM ใน React Native 0.87 เป็นแบบ opt-in และทดลอง CocoaPods ยังคงเป็น dependency manager เริ่มต้นสำหรับแอป production เส้นทาง SwiftPM ใช้ XCFramework prebuilt เดียวกันกับที่ React Native เผยแพร่แล้ว จึงไม่ต้องดาวน์โหลด binary เพิ่มเติม

ประโยชน์หลัก: โปรเจกต์ที่ใช้ SwiftPM ต้องการเพียง Xcode Ruby, Bundler และ CocoaPods ไม่จำเป็นบนเครื่อง developer หรือ pipeline CI อีกต่อไป

```bash
# ios-swiftpm-setup.sh
# Step 1: Navigate to iOS directory
cd ios

# Step 2: Deintegrate CocoaPods and generate SwiftPM references
npx react-native spm --deintegrate

# Step 3: Open project in Xcode and build
open MyApp.xcworkspace
```

คำสั่ง `spm --deintegrate` แทรก Swift package reference เข้าไปใน `.xcodeproj` ที่มีอยู่แทนที่จะแทนที่ไฟล์โปรเจกต์ การตั้งค่า code signing, build phases และ capabilities ยังคงไม่เปลี่ยนแปลง หากต้องการย้อนกลับการเปลี่ยนแปลง ให้รัน `npx react-native spm deinit`

## วิธีการทำงานของ SwiftPM Autolinking โดยไม่ต้อง pod install

หลังจากการตั้งค่าเริ่มต้น การเปลี่ยนแปลง dependency จะทริกเกอร์การ relink อัตโนมัติ ติดตั้งหรือลบ native package ด้วย npm หรือ yarn แล้ว build โปรเจกต์ตรวจจับการเปลี่ยนแปลงและรัน autolinking อีกครั้งในระหว่างขั้นตอน build Xcode

```bash
# dependency-workflow.sh
# Install a native dependency
npm install react-native-reanimated

# Build triggers automatic relinking
npx react-native run-ios
# No pod install required
```

สำหรับการ clone ใหม่และสภาพแวดล้อม CI ให้รัน `npx react-native spm` หนึ่งครั้งก่อนการ build ครั้งแรก ซึ่งจะสร้างไฟล์ `Package.swift` และ resolve Swift package dependency

## ข้อจำกัดของ SwiftPM และความพร้อมสำหรับ Production

การรองรับ SwiftPM ในเวอร์ชัน 0.87 มีข้อจำกัดสำคัญที่ส่งผลต่อการตัดสินใจนำไปใช้:

| ข้อจำกัด | ผลกระทบ |
|------------|--------|
| การรองรับ library ชุมชน | แต่ละ library ต้องมีไฟล์ `Package.swift` |
| ความเสถียรของคำสั่ง | Flag และ layout อาจเปลี่ยนใน 0.88+ |
| การกำหนดค่า CI | ต้องมีขั้นตอน `npx react-native spm` ก่อน build |
| เอกสาร | แหล่งข้อมูลการแก้ไขปัญหายังมีจำกัด |

สำหรับแอป production CocoaPods ยังคงเป็นเส้นทางที่แนะนำ ทีมที่ประเมิน SwiftPM ควรสร้าง prototype บน branch แยกและทดสอบ dependency tree ทั้งหมดก่อนตัดสินใจย้าย

## Breaking Change: การ Import Header iOS แบบมี Namespace

React Native 0.87 มี XCFramework ใหม่: `ReactNativeHeaders.xcframework` และ `ReactNativeDependenciesHeaders.xcframework` Native module ที่ใช้ angle include แบบไม่มี namespace ต้องเพิ่ม prefix `React/`

```objective-c
// AppDelegate.m
// Before 0.87 - bare include
#import <RCTAppDelegate.h>
#import <RCTBridge.h>
#import <RCTRootView.h>

// After 0.87 - namespaced include
#import <React/RCTAppDelegate.h>
#import <React/RCTBridge.h>
#import <React/RCTRootView.h>
```

การเปลี่ยนแปลงนี้ใช้กับทั้ง build CocoaPods และ SwiftPM โปรเจกต์ที่มี native module แบบกำหนดเองต้องอัปเดต header import ทั้งหมดก่อนอัปเกรด

## Strict TypeScript API: Interface JavaScript เริ่มต้นใหม่

Strict TypeScript API ที่แสดงตัวอย่างในเวอร์ชัน 0.80 กลายเป็นค่าเริ่มต้นในเวอร์ชัน 0.87 ตอนนี้ type ถูกสร้างโดยตรงจาก source code React Native ซึ่งขจัดความไม่ตรงกันระหว่าง TypeScript definition และพฤติกรรม runtime จริง

```typescript
// component-refs.tsx
import { useRef } from 'react';
import { View, TextInput, ViewInstance, TextInputInstance } from 'react-native';

export function FormComponent() {
  // New dedicated ref types replace generic RefObject<T>
  const containerRef = useRef<ViewInstance>(null);
  const inputRef = useRef<TextInputInstance>(null);

  const focusInput = () => {
    // Type-safe method access
    inputRef.current?.focus();
  };

  return (
    <View ref={containerRef}>
      <TextInput ref={inputRef} placeholder="Email" />
    </View>
  );
}
```

การเปลี่ยนแปลง type ที่ทำให้เกิดข้อผิดพลาดสามประการต้องได้รับความสนใจระหว่างการย้าย:

1. **Deep import ถูกบล็อก**: เส้นทาง `react-native/Libraries/*` ตอนนี้สร้าง type error export ทั้งหมดต้องมาจาก package root `react-native`

2. **อัปเดต ref type**: `ViewInstance` และ `TextInputInstance` แทนที่ generic ref types type alias `*Properties` ถูกลบและแทนที่ด้วย `*Props`

3. **การเปลี่ยนแปลง useColorScheme**: คืนค่า `ColorSchemeName | null` แทนค่า string `'unspecified'` ก่อนหน้า

## การ Opt-Out จาก Strict TypeScript ระหว่างการย้าย

ทีมที่ต้องการเวลามากขึ้นในการย้ายสามารถกู้คืน legacy deep import จนถึง React Native 0.88:

```json
// tsconfig.json
{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "customConditions": ["react-native", "react-native-legacy-deep-imports"]
  }
}
```

ทางหนีนี้จะถูกลบใน React Native 0.89 โปรเจกต์ควรให้ความสำคัญกับการย้ายก่อนรุ่นนั้น

## Metro 0.87: Source Map เร็วขึ้น 2 เท่า และลดหน่วยความจำ 50%

Metro bundler เวอร์ชัน 0.87 มาพร้อมกับการปรับปรุงประสิทธิภาพที่สำคัญซึ่งส่งผลต่อ workflow การพัฒนาและเวลาเริ่มต้น React Native DevTools

การสร้าง source map เร็วขึ้น 2 เท่าเนื่องจากการจัดการ string ที่เหมาะสม DevTools ตอนนี้โหลดเร็วขึ้นเพราะ source map ถูกสร้างอย่างมีประสิทธิภาพมากขึ้นระหว่าง build การพัฒนา

การใช้หน่วยความจำลดลง 50% ผ่านการจัดเก็บ source map ที่มีประสิทธิภาพมากขึ้น ซึ่งสำคัญสำหรับ codebase ขนาดใหญ่ที่ Metro ก่อนหน้านี้ใช้ RAM จำนวนมากระหว่างเซสชันการพัฒนาที่ยาวนาน

การเปลี่ยนแปลง Metro เพิ่มเติม:
- การรองรับที่เสถียรสำหรับไฟล์กำหนดค่า TypeScript (`metro.config.mts`)
- การรองรับไฟล์กำหนดค่า ESM ร่วมกับ CommonJS
- Package self-resolve ใน resolver
- ยกเลิกการรองรับนามสกุลไฟล์ `.es6` และไฟล์กำหนดค่า YAML

## ความต้องการ Toolchain ขั้นต่ำสำหรับ React Native 0.87

รุ่นนี้เพิ่มความต้องการเวอร์ชันขั้นต่ำทั่วทั้ง toolchain Pipeline CI และสภาพแวดล้อม developer ต้องอัปเดตก่อนอัปเกรด

| ความต้องการ | เวอร์ชัน |
|-------------|-------|
| Node.js | >= 22.13.0 |
| Kotlin | >= 2.0 (bundled: 2.2.0) |
| Android minCompileSdk | 34 |
| Android compileSdk | 37 |
| Android Gradle Plugin | 9.x |

สำหรับปัญหาความเข้ากันได้ของ AGP 9 ให้เพิ่ม opt-out ใน `android/gradle.properties`:

```properties
# android/gradle.properties
# Temporary opt-outs for AGP 9 migration
android.builtInKotlin=false
android.newDsl=false
```

## API ที่ถูกลบใน React Native 0.87

API deprecated หลายตัวถูกลบในรุ่นนี้ โปรเจกต์ที่ใช้ API เหล่านี้ต้อง refactor ก่อนอัปเกรด

| API ที่ถูกลบ | ตัวแทน |
|-------------|----------|
| `InteractionManager` | `requestIdleCallback` |
| `Modal` animated prop | ใช้ default transition behavior |
| `NativeMethods` type | `HostInstance` |
| `useTurboModules` flag | เปิดใช้งานตลอด flag ถูกลบ |
| `Touchable` root export | Extend `ViewProps` โดยตรง |
| `react-native/rn-get-polyfills` | `@react-native/js-polyfills` |

Deprecation เพิ่มเติมที่กำหนดเป้าหมายการลบในอนาคตรวมถึง `ImageBackground` (ใช้ `View` กับ `Image` ที่ตำแหน่ง absolute), `DrawerLayoutAndroid` (ใช้ [react-native-drawer-layout](https://github.com/react-navigation/react-navigation/tree/main/packages/drawer)) และ `react-native/Libraries/Core/InitializeCore` (ใช้ `react-native/setup-env`)

## คำถามสัมภาษณ์ React Native 0.87 สำหรับ Developer ระดับสูง

คำถามเหล่านี้ปรากฏในการสัมภาษณ์ mobile developer ระดับสูงหลังจากรุ่นใหญ่ของ React Native การเข้าใจการตัดสินใจด้านสถาปัตยกรรมเบื้องหลังการรองรับ SwiftPM และ Strict TypeScript API แสดงให้เห็นความรู้ระดับ framework

**Q: ทำไม React Native 0.87 ถึงแนะนำ SwiftPM เป็นแบบทดลองแทนที่จะแทนที่ CocoaPods ทันที?**

การรองรับ SwiftPM ขึ้นอยู่กับ library ชุมชนที่มีไฟล์ `Package.swift` ต่างจาก CocoaPods ที่มี registry `Podspec` แบบรวมศูนย์ SwiftPM ต้องการให้ผู้เขียน library แต่ละคนเพิ่มการกำหนดค่า Swift package native ขั้นตอนทดลองอนุญาตให้ระบบนิเวศนำ SwiftPM มาใช้อย่างค่อยเป็นค่อยไปในขณะที่ CocoaPods ยังคงเสถียรสำหรับแอป production นอกจากนี้ คำสั่ง CLI และ layout โปรเจกต์ที่สร้างขึ้นอาจเปลี่ยนแปลงตามข้อเสนอแนะของ developer ก่อนที่จะเสถียร

**Q: ปัญหาอะไรที่ Strict TypeScript API แก้ไขได้ที่ type definition ที่ดูแลด้วยมือไม่สามารถทำได้?**

Type definition ที่ดูแลด้วยมืออาจแตกต่างจากพฤติกรรม runtime ระหว่างรุ่น การ refactor ภายในที่เปลี่ยน function signature หรือเพิ่มพารามิเตอร์อาจไม่สะท้อนใน type ทันที ทำให้เกิด crash runtime ที่ TypeScript ควรจับได้ Strict API สร้าง type โดยตรงจาก source code ทำให้ type มีอำนาจแทนที่จะเป็นเพียงความหวัง มันยังบล็อก deep import ที่เข้าถึง API ภายในที่ไม่เสถียร ป้องกันการแตกหักเมื่อภายในเหล่านั้นเปลี่ยนแปลง

**Q: SwiftPM autolinking แตกต่างจาก CocoaPods autolinking ใน React Native อย่างไร?**

CocoaPods autolinking ทำงานระหว่าง `pod install` ซึ่ง developer ต้องจำที่จะรันหลังจากเปลี่ยน dependency SwiftPM autolinking ทำงานระหว่างขั้นตอน build Xcode โดยอัตโนมัติ ระบบ build ตรวจจับการเปลี่ยนแปลง dependency และสร้าง package manifest ใหม่โดยไม่ต้องแทรกแซงด้วยมือ ซึ่งขจัดแหล่งที่มาทั่วไปของปัญหา "works on my machine" ที่ developer ลืมรัน `pod install` หลังจาก pull การเปลี่ยนแปลง

สำหรับการเตรียมสัมภาษณ์ React Native เพิ่มเติม ดู [native modules deep dive](/technologies/react-native/interview-questions/rn-native-modules) และธนาคารคำถาม [testing strategies](/technologies/react-native/interview-questions/rn-testing)

## กลยุทธ์การอัปเกรดสำหรับโปรเจกต์ React Native 0.87

[React Native Upgrade Helper](https://react-native-community.github.io/upgrade-helper/) สร้าง diff ระหว่าง template โปรเจกต์ปัจจุบันและ 0.87 diff นี้แสดงให้เห็นว่าไฟล์ใดต้องเปลี่ยนแปลง

ให้ความสำคัญกับขั้นตอนการย้ายเหล่านี้:

1. **อัปเดต Node.js เป็น 22.13.0+** และตรวจสอบว่าสภาพแวดล้อม CI ตรงกัน
2. **รัน TypeScript compilation** เพื่อระบุการละเมิด deep import
3. **อัปเดต ref types** จาก generic เป็น dedicated instance types
4. **อัปเดต iOS header import** เป็นรูปแบบที่มี namespace
5. **ทดสอบ native dependency tree ทั้งหมด** ก่อนเปิดใช้งาน SwiftPM

สำหรับโปรเจกต์ Expo React Native 0.87 มีใน `expo@canary` releases โปรเจกต์ Expo production ควรรอรุ่น SDK ที่เสถียร

## ความหมายของการรองรับ SwiftPM 0.87 สำหรับเวลา Build iOS

SwiftPM ขจัด `pod install` ออกจาก workflow การพัฒนา แต่การตั้งค่าโปรเจกต์เริ่มต้นใช้เวลามากขึ้น คำสั่ง `npx react-native spm` resolve Swift package จาก source ซึ่งใช้เวลานานกว่าการดาวน์โหลด binary CocoaPods ที่ build ไว้แล้ว

การ build ครั้งต่อไปได้รับประโยชน์จากการ resolve package แบบ incremental ของ Xcode เฉพาะ package ที่เปลี่ยนแปลงเท่านั้นที่จะถูกดึงใหม่ สำหรับทีมที่มีการเปลี่ยนแปลง dependency บ่อย วิธีการ incremental นี้อาจเร็วกว่ารอบ `pod install` ซ้ำๆ

การเพิ่มประสิทธิภาพ CI แตกต่างกันระหว่างสองวิธี CocoaPods cache ไดเรกทอรี `Pods/` ได้อย่างมีประสิทธิภาพ SwiftPM cache ผ่าน derived data ของ Xcode ซึ่งต้องใช้กลยุทธ์ cache key ที่แตกต่างกัน ทีมที่ย้าย pipeline CI ควรทำ benchmark ทั้งสองวิธีกับชุด dependency เฉพาะของตน

สำหรับเทคนิคการเพิ่มประสิทธิภาพ build iOS ที่เกี่ยวข้อง ดู [คู่มือ React Native New Architecture](/blog/react-native/react-native-new-architecture-hermes-v1-bridgeless) ที่ครอบคลุมลักษณะประสิทธิภาพของ Hermes V1 และ bridgeless mode

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/th/blog/react-native/react-native-087-swiftpm-ios-build-interview-questions