Building a Place-Search Map in Rork Max with MapKit: MKLocalSearch, Pin Clustering, and Location Permissions

Composing SwiftUI Map with the iOS 17 APIs

From iOS 17, SwiftUI Map controls its camera declaratively through MapCameraPosition. Following the user is a single initial value — .userLocation(fallback:) — and the standard behavior even handles detaching the follow mode when the user drags the map.

// SpotMapView.swift — the map body rendering search results as pins
import SwiftUI
import MapKit
 
struct SpotMapView: View {
    @State private var camera: MapCameraPosition =
        .userLocation(fallback: .automatic)
    @State private var spots: [Spot] = []   // search results
    @State private var selected: Spot?
 
    var body: some View {
        Map(position: $camera, selection: $selected) {
            UserAnnotation()   // the blue current-location dot
            ForEach(spots) { spot in
                Marker(spot.name, coordinate: spot.coordinate)
                    .tag(spot)
            }
        }
        .mapControls {
            MapUserLocationButton()
            MapCompass()
        }
        .sheet(item: $selected) { spot in
            SpotDetailSheet(spot: spot)
                .presentationDetents([.height(220), .medium])
        }
    }
}

Marker gives you the system look; Annotation hosts any custom SwiftUI view as a pin. The temptation is to start with fancy Annotation pins right away, but for the performance reasons below, I build with Marker first and only upgrade when the design genuinely calls for it.

Nearby Search with MKLocalSearch

The core of nearby search is MKLocalSearch. The one thing you must get right is passing the currently visible region into the request. Skip it and you get the badly broken experience of searching "cafe" in Tokyo and receiving results from another city.

// SpotSearchService.swift — nearby search biased to the visible region
import MapKit
 
struct SpotSearchService {
    func search(for query: String,
                in region: MKCoordinateRegion) async throws -> [Spot] {
        let request = MKLocalSearch.Request()
        request.naturalLanguageQuery = query
        request.region = region                    // bias to the visible area
        request.resultTypes = .pointOfInterest     // exclude address hits
 
        let response = try await MKLocalSearch(request: request).start()
        return response.mapItems.map { item in
            Spot(name: item.name ?? "Unknown",
                 coordinate: item.placemark.coordinate,
                 mapItem: item)
        }
    }
}
// Example: searching "cafe" with a region around a train station
// returns roughly 20 results within about 1 km (the API caps the count)

The visible region comes from the map's onMapCameraChange. When asking Rork Max to wire this up, specify the data flow itself — "hold the region from onMapCameraChange in State, and use it when searching" — and the plumbing comes out right. When I only said "add a search bar," the generated code reused a fixed initial region, and I was slow to notice that panning the map never changed the search area.

To constrain categories, use pointOfInterestFilter. Restricting to cafés and restaurants is MKPointOfInterestFilter(including: [.cafe, .restaurant]). It stabilizes results compared to free-form natural language queries, which is worth it whenever your app's search domain is fixed.

When Pins Multiply, SwiftUI Map Runs Out of Road

This is the judgment call I most want to pass on. As of July 2026, SwiftUI's Map still has no automatic pin clustering. When my saved photo spots grew to around 300 pins rendered as Annotation views, map dragging stuttered visibly even on my iPhone 15 Pro. Switching to Marker helped somewhat, but with no clustering the map turns into a carpet of pins — usability collapses before performance does.

You have two options.

For rendering search results (a few dozen at most), SwiftUI Map is fine as is. For a screen drawing every spot the user has saved, switching to MKMapView turned out to be the shortcut after all. Clustering activates simply by setting clusteringIdentifier on the MKMarkerAnnotationView.

// ClusteredMapView.swift — wrapping MKMapView for built-in clustering
import SwiftUI
import MapKit
 
struct ClusteredMapView: UIViewRepresentable {
    let annotations: [MKPointAnnotation]
 
    func makeUIView(context: Context) -> MKMapView {
        let mapView = MKMapView()
        mapView.delegate = context.coordinator
        mapView.register(
            MKMarkerAnnotationView.self,
            forAnnotationViewWithReuseIdentifier: "spot")
        return mapView
    }
 
    func updateUIView(_ mapView: MKMapView, context: Context) {
        mapView.removeAnnotations(mapView.annotations)
        mapView.addAnnotations(annotations)
    }
 
    func makeCoordinator() -> Coordinator { Coordinator() }
 
    final class Coordinator: NSObject, MKMapViewDelegate {
        func mapView(_ mapView: MKMapView,
                     viewFor annotation: MKAnnotation) -> MKAnnotationView? {
            guard !(annotation is MKUserLocation) else { return nil }
            let view = mapView.dequeueReusableAnnotationView(
                withIdentifier: "spot", for: annotation)
                as! MKMarkerAnnotationView
            view.clusteringIdentifier = "spotCluster"  // enables clustering
            return view
        }
    }
}

When requesting this switch from Rork Max, write "replace the SwiftUI Map with a UIViewRepresentable-wrapped MKMapView and enable clustering via clusteringIdentifier" and it lands in one pass. A vague "the map is slow with many pins, please fix" got me a response that merely capped the number of rendered pins — treating the symptom, not the cause. This matches the pattern I described in How to Build SwiftUI Native Apps with Rork Max: the dividing line is whether you can specify what to solve it with, not just what hurts.

Handing Directions Off to Apple Maps

There's no need to implement routing yourself. Pass the search result's MKMapItem straight to Apple Maps and walking, driving, and transit directions are all handled for you.

// The Directions button inside SpotDetailSheet
Button("Directions") {
    spot.mapItem.openInMaps(launchOptions: [
        MKLaunchOptionsDirectionsModeKey:
            MKLaunchOptionsDirectionsModeWalking
    ])
}

In-app route rendering with MKDirections is possible, but for a first indie release, delegating to Apple Maps cuts maintenance cost dramatically. I always choose the handoff for version one and only consider in-app routing once users actually ask for it.

Where Review and Real-World Use Slowed Me Down

Finally, the points where my prototype-to-submission run actually stalled.

• Purpose string specificity: the Guideline 5.1.1 classic mentioned above. I rewrote mine to name the feature before resubmitting.
• Location testing in the simulator: Rork Max's in-browser simulator supports custom coordinates, but verification involving movement simulation (freeway drives and the like) was more reliable on a physical device via the Companion app.
• Combining with WeatherKit: showing weather in the spot detail sheet is a natural extension, but the authentication has its own hoops. The pitfalls in Using WeatherKit in a Rork Max Weather App: Authentication and Attribution Pitfalls apply directly.
• Conserving credits: map screens invite many revision round-trips. Scoping change requests to specific files — "only LocationManager," "only the search service" — prevented unrelated screens from being regenerated and cut my credit consumption by what felt like 30–40%.

Wrapping Up

Start by having Rork Max generate just the search-results-as-Markers stage, then verify the onMapCameraChange-to-search wiring before anything else. The clustering switch can wait until saved pins pass the 100 mark. Don't build the whole map screen at once: permission, rendering, search, clustering — confirming one layer at a time has proven to be the fastest route in the end.