React Native で iOS アプリを作るとき、「プロトタイプは動いたのに、本番品質にするのが大変」という壁を感じたことはないでしょうか。
Antigravity を使うと、コードの骨格を素早く作れますが、生成されたコードをそのまま App Store に出せるかというと、もう一手間が必要です。ここではAntigravity を使った React Native iOS アプリの開発を、プロトタイプから本番品質まで引き上げるワークフローを整理します。
プロジェクト設定と Antigravity の活用開始
まず Expo + React Native のプロジェクトを用意します。Antigravity は既存プロジェクトへの追加も可能ですが、新規プロジェクトでは最初からコンテキストを共有するとコード品質が上がります。
# Expo プロジェクトの作成
npx create-expo-app MyApp --template blank-typescript
cd MyApp
# 必要なパッケージの追加
npx expo install expo-router react-native-safe-area-context react-native-screensAntigravity でプロジェクト構造を説明するプロンプトのテンプレートです:
このReact Native + Expo + TypeScriptプロジェクトについて:
- Expo Router を使ったファイルベースルーティング
- React Native Safe Area Context でセーフエリア対応
- Supabase をバックエンドとして使用予定
- iOS 16以上をターゲット
この前提で[機能の説明]を実装してください。
このような前提条件を最初に共有することで、Antigravity が生成するコードが実際のプロジェクト構成に即したものになります。
型安全なコード生成を引き出す
Antigravity が React Native + TypeScript で強みを発揮するのは、型定義を丁寧に指定したときです。
// Antigravity への指示:型定義を先に作ってもらう
// プロンプト例:「商品データの型定義と、それを使ったAPIフック一式を作ってください」
// Antigravity が生成した型定義の例
interface Product {
id: string;
name: string;
price: number;
imageUrl: string;
category: ProductCategory;
inStock: boolean;
}
type ProductCategory = 'electronics' | 'clothing' | 'food' | 'other';
// Antigravity が生成したカスタムフックの例
function useProducts(category?: ProductCategory) {
const [products, setProducts] = useState<Product[]>([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState<Error | null>(null);
useEffect(() => {
const fetchProducts = async () => {
try {
setLoading(true);
const url = category
? `/api/products?category=${category}`
: '/api/products';
const response = await fetch(url);
if (!response.ok) throw new Error('Failed to fetch products');
const data = await response.json();
setProducts(data);
} catch (err) {
setError(err instanceof Error ? err : new Error('Unknown error'));
} finally {
setLoading(false);
}
};
fetchProducts();
}, [category]);
return { products, loading, error };
}型定義を先に作成してもらい、それを参照してフック・コンポーネントを生成する流れは、後から型エラーが大量に出る事態を防げます。
よくある落とし穴と対策
React Native + Antigravity の組み合わせで遭遇しやすいパターンを整理しておきます。
Platform 固有コードの扱い
Antigravity は Platform.OS を適切に使ったコードを生成することが多いですが、iOS 固有の UI 要件(ステータスバーの色、セーフエリアの扱い)については明示的に指定すると精度が上がります。
// iOS 固有の処理を明示して指定する例
// プロンプト:「ヘッダーコンポーネントを作ってください。iOS ではノッチとセーフエリアを考慮し、
// StatusBar は light-content にしてください」
// 生成されたコンポーネント例(エラーハンドリング付き)
import { View, StatusBar, Platform, StyleSheet } from 'react-native';
import { useSafeAreaInsets } from 'react-native-safe-area-context';
interface HeaderProps {
title: string;
backgroundColor?: string;
}
export function Header({ title, backgroundColor = '#007AFF' }: HeaderProps) {
const insets = useSafeAreaInsets();
return (
<View style={[
styles.container,
{
backgroundColor,
paddingTop: Platform.OS === 'ios' ? insets.top : 0
}
]}>
<StatusBar barStyle="light-content" backgroundColor={backgroundColor} />
{/* ヘッダーコンテンツ */}
</View>
);
}
const styles = StyleSheet.create({
container: {
width: '100%',
paddingHorizontal: 16,
paddingBottom: 12,
}
});非同期処理のエラーハンドリング
Antigravity が生成するコードにエラーハンドリングが甘いケースがあります。「エラーハンドリングとローディング状態を必ず含める」という指示を追加すると改善されます。
App Store 提出前のチェックリスト
Antigravity で作成したコードを App Store に提出する前に確認すべきポイントです。
パフォーマンス面
FlatListのkeyExtractorが適切に設定されているか- 不要な再レンダリングが
useCallback/useMemoで防がれているか - 画像の遅延読み込みが実装されているか
アクセシビリティ面
accessibilityLabelがインタラクティブ要素に設定されているか- VoiceOver でのナビゲーションが確認されているか
iOS 固有の要件
- Privacy Manifest(NSPrivacyAccessedAPITypes)が適切に設定されているか
- App Tracking Transparency(ATT)の実装が App Store ガイドラインに準拠しているか
これらのチェックを Antigravity に依頼することもできます。「このコードの App Store 提出前チェックをしてください」というプロンプトで、見落としの指摘を受けられます。
Antigravity の全体的な使い方についてはスタートガイドを、エージェント連携を使ったより高度な自動化についてはAgentKit 2.0 完全ガイドも参考にしてください。
本番品質への最後の一手
Antigravity で生成したコードは「85点の実装」として受け取るのが現実的です。残りの15点 — 細かいパフォーマンスチューニング、アクセシビリティ対応、エッジケースの処理 — は人間のレビューで補完する必要があります。
でも、その85点を即座に手に入れられることの価値は大きいです。ゼロから書くより速く、雛形から始めるより品質が高い。そのバランスをうまく使うことが、Antigravity を実際の開発に組み込むコツだと感じています。