Skip to content

creator scanner

Turn your repo intoapp kits people can build with.

Upload source, paste code, or point axint at a public repo. axint finds reusable Apple-native pieces, turns them into installable Registry kits, and shows how an agent can compose them into a working demo before anyone else installs them.

Extract componentsPublish manually
Secret scan before any draftLicense + ownership promptsOpen-source sharing pathCertification checklistHuman + agent review
01

Find what others can reuse

axint scans for App Intents, SwiftUI views, widgets, app scaffolds, and reusable systems already living inside your code.

02

Draft the package for you

Each candidate gets a name, reuse promise, proof checklist, license note, README outline, and an agent-readable next step.

03

Nothing goes live without approval

The creator decides what becomes open source, certified, private, or ignored. Pattern learning is explicit and can stay off.

Source intake

Upload source. axint finds Registry components.

Drafts only

What this turns into

Your repo becomes installable source kits first. From there, a builder or agent can compose those kits into a working Apple demo, run proof, and decide what should be open source, private, or paid.

Extraction result

Registry drafts ready

certification first
6
Components
3
Selected
6
Strong fit
2
Review
1 files read37 lines scannedSwift detected

Demo app path

Daily command center from 3 Registry-ready components

A builder can start from installable Apple-native source kits instead of asking an agent to invent every App Intent, view, widget, and proof loop from scratch.

App Intents

Log Water Intent package

Siri and Shortcuts actions

axint add @your-handle/log-water-intent --to RegistryComponents/log-water-intent-package
WidgetKit

Hydration Ring Widget package

the home-screen widget

axint add @your-handle/hydration-ring-widget --to RegistryComponents/hydration-ring-widget-package
SwiftUI

Creator Profile View package

the visible app screen

axint add @your-handle/creator-profile-view --to RegistryComponents/creator-profile-view-package
Agent build prompt
Build a working Apple app demo called "Daily command center" from these Axint Registry components.

Use the installed packages as source contracts. Do not rewrite them from memory.
Create a small SwiftUI shell that makes each selected capability visible and demoable.
Keep the package boundaries intact so another builder can inspect, replace, or extend each component.
Run Axint validation after composition and write the proof summary into .axint/run/latest.md.

Selected packages:
- @your-handle/log-water-intent: App Intents for Siri and Shortcuts actions
- @your-handle/hydration-ring-widget: WidgetKit for the home-screen widget
- @your-handle/creator-profile-view: SwiftUI for the visible app screen

Source signal: sample source
Surfaces: App Intents, WidgetKit, SwiftUI
Proof steps
  • Install the selected Registry packages into a fresh demo workspace.
  • Compose a small SwiftUI app shell that exposes every package in one flow.
  • Run Axint compile and validation for every source contract.
  • Run a focused Xcode or Swift proof for the generated Apple surface.
  • Attach the run report, screenshots, and component list before sharing.
Shareable claims
  • Started from 3 reusable Apple-native components.
  • Every selected package includes proof checks before it becomes public.
  • The demo is composed from inspectable source, not a static screenshot.
01
Certification candidateApp Intents94% confidence

Log Water Intent package

@creator/log-water-intent

A reusable Siri and Shortcuts action that another builder can install, inspect, and adapt without starting from blank Swift.

Registry fit
excellent
1 source file connected
Reusable boundary
  • Intent definitions have a clean command boundary.
  • Parameters, titles, and result behavior can be documented and tested.
  • Agents can reuse the shape without guessing Apple boilerplate.
Certification checks
  • Compile the generated Swift intent.
  • Verify parameter names and localized titles.
  • Attach an example invocation and expected result.
Review notes
  • Remove app-specific account IDs, API keys, or private endpoints.
  • Document required entitlements or permissions.
Source evidence
  4  import HealthKit
  5  import StoreKit
  6  
  7  struct LogWaterIntent: AppIntent {
  8    static var title: LocalizedStringResource = "Log water"
  9    @Parameter(title: "Amount") var amount: Double
 10    func perform() async throws -> some IntentResult { .result() }
 11  }
 12  
 13  struct HydrationRingWidget: Widget {
 14    var body: some WidgetConfiguration {
 15      StaticConfiguration(kind: "hydration", provider: Provider()) { entry in
 16        Text("Hydration")
 17      }
 18    }
 19  }
 20  
 21  struct CreatorProfileView: View {
Extract the intent into a minimal package, run Axint validation, then generate the install README.
02
Certification candidateWidgetKit90% confidence

Hydration Ring Widget package

@creator/hydration-ring-widget

A reusable home-screen widget foundation with timeline structure, sample entries, and proof-ready packaging.

Registry fit
excellent
1 source file connected
Reusable boundary
  • Timeline/provider structure repeats across many apps.
  • The widget can ship with sample data and visible preview proof.
  • Buyers can swap data sources while keeping Apple-native shape.
Certification checks
  • Compile the widget extension sample.
  • Attach preview screenshot for supported families.
  • Document timeline refresh assumptions.
Review notes
  • Separate private data sources from the reusable provider.
  • Document supported widget families.
Source evidence
 10    func perform() async throws -> some IntentResult { .result() }
 11  }
 12  
 13  struct HydrationRingWidget: Widget {
 14    var body: some WidgetConfiguration {
 15      StaticConfiguration(kind: "hydration", provider: Provider()) { entry in
 16        Text("Hydration")
 17      }
 18    }
 19  }
 20  
 21  struct CreatorProfileView: View {
 22    var body: some View {
 23      ScrollView {
 24        Button("Message") {}
 25        Button("Install source kit") {}
 26      }
 27      .accessibilityIdentifier("creator-profile-scroll")
Extract the widget, add sample timeline entries, and produce a validation packet.
03
Certification candidateSwiftUI88% confidence

Creator Profile View package

@creator/creator-profile-view

A polished Apple-native screen or component that can become a reusable starter for apps, agents, and demos.

Registry fit
strong
1 source file connected
Reusable boundary
  • The visual surface is easy for buyers to inspect.
  • State, layout, and accessibility identifiers can be packaged together.
  • A screenshot and UI test can make the component trustworthy.
Certification checks
  • Compile in a minimal SwiftUI preview target.
  • Attach a screenshot proof.
  • Check accessibility labels and tappable controls.
Review notes
  • Replace private branding, copy, and app-specific routes.
  • Move hardcoded sample data into documented inputs.
Source evidence
 18    }
 19  }
 20  
 21  struct CreatorProfileView: View {
 22    var body: some View {
 23      ScrollView {
 24        Button("Message") {}
 25        Button("Install source kit") {}
 26      }
 27      .accessibilityIdentifier("creator-profile-scroll")
 28    }
 29  }
 30  
 31  final class PurchaseCoordinator {
 32    func buySourceKit(productID: String) async throws {}
 33  }
 34  
 35  final class HydrationUITests: XCTestCase {
Wrap the view in a small sample app, add preview data, and generate the component README.
04
Open-source trust builderXCTest / UI proof82% confidence

Hydration UITests package

@creator/hydration-uitests

A reusable proof loop that helps humans and agents verify fragile Apple UI behavior instead of relying on screenshots alone.

Registry fit
strong
1 source file connected
Reusable boundary
  • Proof harnesses build trust for the rest of the package.
  • Agents can follow selectors, expected behavior, and rerun commands.
  • Open-source proof increases confidence in paid or private components later.
Certification checks
  • Run the focused test locally.
  • Attach the passing command and artifact path.
  • Document which selectors are app-specific.
Review notes
  • Keep app-specific bundle identifiers configurable.
  • Do not publish private fixture data.
Source evidence
 24        Button("Message") {}
 25        Button("Install source kit") {}
 26      }
 27      .accessibilityIdentifier("creator-profile-scroll")
 28    }
 29  }
 30  
 31  final class PurchaseCoordinator {
 32    func buySourceKit(productID: String) async throws {}
 33  }
 34  
 35  final class HydrationUITests: XCTestCase {
 36    func testProfileActionsAreHittable() {}
 37  }
Turn the proof into an open-source companion package that raises trust for the source kit.
05
Needs reviewHealthKit80% confidence

Hydration UITests package

@creator/hydration-uitests

A permission-aware Apple health data component for wellness apps that need a reliable starting point.

Registry fit
strong
1 source file connected
Reusable boundary
  • Health permission flows are painful to recreate.
  • Data types and write/read boundaries can be documented.
  • Good proof gives buyers confidence before integrating sensitive code.
Certification checks
  • Document HealthKit usage descriptions.
  • Verify no personal sample health data is included.
  • Compile a minimal sample flow.
Review notes
  • Health-related code needs extra privacy review.
  • Block publishing if sample data contains personal records.
Source evidence
  1  import SwiftUI
  2  import AppIntents
  3  import WidgetKit
  4  import HealthKit
  5  import StoreKit
  6  
  7  struct LogWaterIntent: AppIntent {
  8    static var title: LocalizedStringResource = "Log water"
  9    @Parameter(title: "Amount") var amount: Double
 10    func perform() async throws -> some IntentResult { .result() }
 11  }
 12  
 13  struct HydrationRingWidget: Widget {
 14    var body: some WidgetConfiguration {
 15      StaticConfiguration(kind: "hydration", provider: Provider()) { entry in
 16        Text("Hydration")
 17      }
 18    }
Separate the HealthKit boundary, document permissions, and mark it for human privacy review.
06
Needs reviewStoreKit78% confidence

Purchase Coordinator package

@creator/purchase-coordinator

A clean purchase and entitlement boundary that can help another Apple app add monetization safely.

Registry fit
strong
1 source file connected
Reusable boundary
  • Product loading and entitlement state are common across apps.
  • The boundary can be packaged without the original app UI.
  • A proof checklist makes this safer than copying random snippets.
Certification checks
  • Run against a StoreKit configuration file.
  • Document products and entitlement states.
  • Add restore/refund behavior notes.
Review notes
  • Payment code must go through stricter review before public listing.
  • Remove production product IDs unless intentionally documented.
Source evidence
  2  import AppIntents
  3  import WidgetKit
  4  import HealthKit
  5  import StoreKit
  6  
  7  struct LogWaterIntent: AppIntent {
  8    static var title: LocalizedStringResource = "Log water"
  9    @Parameter(title: "Amount") var amount: Double
 10    func perform() async throws -> some IntentResult { .result() }
 11  }
 12  
 13  struct HydrationRingWidget: Widget {
 14    var body: some WidgetConfiguration {
 15      StaticConfiguration(kind: "hydration", provider: Provider()) { entry in
 16        Text("Hydration")
 17      }
 18    }
 19  }
Extract purchase logic into a standalone boundary and require payment review before publishing.

learning model

axint gets smarterwithout taking ownership.

The Registry can learn from repeated structure — which packages people reuse, which proof checks fail, what builders search for, and which Apple-native patterns travel. It does not need to copy a creator's source code to improve component discovery.

Pattern learning is opt-in

Creators can allow anonymous structure and validation outcomes to improve axint. Raw source training stays explicit.

Private source stays private

The product promise is draft generation and proof. Publishing, licensing, and learning permissions stay under creator control.

Agents can operate it

Every output is structured: draft queue, risk list, proof plan, review status, and the next command for human or agent workflows.

Choose how each kit is shared

Keep a component private, publish it open source, or prepare it for a paid source kit once the proof and licensing are ready.