Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
76 lines (52 loc) · 3.45 KB

CONTRIBUTING.md

File metadata and controls

76 lines (52 loc) · 3.45 KB
Raw

Contributing to HushMap

Thanks for your interest in making the world more navigable for people with sensory sensitivities. 💙 Contributions of all kinds are welcome — code, docs, bug reports, and even sensory reports from your own neighbourhood.

Ways to contribute

  • 🐛 Report a bug — open an issue with steps to reproduce, device/iOS version, and screenshots if relevant.
  • 💡 Suggest a feature — check the Roadmap first, then open a feature-request issue.
  • 🛠️ Send a pull request — fixes, improvements, tests, docs.
  • ♿ Improve accessibility — VoiceOver, Dynamic Type, contrast, and clear language changes are especially valued.

Development setup

Prerequisites: Xcode 16+, an iOS 18+ simulator, and a Google Maps Platform key (Maps SDK for iOS + Places API enabled).

git clone https://github.com/nickjlamb/HushMap.git
cd HushMap
cp HushMap/Config.xcconfig HushMap/Config-Local.xcconfig
#   → add your Google keys to Config-Local.xcconfig (it is gitignored)
open HushMap.xcodeproj      # SPM resolves on first open, then ⌘R

AI features (optional): predictions and venue facts call App-Check-gated Cloud Functions. To run them against your own backend, deploy functions/ to your Firebase project — see functions/DEPLOY.md. The rest of the app runs without them.

Building from the command line

Use a -destination, not -sdk (an embedded watchOS target means -sdk iphonesimulator mis-targets it):

xcodebuild -project HushMap.xcodeproj -scheme HushMap \
  -destination 'platform=iOS Simulator,name=iPhone 16' build

Cloud Functions

cd functions
npm ci
npm run build      # tsc — this is what CI checks

Architecture & conventions

Read docs/ARCHITECTURE.md and CLAUDE.md for the full picture. In short:

  • MVVM + SwiftUI + SwiftData.
  • Services are @MainActor singletons (shared) that own business logic and I/O.
  • View models use @Published; views use @State / @StateObject / @ObservedObject.
  • All UI work on @MainActor; async I/O via async/await.
  • Never commit secrets. Keys live in Config-Local.xcconfig (gitignored). The OpenAI key stays server-side.
  • Match the surrounding code — naming, comment density, and idioms.

Pull request workflow

  1. Branch off main (feature/…, fix/…).
  2. Keep it focused — one logical change per PR.
  3. Build cleanly — the iOS app compiles with zero warnings from your changes; functions/ passes npm run build.
  4. Test on device/simulator for any UI or behavioral change, including VoiceOver and Dynamic Type where relevant.
  5. Describe the change — what, why, and how you verified it. Link related issues.
  6. Open the PR against main.

We use squash merges, so your PR title becomes the commit — make it clear and imperative (e.g. "Add sensory-aware routing").

Commit style

  • Imperative mood: "Fix…", "Add…", "Update…".
  • Explain the why in the body when it isn't obvious.

Code of conduct

Be kind and assume good faith. This project exists to help a community that is too often overlooked — let's model that care in how we work together. Harassment or discrimination of any kind isn't welcome here.

License

By contributing, you agree that your contributions are licensed under the MIT License.