Skip to main content
Choose UIKit when the request is primarily a standard social surface, fast launch, white-label experience, or supported UIKit customization. Vise keeps UIKit fit and customization advisory while continuing to validate customer-owned configuration, SDK setup, authentication, and project sensors.

​
Suggested request

Use social.plus UIKit to launch a standard community feed in this app. Recommend the lowest customization level that fits the existing design system, and do not hand-roll the standard surface from SDK primitives.

​
Confirm the path before implementation

vise inspect .
vise plan . --request "Use social.plus UIKit to launch a standard community feed" --summary
Review solutionPath and uikitCustomization. If UIKit is the chosen path, repeat the plan and initialize with explicit answers such as: 
vise plan . --request "Use social.plus UIKit to launch a standard community feed" \
  --answer solution_path=uikit \
  --answer uikit_customization=dynamic-ui
Also answer the platform, route, region, identity, and target questions Vise reports. The exact customization choice may instead be component styling, localization, behavior overrides, fork-and-extend, or a hybrid path.

​
Implementation boundary

  • Treat UIKit installation, provider/page, behavior, localization, and customization guidance as the primary implementation source.
  • Do not execute direct-SDK feed/chat/profile steps for a locked UIKit route.
  • Use hybrid only when UIKit covers standard surfaces and direct SDK code is genuinely needed for differentiated app behavior.
  • Do not claim deterministic validation of UIKit internals hidden outside the customer repository.
Finish with vise check, vise validate, project sensors, and a real app launch. A themed UIKit screen still requires product QA and runtime verification.

CLI reference

Review planning, validation, evidence, and sensor commands.