Logo Ahoi Kapptn!

Ahoi Kapptn!

Digital Agency

App Clips

Description

Philipp Jahoda von Ahoi Kapptn! präsentiert in seinem devjobs.at TechTalk die Grundidee der iOS App Clips und gibt ein Beispiel einer Implimentierung.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "App Clips," Philipp Jahoda explains how iOS App Clips deliver lightweight app experiences launched via an App Clip code and a launch URL, bypassing App Store installation. He covers key SDK capabilities—Apple Pay, Sign in with Apple, user-approved notifications limited to eight hours, and location services with geofencing—and walks through a coffee shop demo: creating an App Clip target in Xcode, configuring associated domains and entitlements, building the storyboard UI, setting up local experiences, and testing with schemes and environment variables. Viewers will be able to implement, test, and prepare App Clips in App Store Connect to streamline onboarding and encourage installation of the full app.

App Clips on iOS: From QR Scan to Transaction – A Technical Field Guide from the DevJobs Tech Talk with Philipp Jahoda (Ahoi Kapptn!)

Why App Clips matter right now

At the DevJobs Tech Talk titled “App Clips,” Philipp Jahoda, CTO and founder of Ahoi Kapptn!, delivered a clear, implementation‑first tour of a feature designed to remove friction from the first contact with your product. His punchline was simple and powerful: App Clips are “a very lightweight version of your iOS app,” usable without a full App Store install. For location‑centric or task‑driven use cases—buying, checking in, collecting—this shift is significant.

What stood out to us was how tightly the talk aligned with engineering practice: define the use case, pick the right iOS SDK features, and implement step by step in Xcode. A compact coffee‑shop scenario served as the running example: scan the App Clip code, either pay or sign in, and pick up your coffee at the counter. It’s a minimal flow that showcases the platform’s strengths.

The problem space: onboarding friction vs. instant usage

Traditionally, using an app starts with a visit to the App Store, a download, the first launch—and only then can the user complete a simple task. For small, repeatable actions (payment, check‑in, lightweight registration, pickup), this is unnecessary friction.

App Clips attack that friction head‑on:

  • A user scans an App Clip code (e.g., with the iPhone camera, QR code, or NFC tag)
  • A launch URL is invoked, which starts the relevant App Clip experience
  • No full installation is needed—the interaction is immediate and focused

As Philipp put it, App Clips remove the full installation step without giving up essential iOS capabilities. For transactional and location‑aware scenarios, the hurdle drops dramatically—while still serving as a gateway to the full app later.

Architecture at a glance: from App Clip code to UI

An App Clip starts via an invocation URL embedded in an App Clip code. The iOS chain—simplified—looks like this:

  1. Scan: An App Clip code (QR or NFC) is captured with the iPhone camera.
  2. Invoke: iOS recognizes the code and calls the embedded launch URL.
  3. App Clip card: The system presents an App Clip card—only partially customizable—which offers the “open” action.
  4. App Clip UI: After opening, the App Clip experience starts (your project’s UI), and the user completes the task.

The key is associating your domain with the App Clip experience (associated domains)—more on that shortly. One important nuance: the card UI is owned by the system and intentionally limited. The real interaction begins after the user opens the clip, where your storyboard‑driven UI takes over.

The iOS SDK features that matter most in App Clips

Philipp highlighted four capabilities that are particularly well‑suited to real‑world App Clip flows. Each ties back to the coffee‑shop example or its immediate context.

1) Apple Pay: checkout without friction

Apple Pay is the heavyweight tool for short, business‑critical flows. In App Clips, you can accept payments straight away, so a coffee purchase can be completed in one familiar, trusted payment dialog. No forms, no manual card entry—the system handles the heavy lifting.

2) Sign in with Apple: fast onboarding

Instead of a traditional registration form, an App Clip can offer Sign in with Apple. The benefit is a quick, low‑friction onboarding without typing. For spontaneous, location‑based interactions, this reduces drop‑off while still providing an identifiable account.

3) Notifications—with an 8‑hour window

App Clips can send notifications if the user grants permission. One key limitation: sending is allowed for only eight hours after the permission is granted. Philipp called this out explicitly—a crucial design constraint. App Clip pushes are best suited for timely, task‑adjacent messages (e.g., “Your order is ready”), not long‑term CRM.

4) Location services and geofencing

App Clips can access the user’s location. Geofencing is particularly useful: you can restrict the App Clip to show only when the user is near a specific place. Back to the coffee shop: if the invocation URL is scanned far away from the store, the App Clip won’t open. This acts as a guardrail against malicious or unintended use.

Step by step: implementing an App Clip in Xcode

Philipp laid out a clean path we’re recapping here, focusing on the concrete settings and artifacts involved.

1) Create or open an Xcode app project

Start with an iOS app project. If you already have one, you’ll extend it; otherwise, create a new one in Xcode.

2) Add a new target using the App Clip template

Add an App Clip target to your project. Xcode will generate the required files automatically. The result is a separate App Clip target with its own display name and bundle identifier.

Keep the separation in mind: the App Clip is its own target with its own identity, yet it remains tightly coupled to the host app.

3) Configure an associated domain

For iOS to map your launch URL to your App Clip target, you need to set up associated domains. The launch URL contains your domain; your App Clip must be linked to that domain via entitlements.

  • Add an entitlements file to your project
  • Add the “associated domain” entry
  • Provide the appropriate domain/subdomain for the App Clip (Philipp mentioned using their domain with an App Clip subdomain)

With that configuration, iOS knows which App Clip to start when the code is scanned.

4) Build the UI—using storyboards

In his example, Philipp built the App Clip UI “the traditional way,” using storyboards. That works well for a minimal, focused interface. The App Clip card shown by the system is only modifiable in specific ways; your storyboard screens define the real flow after the user taps “Open.”

The example screen contains two options:

  • Sign in with Apple (to get a free coffee)
  • Apple Pay (to pay for the coffee)

Two clear paths, no extra clutter—the essence of a good App Clip. Philipp also noted that you can do “almost anything” you could in a regular app, with some restrictions.

5) Local testing: configure a “local experience”

For production, you’ll set up your App Clip in App Store Connect. For local development, you can configure a “local experience” in the Developer Settings. As Philipp showed, you’ll:

  • Define a URL prefix (the start of your invocation URL)
  • Provide the App Clip bundle identifier
  • Add any additional parameters for your test launch

With that, you can trigger the launch without the full production configuration. This speeds up iteration and polishing.

6) Launch from Xcode: schemas and environment variables

For reproducible runs directly from Xcode, Philipp suggested a pragmatic setup: add environment variables in your scheme—e.g., the invocation URL and a separate “location” parameter (in his example, the office name “Ahoi Kapptn!”).

Inside the App Clip, you can map that location name to an actual geo coordinate and then enforce geofencing. That provides a security gate and simulates the near‑store behavior during development.

The coffee‑shop demo: a blueprint for focused experiences

The demo flow crystallizes the design principles into a concrete sequence:

  1. The user scans the App Clip code at the coffee shop (QR or NFC)
  2. iOS shows the App Clip card; the user taps “Open”
  3. The App Clip launches and offers two options: sign in or pay
  4. The task completes: either get a free coffee via Sign in with Apple or pay via Apple Pay, then pick it up at the counter

A few noteworthy traits:

  • The flow is intentionally short; critical steps rely on system‑provided dialogs (Apple Pay, Sign in with Apple)
  • No registration form, no manual payment entry—everything happens in a trusted iOS context
  • Optional geofencing can ensure the App Clip only functions near the store

This structure is a template for many location‑anchored tasks: ticket purchase at the gate, pickup and collection, access credentials at an event, lightweight account creation for on‑site services.

Product implications: what teams should optimize for

Philipp’s feature choices underscore the practical priorities—and Apple’s guardrails.

  • Radical clarity: An App Clip should execute one well‑defined job. Don’t turn it into a mini full app.
  • Lean on system flows: Apple Pay and Sign in with Apple are fast, secure, and familiar—ideal for conversion‑critical steps.
  • Respect the time window: The 8‑hour limit for notifications frames their purpose—timely, task‑adjacent messages.
  • Use location as a filter: Geofencing helps prevent misuse and keeps the experience relevant to the physical context.
  • Test like it’s live: Local Experience and Xcode scheme variables enable field‑like tests before setting up App Store Connect.

Technical touchpoints—practical but restrained

Although Philipp didn’t show code, his walkthrough implies a few concrete engineering habits:

  • Separate targets and identities: Give the App Clip its own target, display name, and bundle identifier. Keep the host app stable while iterating the clip.
  • Maintain entitlements: Associated domains are the glue. Without a correct entitlement setup, iOS won’t route your launch URL to the clip.
  • Keep the UI tiny: With storyboards, make the first screen do the heavy lifting—two options and done.
  • Ask permissions with purpose: Request push or location access in context, when the benefit is obvious to the user.
  • Parameterize for realism: With Xcode scheme variables (e.g., a “location” name), you can simulate scenarios that would otherwise require being on‑site. Iteration speeds up, and quality rises.

Security and misuse prevention in the App Clip context

One thread in the talk was the value of gating by location. Philipp illustrated how a location name passed via environment variables can be mapped to actual coordinates, which then back a geofence. Two benefits follow:

  • The App Clip remains usable only where it makes sense (near the store)
  • External triggering (e.g., the URL circulating elsewhere) won’t start the clip—misuse is discouraged

Combined with system flows (Apple Pay and Sign in with Apple), you get an experience that is both frictionless and appropriately guarded.

From App Clip to full app

Philipp closed with a perspective we share from a product standpoint: for the “right” scenarios, App Clips can “drastically” improve the user experience—and serve as a convincing teaser for a later full install. When a user sees immediate value on site (purchase, pickup, entry), readiness to install the complete app tends to rise.

The discipline is to design the App Clip as a lightweight, purpose‑built experience—not a shrunken copy of the full app. The clip solves a job; the full app deepens the relationship.

A practical checklist (based on the session)

  • Sharpen the use case: one job, clear value, relevant to place or moment
  • Select SDK features: Apple Pay, Sign in with Apple, notifications (remember the 8‑hour limit), location/geofencing
  • Project setup: add an App Clip target; pick a display name and bundle identifier
  • Associated domains: configure entitlements; set domain/subdomain for the clip
  • UI: storyboard screen with minimal choices (e.g., “Sign in” or “Pay”)
  • Local testing: Developer Settings → Local Experience (URL prefix, bundle ID, parameters)
  • Xcode schemas: environment variables (invocation URL, location name) for reproducible runs
  • Production: App Store Connect for the final App Clip configuration

Quotes and core statements from Philipp Jahoda

A few remarks that encapsulate the App Clip philosophy:

“App Clips are a very lightweight version of your iOS app.”

“It’s possible to accept payments via Apple Pay in App Clips.”

“It’s only possible to send notifications for eight hours after users have given permission in App Clips.”

“We like to use location services … geofencing … so the App Clip only opens at the intended place.”

“The App Clip card can only be modified in certain ways; we define the actual UI in storyboards.”

These capture the balance that App Clips demand: maximum focus, minimal friction, secured by system features and context.

Conclusion: our takeaways from the DevJobs Tech Talk “App Clips”

The “App Clips” session with Philipp Jahoda (Ahoi Kapptn!) offered a clean, practice‑oriented journey from the friction problem to the right iOS building blocks to the concrete setup in Xcode. The coffee‑shop demo provided a reusable blueprint that many local or situational services can adopt.

  • App Clips lower the entry barrier dramatically
  • System‑native flows (Apple Pay, Sign in with Apple) deliver speed and trust
  • Notifications are for near‑term messages (8‑hour window)
  • Location/geofencing provides context and safeguards
  • Associated domains and local experience are the technical keys for a robust start and efficient testing

Assembling these pieces yields a production‑ready experience that does exactly what users need in the moment—while increasing the likelihood they’ll install the full app later. Or, as Philipp framed it in closing: used correctly and for the right use cases, App Clips can drastically improve user experience and help convince users to download the full app.

For contact and a look at his open‑source work, Philipp pointed to email/website and his GitHub handle “philj.”

More Tech Talks

More Tech Lead Stories