先日、知り合いから「Rork Max と普通の Rork、結局どっちで作ればいいの」と尋ねられました。料金ページを開くと、通常版は月 $25 から、Rork Max は月 $200。8倍の差を前に、その方は手が止まってしまったそうです。
金額だけを並べれば誰でも迷います。けれど判断の起点は価格ではありません。作りたいアプリが Apple のネイティブ機能をどれだけ必要とするか。ここが定まれば、8倍の差は「高い・安い」ではなく「要る・要らない」の問いに変わります。
その問いをいくつかの具体的な判断に分解し、個人開発でアプリを出し続けてきた立場から、どちらを選ぶかの物差しを一緒に組み立ててみます。私自身がアプリを App Store と Google Play に出すたびに突き当たってきた、地に足のついた基準です。
二つのプロダクトが、そもそも何を出力するのか
同じ Rork という名前でも、通常版と Max では生成される成果物が根本的に違います。ここを曖昧にしたまま料金だけ比べると、判断を誤ります。
通常版が出力するのは React Native(Expo) のプロジェクトです。JavaScript / TypeScript で書かれた一つのコードベースから、iOS と Android の両方が同時に立ち上がります。Web の技術に近く、更新も速い。個人開発で「まず二つのストアに出したい」という最短距離には、これが向いています。
Rork Max が出力するのは ネイティブ Swift のプロジェクトです。iPhone だけでなく iPad・Apple Watch・Apple TV・Vision Pro・iMessage まで、Apple のデバイス群に正面から対応します。React Native の橋(ブリッジ)を経由せず、OS の機能を直接叩けるのが最大の違いです。
つまり選択とは「二つのストアへの速さ」と「Apple 世界への深さ」の、どちらを今回の主役に据えるかという設計判断なのです。
決め手は「Apple ネイティブ機能をどれだけ使うか」
私が最初に確かめるのは、作ろうとしているアプリの中心的な体験が、React Native の標準的な部品で成立するかどうかです。
たとえば、記事を並べるリスト、フォーム、簡単なアニメーション、画像の表示、ローカル保存、広告(AdMob 等)やサブスクリプション。これらは React Native の生態系が長年かけて成熟させてきた領域で、通常版で不足を感じることはまずありません。
一方、ロック画面のウィジェット、Dynamic Island、Live Activities、Siri へのショートカット提供、HealthKit や HomeKit との連携、Core NFC、オンデバイスの Core ML 推論、Metal による 3D 描画。この辺りに主役級の機能が来るなら、React Native では回り道が増え、最後は自分でネイティブモジュールを書く羽目になります。それなら最初から Swift を出力する Rork Max のほうが、遠回りせずに済みます。
判断がぐらつくのは「あったら嬉しい」程度の付加機能にネイティブ依存が混じるときです。次の節のフレームは、そのぐらつきを言語化するために使います。
二択を5つの問いに分解する
「どちらが良いか」という漠然とした問いのままでは答えは出ません。私は次の5つの問いに順番に答え、その傾きで決めています。
| 問い | 通常版(React Native)に傾く | Rork Max(Swift)に傾く |
| 1. Android も同時に出すか | 出す(両ストア必須) | 当面 iOS だけでよい |
| 2. 中心機能に Apple 固有 API が要るか | 不要(一般的な UI で足りる) | Widget / Live Activity / HealthKit 等が主役 |
| 3. iPad・Watch・Vision Pro に広げるか | 広げない | デバイス横断が価値になる |
| 4. 月額コストを抑えたいか | 抑えたい($25 で始めたい) | 機能価値が $200 を上回る見込み |
| 5. 将来ネイティブへ移す覚悟があるか | 当面は不要 | どうせ移すなら最初から |
5問のうち3問以上が右に寄れば Rork Max、そうでなければ通常版。これは厳密な計算ではなく、判断の重心を可視化するための粗い天秤です。実際には問い2の重みが最も大きく、ここが「主役級で要る」なら、他が左でも Rork Max を選ぶ価値があります。
コスト構造を、月額と時間の両面で見る
料金だけを見ると通常版の圧勝に見えます。けれど個人開発で本当に効いてくるのは、月額と開発時間の合算です。
| 観点 | 通常版 | Rork Max |
| 月額(有料開始) | $25/月〜 | $200/月 |
| 出力 | React Native / Expo | ネイティブ Swift |
| 同時対応OS | iOS + Android | Apple 各デバイス |
| ネイティブ機能の追加コスト | 自作モジュールの実装時間が上乗せ | ゼロ(標準で扱える) |
| 向く規模 | MVP・二ストア展開 | Apple 前提の作り込み |
損益分岐はこう考えます。もし React Native で Widget や Live Activity を後付けするなら、ネイティブモジュールの調査・実装・審査対応でおそらく数十時間は溶けます。その時間を時給に換算すると、Rork Max の月 $200 は一機能ぶんの外注費より安く付くことも珍しくありません。
逆に、ネイティブ依存がゼロで Android も出すアプリなら、$200 は純粋な無駄です。安さは正義ではなく、要件との一致だけが正義だと私は考えています。
React Native 版で十分なケース
具体例で境界を確かめましょう。ユーザー設定をローカルに保存し、次回起動時に復元する。この程度なら通常版で何の不足もありません。
import AsyncStorage from "@react-native-async-storage/async-storage";
const SETTINGS_KEY = "user_settings_v1";
type Settings = { theme: "light" | "dark"; notify: boolean };
export async function saveSettings(next: Settings): Promise<void> {
// 破損時に全消しになるのを避け、キー単位でなくまとめて1レコードに畳む
await AsyncStorage.setItem(SETTINGS_KEY, JSON.stringify(next));
}
export async function loadSettings(): Promise<Settings> {
const raw = await AsyncStorage.getItem(SETTINGS_KEY);
if (!raw) return { theme: "light", notify: true }; // 初回は既定値
try {
return JSON.parse(raw) as Settings;
} catch {
// 壊れた JSON は握りつぶし、既定へフォールバック(起動を止めない)
return { theme: "light", notify: true };
}
}
このコードで大事なのは、後半の catch です。保存データが壊れていても、アプリの起動そのものは止めない。個人開発では、本番環境のユーザー端末で起きた不具合を手元で再現できないことが多く、「最悪でも既定値に戻って動く」という設計が救いになります。
こうした一般的な永続化・UI・ナビゲーションは React Native の得意分野で、Rork Max を持ち出す理由になりません。
Rork Max でしか届かない境界
では、どこから Swift が要るのか。ロック画面に「今日の残り時間」を出す Live Activity は、その典型です。React Native からは素直に届かず、結局は WidgetKit を Swift で書くことになります。
import ActivityKit
import WidgetKit
import SwiftUI
// Live Activity が保持する動的な状態を宣言する
struct TimerAttributes: ActivityAttributes {
public struct ContentState: Codable, Hashable {
var remaining: TimeInterval // 画面更新のたびに差し替わる値
}
var title: String // セッション中は不変の値
}
struct TimerLiveActivity: Widget {
var body: some WidgetConfiguration {
ActivityConfiguration(for: TimerAttributes.self) { context in
// ロック画面に出る本体
HStack {
Text(context.attributes.title)
Spacer()
Text(timerLabel(context.state.remaining))
.monospacedDigit() // 桁揺れを防ぐ
}
.padding()
} dynamicIsland: { context in
DynamicIsland {
DynamicIslandExpandedRegion(.center) {
Text(timerLabel(context.state.remaining))
}
} compactLeading: {
Image(systemName: "timer")
} compactTrailing: {
Text(timerLabel(context.state.remaining))
} minimal: {
Image(systemName: "timer")
}
}
}
}
func timerLabel(_ t: TimeInterval) -> String {
let m = Int(t) / 60, s = Int(t) % 60
return String(format: "%02d:%02d", m, s)
}
ActivityAttributes が「セッション中に変わらない値」と「更新のたびに差し替わる状態(ContentState)」を分けている点に注目してください。この分離が、Live Activity の更新コストとバッテリー消費を左右します。React Native のブリッジ越しにこの粒度を制御するのは骨が折れ、素直に Swift で書けるほうが結果的に速いのです。
Rork Max はこの Swift を生成する側に立つので、Dynamic Island や Live Activity を「主役」に据えたアプリでは、通常版より段違いに近道になります。
途中で乗り換える現実 — 併存と移行
一度選んだら固定、ではありません。私自身、最初は React Native で軽く出し、反応を見てから作り込む段取りをよく取ります。
現実的な進め方は二つです。ひとつは、通常版で MVP を出して市場の反応を確かめ、ネイティブ機能が明確に要ると分かった時点で Rork Max へ作り直す道。もうひとつは、iOS の作り込みは Rork Max、Android は通常版、とプラットフォームごとに分ける道です。
| 戦略 | 向く状況 | 注意点 |
| 通常版で先行 → 後で Max | 需要が未検証・まず反応を見たい | 作り直しの工数を織り込む |
| iOS=Max / Android=通常版 | iOS に価値が偏るプロダクト | 二重メンテの負担が増える |
| 最初から Max 一本 | Apple 固有機能が中核と確定 | Android を捨てる判断が要る |
乗り換えの工数を恐れて最初から Rork Max を選ぶ、という判断もあり得ます。ただ、需要が未検証の段階で月 $200 を払い続けるのは、個人開発ではそれ自体がリスクです。私は「検証は安く、作り込みは深く」を基本線にしています。
まとめ:次の一手
二択で迷ったら、価格表を閉じて、作りたいアプリの中心にある体験をもう一度書き出してみてください。その体験が Widget や Live Activity、HealthKit のような Apple 固有機能を必要とするなら Rork Max、一般的な UI と二ストア展開で足りるなら通常版。判断の重心はいつもそこにあります。
まず試すなら、無料枠で通常版のプロジェクトを一つ生成し、中心機能を React Native の標準部品だけで組めるか手を動かしてみるのが確実です。組めなければ、それがあなたにとっての「Swift が要る境界」です。私はこの手順で境界を先に確かめてから予算を決めることをお勧めします。
私自身、この物差しに何度も助けられてきました。この記事が、あなたのアプリの最初の一歩を軽くできれば嬉しいです。お読みいただき、ありがとうございました。