Benchmarking Rork Max SwiftUI Native Generation Across 30 Features — What to Delegate and When to Step In

S-Rated Features — Delegate Without Hesitation

Basic UI, REST API, and core CRUD operations consistently earn S ratings. List, Form, NavigationStack, Sheet, Alert, and TabView all compile correctly on the first attempt and reach design-polished quality by the second prompt.

REST API integration is where Rork Max shines most consistently. URLSession-based async/await, Codable JSON decoding, and error-handling fetch methods — this is the category where AI generation is most reliable.

// S-rated: REST API integration generated by Rork Max
// All three pillars present: error handling, async/await, Codable
 
struct Article: Codable, Identifiable {
    let id: Int
    let title: String
    let body: String
}
 
@MainActor
class ArticleViewModel: ObservableObject {
    @Published var articles: [Article] = []
    @Published var isLoading = false
    @Published var errorMessage: String?
 
    func fetchArticles() async {
        isLoading = true
        errorMessage = nil
 
        do {
            guard let url = URL(string: "https://jsonplaceholder.typicode.com/posts") else {
                errorMessage = "Invalid URL"
                isLoading = false
                return
            }
 
            let (data, response) = try await URLSession.shared.data(from: url)
 
            guard let httpResponse = response as? HTTPURLResponse,
                  (200...299).contains(httpResponse.statusCode) else {
                errorMessage = "Server error"
                isLoading = false
                return
            }
 
            articles = try JSONDecoder().decode([Article].self, from: data)
        } catch {
            errorMessage = error.localizedDescription
        }
 
        isLoading = false
    }
}

The @MainActor annotation on the class and the parallel management of isLoading and errorMessage are both present from the first generation. This is already designed for clean UI binding without any manual intervention.

Full S-rated category list:

• Core UI components (List, Form, Sheet, Alert)
• REST API with Codable async fetching
• Supabase/Firebase Auth UI basic flows
• CoreData basic CRUD (1–3 entities)
• UserDefaults/AppStorage
• Swift Charts (line, bar, pie)
• TabView/NavigationStack basic transitions

A-Rated Features — High Quality After 2–4 Prompts

StoreKit 2, MapKit, Core Location, and Local Notifications land in the A tier. The generated code is largely correct, but specific parts require targeted adjustments.

StoreKit 2 illustrates this well. The basic subscription purchase flow works. But Transaction.currentEntitlements for purchase restoration and expiration handling tend to be oversimplified. You need to explicitly request complete behavior.

// A-rated: StoreKit 2 subscription flow (polished after 3 prompts)
// Key: explicit transaction verification and update listener lifecycle
 
class SubscriptionManager: ObservableObject {
    @Published var isSubscribed = false
    private var updateListenerTask: Task<Void, Error>?
 
    init() {
        updateListenerTask = listenForTransactions()
        Task {
            await updateSubscriptionStatus()
        }
    }
 
    deinit {
        updateListenerTask?.cancel()
    }
 
    func purchase(product: Product) async throws -> StoreKit.Transaction? {
        let result = try await product.purchase()
 
        switch result {
        case .success(let verification):
            let transaction = try checkVerified(verification)
            await updateSubscriptionStatus()
            await transaction.finish()
            return transaction
        case .userCancelled:
            return nil
        case .pending:
            return nil
        @unknown default:
            return nil
        }
    }
 
    private func checkVerified<T>(_ result: VerificationResult<T>) throws -> T {
        switch result {
        case .unverified(_, let error):
            throw error
        case .verified(let safe):
            return safe
        }
    }
 
    @MainActor
    func updateSubscriptionStatus() async {
        for await result in StoreKit.Transaction.currentEntitlements {
            if case .verified(let transaction) = result {
                if transaction.revocationDate == nil {
                    isSubscribed = true
                    return
                }
            }
        }
        isSubscribed = false
    }
 
    private func listenForTransactions() -> Task<Void, Error> {
        // Drop [weak self] and the task holds the instance forever — deinit never runs
        return Task.detached { [weak self] in
            for await result in StoreKit.Transaction.updates {
                guard let self else { return }
                if case .verified(let transaction) = result {
                    await self.updateSubscriptionStatus()
                    await transaction.finish()
                }
            }
        }
    }
}

The listenForTransactions() call in init is frequently omitted in first-pass generation. Without it, any purchase events that happen while the app is backgrounded get lost. Adding the instruction "always start a Transaction.updates listener in init and cancel it in deinit" to your prompt resolves this reliably on the second attempt.

There is one more spot here that tends to slip through review. Write Task.detached { ... self ... } the obvious way and that task holds a strong reference to the instance. deinit never fires, updateListenerTask?.cancel() is never reached, and every push and pop of the screen leaves another SubscriptionManager behind with its own live listener. Purchases still succeed, which is why it hides so well — I only noticed when the same post-purchase log line appeared three times in a row. Adding [weak self] and bailing out with guard let self else { return } is two lines, and in my experience those two lines almost never come out of the generator on their own.

Full A-rated list:

• StoreKit 2 purchase flows
• MapKit display and pin annotation
• Core Location basic geofencing
• Local Notifications (including Expo Notifications)
• Keychain Services (basic storage/retrieval)
• FaceID/TouchID (LocalAuthentication)
• SwiftUI animations (basic to intermediate)
• AVFoundation audio playback

B-Rated Features — Workable With the Right Approach

Dynamic Island, HealthKit, AVFoundation camera capture, and WidgetKit are B-rated. The code sometimes works, but specific edge cases and state transitions cause problems — and repeating the same prompt often produces the same errors.

For Dynamic Island (ActivityKit), expect the ActivityKit import to be missing from the first generation almost every time. The ActivityAttributes definition and ContentState update timing also tend to get conflated.

The fix is to decompose the request into sequential steps rather than asking for everything at once:

Step 1: "Create a DeliveryAttributes struct conforming to ActivityAttributes.
         Its ContentState should have two properties: currentStatus: String
         and estimatedTime: Date."

Step 2: "Using the DeliveryAttributes from Step 1, implement a
         startDeliveryTracking() method that starts an Activity.
         Include error handling and a check for whether ActivityKit
         is available on this device."

Step 3: "Implement the Live Activity UI with compact, expanded, and
         lock screen presentations using SwiftUI. Use .blue as the
         background color and .system(.headline) as the base font."

Breaking it into three steps produces high-quality output at each stage. Asking for everything in one prompt results in something that compiles but behaves unpredictably at runtime.

For HealthKit, adding this instruction significantly improves output quality:

"Request HealthKit authorization when the view appears (equivalent to
viewDidAppear). If access is denied, show a prompt that guides the user
to the Settings app. Also add the required NSHealthShareUsageDescription
and NSHealthUpdateUsageDescription keys to Info.plist."

Full B-rated list:

• Dynamic Island / Live Activities (ActivityKit)
• HealthKit (read/write)
• AVFoundation camera capture
• WidgetKit (basic widgets)
• Background Task / BGTaskScheduler
• Core NFC tag reading
• UNNotificationServiceExtension (rich push)

C-Rated Features — Human Intervention Required

ARKit, custom Core ML model integration, Metal, CarPlay, and App Clips earn C ratings. The generated code occasionally compiles, but getting it to production quality effectively requires a rewrite.

ARKit is the clearest example. The choice between ARView and ARSCNView is inconsistent — the same prompt can yield different implementations. ARSessionDelegate error handling is almost always absent, and ARWorldTrackingConfiguration settings are usually incomplete.

// C-rated: The ARKit code Rork Max typically generates
// This crashes on a real device within seconds
 
class BadARViewController: UIViewController {
    var arView = ARSCNView()  // No frame binding, no autolayout
 
    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(arView)  // No constraints
        arView.session.run(ARWorldTrackingConfiguration())  // No delegate, no config
    }
}
 
// Minimum viable ARKit implementation (written by hand after C-rated output)
class GoodARViewController: UIViewController, ARSCNViewDelegate, ARSessionDelegate {
    private lazy var arView: ARSCNView = {
        let view = ARSCNView(frame: .zero)
        view.translatesAutoresizingMaskIntoConstraints = false
        view.delegate = self
        view.session.delegate = self
        view.autoenablesDefaultLighting = true
        return view
    }()
 
    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(arView)
        NSLayoutConstraint.activate([
            arView.topAnchor.constraint(equalTo: view.topAnchor),
            arView.leadingAnchor.constraint(equalTo: view.leadingAnchor),
            arView.trailingAnchor.constraint(equalTo: view.trailingAnchor),
            arView.bottomAnchor.constraint(equalTo: view.bottomAnchor)
        ])
    }
 
    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        // Running on an unsupported device just silently shows nothing on hardware
        guard ARWorldTrackingConfiguration.isSupported else {
            showUnsupportedDeviceAlert()
            return
        }
        let config = ARWorldTrackingConfiguration()
        config.planeDetection = [.horizontal, .vertical]
        if let format = ARWorldTrackingConfiguration.supportedVideoFormats.first {
            config.videoFormat = format
        }
        arView.session.run(config, options: [.resetTracking, .removeExistingAnchors])
    }
 
    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        arView.session.pause()  // Prevent memory leak
    }
 
    func session(_ session: ARSession, didFailWithError error: Error) {
        if let arError = error as? ARError {
            switch arError.code {
            case .cameraUnauthorized:
                showCameraPermissionAlert()
            case .worldTrackingFailed:
                restartSession()
            default:
                print("AR error: \(arError.localizedDescription)")
            }
        }
    }
 
    private func showCameraPermissionAlert() {
        let alert = UIAlertController(
            title: "Camera Access Required",
            message: "Please enable camera access in Settings.",
            preferredStyle: .alert
        )
        alert.addAction(UIAlertAction(title: "Open Settings", style: .default) { _ in
            guard let url = URL(string: UIApplication.openSettingsURLString) else { return }
            UIApplication.shared.open(url)
        })
        alert.addAction(UIAlertAction(title: "Cancel", style: .cancel))
        present(alert, animated: true)
    }
 
    private func showUnsupportedDeviceAlert() {
        let alert = UIAlertController(
            title: "AR Is Not Available on This Device",
            message: "Everything outside the AR features still works normally.",
            preferredStyle: .alert
        )
        alert.addAction(UIAlertAction(title: "OK", style: .default))
        present(alert, animated: true)
    }
 
    private func restartSession() {
        arView.session.run(ARWorldTrackingConfiguration(),
                           options: [.resetTracking, .removeExistingAnchors])
    }
}

For C-rated features, I recommend having Rork Max handle the non-core parts — UI layout, navigation, and unrelated business logic — while writing the AR/ML processing core yourself. This hybrid approach consistently produces better results than either full AI generation or fully manual implementation.

Full C-rated list:

• ARKit / RealityKit
• Core ML custom model integration
• Metal / custom shaders
• CarPlay integration
• App Clips
• GameKit (multiplayer)
• Passkeys (latest Authentication Services)

A Worked Example — Lifting a C-Rated On-Device Core ML Feature to A Quality

Even C-rated features can reach production quality if you split the task and aim your verification carefully. Using on-device image classification as the subject, I recorded how the generated code was repaired. In my case the first prompt did not compile, and it took five exchanges to reach working on-device behavior.

Asking for everything at once — "build a SwiftUI view that classifies images with Core ML" — returned code like this. It loads the model inside the view's body on every call, pressuring memory with each inference.

// Fresh output (typical C-rated) — reloads the model inside body every time
struct BadClassifierView: View {
    @State private var label = ""
    var body: some View {
        VStack {
            Text(label)
            Button("Classify") {
                // ❌ re-initializes the model on every tap
                let model = try! MyImageClassifier(configuration: .init())
                // ❌ leaves a try! crash path in place
            }
        }
    }
}

From here I resent the instructions in three stages. Stage one: "Initialize VNCoreMLModel once outside the view and share it as a singleton." Stage two: "Run inference through Vision's VNImageRequestHandler and return the top label and its confidence score." Stage three: "Avoid try!, and express model-loading failure and inference failure as separate enum error cases."

What it finally settled into is below. The model is built once, inference is moved off onto an async path, and failure routes are expressed through types.

// A-quality Core ML inference, reached in five prompts
enum ClassifierError: Error {
    case modelUnavailable
    case inferenceFailed
}
 
final class ImageClassifier {
    // Holding it as an Optional throws away the reason it failed, so keep a Result
    private static let instance = Result { try ImageClassifier() }
    static func shared() throws -> ImageClassifier { try instance.get() }
 
    private let model: VNCoreMLModel
 
    private init() throws {
        guard let coreMLModel = try? MyImageClassifier(configuration: MLModelConfiguration()) else {
            throw ClassifierError.modelUnavailable
        }
        self.model = try VNCoreMLModel(for: coreMLModel.model)
    }
 
    func classify(_ image: CGImage) async throws -> (label: String, confidence: Float) {
        try await withCheckedThrowingContinuation { continuation in
            var outcome: Result<(label: String, confidence: Float), Error> =
                .failure(ClassifierError.inferenceFailed)
 
            let request = VNCoreMLRequest(model: model) { request, error in
                if let error {
                    outcome = .failure(error)
                    return
                }
                guard let top = (request.results as? [VNClassificationObservation])?.first else {
                    return
                }
                outcome = .success((top.identifier, top.confidence))
            }
            request.imageCropAndScaleOption = .centerCrop
 
            do {
                // perform runs synchronously and calls the handler before it returns,
                // so a single resume placed here is enough.
                try VNImageRequestHandler(cgImage: image, options: [:]).perform([request])
                continuation.resume(with: outcome)
            } catch {
                continuation.resume(throwing: error)
            }
        }
    }
}

The delta from the generated version came down to three things: where the model is built, removing try!, and giving the failure paths a type.

The third one caught me a second time in my own rewrite. Writing static let shared = try? ImageClassifier() makes the type ImageClassifier?, which forces every call site into ImageClassifier.shared?.classify(...). Whether the model failed to load or the inference failed, the screen can only say "couldn't classify that." Wrapping it in a Result so you can write try ImageClassifier.shared().classify(image) lets the actual reason land in your catch.

The continuation had a trap of its own. VNImageRequestHandler.perform(_:) runs synchronously, and the completion handler fires before perform returns. Resume from inside the handler and from the catch around perform, and under the right conditions you resume twice and crash. Collecting the result into outcome and resuming exactly once after perform fixed it, and I have not seen the crash on device since.

Name the landmines before generation rather than patching them afterward. For C-rated features, that is the one habit I hold onto.

Common Pitfalls and How to Fix Them

Five issues appear repeatedly when working with B and C-rated features.

① Missing @MainActor

The most frequent issue in generated ObservableObject subclasses is a missing @MainActor annotation. Without it, updating @Published properties from background threads produces runtime warnings and potential data races.

// Pattern that frequently appears without @MainActor (generates warnings)
class BadViewModel: ObservableObject {
    @Published var items: [String] = []
 
    func loadItems() async {
        items = await fetchFromServer()  // Warning: published from non-main thread
    }
}
 
// Correct pattern
@MainActor
class GoodViewModel: ObservableObject {
    @Published var items: [String] = []
 
    func loadItems() async {
        items = await fetchFromServer()  // Safe: MainActor ensures main thread
    }
}

Adding "always annotate ObservableObject subclasses with @MainActor" to your prompt eliminates this issue almost completely.

② @State vs @StateObject confusion

Value types (structs) use @State; reference types (classes) use @StateObject. When a custom ViewModel is declared with @ObservedObject instead of @StateObject, it gets reset every time the parent View re-renders — producing subtle bugs where data appears to reset randomly.

③ Preview Provider crashes

Features requiring real hardware — HealthKit, the camera, NFC — crash in Xcode Previews. Explicitly request that generated Previews use mock/stub data to avoid this.

④ Inter-framework dependency ordering

When combining Core ML with Vision Framework, model initialization timing can cause issues. Specifying "initialize the VNCoreMLModel outside the View, managed as a singleton" stabilizes the behavior significantly.

⑤ Missing Entitlements configuration

Rork Max generates the code for HealthKit, Push Notifications, NFC, and iCloud — but does not configure the .entitlements file or Xcode's Signing & Capabilities section. These must be set manually. Forgetting this step causes cryptic runtime errors that look like code bugs but are actually capability configuration issues.

Measured Development Time by Rating

For solo development, how much time a feature burns matters as much as its quality. Implementing the same small feature from scratch, I recorded the time it took to reach production quality by hand.

This time gap feeds directly into revenue design. What I have kept doing as an indie developer is the kind of app that recovers its costs in small increments through AdMob ads and subscriptions. For that pattern the core features fall within S and A, so the implementation time per app stays low. An app whose selling point is AR or on-device ML, by contrast, will keep slipping its release date unless you budget the C-rated time cost from the start.

Before deciding what to build, estimate which rating band each feature belongs to. That single step, I believe, has an outsized effect on how a solo developer paces the work. Build your footing with S- and A-centered apps that recover quickly, then invest any surplus into the more ambitious C-rated features. Over the long run, on limited time, that ordering feels like the realistic one.

You Can Estimate the Tier Before You Start — Three Conditions Separating S from C

After laying all thirty features side by side, I noticed the ranks were not scattered at random. This is the part I most want to pass along. Thirty sounds like a lot, but most of the APIs you are about to touch are not on the list. The mechanism that sets the score outlasts the scores themselves.

The estimate I use comes down to three questions.

Question one matters because what a generative model does well is write a mapping from input to output. A REST client, a CoreData CRUD layer, a Swift Charts view — strip them down and each one carries values from one shape to another. ARKit and AVFoundation capture are different: the correct call depends on what state the session is currently in. That state machine is not written down in one place; it is scattered across prose in the docs and behavior on the device, and that is where generated code goes wrong.

Question two is the axis I have felt most sharply. When failure surfaces through throws, generated code tends to bring do-catch along with it. When failure only surfaces through a delegate, the generated code writes the happy path and looks pleased with itself. The missing session(_:didFailWithError:) in the ARKit example, and the missing ARWorldTrackingConfiguration.isSupported check, both come from the same place.

Question three is blunt, but it holds. The distribution of training material shows up directly in output quality. APIs whose official samples are written in SwiftUI come out working on the first try; APIs still dominated by UIKit-era material leave the generator hesitating exactly at the bridge into SwiftUI.

Count how many of the three fall on the right-hand column: zero or one suggests S or A, two suggests B, all three suggests C. Against my own thirty-feature measurements that mapping held up well. CarPlay, Metal, and GameKit sit on the right for all three. Swift Charts and AppStorage sit on the left for all three, and in practice neither needed much from me.

The estimate does miss sometimes. When it has, the cause was almost always question two — I reopen the documentation and find that failure comes back through a notification or a callback rather than a return value. What sets the tier is how an API chooses to show you its failures. When I pick up an unfamiliar framework now, that is the one thing I check before writing anything.

Decision Framework — Matching Features to the Right Approach

Based on the 30-feature benchmark, here's how I approach the strategy decision for each new project.

Fully delegate to Rork Max when:

Your app's core features are drawn from S and A-rated categories. The pattern "fetch data from a REST API, display it in a list, monetize with subscriptions" is almost entirely achievable through AI generation. For apps in this category, 90% or more of the code can be AI-generated with confidence.

Use Rork Max as a starter, then tune manually:

Apps containing B-rated features like Dynamic Island, HealthKit, or WidgetKit. Let Rork Max generate the skeleton, then apply the step-by-step prompt approach described above to polish each feature. Budget roughly 2–3× the development time compared to S-rated-only apps.

Use Rork Max as scaffolding only:

Apps requiring C-rated features like ARKit or Core ML. Have Rork Max handle navigation, UI layout, and non-core business logic, while you implement the AR/ML processing core manually. This division of labor is consistently faster than either pure AI generation or fully manual development.

One thing I've come to accept is that Rork Max's generation quality is probabilistic. The same prompt doesn't always produce the same code, and quality varies across sessions. The ratings in this article describe tendencies, not guarantees. There are better days and harder days, and learning to work with that variability — rather than against it — is part of what makes the tool genuinely useful over time.

If you want to carry on-device inference all the way into a shipped app, I wrote down the conversion-to-distribution path in Rork × Core ML custom models and on-device AI. If you would rather see the seam between generated and hand-written code in a real project, testing Rork Max SwiftUI features on a wallpaper app is closer to that. For the camera stack specifically, there are also my Rork × Vision Camera v4 implementation notes.

Generation quality moves with every Rork Max release, so I will measure these numbers again in time. For now, pick one feature you plan to build next and run it through those three questions before you write a line — that is how I start with an unfamiliar API these days.