System Requirements Document for iphone-17-simulador

1. Introduction

iphone-17-simulador is a browser-based, interactive simulator of the iPhone 17: a realistic, playable mockup of the new phone that presents a fake iOS interface demo — home screen, apps, settings, and camera — inside a stylised device body. The product intent is to let gadget-curious visitors explore a convincing, tactile phone experience end to end, without owning or operating a real device.

The audience is the Simulator Visitor: a person who opens the simulator to freely browse a realistic interactive mockup of the phone, navigate its simulated iOS interface, and expect the mockup to respond like a real device. Success is a convincing, playable phone experience they can browse from the home screen through apps, settings, and camera, and back again.

This is explicitly a fake iOS interface demo / mockup — not a real device and not a real iOS environment. It is a visual, interactive product demo, not a utility.

2. System Overview

The system is a single first-party web application with two surfaces:

• Landing — an anonymous public entry surface that explains the iPhone 17 simulator and invites the visitor to open the interactive fake iOS mockup.
• Simulator — the interactive visual phone workspace containing the simulated home screen, apps, settings, camera, and navigation back to home.

Both surfaces are application-owned and require no account or sign-in. There is no identity establishment, no persistence of visitor-specific state, and no differentiated permissions: every visitor sees and can do the same things. All simulated device state (which app is open, current settings values, camera viewfinder state) is ephemeral in-session state of the mockup itself, not durable visitor data.

Actors

• Simulator Visitor (human, active) — the sole accepted persona; explores the mockup.
• Application / system process (non-persona) — renders the fake iOS interface, holds in-session simulated device state, and performs simulated (non-real) device operations such as the camera shutter.

Narrow exclusions

• The simulator is a mockup, not a real device or real iOS environment; it does not perform real device operations.
• No real camera capture, no real telephony, no real OS services, no real app installation.
• No account creation, sign-in, or visitor profiles.
• No blue or indigo accents anywhere in the UI.

2a. Product Interpretation and Delivery Boundary

The product is delivered entirely as a first-party, browser-rendered web experience. The visitor arrives anonymously at the Landing surface, reads what the simulator is, and opens the Simulator surface. Inside the Simulator, the visitor interacts with a fake iOS interface: a home screen with app icons and a dock, apps that open into full-screen panels, a settings panel with adjustable simulated values, and a camera with a viewfinder and shutter. Navigation back to the home screen is always available, and the visitor can return to the Landing surface.

Everything the visitor sees and manipulates is simulated. The device frame, status bar, battery pill, and clock are part of the mockup's presentation, not real device telemetry. The camera shutter produces a simulated capture event and a lime flash — it does not access a real camera or store real photos.

Current boundary: the Landing and Simulator surfaces, the fake iOS home screen, the apps, the settings panel, and the camera, all as an interactive visual mockup.

Future boundary: nothing beyond the current scope is committed. Any real-device integration, real OS behaviour, real media capture, or account-based features are outside the current delivery and are not part of this document's acceptance.

2c. Page Content and Component Coverage

Landing

• Information and state: Product identity for the iPhone 17 simulator; a short explanation that this is an interactive fake iOS mockup the visitor can explore; the headline "iPhone 17, playable."; the primary invitation to open the simulator. No visitor-specific state; the surface is identical for every visitor.
• Primary action: Open the simulator (lime capsule CTA "Open the simulator") — navigates to the Simulator surface.
• Supporting actions: None required; the CTA is the single commitment action.
• Domain entities: Simulator (the product being presented); the stylised phone body as the hero object.
• Component responsibilities:
  • Hero phone object — an oversized glossy phone body, angled 8 degrees, floating on the pink field with a soft pink-tinted shadow; its screen shows a stylised iOS home screen with a lime-tinted clock and a single pink app icon pulsing gently. It tilts toward the cursor (max 6°) with a spring and carries a slow glossy highlight sweep across its frame every 6 seconds.
  • Headline block — stacked Comfortaa headline "iPhone 17, playable." in ink-plum, 56px mobile / 96px desktop, sentence case, left column.
  • Primary CTA — lime capsule "Open the simulator" pinned beneath the headline, with a moving specular highlight.
  • Section transition — a thin pink hairline arcing from the phone's top-left corner across the headline block.
• States:
  • Loading: the hero phone body and headline render immediately as static composition; motion (tilt, sweep, icon pulse) begins once the surface is interactive.
  • Empty: not applicable — the Landing surface has no collection or data-dependent content.
  • Success: the visitor reads the headline and explanation and activates "Open the simulator", arriving at the Simulator surface.
  • Error: if the Simulator surface fails to load, the visitor remains on Landing with the CTA still available to retry.
  • Recovery: the CTA remains present and re-activatable; no partial state is left behind.
  • Reduced motion: no tilt, no highlight sweep, no icon pulse — the phone, headline, and CTA render as a static composition with icons cross-fading only.

Simulator

• Information and state: The simulated device state of the mockup — which app panel is currently open (home screen or an app), the current values of simulated settings, and the camera viewfinder/shutter state. All state is in-session and ephemeral; it is not persisted to any visitor account.
• Primary actions: Open an app from the home screen; navigate back to the home screen; adjust simulated settings values; trigger the camera shutter.
• Supporting actions: Return from the Simulator to the Landing surface.
• Domain entities: Simulated device (the phone body and its display); simulated home screen; simulated apps; simulated settings; simulated camera; the floating pill dock.
• Component responsibilities:
  • Phone body — a sculptural squircle with a continuous-curve radius (roughly 22% of width), centred with a soft shadow, tilting toward the cursor (max 6°) with a spring and carrying a glossy highlight sweep every 6 seconds.
  • Status bar — a live lime dot and a pink battery pill, plus a lime-tinted clock, making the fake device feel powered on; only tiny status-bar hairlines may be sharp-cornered.
  • Home screen — the fake iOS home screen filling the phone display, with app icons as squircles at 30% radii.
  • App icons — flat but glossy rounded shapes with a single highlight; scale up with a gentle overshoot on hover; morph into a full-screen panel via a shared-element transition when opened.
  • App panels — full-screen panels within the phone display for each simulated app, entered by the shared-element morph from the corresponding icon.
  • Settings panel — the simulated settings app, presenting adjustable simulated values that the visitor can change within the mockup.
  • Camera panel — the simulated camera app, presenting a viewfinder and a shutter control; the shutter uses a quick lime flash as its capture feedback.
  • Floating pill dock — a full pill dock sitting at the bottom of the screen area, providing the home affordance and dock app access.
  • Home navigation — the means of returning from any open app panel to the home screen.
  • Return to Landing — the means of leaving the Simulator surface and returning to the Landing surface.
• States:
  • Loading: the phone body and display render, then the home screen composition appears; motion begins once interactive.
  • Empty: not applicable — the home screen always presents its app icons and dock; there is no data-dependent empty collection.
  • Success: an app opens into its full-screen panel; settings values change and reflect the new value; the camera shutter fires with a lime flash; home navigation returns to the home screen.
  • Error: if an app panel fails to open, the home screen remains intact and the icon stays activatable to retry; if the camera panel fails to initialise, the visitor can navigate home and re-enter.
  • Recovery: home navigation is always available to return to a known state; re-opening an app restores its panel.
  • Reduced motion: no tilt, no highlight sweep; app icons cross-fade instead of morphing with overshoot; the camera shutter flash is suppressed or reduced to a non-animated state change.

3. Functional Requirements

FR-1 — Open the simulator from the landing surface As a Simulator Visitor, I should be able to open the interactive iPhone 17 simulator from the landing surface, so that I can begin exploring the mockup.

• Provenance: explicit (product commitment) + required_inference (entry mechanics).
• Trigger/input: the visitor activates the "Open the simulator" CTA on the Landing surface.
• Observable result: the Simulator surface is presented, showing the phone body with the fake iOS home screen.
• Access state: anonymous; no account or sign-in required.
• Failure/recovery: if the Simulator surface does not load, the visitor remains on Landing with the CTA still available to retry.
• Continuation: the visitor proceeds to explore the home screen and apps.

FR-2 — Understand what the simulator is before entering As a Simulator Visitor, I should be able to read what the iPhone 17 simulator is and that it is an interactive fake iOS mockup, so that I know what I am about to explore.

• Provenance: required_inference (public entry surface).
• Trigger/input: the visitor arrives at the Landing surface.
• Observable result: the headline "iPhone 17, playable." and the explanation of the interactive fake iOS mockup are visible, with the CTA beneath.
• Access state: anonymous.
• Failure/recovery: not applicable — static content.
• Continuation: the visitor activates the CTA (FR-1).

FR-3 — See a realistic simulated home screen As a Simulator Visitor, I should see a fake iOS home screen inside the phone display, so that the mockup reads as a real device.

• Provenance: explicit.
• Trigger/input: the Simulator surface is presented, or the visitor navigates home from an app.
• Observable result: the home screen fills the phone display with app icons (squircles at 30% radii) and a floating pill dock at the bottom of the screen area.
• Access state: anonymous.
• Failure/recovery: if the home screen fails to render, the phone body remains and the surface can be reloaded.
• Continuation: the visitor opens an app (FR-4).

FR-4 — Open an app from the home screen As a Simulator Visitor, I should be able to open an app from the home screen, so that I can explore the simulated apps.

• Provenance: explicit.
• Trigger/input: the visitor activates an app icon on the home screen.
• Observable result: the app opens into a full-screen panel within the phone display, entered by a shared-element morph from the icon.
• Access state: anonymous.
• Failure/recovery: if the panel fails to open, the home screen remains intact and the icon stays activatable to retry.
• Continuation: the visitor uses the app, then navigates home (FR-7).

FR-5 — Adjust simulated settings As a Simulator Visitor, I should be able to open the settings app and adjust simulated values, so that the mockup responds like a real device.

• Provenance: explicit.
• Trigger/input: the visitor opens the settings app and changes a simulated value.
• Observable result: the settings panel shows the changed value, reflecting the visitor's adjustment within the mockup.
• Access state: anonymous; changes are in-session simulated state only and are not persisted to any account.
• Failure/recovery: if the settings panel fails to open, the visitor can navigate home and re-enter.
• Continuation: the visitor continues adjusting values or navigates home (FR-7).

FR-6 — Use the simulated camera As a Simulator Visitor, I should be able to open the camera app and trigger the shutter, so that I can explore the simulated camera.

• Provenance: explicit.
• Trigger/input: the visitor opens the camera app and activates the shutter control.
• Observable result: the camera panel presents a viewfinder; the shutter fires with a quick lime flash as simulated capture feedback.
• Access state: anonymous; no real camera is accessed and no real photo is stored.
• Failure/recovery: if the camera panel fails to initialise, the visitor can navigate home and re-enter.
• Continuation: the visitor takes another simulated capture or navigates home (FR-7).

FR-7 — Navigate back to the home screen As a Simulator Visitor, I should be able to navigate back to the home screen from any app, so that I can move freely through the mockup.

• Provenance: explicit.
• Trigger/input: the visitor uses the home affordance (dock / home navigation) while an app panel is open.
• Observable result: the app panel closes and the home screen is shown again.
• Access state: anonymous.
• Failure/recovery: home navigation is always available as the recovery path to a known state.
• Continuation: the visitor opens another app or returns to Landing (FR-8).

FR-8 — Return to the landing surface As a Simulator Visitor, I should be able to leave the simulator and return to the landing surface, so that I can re-read the introduction or start over.

• Provenance: required_inference (navigation continuity between the two accepted surfaces).
• Trigger/input: the visitor activates the return-to-Landing control on the Simulator surface.
• Observable result: the Landing surface is shown again with its headline and CTA.
• Access state: anonymous.
• Failure/recovery: if the return fails, the Simulator surface remains usable.
• Continuation: the visitor can re-open the simulator (FR-1).

FR-9 — Experience the mockup as a powered-on device As a Simulator Visitor, I should see a live status bar and a device that responds to my pointer, so that the fake device feels powered on and tactile.

• Provenance: explicit (interactive and visual mockup) + required_inference (device-feel mechanics).
• Trigger/input: the visitor views and moves the pointer over the phone body.
• Observable result: the status bar shows a live lime dot, a pink battery pill, and a lime-tinted clock; the phone body tilts toward the cursor (max 6°) with a spring and a glossy highlight sweeps across the frame every 6 seconds.
• Access state: anonymous.
• Failure/recovery: with reduced motion, tilt and sweep are suppressed and the device renders as a static composition.
• Continuation: the visitor continues exploring.

FR-10 — Explore the mockup without an account As a Simulator Visitor, I should be able to explore the entire simulator without creating an account or signing in, so that I can start immediately.

• Provenance: required_inference (both surfaces are application-owned with no access requirement).
• Trigger/input: the visitor arrives at either surface.
• Observable result: all accepted behavior — home screen, apps, settings, camera, navigation — is available without identity establishment.
• Access state: anonymous on both surfaces; no differentiated permissions exist.
• Failure/recovery: not applicable.
• Continuation: the visitor explores freely.

4. User Personas

Simulator Visitor

Product context. The Simulator Visitor is a gadget-curious person who has heard about the iPhone 17 and wants to see and play with it without owning one. They arrive at the Landing surface with no account and no prior setup, expecting a demo they can immediately touch. They are evaluating the phone's feel and interface, not performing a task — their motivation is curiosity and delight.

Primary goal. To explore a convincing, playable iPhone 17 mockup end to end: home screen, apps, settings, and camera, with the mockup responding like a real device.

Distinct accepted responsibilities.

• Reading the Landing surface to understand that this is an interactive fake iOS mockup, then opening the simulator.
• Browsing the simulated home screen and its app icons and dock.
• Opening apps and moving between them and the home screen.
• Adjusting simulated settings values and observing the mockup reflect the change.
• Using the simulated camera and triggering the shutter.
• Returning to the Landing surface when they want to start over.

Relevant inputs or decisions. Which app to open next; whether to change a simulated setting and to what value; when to trigger the camera shutter; when to navigate home; when to leave the simulator.

Interactions with other accepted participants. The Simulator Visitor is the only accepted human participant. All other work is performed by the application/system process, which renders the fake iOS interface, holds in-session simulated device state, and produces simulated capture feedback. There is no handoff to another human, no counterparty, and no shared state with another visitor.

Observable success. The visitor has moved from the Landing surface into the Simulator, opened apps, adjusted settings, fired the simulated camera, navigated home, and returned to Landing — with the mockup responding smoothly and reading as a real, powered-on device throughout.

Source-backed constraints. The visitor is exploring a mockup, not a real device or real iOS environment; nothing they do performs a real device operation. No account is required, and no visitor-specific state is persisted.

5. Core User Flows

Flow 1 — Arrive, understand, and open the simulator

1. The Simulator Visitor arrives anonymously at the Landing surface.
2. The visitor sees the pink field with the oversized glossy phone body floating on the right, angled 8 degrees, its screen showing a stylised iOS home screen with a lime-tinted clock and a single pink app icon pulsing gently.
3. The visitor reads the stacked Comfortaa headline "iPhone 17, playable." in ink-plum on the left, with the lime capsule CTA "Open the simulator" pinned beneath it, and understands that this is an interactive fake iOS mockup they can explore.
4. The visitor activates "Open the simulator".
5. Observable result: the Simulator surface is presented, showing the phone body centred with a soft shadow and the fake iOS home screen filling its display.
6. Continuation: the visitor begins exploring the home screen (Flow 2).
7. Failure/recovery: if the Simulator surface fails to load, the visitor remains on Landing with the CTA still available and can retry.

Flow 2 — Explore the home screen and open an app

1. The visitor is on the Simulator surface with the home screen displayed.
2. The visitor observes the status bar — live lime dot, pink battery pill, lime-tinted clock — and the floating pill dock at the bottom of the screen area.
3. The visitor moves the pointer over the phone body; the body tilts toward the cursor (max 6°) with a spring, and a glossy highlight sweeps across the frame every 6 seconds.
4. The visitor hovers an app icon; it scales up with a gentle overshoot.
5. The visitor activates an app icon.
6. Observable result: the icon morphs into a full-screen panel within the phone display via a shared-element transition, so the fake OS feels physically continuous.
7. Continuation: the visitor uses the app (Flow 3, Flow 4, or Flow 5).
8. Failure/recovery: if the panel fails to open, the home screen remains intact and the icon stays activatable to retry.

Flow 3 — Adjust simulated settings

1. The visitor opens the settings app from the home screen (Flow 2).
2. The settings panel opens as a full-screen panel within the phone display.
3. The visitor changes a simulated value.
4. Observable result: the settings panel shows the changed value, reflecting the adjustment within the mockup.
5. Continuation: the visitor adjusts further values, or navigates home (Flow 6).
6. Failure/recovery: if the settings panel fails to open, the visitor navigates home and re-enters.

Flow 4 — Use the simulated camera

1. The visitor opens the camera app from the home screen (Flow 2).
2. The camera panel opens with a viewfinder.
3. The visitor activates the shutter control.
4. Observable result: the shutter fires with a quick lime flash as simulated capture feedback.
5. Continuation: the visitor takes another simulated capture, or navigates home (Flow 6).
6. Failure/recovery: if the camera panel fails to initialise, the visitor navigates home and re-enters.

Flow 5 — Move between apps

1. The visitor is inside an open app panel on the Simulator surface.
2. The visitor uses the home affordance (dock / home navigation).
3. Observable result: the app panel closes and the home screen is shown again.
4. The visitor opens a different app icon.
5. Observable result: the new app morphs into its full-screen panel.
6. Continuation: the visitor continues browsing, or returns to Landing (Flow 6).

Flow 6 — Leave the simulator and return to Landing

1. The visitor is on the Simulator surface, on the home screen or inside an app.
2. The visitor activates the return-to-Landing control.
3. Observable result: the Landing surface is shown again with its headline and CTA.
4. Continuation: the visitor can re-open the simulator (Flow 1) or leave.
5. Failure/recovery: if the return fails, the Simulator surface remains usable.

Flow 7 — Reduced-motion exploration

1. The visitor has prefers-reduced-motion enabled and arrives at the Landing surface.
2. The phone, headline, and CTA render as a static composition: no tilt, no highlight sweep, no icon pulse; icons cross-fade only.
3. The visitor activates "Open the simulator" and reaches the Simulator surface.
4. Inside the simulator, app icons cross-fade instead of morphing with overshoot, and the camera shutter flash is suppressed or reduced to a non-animated state change.
5. Observable result: every accepted capability — home screen, apps, settings, camera, navigation — remains fully usable without motion.
6. Continuation: the visitor explores exactly as in Flows 2–6.

6. Visuals, Colors, and Theme

Muse and headline. Karim Rashid — sensual pop minimalism for a phone you can play with. The register is optimistic, glossy, and slightly futuristic: a product demo that feels like a design object, not a utility. The simulator is a fake device, so the visual language leans into a stylised, almost sculptural phone rather than a literal Apple clone. Blob-and-capsule geometry maps to rounded phone bodies, app icons, and a dock; the saturated palette keeps the mockup feeling like a desirable product rather than a wireframe.

Palette (light mode).

No blue or indigo anywhere in the UI. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Typography.

• Headings: Comfortaa — rounded, futuristic, wide apertures; used at large sizes with tight leading and occasional soft-weight contrast. Headlines are sentence case, never all-caps.
• Body and UI: Quicksand — geometric-rounded, medium weight, generous line-height so the fake OS reads easily.
• Scale: 1.25 modular — 96 / 64 / 40 / 28 / 20 / 16 / 14; mobile down to 56 / 40 / 28 / 20 / 16 / 14.
• Forbidden families: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, system-ui.

Shape language. Blob and capsule geometry. The phone body is a squircle with a continuous-curve radius (roughly 22% of width), floating on a soft pink field. App icons are squircles with 30% radii; the dock is a full pill. Section boundaries curve into each other with large elliptical arcs rather than straight rules. Buttons are glossy capsules with a small specular highlight. No sharp corners anywhere except tiny status-bar hairlines.

Spacing rhythm. Single-column, device-first layout with generous breathing room around the phone; consistent vertical rhythm built on the type scale, with the phone as the dominant object and text blocks stacked in a narrow left column on desktop.

Imagery style. Glossy 3D-rendered phone body with candy-pink and pearl-white surfaces, soft studio lighting, and a subtle iridescent sheen. App icons are flat but glossy — rounded shapes with a single highlight. No stock photography, no gradients-as-decoration, no generic SaaS illustration. The phone itself is the hero image, rendered as a sculptural object rather than a spec sheet.

Layout. Landing: an oversized phone silhouette occupies the right two-thirds of the viewport, headline and CTA stack to its left on a pink field. Simulator: the phone is centred with a soft shadow, the fake iOS home screen fills its display, and a floating pill dock sits at the bottom of the screen area. On mobile the phone scales down and the headline stacks above it. All type and controls stay fully inside the viewport at 375 / 768 / 1280.

Readable-text rule. Headlines, wordmarks, labels, numbers, and cards' text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

"The phone is the hero, and it is alive."

The public entry is a full-height pink field (#FFF4F8) with a giant glossy phone body floating on the right, angled 8 degrees, casting a soft pink-tinted shadow. The phone's screen shows a stylised iOS home screen with a lime-tinted clock and a single pink app icon pulsing gently. To the left, a stacked headline in Comfortaa at 56px mobile / 96px desktop reads "iPhone 17, playable." in ink-plum, with a lime capsule CTA "Open the simulator" pinned beneath it. A thin pink hairline arcs from the phone's top-left corner across the headline block as a section transition. Nothing is centred, nothing is blue.

The signature moves that carry the concept:

• The phone body is a sculptural squircle that tilts toward the cursor and sweeps a glossy highlight across its frame every 6 seconds.
• App icons morph into full-screen panels via shared-element transitions, so the fake OS feels physically continuous.
• A lime capsule CTA with a moving specular highlight sits pinned under an oversized Comfortaa headline that spans the left column.
• Section boundaries are large elliptical arcs in pink, cutting between the landing and simulator surfaces instead of straight rules.
• The status bar uses a live lime dot and a pink battery pill, making the fake device feel powered on.

This concept only recomposes accepted content, states, and controls — the headline, the CTA, the phone body, the home screen preview, and the status bar. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: dimensional_css

Landing Hero Motion Brief

• Focal subject: the oversized glossy phone body floating on the pink field, angled 8 degrees, its screen showing a stylised iOS home screen with a lime-tinted clock and a single pink app icon pulsing gently.
• Input → transformation → outcome thesis: as the visitor moves the pointer across the hero, the phone body tilts toward the cursor (max 6°) with a spring, and a slow glossy highlight sweeps across the device frame every 6 seconds — so the static product image becomes a tactile, powered-on object that invites the visitor to activate the lime capsule CTA and open the simulator.
• Motion vocabulary: liquid and soft. Gentle overshoot on icon hover; spring-based tilt; slow specular sweep; quick lime flash for the camera shutter; shared-element morphs for app opening.
• Composed first frame: pink field, phone body on the right at 8 degrees with a soft pink-tinted shadow, headline stacked left in Comfortaa, lime capsule CTA pinned beneath, thin pink hairline arcing from the phone's top-left corner across the headline block.
• Reduced-motion state: no tilt, no sweep, no icon pulse — the phone, headline, and CTA render as a static composition; icons cross-fade only.

9. Non-Functional Requirements

NFR-1 — Mockup, not a real device. The simulator is a fake iOS interface demo / mockup, not a real device or real iOS environment. No real device operation, real camera access, real telephony, or real OS service is performed. (Provenance: explicit hard constraint. Rationale: the product is a visual, interactive demo.)

NFR-2 — Anonymous access. Both surfaces are reachable without an account or sign-in; no identity establishment, session continuity, or differentiated permissions are required. (Provenance: required_inference from the accepted access contract. Rationale: the visitor must be able to start immediately.)

NFR-3 — No persisted visitor state. Simulated device state (open app, settings values, camera state) is in-session and ephemeral; nothing is persisted to a visitor account. (Provenance: required_inference. Rationale: no account exists and no durable visitor relationship is created.)

NFR-4 — Responsive readability. Headlines, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no element covering them. (Provenance: explicit design constraint. Rationale: the mockup must be usable at every supported viewport.)

NFR-5 — Reduced-motion support. With prefers-reduced-motion, the experience provides a usable static arrangement: no tilt, no highlight sweep, no icon pulse; icons cross-fade; the camera flash is suppressed or reduced to a non-animated state change. (Provenance: explicit design constraint. Rationale: accessibility without losing any accepted capability.)

NFR-6 — Palette and typography fidelity. The specified palette (#FFF4F8, #FFFFFF, #1A1024, #FF4FA3, #7CFF6B, #8E7F96), Comfortaa headings, and Quicksand body are preserved; no blue or indigo accents appear anywhere. (Provenance: explicit design constraint. Rationale: the creative direction is authoritative for this project.)

NFR-7 — Interactive responsiveness. App icon hover, app opening, settings changes, camera shutter, and home navigation respond immediately to visitor input, so the mockup reads as a real device. (Provenance: explicit ("interactive and visual"). Rationale: the product's value is a convincing, playable experience.)

10. Tech Stack

• Frontend: React (single-page web application) with CSS for the dimensional phone body, squircle geometry, capsule controls, and shared-element app transitions.
• Motion: CSS transitions and spring-based pointer tilt for the device; shared-element morphs for app opening; reduced-motion variants for all motion.
• Storage: none required — all simulated device state is in-session and ephemeral (NFR-3).
• Backend: none required for the accepted scope; the simulator is a client-rendered mockup.
• Deployment: static web delivery of the built frontend.

(No source-specified backend, database, container, or orchestration technology was provided; none is added, since the accepted scope is a client-rendered mockup with no persistence.)

11. Assumptions and Constraints

Assumptions

• A1 — The visitor's browser supports modern CSS and JavaScript sufficient for the dimensional phone body and shared-element transitions. (Labeled assumption; not source-specified.)
• A2 — The Landing and Simulator surfaces are the complete current information architecture; no additional destinations are required for the accepted behavior. (Derived from the accepted page contract.)
• A3 — "Apps" in the simulator are the simulated apps presented on the home screen and dock; the accepted named examples are settings and camera. (Derived from the explicit requirement naming home screen, apps, settings, and camera.)

Constraints

• C1 — The simulator is a fake iOS interface demo / mockup, not a real device or real iOS environment. (Explicit.)
• C2 — No blue or indigo accents anywhere in the UI; the generic indigo/blue-on-white SaaS template is forbidden. (Explicit design constraint.)
• C3 — Headlines, labels, numbers, and controls stay whole and uncovered at 375px, 768px, and 1280px. (Explicit design constraint.)
• C4 — No account creation, sign-in, or visitor profiles; no persisted visitor state. (Required inference from the accepted access contract.)
• C5 — No real camera capture, real telephony, real OS services, or real app installation. (Explicit constraint C1 applied to device operations.)

12. Glossary

• Simulator — the interactive visual phone workspace containing the simulated home screen, apps, settings, camera, and navigation back to home.
• Landing — the anonymous public entry surface that explains the iPhone 17 simulator and invites the visitor to open the mockup.
• Simulator Visitor — the sole accepted human persona; a gadget-curious person who explores the mockup.
• Fake iOS interface — the simulated iOS presentation inside the phone display; explicitly not a real iOS environment.
• Mockup — a visual, interactive imitation of the iPhone 17; not a real device.
• Home screen — the simulated iOS home screen with app icons and the floating pill dock.
• Dock — the full-pill dock at the bottom of the screen area providing home affordance and dock app access.
• App panel — a full-screen panel within the phone display, entered by a shared-element morph from an app icon.
• Squircle — a rounded square with a continuous-curve radius; used for the phone body (roughly 22% of width) and app icons (30% radii).
• Shared-element transition — a motion technique in which an app icon morphs into its full-screen panel so the fake OS feels physically continuous.
• Simulated capture — the camera shutter's lime flash feedback; it does not access a real camera or store a real photo.
• In-session state — ephemeral simulated device state (open app, settings values, camera state) that is not persisted.