AirCard: Custom Apple Wallet Card Skins and Lockscreen Passcode Themes on iOS 18+ Without a Jailbreak

What AirCard changes, and the users it is built for

AirCard assigns custom artwork to individual Apple Pay and Wallet cards, and it applies lockscreen passcode button themes in the .passthm format to iOS 18+ devices. Both jobs happen from a Mac over a USB connection. The README states the project is tested on an iOS 27 release and requires no jailbreak.

The second half of the tool is arguably the more interesting one. AirCard can open an existing Cowabunga or Nugget theme package, let you adjust button artwork, reposition photos inside the keypad buttons, and then re-export or flash it. There is also a creator that builds a theme from a single wallpaper through what the README calls Seamless Poster Slicing, or key by key through Individual Keys.

This is not a tool for a general iPhone owner. It assumes a Mac, a USB cable, an unlocked and trusted device, and a willingness to right-click past a Gatekeeper prompt. The README is explicit that macOS users need no Homebrew, Python packages or terminal setup, and that device-communication utilities and image engines are bundled inside the app. That packaging is what makes the audience wider than the usual exploit-tool crowd, but the workflow still ends with force-closing Wallet or restarting the iPhone.

How AirCard talks to the iPhone: airlift, MobileDevice and the unified log

The mechanism is visible in the repository layout and the Makefile. Two native helpers are compiled: build/device_helper links against Foundation, CoreFoundation and the private MobileDevice framework, while build/airtraffic_host links against AirTrafficHost. Both are built with -fobjc-arc and ad-hoc signed with codesign --force --sign -. The Makefile builds universal binaries for arm64 and x86_64.

The README credits the core exploit to airlift, described as the original AirTraffic/ATAirlock sandbox escape and proof of concept underlying AirliftFFI. AirCard is the front end over that escape, not a reimplementation of it.

Card detection works differently from flashing. The README says the scanner reads the iPhone's unified log service, including Info and Debug events, which is why the instructions ask you to open Apple Pay, authenticate with Face ID, and tap a card to trigger detection. That is also the source of the tool's most documented failure: on iOS 18.6.2 the legacy log service can show Wallet activity while omitting the resource lookup messages that carry card identifiers. Values iOS replaces with <private> are not recoverable by the scanner, according to the README. A log line reading Connected to the unified device log stream is the signal that the reader is attached.

The repository also contains aircard.py, aircard_backend.py, apply_card_skin.py and card_assets.py alongside the Swift app entry point, so the Python layer handles image preparation and the skin application path while the compiled helpers handle device communication.

Installing AirCard from the DMG and flashing a first card skin

The README points macOS users at the AirCard.dmg asset on the Releases page. Drag AirCard.app into Applications. If macOS shows an unidentified developer prompt on first launch, either right-click the app and choose Open, or clear the quarantine attribute from a terminal:

sudo xattr -cr /Applications/AirCard.app

The README describes this as the first-launch Gatekeeper workaround, not a permanent setting. After that, connect the iPhone by USB, unlock it, and trust the computer.

With the device attached, open the Wallet Cards tab and click Scan Cards. The README's sequence is: double-click the side button to open Apple Pay, authenticate with Face ID, then tap your card to trigger detection. The Log view should show the connection line before the taps register. Once a card appears, drop an image onto the card mockup or click the card and pick artwork, then click Flash Skins. The README says you must force-close the Wallet app from the App Switcher, or reboot, before the new design shows.

Building from source instead of using the DMG follows the README exactly:

git clone https://github.com/mak5er/AirCard.git
cd AirCard
chmod +x build.sh
./build.sh

The README states this produces universal arm64 and x86_64 binaries, bundles dependencies into build/AirCard.app, and writes build/AirCard.dmg. The Makefile targets are build/device_helper and build/airtraffic_host, so the build depends on the private MobileDevice and AirTrafficHost frameworks present on the host Mac.

Applying a .passthm passcode theme, and why a restart is mandatory

Switch to the Passcode Themes tab and drag a .passthm file into the window, or click Choose .passthm File. AirCard inspects the theme and renders an interactive preview across the numeric keypad, covering 0 through 9 plus the asterisk and hash keys. Click Apply Passcode Theme, then restart the iPhone. The README is clear that the restart is what reloads the lockscreen cache.

One detail worth noting is locale handling. The README states AirCard expands and flashes custom keypad assets for all system locales, naming English, Ukrainian, Russian, Spanish, German and French among others, and generates both standard and Bold Text cache bitmaps using the --white and --white-bold suffixes. That means a theme does not silently break when the phone language changes or when accessibility bold text is enabled. Anyone who has chased a half-themed keypad after switching system language will recognise why this matters, and the README treats it as a supported path rather than an edge case.

The restart requirement is the real cost here. A theme change is not a live preview on the device; it is a flash followed by a reboot. If you are iterating on button artwork, budget for that cycle each time.

Where AirCard fails: private log values, scanner coverage and platform limits

The most concrete limitation is documented by the project itself. Card detection depends on resource lookup messages in the unified log, and the README notes that on iOS 18.6.2 the legacy log service can show Wallet activity while omitting exactly those messages. When that happens, Scan Cards returns nothing even though the phone is connected and Apple Pay is open. The README also states that values iOS replaces with <private> cannot be recovered by the scanner. There is no fallback path described for that case.

A second limitation is the restart requirement on both workflows. Force-closing Wallet or rebooting the iPhone is part of the documented procedure, not an optional step, so this is not a tool for someone who wants to preview a skin and keep using the phone uninterrupted.

The platform boundary is absolute. Despite the name, this AirCard has nothing to do with the Netgear or Sierra Wireless hotspots, the Rolling Square tracker, or the Android and Windows searches that share the term. The README describes a macOS-only app that talks to an iPhone over USB. There is no Windows build, no Android support and no self-hosted server component. If you do not own a Mac, the project offers you nothing.

Finally, the README asks users who hit a zero-card scan to report their iPhone model, iOS version, macOS version and AirCard version or commit, while warning against posting full device logs or card identifiers. That request implies scanner coverage is still incomplete for some device and OS combinations, and docs/wallet-card-detection.md is the place the README points to for the verified environment.

AirCard compared with Cowabunga and Nugget theme workflows

The closest comparison the README itself makes is with Cowabunga and Nugget. AirCard opens .passthm packages produced by those tools, which means it is designed to sit alongside them rather than replace them. The difference is in where the work happens. Cowabunga and Nugget are iPhone-side tools; AirCard moves the theme editing and the flashing to a Mac app with a live keypad preview and per-button photo framing, and then pushes the result over USB.

That split has consequences. You get a larger editing surface and a real preview, but you give up the ability to tweak a theme on the phone itself, and you add a cable, a trusted-computer pairing and a restart to every iteration. AirCard also handles Wallet card artwork, which the theme tools are not described as doing.

On the exploit side, AirCard depends on airlift rather than shipping its own escape. That is a reasonable division, and it also means AirCard's compatibility window is tied to whatever airlift supports on a given iOS release. The README's tested-on-iOS-27 claim is a point-in-time statement, not a guarantee for future releases.

Licence, maintenance and what an upgrade actually costs you

AirCard is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. The repository includes the LICENSE file. The bundled airlift exploit is credited to 0xjohnny and carries its own repository and licence, so anyone redistributing AirCard should check that dependency separately. Nothing here is legal advice.

Maintenance looks current. The last push was on 2026-09-22, and v1.2.4 was released the same day, following v1.2.3 and v1.2.2 on 2026-09-19. The v1.2.2 release notes describe it as Ultra-Fast Atomic Batch Injection. The repository is not archived.

Upgrade cost is dominated by iOS, not by AirCard. Each iOS release can change the unified log behaviour the scanner relies on, as the iOS 18.6.2 note shows, and it can also change whether the underlying airlift escape still works. Budget for re-verifying card detection after every iOS update, and read the release notes before assuming a new AirCard build covers your OS. The macOS side is comparatively stable, since the DMG is universal and bundles its dependencies.

Editorial conclusion

AirCard suits Mac owners who already accept Gatekeeper workarounds and want per-card Wallet artwork or .passthm passcode themes on iOS 18+ without jailbreaking. It is the wrong tool for anyone on Windows or Android, and for users who cannot tolerate a full iPhone restart after flashing. Before adopting it, verify your iPhone model and iOS version against docs/wallet-card-detection.md, confirm the Scan Cards step actually finds your cards, and check whether your device's unified log replaces card identifiers with <private>, because the README states those values cannot be recovered.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Mak5er/AirCard on GitHub
4. README
5. Releases