NeighborLink UIKit feed, search, forms, camera, and maps
NeighborLink is a UIKit-heavy community marketplace where client architecture, backend authority, real-time collaboration, commerce, and moderation must reinforce the same trust model.
Product decision
How can an imperative interface keep a media-rich, rapidly changing marketplace coherent?
The smallest useful vertical slice is concrete: Drive compositional feed snapshots, listing drafts, photo acquisition, validation, search, and map results from explicit presentation state.
Boundaries that keep the design honest
- Keep authentication tokens, transport DTOs, and framework callbacks outside domain and application policy.
- Use stable client operation IDs, durable outboxes, explicit server ordering, and idempotent reconciliation for ambiguous networks.
- Treat approximate location, media, chat, reports, blocks, retention, and audit access as one privacy and security surface.
- Exercise hostile inputs, role changes, inaccessible content, delayed services, and operational moderation before release.
- Avoid this failure: Mutating collection views and domain models independently, then hoping their identity and ordering stay aligned.
Release evidence
No NeighborLink UIKit target, backend, identity provider, upload, message stream, push environment, Apple Pay merchant setup, moderation system, load test, or adversarial device journey was implemented or exercised.
This chapter records product and architecture decisions. Apple SDK behavior still requires the matching Xcode target, configured service or entitlement where applicable, and named Simulator or physical-device evidence. The browser Swift runner does not validate these Apple SDK surfaces.
Series navigation
- Previous: Part 130: NeighborLink architecture, identity, and API contracts
- Next: Part 132: NeighborLink chat, offline writes, push, and deep links
- Series index: Zero to iOS Hero