iOS Configuration Profile Compliance Platform
Config Pulse is a platform for verifying that iOS configuration profiles remain installed — and holding users accountable when they don't. It combines DNS-over-HTTPS filtering, cryptographically signed iOS profiles, daily compliance check-ins, and a sponsor escalation system into a single infrastructure.
Download on the App Store · configpulse.com · Built by Robert Sneiderman
| Config Pulse Website | BetBarrier Website |
|---|---|
 |
 |
| iOS Dashboard | iOS Check-In |
|---|---|
 |
 |
iOS configuration profiles are powerful — they can enforce DNS filtering, VPN policies, email settings, and security restrictions at the OS level. But they have a fatal flaw: any user can remove them in seconds, silently, with no record and no consequence.
This makes profiles unreliable for any scenario where compliance actually matters: gambling recovery, parental controls, corporate device policies, or security verification.
Config Pulse solves this by making profile removal a visible, accountable action rather than a private one.
Config Pulse operates on a simple principle borrowed from parole systems, sobriety programs, and workplace attestations:
You must prove compliance. Silence is non-compliance.
Users check in daily through the iOS app. The app verifies their profile status at the moment of check-in and reports it to the server. If check-ins stop, status degrades through a four-tier compliance model:
| Status | Condition |
|---|---|
| Verified | Check-in within 24 hours, profile present |
| Unverified | No check-in in 24 hours, status unknown |
| Non-Compliant | No check-in in 48 hours OR profile missing |
| Escalated | Sponsor alert policy triggered, action required |
When sponsor alerts are configured, missed check-ins or detected profile removal can notify an accountability partner — someone the user chose voluntarily, in a moment of clarity, to hold them accountable during moments of weakness.
┌─────────────────────────────────────────────────────────────┐
│ iOS Device │
│ │
│ ┌──────────────┐ ┌──────────────────────────────────┐ │
│ │ Config Pulse │ │ DNS Configuration Profile │ │
│ │ iOS App │ │ (Signed .mobileconfig) │ │
│ │ │ │ │ │
│ │ • Check-ins │ │ • Routes DNS-over-HTTPS to │ │
│ │ • Profile │ │ Config Pulse resolver │ │
│ │ detection │ │ • Blocks domains via NXDOMAIN │ │
│ │ • VPN detect │ │ • Cryptographically signed │ │
│ │ • Keychain │ │ • Per-user UUID binding │ │
│ │ persist │ │ │ │
│ └──────┬───────┘ └──────────────┬───────────────────┘ │
│ │ │ │
└─────────┼───────────────────────────┼───────────────────────┘
│ HTTPS │ DNS-over-HTTPS
▼ ▼
┌─────────────────────┐ ┌─────────────────────────┐
│ API Server │ │ DNS Resolver │
│ (Node.js/Express) │ │ (Python/Flask) │
│ │ │ │
│ • Profile generation│ │ • 210K+ blocked domains │
│ • Check-in tracking │ │ • Static + dynamic lists │
│ • Heartbeat monitor │ │ • 5-min DB refresh cycle │
│ • Sponsor alerts │ │ • Parent domain matching │
│ • Stripe billing │ │ • NXDOMAIN for blocked │
│ • Admin dashboard │ │ • Forward to Google DNS │
│ │ │ for everything else │
│ 70+ API endpoints │ │ │
│ 1,153 backend tests │ │ │
└────────┬────────────┘ └──────────┬──────────────┘
│ │
▼ ▼
┌─────────────────────────────────────────────────────┐
│ Supabase │
│ (PostgreSQL + Row Level Security) │
│ │
│ • User profiles • Heartbeat events │
│ • Device registrations • Check-in history │
│ • Sponsor relationships• Dynamic blocklist │
│ • Subscription state • Alert delivery logs │
└─────────────────────────────────────────────────────┘
Notifications: Resend (email) + Twilio (SMS)
Payments: Stripe (subscriptions + promo codes)
Hosting: Railway (API) + GCP Cloud Run (DNS) + Vercel (frontend)
Most content blockers route traffic through a VPN. I chose DNS filtering because:
- No battery drain — DNS resolution adds negligible overhead vs. tunneling all traffic
- Works across all apps and browsers — not just Safari or a specific browser extension
- Can't be toggled off in Control Center — removing the profile requires going into Settings, which is a deliberate action (and one we can detect)
- No bandwidth bottleneck — only DNS queries touch the servers, not actual traffic
The tradeoff: we can't do deep packet inspection or filter by URL path. But for domain-level blocking (which covers the vast majority of use cases), DNS is the right layer.
The server dynamically generates .mobileconfig XML payloads with:
- CMS cryptographic signing so iOS trusts the profile without user warnings
- Per-user UUID binding (same UUID on reinstall, looked up by email)
- XML-escaped user inputs to prevent injection attacks
This means each user gets a unique profile tied to their account, and the signing means iOS displays it as a verified configuration rather than an untrusted payload.
Most iOS apps lose all state when uninstalled. Config Pulse uses a dual-write persistence strategy:
- Keychain — survives app deletion and reinstall (iOS preserves Keychain items)
- UserDefaults — faster for reads during normal operation
On launch, the app reconciles both sources: takes the maximum streak count, earliest first-check-in date, and latest last-check-in timestamp. This means a user can't reset their compliance history by deleting and reinstalling the app — and the system can distinguish between a fresh install and a reinstall (sending different notifications to sponsors for each).
The app doesn't just check one signal to determine if the DNS profile is active. It:
- Makes HTTP HEAD requests to multiple known-blocked domains using an ephemeral URLSession (no DNS cache)
- Classifies responses by NSURLError code:
-1003,-1004,-1006= blocked; HTTP 200 = reachable - Uses majority voting across all test URLs to determine the final status
This approach is resilient against individual domain changes, DNS propagation delays, and transient network errors. A single false positive doesn't trigger a sponsor alert.
Not all compliance failures are equal:
| Alert Level | Trigger | Meaning |
|---|---|---|
CHECKIN_MISSED |
48 hours without check-in | Soft — could be vacation, phone off |
HEARTBEAT_LOST |
24 hours without heartbeat | Medium — device may be offline |
DNS_DISABLED |
Profile removal detected | Critical — protection actively removed |
Each tier has independent cooldowns and spam limits to prevent alert fatigue for sponsors (max 5 emails/hour to any single sponsor, 1-hour cooldown between duplicate alerts per user).
Sending alerts to third parties requires careful guardrails:
- Sponsor email verification — confirms the registered sponsor matches the request
- Subscription gating — only premium users trigger sponsor alerts
- Per-user cooldown — prevents rapid-fire duplicate alerts
- Per-sponsor spam limit — protects sponsors from notification overload
- Timing context — every alert includes last heartbeat and check-in timestamps so sponsors have full context
BetBarrier is the first product built on Config Pulse — a gambling site blocker with accountability partner support.
Why gambling: Online gambling is a $100B+ industry designed to be addictive and available 24/7. Existing blockers (browser extensions, VPN-based tools, router blocking) all share the same failure mode: they can be disabled in seconds, silently, when urges are strongest. BetBarrier addresses this by making disabling protection a visible, accountable action.
The blocklist: 210,000+ gambling domains aggregated from multiple sources, updated daily, covering online casinos, sportsbooks, poker sites, and crypto gambling platforms. Both a static list and dynamic additions via the database.
The behavioral model: Inspired by pre-commitment devices in behavioral economics — the idea that people make better decisions in calm moments than under stress. Users set up BetBarrier when thinking clearly, choosing an accountability partner they respect. When cravings hit later, the earlier decision steps in: disabling protection means someone will know.
Config Pulse's infrastructure is designed to be application-agnostic:
- Family accountability — parents verify parental control profiles remain active via daily check-ins
- Corporate compliance — employees attest that required VPN/security profiles are installed on personal devices used for work
- Security verification — verify DNS-over-HTTPS, VPN, or security profiles are active
The core loop is always the same: install a profile, check in daily to prove it's there, escalate if check-ins stop.
| Layer | Technology |
|---|---|
| iOS App | Swift, SwiftUI, Keychain Services |
| API Server | Node.js, Express (70+ endpoints, 1,153 tests) |
| DNS Resolver | Python, Flask, deployed on GCP Cloud Run |
| Frontend | React, Vite, deployed on Vercel |
| Database | Supabase (PostgreSQL + Row Level Security) |
| Payments | Stripe (subscriptions, webhooks, promo codes) |
| Resend (transactional + weekly sponsor reports) | |
| SMS | Twilio (complementary sponsor notification channel) |
| Infrastructure | Railway, GCP Cloud Run, Vercel, Cloudflare |
See docs/tech-stack.md for detailed rationale behind each choice.
- Architecture Deep Dive — DNS pipeline, profile signing, heartbeat system, persistence strategy
- DNS-Level Blocking — How DNS-over-HTTPS filtering works and its tradeoffs
- Security Model — Rate limiting, RLS, notification security, input validation
- Tech Stack — Technology choices and rationale
- 1,153 backend tests covering all API endpoints, webhook handlers, edge cases
- 162 frontend tests for the React dashboard
- iOS app compiled and tested on device
- Config Pulse (App Store): apps.apple.com/app/config-pulse/id6757651341
- Config Pulse (Website): configpulse.com
- BetBarrier (Website): betbarrier.app
- Author: Robert Sneiderman
All rights reserved. This repository contains documentation and architecture descriptions only. Source code is proprietary and not included.
© 2026 Robert Sneiderman