AdminConsole
Tutorials/Beginner
Beginner25 miniOS

Add Mappls to an iOS app with Swift Package Manager

Select distribution packages, configure credentials, and render the native map.

By the endA native Swift map screen.
Real-world scenario

Build against an explicit contract

A Swift application needs a native map installed through Swift Package Manager with explicit credential and view ownership.

A Mappls developer projectA restricted iOS applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

A Swift application needs a native map installed through Swift Package Manager with explicit credential and view ownership. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Select the supported distribution

Pin an approved package version, resolve its transitive requirements, and keep credentials in build/runtime configuration rather than source control.

Maps · SDK or product slice
<!doctype html>
<html>
  <head>
    <script src="https://sdk.mappls.com/map/sdk/web?v=3.0&access_token=YOUR_STATIC_KEY"></script>
    <style>html, body, #map { height: 100%; margin: 0; }</style>
  </head>
  <body>
    <div id="map"></div>
    <script>
      const map = new mappls.Map("map", {
        center: { lat: 28.612964, lng: 77.229463 },
        zoom: 12
      });
    </script>
  </body>
</html>
Step 3

Create the view on the main actor

Own the map view from one view controller or SwiftUI wrapper, make constraints deterministic, and avoid duplicate initialization during view updates.

Step 4

Treat location as optional evidence

Ask only when a user-visible feature needs it, retain accuracy and timestamp, and provide search or manual map movement when authorization is absent.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when cold and warm launches render once; layout changes preserve the selected feature; denied location has a complete alternate flow. Capture provider request identity without logging credentials or unnecessary precise location.

Recovery design

Failure modes you must exercise

package resolution conflict

Fail fast with a typed, user-safe outcome and preserve the original request identity.

view recreated with duplicate delegates

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

location authorization changes at runtime

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Acceptance criteria

Definition of done

cold and warm launches render oncelayout changes preserve the selected featuredenied location has a complete alternate flow

iOS production checks

Package and binary versions belong to the same release lineSecrets are not recoverable from the app bundleInfo.plist purpose strings match actual collectionDelegates, observers, and background sessions terminate cleanly
Grounded implementation

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Tutorial complete

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.