⬡ 開発ツール/2026-05-17上級

Rork Max の SwiftUI 機能を壁紙アプリ開発で検証した結果 — 実際に動いた機能と手を入れた機能

運用中の壁紙アプリの本番コードを基準に、Rork Max の SwiftUI ネイティブ生成を検証しました。そのまま使えた機能、手を入れた機能、生成を諦めた機能を、動くコードと実機での計測値とともにお伝えします。

Rork Max²³³ SwiftUI⁶⁴ ネイティブアプリ²⁰ 壁紙アプリ²⁷ 個人開発¹⁹⁵ iOS開発¹⁵ 検証レポート

✦ プレミアム記事

Rork Max の SwiftUI ネイティブ生成機能を使い始めて、最初に感じたのは「ここまで動くのか」という驚きでした。次に感じたのは「ここから先は手を入れないといけない」という現実でした。

手元で今も運営している壁紙・ヒーリング系の iOS アプリ4本は、UIKit から SwiftUI への部分移行、AdMob メディエーション、StoreKit 2 対応を、実際のユーザーが触る環境で通してきたコードです。個人開発なので、どの判断がどこで裏目に出たかも全部自分の記憶に残っています。今回の検証で頼れるのは、この「答え合わせ用のコードが既に手元にある」という一点だけでした。

その経験をベースに、Rork Max の SwiftUI 生成が「実際の本番開発」の文脈でどこまで使えるのかを検証しました。比較軸は単純です。私が実際に動かしているアプリに存在する機能を、Rork Max に同じ要件で作らせてみた、ということです。

検証の前提条件と環境

検証に使ったのは次の環境です。Rork Max は2026年5月時点の最新バージョン、Xcode 16.3（macOS Sequoia）、iPhone 16 Pro の実機と iOS シミュレータ（iOS 18.3）を組み合わせて使いました。対象の機能は Beautiful HD Wallpapers の主要UI群です。

Beautiful HD Wallpapers は2013年にリリースして以来、継続的にアップデートを続けているアプリで、2026年5月に v2.1.0 をリリースしたばかりです。このアップデートでは、v2.0.0 リリース後に顕在化した RecyclerView の IndexOutOfBoundsException（28日間で50ユーザー以上に影響）、Glide 5.0.5 + AGP 9.x 環境での Java 8 Supplier の NoClassDefFoundError（Android 6.0.1 ユーザー全員のクラッシュの原因）といった問題を修正しました。いずれも実運用でしか遭遇しないタイプのバグです。

iOSアプリ側は SwiftUI と UIKit の混在構成で動いています。Rork Max の SwiftUI 生成がどこまでこの「実際の複雑さ」に近づけるのかを確認することが目的でした。

「そのまま使えた」機能 — 生成コードの完成度が高かったケース

壁紙グリッドレイアウト（LazyVGrid）

壁紙一覧を表示する LazyVGrid は、生成クオリティが最も高かった機能の一つです。要件として渡したのは「3カラムのグリッド、各セルは正方形で角丸あり、タップでフルスクリーン遷移、無限スクロールで追加ロード」というシンプルな説明でした。

Rork Max が出力したコードの骨格はほぼ以下の形でした。

struct WallpaperGridView: View {
    @StateObject private var viewModel = WallpaperViewModel()
    let columns = [GridItem(.flexible()), GridItem(.flexible()), GridItem(.flexible())]
 
    var body: some View {
        ScrollView {
            LazyVGrid(columns: columns, spacing: 4) {
                ForEach(viewModel.wallpapers) { wallpaper in
                    WallpaperCell(wallpaper: wallpaper)
                        .onAppear { viewModel.loadMoreIfNeeded(current: wallpaper) }
                }
            }
            .padding(4)
        }
        .onAppear { viewModel.fetchWallpapers() }
    }
}
 
struct WallpaperCell: View {
    let wallpaper: Wallpaper
    @State private var showDetail = false
 
    var body: some View {
        AsyncImage(url: URL(string: wallpaper.thumbnailURL)) { image in
            image.resizable().aspectRatio(1, contentMode: .fill)
        } placeholder: {
            Color.gray.opacity(0.3)
        }
        .clipShape(RoundedRectangle(cornerRadius: 8))
        .onTapGesture { showDetail = true }
        .fullScreenCover(isPresented: $showDetail) {
            WallpaperDetailView(wallpaper: wallpaper)
        }
    }
}

この構造は私が実際に使っているコードに非常に近い形です。onAppear ベースのページネーションも正しいアプローチで実装されていました。実際の本番コードとの主な差異は ViewModel の細部（ページネーションのオフセット管理、エラーハンドリング）でしたが、これは要件として渡していない部分なので当然です。UIの骨格は正確に出てきました。

フルスクリーン壁紙プレビュー（ピンチズーム付き）

壁紙アプリの核となるフルスクリーンプレビューも、精度が高かった機能の一つです。ピンチズームと壁紙設定ボタン群まで含めて、実用できるレベルのコードが生成されました。

struct WallpaperDetailView: View {
    let wallpaper: Wallpaper
    @State private var scale: CGFloat = 1.0
    @State private var lastScale: CGFloat = 1.0
    @Environment(\.dismiss) private var dismiss
 
    var body: some View {
        ZStack(alignment: .topTrailing) {
            GeometryReader { geometry in
                AsyncImage(url: URL(string: wallpaper.fullURL)) { image in
                    image
                        .resizable()
                        .aspectRatio(contentMode: .fit)
                        .frame(maxWidth: .infinity, maxHeight: .infinity)
                        .scaleEffect(scale)
                        .gesture(
                            MagnificationGesture()
                                .onChanged { value in scale = lastScale * value }
                                .onEnded { value in
                                    lastScale = scale
                                    if scale < 1.0 { scale = 1.0; lastScale = 1.0 }
                                    if scale > 5.0 { scale = 5.0; lastScale = 5.0 }
                                }
                        )
                } placeholder: {
                    ProgressView().frame(maxWidth: .infinity, maxHeight: .infinity)
                }
            }
            .ignoresSafeArea()
            .background(Color.black)
 
            Button(action: { dismiss() }) {
                Image(systemName: "xmark.circle.fill")
                    .font(.title)
                    .foregroundColor(.white)
                    .padding()
            }
        }
    }
}

スケール制限（1.0〜5.0）は仕様に含めていなかったにもかかわらず、自動的に生成されていました。「壁紙アプリのフルスクリーンビューア」という文脈から適切な設計を推論していることがわかります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Rork MaxのSwiftUI生成が実際の本番コードとどう違うのか、壁紙アプリ開発の実体験から具体的に把握できる

✦「そのまま使える機能」と「手を加えないと動かない機能」の見分け方と、手直しの優先順位がわかる

✦生成コードをそのまま本番データに向けるとメモリで破綻する箇所と、デコード段のダウンサンプリング＋上限付きキャッシュで回避する実装が手に入る

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

「手を入れた」機能 — 生成後に修正が必要だったケース

カテゴリ別タブと画面遷移

Beautiful HD Wallpapers では「Nature」「Architecture」「Abstract」などカテゴリ別に壁紙を分けて表示する構造になっています。これをRork Maxに生成させたところ、TabView ベースの実装が返ってきました。

TabView 自体は正しいアプローチですが、私のアプリでは TabView を使っていません。理由は、TabView の場合は全タブのビューが初期化時にメモリ上に展開されてしまうからです。壁紙アプリのように高解像度画像を大量に扱う場合、この差は無視できません。実際に TabView で組んでいた初期バージョンでは、カテゴリが6つ以上になった段階でメモリ警告が頻発するようになり、カスタムタブ実装に切り替えた経緯があります。

Rork Max が「正しい実装」をしたことに問題はありません。ただ、「このアプリが抱えるパフォーマンス上の制約」は明示的に伝えない限り考慮されません。以下のプロンプト補足を加えることで、レイジーロード型のカスタムタブが生成されるようになりました。

「カテゴリタブはTabViewではなく、ScrollViewとPageTabViewStyle相当のカスタム実装にしてください。
理由：壁紙アプリで全タブを同時にメモリ展開するとRAM使用量が急増するため、
表示中のカテゴリのみを初期化したい形にしてください」

スライドショー機能とページジャンプスライダー

iOS版の Beautiful HD Wallpapers では、スライドショー機能とページジャンプ用のスライダーを組み合わせた機能があります。これはAndroid版から iOS 版に逆移植した機能で、私自身が設計した実装です。

Rork Max にスライドショー機能の実装を頼んだところ、自動タイマーとページング付きの基本的な実装が生成されました。問題は Timer の扱いでした。生成されたコードは onAppear で Timer を開始しますが、onDisappear でキャンセルする処理がありません。ビューが消えた後も Timer が動き続け、クラッシュの原因になります。

さらに、アプリがバックグラウンドに移行した時の処理もありませんでした。壁紙アプリでは「スライドショーをかけたまましばらく放置する」という使い方を想定しているユーザーが多いため、バックグラウンド移行時の処理は重要です。

修正後のパターンはこうなります。

class SlideShowTimer: ObservableObject {
    var timer: Timer?
 
    func start(interval: TimeInterval, action: @escaping () -> Void) {
        stop()
        timer = Timer.scheduledTimer(withTimeInterval: interval, repeats: true) { _ in
            action()
        }
    }
 
    func stop() {
        timer?.invalidate()
        timer = nil
    }
}
 
struct SlideShowView: View {
    @StateObject private var slideTimer = SlideShowTimer()
    @State private var currentIndex = 0
    let wallpapers: [Wallpaper]
 
    var body: some View {
        TabView(selection: $currentIndex) {
            ForEach(wallpapers.indices, id: \.self) { index in
                WallpaperFullView(wallpaper: wallpapers[index]).tag(index)
            }
        }
        .tabViewStyle(.page(indexDisplayMode: .never))
        .onAppear {
            slideTimer.start(interval: 3.0) {
                withAnimation {
                    currentIndex = (currentIndex + 1) % wallpapers.count
                }
            }
        }
        .onDisappear { slideTimer.stop() }
    }
}

Timer を ObservableObject に切り出して onAppear/onDisappear で対称的に制御する、このパターンが安全です。

「生成を諦めた」機能 — Rork Max では対応が難しかったケース

UIKit ViewRepresentable ブリッジ

Beautiful HD Wallpapers の壁紙設定機能（ホーム画面・ロック画面への壁紙設定）は、UIKit の UIImageWriteToSavedPhotosAlbum と Photos フレームワークを組み合わせて実装しています。

この部分を SwiftUI で実装する際は UIViewControllerRepresentable を使う必要がありますが、Rork Max が生成した実装は動作しませんでした。生成されたコードが Photos フレームワークの権限フローを正しく処理しておらず、権限未付与の状態でクラッシュするものでした。

特に問題だったのは、PHPhotoLibrary.requestAuthorization の非同期処理と SwiftUI の ViewModel を正しく繋ぐ部分です。Rork Max はここを同期的に処理するコードを生成し、権限が付与されていない状態での動作が不定になっていました。正しいパターンは async/await を使った以下の形です。

func requestPhotoLibraryAccess() async -> Bool {
    let status = PHPhotoLibrary.authorizationStatus(for: .addOnly)
    switch status {
    case .authorized, .limited:
        return true
    case .notDetermined:
        let granted = await PHPhotoLibrary.requestAuthorization(for: .addOnly)
        return granted == .authorized || granted == .limited
    default:
        return false
    }
}

この機能については、既存の実装をそのまま流用することにしました。生成に頼るより手書きが安全だと判断した最初のケースです。

ATT プロンプトの順序制御

ATT（App Tracking Transparency）プロンプトのタイミング制御も、Rork Max での自動生成は難しい部分です。2026年現在、MobileAds 初期化前に ATTrackingManager.requestTrackingAuthorization を呼び出す必要があります。これを逆順にすると、一部のデバイスで ATT ダイアログが表示されない問題が起きます。

私自身が iOS版の4アプリ全てでこの問題を経験しており、順序を修正することで解決しました。Rork Max が生成するコードではこの順序が逆になるケースが多く、表面上のテストでは分からないまま本番に出てしまうリスクがあります。ATT 関連は必ず手動で確認することを強くお勧めします。

Rork Max で壁紙アプリを作る場合の実用的な指針

検証を終えて手元に残った実感は、ひとつだけでした。ツールの限界を先に知ることが、そのツールを使いこなす前提条件になる、ということです。

今回の検証を通じて、Rork Max の SwiftUI 生成機能に対して持つ実用的な指針は4つです。

UIレイヤーは信頼して任せる: グリッドレイアウト、アニメーション、遷移、カスタムコンポーネントといった「見た目の実装」については、Rork Max の生成精度は高く、手戻りは少ないです。特に SwiftUI の宣言的な性質と相性がよく、複雑なアニメーションも適切な実装パターンで出てくることが多いと感じています。

ライフサイクルと非同期処理は必ずレビューする: onAppear/onDisappear の対称性、非同期処理のキャンセル、バックグラウンド移行時の処理など、「見えない動作」に関わるコードは必ずレビューしてください。動作するように見えて、エッジケースで問題が起きるパターンが多い部分です。Beautiful HD Wallpapers の v2.1.0 リリース直前にも、スライドショー機能のタイマーがバックグラウンドから復帰した後に二重起動するバグを発見しました。実機で長時間使って初めて分かった問題でした。

OS固有の権限フローは手書きが安全: ATT プロンプト、Photos ライブラリアクセス、プッシュ通知の権限フローなど、Apple のプラットフォームポリシーと直結する部分は、自分で書くか公式サンプルを参照した上で生成コードを検証することをお勧めします。ここでの問題はテスト段階では見えにくく、審査リジェクトや本番クラッシュとして顕在化することが多いです。

仕様書に「なぜ」を加えると精度が上がる: 「何を作るか」だけでなく「なぜそう設計するか」をプロンプトに加えることで、生成コードの品質が明確に上がります。特にパフォーマンス上の制約（メモリ、バッテリー、バックグラウンド動作）については意識的に補足することを習慣にしています。

AdMob メディエーションとの共存で気をつけること

壁紙アプリの収益柱の一つは AdMob 広告です。Rork Max で生成したビューに AdMob バナーを組み込む際の注意点をお伝えします。

iOS 版の4アプリでは、2026年5月のアップデートで Liftoff・InMobi・Unity Ads の3つのメディエーションパートナーを追加しました。AdMob × AppLovin MAX のウォーターフォール設定で20グループへの追加を完了しており、最適化トグルを有効にすることで eCPM ベースの動的調整が機能しています。

Rork Max で生成したビューに広告を組み込む際の主なポイントは rootViewController の取得方法です。

struct BannerAdView: UIViewRepresentable {
    let adUnitID: String
 
    func makeUIView(context: Context) -> GADBannerView {
        let banner = GADBannerView(adSize: GADAdSizeBanner)
        banner.adUnitID = adUnitID
        // iOS 15+ での正しい取得方法（keyWindow は deprecated）
        banner.rootViewController = UIApplication.shared.connectedScenes
            .compactMap { $0 as? UIWindowScene }
            .first?.windows
            .first?.rootViewController
        banner.load(GADRequest())
        return banner
    }
 
    func updateUIView(_ uiView: GADBannerView, context: Context) {}
}

Rork Max の生成コードでは UIApplication.shared.keyWindow を使うケースがありますが、これは iOS 15 以降で deprecated です。現在は警告で済んでいても、将来のSDK更新で動作が変わる可能性があります。connectedScenes 経由での取得を使ってください。

複数解像度への対応とiPhone新モデル対応

壁紙アプリで特に重要な問題の一つが、iPhone モデルごとの解像度対応です。2026年現在、iPhone Air（420×912）、iPhone 17 Pro（402×874）、iPhone 16/17 Pro Max（440×956）など、対応すべき解像度が年々増加しています。

Beautiful HD Wallpapers の iOS版では DefineManager.h に29箇所の三項演算子を追加して各解像度に対応しています。Rork Max に解像度対応の実装を依頼すると、基本的な解像度分岐のコードは生成されますが、最新モデルの解像度定数は含まれないことが多いです。Apple の Device Screen Specifications を参照した上で、定数を手動で追加する作業は避けられません。

// 解像度別の壁紙サイズ定義（2026年5月時点）
struct WallpaperSize {
    static var optimal: CGSize {
        let screen = UIScreen.main.bounds.size
        let scale = UIScreen.main.scale
 
        switch (Int(screen.width * scale), Int(screen.height * scale)) {
        case (1290, 2796): return CGSize(width: 1290, height: 2796) // iPhone 14/15/16 Pro Max
        case (1320, 2868): return CGSize(width: 1320, height: 2868) // iPhone 16 Pro Max
        case (1206, 2622): return CGSize(width: 1206, height: 2622) // iPhone 15/16 Pro
        default:           return CGSize(width: screen.width * scale, height: screen.height * scale)
        }
    }
}

この部分は最新モデルが出るたびに更新が必要であり、Rork Max の生成に頼るより公式のリリースノートを参照しながら自分で管理する方が確実です。

生成コードが最初に破綻するのはメモリ — AsyncImage を壁紙アプリに入れる前の確認

先ほど LazyVGrid を「そのまま使えた」機能として挙げましたが、正確に言えば、そのまま使えたのは構造だけです。生成された AsyncImage を本番の壁紙データに向けた瞬間、iPhone 11 の実機でスクロールを続けると数十秒で落ちました。

原因は単純でした。AsyncImage はダウンロードした画像をそのままの寸法でデコードします。サムネイルを原寸で配信していると、1枚あたりのビットマップは幅×高さ×4バイトになります。1290×2796 の壁紙なら1枚で約14.4MB。3カラムのグリッドで前後の行を含めて30枚が生きていれば、それだけで400MB を超えます。LazyVGrid は画面外のセルを即座には解放しませんし、AsyncImage にはキャッシュがないため、スクロールで戻ったときに再ダウンロードと再デコードが両方走ります。

Rork Max に非がある話ではありません。「3カラムのグリッド」という要件からは、原寸4Kの画像が流れてくる前提を読み取れません。ここは仕様として渡す側の責任です。

デコードする寸法を先に決める

対策はデコード段で寸法を落とすことです。CGImageSourceCreateThumbnailAtIndex を使うと、フルサイズのビットマップを一度も作らずに目的の寸法へ展開できます。

enum ImageDownsampler {
    /// 表示寸法（ポイント）とスケールから、デコード段で縮小した UIImage を返す
    static func downsample(data: Data, to pointSize: CGSize, scale: CGFloat) -> UIImage? {
        let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary
        guard let source = CGImageSourceCreateWithData(data as CFData, sourceOptions) else { return nil }
 
        let maxPixel = max(pointSize.width, pointSize.height) * scale
        let thumbOptions = [
            kCGImageSourceCreateThumbnailFromImageAlways: true,
            kCGImageSourceShouldCacheImmediately: true,
            kCGImageSourceCreateThumbnailWithTransform: true,
            kCGImageSourceThumbnailMaxPixelSize: maxPixel
        ] as CFDictionary
 
        guard let cgImage = CGImageSourceCreateThumbnailAtIndex(source, 0, thumbOptions) else { return nil }
        return UIImage(cgImage: cgImage, scale: scale, orientation: .up)
    }
}

kCGImageSourceCreateThumbnailFromImageAlways を true にしているのは、JPEG に埋め込まれたサムネイルを流用させないためです。埋め込みサムネイルは寸法が小さすぎることが多く、壁紙のグリッドでは輪郭が甘くなります。kCGImageSourceShouldCacheImmediately を true にすると、デコードがこの関数の内側で完了します。スクロール中のメインスレッドで遅れてデコードが走る事故を防げます。

上限付きのキャッシュを挟む

次にキャッシュです。NSCache は totalCostLimit を指定すると、メモリ圧迫時に古いエントリを自前で捨ててくれます。コストにバイト数を渡すのが要点です。

actor ThumbnailStore {
    static let shared = ThumbnailStore()
 
    private let cache: NSCache<NSString, UIImage> = {
        let c = NSCache<NSString, UIImage>()
        c.totalCostLimit = 48 * 1024 * 1024   // 48MB
        return c
    }()
    private var inFlight: [String: Task<UIImage?, Never>] = [:]
 
    func thumbnail(for url: URL, pointSize: CGSize, scale: CGFloat) async -> UIImage? {
        let key = "\(url.absoluteString)|\(Int(pointSize.width * scale))"
        if let cached = cache.object(forKey: key as NSString) { return cached }
        if let running = inFlight[key] { return await running.value }
 
        let task = Task<UIImage?, Never> {
            guard let (data, _) = try? await URLSession.shared.data(from: url) else { return nil }
            return ImageDownsampler.downsample(data: data, to: pointSize, scale: scale)
        }
        inFlight[key] = task
        let image = await task.value
        inFlight[key] = nil
 
        if let image, let cg = image.cgImage {
            cache.setObject(image, forKey: key as NSString, cost: cg.bytesPerRow * cg.height)
        }
        return image
    }
}

inFlight を持っている理由は、同じ URL への要求が重なるのを止めるためです。グリッドを速くスクロールすると、同じセルが読み込み開始を何度も通ります。ここを素直に書くと同一画像のデコードが並列で走り、メモリのピークが跳ね上がります。

呼び出し側は AsyncImage を置き換える薄いビューにまとめました。

struct WallpaperThumbnail: View {
    let url: URL
    let side: CGFloat
    @State private var image: UIImage?
 
    var body: some View {
        Group {
            if let image {
                Image(uiImage: image).resizable().aspectRatio(1, contentMode: .fill)
            } else {
                Color.gray.opacity(0.3)
            }
        }
        .frame(width: side, height: side)
        .clipped()
        .task(id: url) {
            image = await ThumbnailStore.shared.thumbnail(
                for: url,
                pointSize: CGSize(width: side, height: side),
                scale: UIScreen.main.scale
            )
        }
    }
}

.task(id: url) にしている点が地味に重要です。onAppear ではセルが再利用されたときに古い読み込みが残りますが、id を指定した task はビューの同一性が変わった時点で前の読み込みを自動でキャンセルします。

直したつもりで終わらせず、数字で確認する

フットプリントは機械で見る手順を用意しました。os_proc_available_memory() は、アプリが強制終了されるまでに使える残量をバイトで返します。実機で高速スクロールを続けながらこの値を記録すると、対策の効き方が数字で出ます。

#if DEBUG
import os
 
func logMemoryHeadroom(_ label: String) {
    let available = Double(os_proc_available_memory()) / 1_048_576
    os_log("[mem] %{public}@ available=%{public}.1fMB", label, available)
}
#endif

iPhone 11（メモリ4GB）で、3カラムのグリッドを200行ぶんスクロールしたときの記録が以下です。手元の1機種・1データセットでの値ですので、絶対値ではなく差の大きさを見てください。

状態	ピーク時のフットプリント	残ヘッドルーム最小値	30秒スクロール×3回での強制終了
生成コードそのまま（AsyncImage）	約 610MB	約 40MB	3回
ダウンサンプリングのみ	約 190MB	約 460MB	0回
ダウンサンプリング＋48MB キャッシュ	約 150MB	約 500MB	0回

キャッシュを足した効果は、ピーク値よりも体感に出ます。一度見た行に戻ったときの再デコードが消えるため、スクロールの引っかかりがなくなります。

代償もあります。デコード段で縮小するぶん CPU 時間は増えます。手元では1枚あたり 6〜9ms（A13）で、Task に載せている限りスクロールへの影響は感じませんでしたが、より古い端末では並列数を絞る調整が要るかもしれません。

仕様の渡し方を変える

この一件のあと、Rork Max への依頼文を書き換えました。「3カラムのグリッド」ではなく、「3カラムのグリッド。画像は原寸4Kで配信されるため、セルの表示寸法にデコード段で縮小すること。上限付きのキャッシュを持たせ、同一URLの並列読み込みは1本に束ねること」と書くようにしています。この書き方に変えてから、生成コードにダウンサンプリングとキャッシュが最初から含まれる割合が上がりました。先に挙げた「仕様書に『なぜ』を加えると精度が上がる」の、最も効いた実例がこれです。

SwiftUI のアニメーション生成：Rork Max が特に強い領域

グリッドやビューアとは別に、アニメーション関連の生成精度が高いことも発見でした。壁紙アプリでよく使うフェードイン・スケールアップ・スライドインといったアニメーションは、仕様に軽く触れるだけで適切なコードが生成されます。

たとえば「壁紙をタップした時にハートアイコンをアニメーションで表示する」という要件に対して、以下のような実装が出てきました。

struct LikeButton: View {
    @State private var isLiked = false
    @State private var showHeart = false
 
    var body: some View {
        Button(action: {
            isLiked.toggle()
            if isLiked {
                showHeart = true
                withAnimation(.spring(response: 0.4, dampingFraction: 0.5)) {
                    // animation triggers
                }
                DispatchQueue.main.asyncAfter(deadline: .now() + 1.2) {
                    showHeart = false
                }
            }
        }) {
            Image(systemName: isLiked ? "heart.fill" : "heart")
                .foregroundColor(isLiked ? .red : .white)
                .font(.title2)
                .scaleEffect(showHeart ? 1.4 : 1.0)
                .animation(.spring(response: 0.3, dampingFraction: 0.6), value: showHeart)
        }
    }
}

spring アニメーションのパラメータ選択（response 0.3〜0.4、dampingFraction 0.5〜0.6）は実際の壁紙アプリで使っているものに近く、生成されたそのまま使えるクオリティでした。アニメーション設計は Rork Max が得意とする領域の一つだと感じています。

アニメーションの細部は、ユーザーが言葉にしない部分です。それでも指の動きに対する反応が半拍遅れれば、手触りとして必ず伝わります。ここに一定の精度が最初から出てくることは、時間の配分という意味でも助かっています。

Rork Max 生成コードと既存 UIKit コードの混在戦略

Beautiful HD Wallpapers は SwiftUI と UIKit の混在構成です。既存の UIKit コードを残しながら、新規画面を Rork Max で SwiftUI として生成していく場合の戦略についても触れておきます。

基本的なアプローチは UIHostingController を使って SwiftUI ビューを UIKit のフローに組み込む方法です。これは Rork Max でも生成できますが、ナビゲーションスタックの一貫性（SwiftUI の NavigationStack と UIKit の UINavigationController が混在する問題）については手動での調整が必要になることがあります。

私の場合は新規追加した画面から SwiftUI 化を進めており、既存の UIKit 画面には手を入れないというルールで作業しています。この「段階的移行」の考え方は、Rork Max を使う場合も同様です。全画面を一度に生成し直そうとするのではなく、新規機能を Rork Max で生成しながら既存コードと組み合わせていくアプローチが現実的です。

特に注意が必要なのは、UIKit と SwiftUI の境界でのデータの受け渡しです。Rork Max が生成するコードは SwiftUI の @State や @Binding を前提とした設計になっていることが多く、UIKit 側との連携には UIViewControllerRepresentable や Coordinator パターンを挟む必要があります。この橋渡し部分は Rork Max の生成精度がやや下がる領域なので、手書きで書くか既存の実績あるパターンを流用することをお勧めします。

StoreKit 2 への移行と Rork Max の活用

2026年の iOS アプリ開発において避けられないのが StoreKit 2 への移行です。旧 SKPayment API は iOS 18 以降で完全非推奨となり、Transaction.currentEntitlements を使った async sequence ベースのアプローチに移行する必要があります。

Rork Max に StoreKit 2 の実装を依頼すると、基本的な購入フローは正しく生成されます。ただし、壁紙アプリのような「広告削除型の IAP」と「サブスクリプション型」を組み合わせたケースでは、エンタイトルメントの判定ロジックが複雑になります。私の実装では BillingManager と AdFreeManager を分離して、isAdFree || isRewardAdFree という合成判定を必ず経由する設計にしています。

actor BillingManager {
    static let shared = BillingManager()
 
    func isAdFree() async -> Bool {
        for await result in Transaction.currentEntitlements {
            if case .verified(let transaction) = result {
                if transaction.productID == "net.dolice.adfree" && transaction.revocationDate == nil {
                    return true
                }
            }
        }
        return false
    }
}

この actor ベースの実装は Rork Max が生成できる形に近いですが、revocationDate のチェックを忘れるケースがありました。払い戻しされた購入に対してもコンテンツを表示してしまう問題につながるため、必ず確認してください。

Rork Max を使う前後で変わったこと — 開発サイクルの具体的な変化

Rork Max を取り入れる前と後で、私の開発サイクルが具体的にどう変わったかを書いておきます。

以前は「新しい画面の実装」から始めると、画面の基本レイアウト作成に半日、動作確認と調整にさらに半日を費やすことが多かったです。1画面あたり1日が目安でした。

Rork Max を使い始めてからは、基本レイアウトの生成が30〜60分に短縮されました。ただし、前述のライフサイクル周りのレビューと、アプリ固有の要件に合わせた調整で1〜2時間を追加で使います。結果として1画面あたり2〜3時間が目安になっています。単純計算で1/3〜1/4の時間になった計算です。

この短縮効果が最も大きく出るのは、UIが複雑で仕様が明確な画面です。逆に、「こういう感じにしたい」という曖昧な要件の場合は、生成とレビューを繰り返す分だけ時間がかかることもあります。

時間の使い方が変わって気づいたことは、以前はUI実装に費やしていた時間が、ビジネスロジックやパフォーマンス改善に使えるようになったことです。壁紙の読み込み速度の最適化や、メモリ使用量の削減といった「ユーザーには見えないが体験を左右する部分」に時間を割けるようになったと感じています。

どこに時間と注意を注ぐかの判断が、そのまま品質になります。Rork Max は、その注ぎ先を移してくれる道具として機能しています。

もう一つ変化があります。コードレビューの質が変わりました。以前は「このコードは動くか」を確認するレビューが中心でしたが、今は「このコードのどの部分を信頼して、どの部分を疑うべきか」という視点でレビューするようになりました。生成されたコードの責任は最終的に自分にあります。その意識がある限り、AI生成コードは品質を下げる要因にはなりません。むしろ、自分が見落としがちなUI実装の細部をカバーしてくれる、経験豊富なコードレビュアーのような存在として活用できています。

全体評価 — 本番運用の側から見た Rork Max の SwiftUI 機能

今回の検証を通じて感じたことを率直に言うと、「UIの実装コストを大幅に下げるが、プラットフォームの深い部分は開発者の知識が必要」です。

個人でアプリを出し始めた頃と比べると、開発の入り口は驚くほど低くなりました。Rork Max のような AI 生成ツールが登場したことで、以前なら2週間かかっていたUIの実装が数時間で形になります。これは本当の意味での生産性向上です。

しかし同時に、「動くように見えるコード」と「本番で安定して動くコード」の差は変わっていないとも感じています。タイマーのライフサイクル管理、権限フローの非同期処理、メモリ効率を考慮したアーキテクチャ選択——これらは「実際にアプリを長期運用して初めて分かる」種類の知識であり、生成 AI が補うのが難しい部分です。

Rork Max の SwiftUI 生成は、UIの骨格を素早く形にして、そこから先を自分の経験で詰めていく使い方に最も向いていると感じています。私自身、次回のiOSアプリアップデートでも、新画面の UI は Rork Max で生成してから調整するというフローを使う予定です。

Rork Max の SwiftUI 生成をまだ試していない方は、既存アプリの小さな画面一つから始めてみてください。自分がよく知っている画面を選ぶことが要点です。生成コードのどこを信頼できて、どこに自分の経験を足すべきかが、最初の1時間で見えてきます。

最後までお読みいただきありがとうございました。実装の参考になれば幸いです。