# Mobile app UI Board: https://swipefile.design/board/mobile-app-ui/ References: 100 Use this board as design direction for my project. Review the references below, identify useful layout, typography, color, and interaction patterns, then adapt them to my brief. Cite the original references you use. Use these references for design principles. Follow the project brief and use original branding, content, and imagery. Captures document a particular date; they do not verify current product behavior. ## 1. Things 3 Source website: https://apps.apple.com/us/app/id904237743 Swipefile reference: https://swipefile.design/ref/mobile-things-3/ Screenshot: https://swipefile.design/_astro/000.BIqvd6h-.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity Colored list icons and restrained dividers organize an otherwise quiet white task interface. Publisher previews: - List navigation: https://swipefile.design/_astro/000.BIqvd6h-.webp - Today task list: https://swipefile.design/_astro/001.CjE0Yxau.webp - Upcoming schedule: https://swipefile.design/_astro/002.CKI2VEg7.webp Useful for: Study list navigation, today task list, upcoming schedule. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: List navigation · Today task list · Upcoming schedule - nav: Lists lead into Today and Upcoming views; circular add controls stay near the bottom. - layout: Colored list icons and restrained dividers organize an otherwise quiet white task interface. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue, white, and small semantic color accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Things 3 Source: https://apps.apple.com/us/app/id904237743 Swipefile reference: https://swipefile.design/ref/mobile-things-3/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: List navigation · Today task list · Upcoming schedule - nav: Lists lead into Today and Upcoming views; circular add controls stay near the bottom. - layout: Colored list icons and restrained dividers organize an otherwise quiet white task interface. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue, white, and small semantic color accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study list navigation, today task list, upcoming schedule. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 2. Todoist Source website: https://apps.apple.com/us/app/id572688855 Swipefile reference: https://swipefile.design/ref/mobile-todoist/ Screenshot: https://swipefile.design/_astro/000.SBbOdKlu.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity Task cards surface due dates and project metadata over a compact list and calendar interface. Publisher previews: - Voice task capture: https://swipefile.design/_astro/000.SBbOdKlu.webp - Task details: https://swipefile.design/_astro/001.DdSLHrC7.webp - Project calendar: https://swipefile.design/_astro/002.D99VFF0s.webp Useful for: Study voice task capture, task details, project calendar. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Voice task capture · Task details · Project calendar - nav: Capture controls lead into task details and a project calendar. - layout: Task cards surface due dates and project metadata over a compact list and calendar interface. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm pastel surrounds, white cards, and red task accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Todoist Source: https://apps.apple.com/us/app/id572688855 Swipefile reference: https://swipefile.design/ref/mobile-todoist/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Voice task capture · Task details · Project calendar - nav: Capture controls lead into task details and a project calendar. - layout: Task cards surface due dates and project metadata over a compact list and calendar interface. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm pastel surrounds, white cards, and red task accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study voice task capture, task details, project calendar. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 3. TickTick Source website: https://apps.apple.com/us/app/id626144601 Swipefile reference: https://swipefile.design/ref/mobile-ticktick/ Screenshot: https://swipefile.design/_astro/000.zo5j2SWq.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity Checkbox lists share space with day and month calendars, while a raised card explains structured task capture. Publisher previews: - Inbox task list: https://swipefile.design/_astro/000.zo5j2SWq.webp - Calendar views: https://swipefile.design/_astro/001.vJM8JVsT.webp - Voice-to-task preview: https://swipefile.design/_astro/002.DzSmoNuS.webp Useful for: Study inbox task list, calendar views, voice-to-task preview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Inbox task list · Calendar views · Voice-to-task preview - nav: Inbox, calendar, and task-entry surfaces provide distinct ways into the same workload. - layout: Checkbox lists share space with day and month calendars, while a raised card explains structured task capture. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and pale blue with blue controls and colored calendar events. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: TickTick Source: https://apps.apple.com/us/app/id626144601 Swipefile reference: https://swipefile.design/ref/mobile-ticktick/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Inbox task list · Calendar views · Voice-to-task preview - nav: Inbox, calendar, and task-entry surfaces provide distinct ways into the same workload. - layout: Checkbox lists share space with day and month calendars, while a raised card explains structured task capture. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and pale blue with blue controls and colored calendar events. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study inbox task list, calendar views, voice-to-task preview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 4. Notion Source website: https://apps.apple.com/us/app/id1232780281 Swipefile reference: https://swipefile.design/ref/mobile-notion/ Screenshot: https://swipefile.design/_astro/000.Yb6ddi0Y.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity A compact page hierarchy uses small icons, generous row spacing, and cover imagery to distinguish personal documents. Publisher previews: - Home page shortcuts: https://swipefile.design/_astro/000.Yb6ddi0Y.webp - Workspace page hierarchy: https://swipefile.design/_astro/001.Bp-RXEr2.webp - Travel database: https://swipefile.design/_astro/002.DYTSQIVo.webp Useful for: Study home page shortcuts, workspace page hierarchy, travel database. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Home page shortcuts · Workspace page hierarchy · Travel database - nav: Home shortcuts lead into nested pages and a document workspace. - layout: A compact page hierarchy uses small icons, generous row spacing, and cover imagery to distinguish personal documents. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Mostly white and black with small content-driven color accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Notion Source: https://apps.apple.com/us/app/id1232780281 Swipefile reference: https://swipefile.design/ref/mobile-notion/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Home page shortcuts · Workspace page hierarchy · Travel database - nav: Home shortcuts lead into nested pages and a document workspace. - layout: A compact page hierarchy uses small icons, generous row spacing, and cover imagery to distinguish personal documents. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Mostly white and black with small content-driven color accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study home page shortcuts, workspace page hierarchy, travel database. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 5. Trello Source website: https://apps.apple.com/us/app/id461504587 Swipefile reference: https://swipefile.design/ref/mobile-trello/ Screenshot: https://swipefile.design/_astro/000.QbFF4ff9.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity White task cards sit within blue board areas, while a separate schedule arranges work into time slots. Publisher previews: - Inbox cards: https://swipefile.design/_astro/000.QbFF4ff9.webp - Calendar schedule: https://swipefile.design/_astro/001.DNbvNbGg.webp - Board to-do cards: https://swipefile.design/_astro/002.en3K7WWq.webp Useful for: Study inbox cards, calendar schedule, board to-do cards. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Inbox cards · Calendar schedule · Board to-do cards - nav: Inbox, calendar, and board surfaces expose different arrangements of the same work. - layout: White task cards sit within blue board areas, while a separate schedule arranges work into time slots. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue, white, and colored calendar blocks. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Trello Source: https://apps.apple.com/us/app/id461504587 Swipefile reference: https://swipefile.design/ref/mobile-trello/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Inbox cards · Calendar schedule · Board to-do cards - nav: Inbox, calendar, and board surfaces expose different arrangements of the same work. - layout: White task cards sit within blue board areas, while a separate schedule arranges work into time slots. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue, white, and colored calendar blocks. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study inbox cards, calendar schedule, board to-do cards. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 6. Asana Source website: https://apps.apple.com/us/app/id489969512 Swipefile reference: https://swipefile.design/ref/mobile-asana/ Screenshot: https://swipefile.design/_astro/000.C4DX3btO.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity Task rows, project shortcuts, and activity updates use compact white panels with clear headings and small identity marks. Publisher previews: - Project task list: https://swipefile.design/_astro/000.C4DX3btO.webp - Home shortcuts: https://swipefile.design/_astro/001.B3FYiBpf.webp - Activity inbox: https://swipefile.design/_astro/002.uZYma9LK.webp Useful for: Study project task list, home shortcuts, activity inbox. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Project task list · Home shortcuts · Activity inbox - nav: Home, project, and inbox surfaces distinguish navigation from updates. - layout: Task rows, project shortcuts, and activity updates use compact white panels with clear headings and small identity marks. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with burgundy, blue, and green promotional surrounds. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Activity & notifications - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Asana Source: https://apps.apple.com/us/app/id489969512 Swipefile reference: https://swipefile.design/ref/mobile-asana/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Project task list · Home shortcuts · Activity inbox - nav: Home, project, and inbox surfaces distinguish navigation from updates. - layout: Task rows, project shortcuts, and activity updates use compact white panels with clear headings and small identity marks. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with burgundy, blue, and green promotional surrounds. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Activity & notifications - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study project task list, home shortcuts, activity inbox. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 7. monday.com Source website: https://apps.apple.com/us/app/id1290128888 Swipefile reference: https://swipefile.design/ref/mobile-monday-com/ Screenshot: https://swipefile.design/_astro/000.CIOxDDMt.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity Status-colored cells, workload totals, and item-detail cards make the organization of work visible in a narrow format. Publisher previews: - Team planning board: https://swipefile.design/_astro/000.CIOxDDMt.webp - My work summary: https://swipefile.design/_astro/001.Cj4VygYQ.webp - Notification list: https://swipefile.design/_astro/002.VyBAeeGX.webp Useful for: Study team planning board, my work summary, notification list. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Team planning board · My work summary · Notification list - nav: Planning, personal work, and notification surfaces have separate headings and controls. - layout: Status-colored cells, workload totals, and item-detail cards make the organization of work visible in a narrow format. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Purple surround, white panels, and green, amber, and red status colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: monday.com Source: https://apps.apple.com/us/app/id1290128888 Swipefile reference: https://swipefile.design/ref/mobile-monday-com/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Team planning board · My work summary · Notification list - nav: Planning, personal work, and notification surfaces have separate headings and controls. - layout: Status-colored cells, workload totals, and item-detail cards make the organization of work visible in a narrow format. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Purple surround, white panels, and green, amber, and red status colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study team planning board, my work summary, notification list. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 8. Evernote Source website: https://apps.apple.com/us/app/id281796108 Swipefile reference: https://swipefile.design/ref/mobile-evernote/ Screenshot: https://swipefile.design/_astro/000.7HkDHTJS.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity A note combines text, attachments, and checklists; highlighted search terms help explain how saved content is retrieved. Publisher previews: - Rich meeting note: https://swipefile.design/_astro/000.7HkDHTJS.webp - Checklist inside a note: https://swipefile.design/_astro/001.DjGIulXL.webp - Search results: https://swipefile.design/_astro/002.C9MCNoeN.webp Useful for: Study rich meeting note, checklist inside a note, search results. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Rich meeting note · Checklist inside a note · Search results - nav: Editor controls sit above the note, with a search surface for returning to content. - layout: A note combines text, attachments, and checklists; highlighted search terms help explain how saved content is retrieved. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content on black promotional framing with bright green actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Evernote Source: https://apps.apple.com/us/app/id281796108 Swipefile reference: https://swipefile.design/ref/mobile-evernote/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Rich meeting note · Checklist inside a note · Search results - nav: Editor controls sit above the note, with a search surface for returning to content. - layout: A note combines text, attachments, and checklists; highlighted search terms help explain how saved content is retrieved. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content on black promotional framing with bright green actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study rich meeting note, checklist inside a note, search results. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 9. Bear Source website: https://apps.apple.com/us/app/id1016366447 Swipefile reference: https://swipefile.design/ref/mobile-bear/ Screenshot: https://swipefile.design/_astro/000.B0hMzx3J.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity Rich text, imagery, and tables sit in a quiet editor beside a tag-based navigation surface. Publisher previews: - Rich note and table: https://swipefile.design/_astro/000.B0hMzx3J.webp - Tag navigation: https://swipefile.design/_astro/001.DNWIHIk2.webp - Editor theme examples: https://swipefile.design/_astro/002.BSiHVbAw.webp Useful for: Study rich note and table, tag navigation, editor theme examples. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Rich note and table · Tag navigation · Editor theme examples - nav: A side panel groups notes by tags; the document remains the main reading surface. - layout: Rich text, imagery, and tables sit in a quiet editor beside a tag-based navigation surface. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White editor, dark purple sidebar, and red brand accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Bear Source: https://apps.apple.com/us/app/id1016366447 Swipefile reference: https://swipefile.design/ref/mobile-bear/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Rich note and table · Tag navigation · Editor theme examples - nav: A side panel groups notes by tags; the document remains the main reading surface. - layout: Rich text, imagery, and tables sit in a quiet editor beside a tag-based navigation surface. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White editor, dark purple sidebar, and red brand accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study rich note and table, tag navigation, editor theme examples. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 10. Craft Source website: https://apps.apple.com/us/app/id1487937127 Swipefile reference: https://swipefile.design/ref/mobile-craft/ Screenshot: https://swipefile.design/_astro/000.n4xE1kMV.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Productivity A document editor combines styled text with a separate task sheet and a familiar keyboard toolbar. Publisher previews: - Document editing: https://swipefile.design/_astro/000.n4xE1kMV.webp - Task capture: https://swipefile.design/_astro/001.vVeGpqej.webp - Document appearance: https://swipefile.design/_astro/002.Dbb-FXnE.webp Useful for: Study document editing, task capture, document appearance. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Document editing · Task capture · Document appearance - nav: Document and task surfaces keep creation controls near the writing context. - layout: A document editor combines styled text with a separate task sheet and a familiar keyboard toolbar. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm neutrals, white sheets, and blue action accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Craft Source: https://apps.apple.com/us/app/id1487937127 Swipefile reference: https://swipefile.design/ref/mobile-craft/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Document editing · Task capture · Document appearance - nav: Document and task surfaces keep creation controls near the writing context. - layout: A document editor combines styled text with a separate task sheet and a familiar keyboard toolbar. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm neutrals, white sheets, and blue action accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study document editing, task capture, document appearance. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 11. Fantastical Source website: https://apps.apple.com/us/app/id718043190 Swipefile reference: https://swipefile.design/ref/mobile-fantastical/ Screenshot: https://swipefile.design/_astro/000.BdYisdmg.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits An agenda groups appointments beneath a compact date strip, with alternative month and year views and a prominent event card. Publisher previews: - Day agenda: https://swipefile.design/_astro/000.BdYisdmg.webp - Calendar view comparison: https://swipefile.design/_astro/001.Dc3sD-ik.webp - Event creation preview: https://swipefile.design/_astro/002.Bv4BsLOH.webp Useful for: Study day agenda, calendar view comparison, event creation preview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Day agenda · Calendar view comparison · Event creation preview - nav: Calendar views separate date navigation from individual event details. - layout: An agenda groups appointments beneath a compact date strip, with alternative month and year views and a prominent event card. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and black calendar surfaces with colored event blocks. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Fantastical Source: https://apps.apple.com/us/app/id718043190 Swipefile reference: https://swipefile.design/ref/mobile-fantastical/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Day agenda · Calendar view comparison · Event creation preview - nav: Calendar views separate date navigation from individual event details. - layout: An agenda groups appointments beneath a compact date strip, with alternative month and year views and a prominent event card. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and black calendar surfaces with colored event blocks. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study day agenda, calendar view comparison, event creation preview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 12. Structured Source website: https://apps.apple.com/us/app/id1499198946 Swipefile reference: https://swipefile.design/ref/mobile-structured/ Screenshot: https://swipefile.design/_astro/000.BQ87uP-3.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Colored time blocks run down a vertical timeline beside completion circles; recurrence options sit in a compact sheet. Publisher previews: - Daily timeline: https://swipefile.design/_astro/000.BQ87uP-3.webp - Repeating routines: https://swipefile.design/_astro/001.C-RPJUUi.webp - Planning prompt: https://swipefile.design/_astro/002.B15vknnS.webp Useful for: Study daily timeline, repeating routines, planning prompt. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Daily timeline · Repeating routines · Planning prompt - nav: A date strip and bottom destinations frame the daily plan, with an add control at the lower edge. - layout: Colored time blocks run down a vertical timeline beside completion circles; recurrence options sit in a compact sheet. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White, pink, and multicolored task blocks. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Structured Source: https://apps.apple.com/us/app/id1499198946 Swipefile reference: https://swipefile.design/ref/mobile-structured/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Daily timeline · Repeating routines · Planning prompt - nav: A date strip and bottom destinations frame the daily plan, with an add control at the lower edge. - layout: Colored time blocks run down a vertical timeline beside completion circles; recurrence options sit in a compact sheet. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White, pink, and multicolored task blocks. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study daily timeline, repeating routines, planning prompt. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 13. Any.do Source website: https://apps.apple.com/us/app/id497328576 Swipefile reference: https://swipefile.design/ref/mobile-any-do/ Screenshot: https://swipefile.design/_astro/000.m100s1r4.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Tasks are grouped by date or status with small completion circles and optional assignee portraits. Publisher previews: - Grouped task list: https://swipefile.design/_astro/000.m100s1r4.webp - Schedule widget: https://swipefile.design/_astro/001.BFldhdbQ.webp - Shared project tasks: https://swipefile.design/_astro/002.B-X93qW5.webp Useful for: Study grouped task list, schedule widget, shared project tasks. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Grouped task list · Schedule widget · Shared project tasks - nav: Today, Tomorrow, and Upcoming group personal tasks; shared work uses explicit status headings. - layout: Tasks are grouped by date or status with small completion circles and optional assignee portraits. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White lists with blue controls and restrained identity colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Any.do Source: https://apps.apple.com/us/app/id497328576 Swipefile reference: https://swipefile.design/ref/mobile-any-do/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Grouped task list · Schedule widget · Shared project tasks - nav: Today, Tomorrow, and Upcoming group personal tasks; shared work uses explicit status headings. - layout: Tasks are grouped by date or status with small completion circles and optional assignee portraits. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White lists with blue controls and restrained identity colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study grouped task list, schedule widget, shared project tasks. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 14. Microsoft To Do Source website: https://apps.apple.com/us/app/id1212616790 Swipefile reference: https://swipefile.design/ref/mobile-microsoft-to-do/ Screenshot: https://swipefile.design/_astro/000.CwsbBA12.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Simple checkbox rows remain consistent across daily planning, groceries, and flagged email lists. Publisher previews: - My Day list: https://swipefile.design/_astro/000.CwsbBA12.webp - List personalization: https://swipefile.design/_astro/001.BKQgJnve.webp - Flagged email tasks: https://swipefile.design/_astro/002.DZg_XagX.webp Useful for: Study my day list, list personalization, flagged email tasks. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: My Day list · List personalization · Flagged email tasks - nav: List-level back controls and a clear heading identify the current task context. - layout: Simple checkbox rows remain consistent across daily planning, groceries, and flagged email lists. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Teal, green, and red list backgrounds with white task rows. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Microsoft To Do Source: https://apps.apple.com/us/app/id1212616790 Swipefile reference: https://swipefile.design/ref/mobile-microsoft-to-do/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: My Day list · List personalization · Flagged email tasks - nav: List-level back controls and a clear heading identify the current task context. - layout: Simple checkbox rows remain consistent across daily planning, groceries, and flagged email lists. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Teal, green, and red list backgrounds with white task rows. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Tasks & checklists - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study my day list, list personalization, flagged email tasks. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 15. Google Calendar Source website: https://apps.apple.com/us/app/id909319292 Swipefile reference: https://swipefile.design/ref/mobile-google-calendar/ Screenshot: https://swipefile.design/_astro/000.BvmBLSXT.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Colored event blocks and illustrations distinguish agenda items while a detail sheet groups location, meeting link, and guests. Publisher previews: - Schedule overview: https://swipefile.design/_astro/000.BvmBLSXT.webp - Event creation: https://swipefile.design/_astro/001.-ZkAosK2.webp - Event details: https://swipefile.design/_astro/002.CTv0vL54.webp Useful for: Study schedule overview, event creation, event details. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Schedule overview · Event creation · Event details - nav: A compact date header leads into schedule entries and event details. - layout: Colored event blocks and illustrations distinguish agenda items while a detail sheet groups location, meeting link, and guests. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White canvas with multicolored calendars and blue actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Google Calendar Source: https://apps.apple.com/us/app/id909319292 Swipefile reference: https://swipefile.design/ref/mobile-google-calendar/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Schedule overview · Event creation · Event details - nav: A compact date header leads into schedule entries and event details. - layout: Colored event blocks and illustrations distinguish agenda items while a detail sheet groups location, meeting link, and guests. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White canvas with multicolored calendars and blue actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study schedule overview, event creation, event details. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 16. Calendars Source website: https://apps.apple.com/us/app/id608834326 Swipefile reference: https://swipefile.design/ref/mobile-calendars/ Screenshot: https://swipefile.design/_astro/000.CgU0qF7U.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Dense calendar views use colored event blocks, while a task panel sits below the timed schedule. Publisher previews: - Month calendar: https://swipefile.design/_astro/000.CgU0qF7U.webp - Day and week schedules: https://swipefile.design/_astro/001.QBECRla8.webp - Tasks alongside appointments: https://swipefile.design/_astro/002.DWYiQCt2.webp Useful for: Study month calendar, day and week schedules, tasks alongside appointments. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Month calendar · Day and week schedules · Tasks alongside appointments - nav: List, Day, Week, Month, and Planner labels make view switching explicit. - layout: Dense calendar views use colored event blocks, while a task panel sits below the timed schedule. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, navy navigation, and pastel event colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Calendars Source: https://apps.apple.com/us/app/id608834326 Swipefile reference: https://swipefile.design/ref/mobile-calendars/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Month calendar · Day and week schedules · Tasks alongside appointments - nav: List, Day, Week, Month, and Planner labels make view switching explicit. - layout: Dense calendar views use colored event blocks, while a task panel sits below the timed schedule. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, navy navigation, and pastel event colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study month calendar, day and week schedules, tasks alongside appointments. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 17. Agenda Source website: https://apps.apple.com/us/app/id1370289240 Swipefile reference: https://swipefile.design/ref/mobile-agenda/ Screenshot: https://swipefile.design/_astro/000._yzOrnTo.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Notes combine dates, tags, rich text, and checklists within a narrow document layout. Publisher previews: - Rich dated note: https://swipefile.design/_astro/000._yzOrnTo.webp - Project note list: https://swipefile.design/_astro/001.BA-mTm0r.webp - Dated tasks and notes: https://swipefile.design/_astro/002.6hHhVRxo.webp Useful for: Study rich dated note, project note list, dated tasks and notes. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Rich dated note · Project note list · Dated tasks and notes - nav: Project headings and note-level dates help connect writing with scheduled work. - layout: Notes combine dates, tags, rich text, and checklists within a narrow document layout. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White pages with yellow controls and highlighted metadata. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Agenda Source: https://apps.apple.com/us/app/id1370289240 Swipefile reference: https://swipefile.design/ref/mobile-agenda/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Rich dated note · Project note list · Dated tasks and notes - nav: Project headings and note-level dates help connect writing with scheduled work. - layout: Notes combine dates, tags, rich text, and checklists within a narrow document layout. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White pages with yellow controls and highlighted metadata. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Notes & documents - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study rich dated note, project note list, dated tasks and notes. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 18. Forest Source website: https://apps.apple.com/us/app/id866450515 Swipefile reference: https://swipefile.design/ref/mobile-forest/ Screenshot: https://swipefile.design/_astro/000.CuZU2V0i.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits A schedule uses weekday buttons and time fields; separate illustrated surfaces visualize focus history and a breathing prompt. Publisher previews: - Blocked-app schedule: https://swipefile.design/_astro/000.CuZU2V0i.webp - Focus achievement overview: https://swipefile.design/_astro/001.PffWuzFm.webp - Breathing exercise: https://swipefile.design/_astro/002.CnNqxbYf.webp Useful for: Study blocked-app schedule, focus achievement overview, breathing exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Blocked-app schedule · Focus achievement overview · Breathing exercise - nav: Schedule settings, achievement overview, and a focused exercise each use a distinct screen structure. - layout: A schedule uses weekday buttons and time fields; separate illustrated surfaces visualize focus history and a breathing prompt. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Green gradients, pale settings panels, and nature illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Forest Source: https://apps.apple.com/us/app/id866450515 Swipefile reference: https://swipefile.design/ref/mobile-forest/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Blocked-app schedule · Focus achievement overview · Breathing exercise - nav: Schedule settings, achievement overview, and a focused exercise each use a distinct screen structure. - layout: A schedule uses weekday buttons and time fields; separate illustrated surfaces visualize focus history and a breathing prompt. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Green gradients, pale settings panels, and nature illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study blocked-app schedule, focus achievement overview, breathing exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 19. Streaks Source website: https://apps.apple.com/us/app/id963034692 Swipefile reference: https://swipefile.design/ref/mobile-streaks/ Screenshot: https://swipefile.design/_astro/000.D8pYY5DB.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Large circular habit controls contrast with compact historical charts and a plain reflection editor. Publisher previews: - Habit completion grid: https://swipefile.design/_astro/000.D8pYY5DB.webp - History and charts: https://swipefile.design/_astro/001.CFCn3CnA.webp - Daily reflection entry: https://swipefile.design/_astro/002.DqXjsvq_.webp Useful for: Study habit completion grid, history and charts, daily reflection entry. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Habit completion grid · History and charts · Daily reflection entry - nav: Habit icons lead into period summaries and dated entries. - layout: Large circular habit controls contrast with compact historical charts and a plain reflection editor. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Violet, pink, and orange themes with white controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Streaks Source: https://apps.apple.com/us/app/id963034692 Swipefile reference: https://swipefile.design/ref/mobile-streaks/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Habit completion grid · History and charts · Daily reflection entry - nav: Habit icons lead into period summaries and dated entries. - layout: Large circular habit controls contrast with compact historical charts and a plain reflection editor. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Violet, pink, and orange themes with white controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study habit completion grid, history and charts, daily reflection entry. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 20. Productive Source website: https://apps.apple.com/us/app/id983826477 Swipefile reference: https://swipefile.design/ref/mobile-productive/ Screenshot: https://swipefile.design/_astro/000.pnmsWYqF.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Planning & habits Illustrated habit templates, a daily checklist, and program cards share compact rounded containers. Publisher previews: - Habit template picker: https://swipefile.design/_astro/000.pnmsWYqF.webp - Today habit list: https://swipefile.design/_astro/001.CeD6wa6h.webp - Program library: https://swipefile.design/_astro/002.o4Oj8hel.webp Useful for: Study habit template picker, today habit list, program library. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Habit template picker · Today habit list · Program library - nav: Today provides a daily anchor; template and program lists support choosing what to track. - layout: Illustrated habit templates, a daily checklist, and program cards share compact rounded containers. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark surfaces with yellow calls to action and blue add controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Productive Source: https://apps.apple.com/us/app/id983826477 Swipefile reference: https://swipefile.design/ref/mobile-productive/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Habit template picker · Today habit list · Program library - nav: Today provides a daily anchor; template and program lists support choosing what to track. - layout: Illustrated habit templates, a daily checklist, and program cards share compact rounded containers. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark surfaces with yellow calls to action and blue add controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study habit template picker, today habit list, program library. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 21. Headspace Source website: https://apps.apple.com/us/app/id493145008 Swipefile reference: https://swipefile.design/ref/mobile-headspace/ Screenshot: https://swipefile.design/_astro/000.jSl9LTLn.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing Category tiles and illustrated content cards lead into a course summary with teacher choices and a clear start control. Publisher previews: - Category discovery: https://swipefile.design/_astro/000.jSl9LTLn.webp - Sleep content library: https://swipefile.design/_astro/001.CDTjbEtV.webp - Course and teacher selection: https://swipefile.design/_astro/002.DxhtmPGD.webp Useful for: Study category discovery, sleep content library, course and teacher selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Category discovery · Sleep content library · Course and teacher selection - nav: Search and bottom destinations frame the library; a back control returns from course detail. - layout: Category tiles and illustrated content cards lead into a course summary with teacher choices and a clear start control. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm orange and yellow contrast with a deep purple sleep surface. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Headspace Source: https://apps.apple.com/us/app/id493145008 Swipefile reference: https://swipefile.design/ref/mobile-headspace/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Category discovery · Sleep content library · Course and teacher selection - nav: Search and bottom destinations frame the library; a back control returns from course detail. - layout: Category tiles and illustrated content cards lead into a course summary with teacher choices and a clear start control. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm orange and yellow contrast with a deep purple sleep surface. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study category discovery, sleep content library, course and teacher selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 22. Calm Source website: https://apps.apple.com/us/app/id571800810 Swipefile reference: https://swipefile.design/ref/mobile-calm/ Screenshot: https://swipefile.design/_astro/000.CvPLOqJc.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing Large image cards are grouped by content type, with compact filter chips above the sleep library. Publisher previews: - Sleep story library: https://swipefile.design/_astro/000.CvPLOqJc.webp - Daily practice library: https://swipefile.design/_astro/001.0U8qZrMw.webp - Soundscape browsing: https://swipefile.design/_astro/002.DU4jYS5R.webp Useful for: Study sleep story library, daily practice library, soundscape browsing. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Sleep story library · Daily practice library · Soundscape browsing - nav: Category labels and See All links offer both broad browsing and narrower collections. - layout: Large image cards are grouped by content type, with compact filter chips above the sleep library. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue backgrounds and soft photographic cover art. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Calm Source: https://apps.apple.com/us/app/id571800810 Swipefile reference: https://swipefile.design/ref/mobile-calm/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Sleep story library · Daily practice library · Soundscape browsing - nav: Category labels and See All links offer both broad browsing and narrower collections. - layout: Large image cards are grouped by content type, with compact filter chips above the sleep library. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue backgrounds and soft photographic cover art. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study sleep story library, daily practice library, soundscape browsing. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 23. Balance Source website: https://apps.apple.com/us/app/id1361356590 Swipefile reference: https://swipefile.design/ref/mobile-balance/ Screenshot: https://swipefile.design/_astro/000.C4KZr1jz.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing A short multiple-choice question contrasts with a recommendation card and an illustrated plan grid. Publisher previews: - Personalization question: https://swipefile.design/_astro/000.C4KZr1jz.webp - Today recommendations: https://swipefile.design/_astro/001.DemRU_bk.webp - Meditation plan grid: https://swipefile.design/_astro/002.DqfwFP4v.webp Useful for: Study personalization question, today recommendations, meditation plan grid. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Personalization question · Today recommendations · Meditation plan grid - nav: Bottom destinations separate Today, plans, sleep, and profile-related areas. - layout: A short multiple-choice question contrasts with a recommendation card and an illustrated plan grid. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, turquoise controls, and light pastel choice rows. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Onboarding & personalization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Balance Source: https://apps.apple.com/us/app/id1361356590 Swipefile reference: https://swipefile.design/ref/mobile-balance/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Personalization question · Today recommendations · Meditation plan grid - nav: Bottom destinations separate Today, plans, sleep, and profile-related areas. - layout: A short multiple-choice question contrasts with a recommendation card and an illustrated plan grid. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, turquoise controls, and light pastel choice rows. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Onboarding & personalization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study personalization question, today recommendations, meditation plan grid. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 24. Insight Timer Source website: https://apps.apple.com/us/app/id337472899 Swipefile reference: https://swipefile.design/ref/mobile-insight-timer/ Screenshot: https://swipefile.design/_astro/000.Bp0_j3ZX.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing Small category shortcuts sit above large meditation cards with duration and teacher metadata. Publisher previews: - Featured meditation: https://swipefile.design/_astro/000.Bp0_j3ZX.webp - Home category shortcuts: https://swipefile.design/_astro/001.BIVH1awx.webp - Content library: https://swipefile.design/_astro/002.CWGfpjq8.webp Useful for: Study featured meditation, home category shortcuts, content library. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Featured meditation · Home category shortcuts · Content library - nav: A home greeting, category grid, and content cards establish multiple routes into the library. - layout: Small category shortcuts sit above large meditation cards with duration and teacher metadata. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with blue promotional framing and photographic covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Insight Timer Source: https://apps.apple.com/us/app/id337472899 Swipefile reference: https://swipefile.design/ref/mobile-insight-timer/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Featured meditation · Home category shortcuts · Content library - nav: A home greeting, category grid, and content cards establish multiple routes into the library. - layout: Small category shortcuts sit above large meditation cards with duration and teacher metadata. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with blue promotional framing and photographic covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study featured meditation, home category shortcuts, content library. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 25. Finch Source website: https://apps.apple.com/us/app/id1528595748 Swipefile reference: https://swipefile.design/ref/mobile-finch/ Screenshot: https://swipefile.design/_astro/000.BWP9Axps.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing A character scene sits above approachable checklists, while a support picker presents friendly illustrated reactions. Publisher previews: - Shared goal checklist: https://swipefile.design/_astro/000.BWP9Axps.webp - Support message picker: https://swipefile.design/_astro/001.DDq5rQKH.webp - Adventure and daily goals: https://swipefile.design/_astro/002.QuzbegB0.webp Useful for: Study shared goal checklist, support message picker, adventure and daily goals. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Shared goal checklist · Support message picker · Adventure and daily goals - nav: Goal lists and a dedicated message-selection surface separate personal progress from social encouragement. - layout: A character scene sits above approachable checklists, while a support picker presents friendly illustrated reactions. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Bright green and pink panels with soft character illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Finch Source: https://apps.apple.com/us/app/id1528595748 Swipefile reference: https://swipefile.design/ref/mobile-finch/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Shared goal checklist · Support message picker · Adventure and daily goals - nav: Goal lists and a dedicated message-selection surface separate personal progress from social encouragement. - layout: A character scene sits above approachable checklists, while a support picker presents friendly illustrated reactions. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Bright green and pink panels with soft character illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study shared goal checklist, support message picker, adventure and daily goals. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 26. Daylio Source website: https://apps.apple.com/us/app/id1194023242 Swipefile reference: https://swipefile.design/ref/mobile-daylio/ Screenshot: https://swipefile.design/_astro/000.vvN7aNDD.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing A calendar of mood icons summarizes previous entries; new entries use a short emotion scale and labeled activity groups. Publisher previews: - Mood calendar: https://swipefile.design/_astro/000.vvN7aNDD.webp - Mood selection: https://swipefile.design/_astro/001.Btg0N6kc.webp - Activity selection: https://swipefile.design/_astro/002.C1NEapcb.webp Useful for: Study mood calendar, mood selection, activity selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Mood calendar · Mood selection · Activity selection - nav: The entry screens use clear close and save controls around a focused question. - layout: A calendar of mood icons summarizes previous entries; new entries use a short emotion scale and labeled activity groups. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space with green controls and multicolored mood icons. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Daylio Source: https://apps.apple.com/us/app/id1194023242 Swipefile reference: https://swipefile.design/ref/mobile-daylio/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Mood calendar · Mood selection · Activity selection - nav: The entry screens use clear close and save controls around a focused question. - layout: A calendar of mood icons summarizes previous entries; new entries use a short emotion scale and labeled activity groups. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space with green controls and multicolored mood icons. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study mood calendar, mood selection, activity selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 27. Stoic Source website: https://apps.apple.com/us/app/id1312926037 Swipefile reference: https://swipefile.design/ref/mobile-stoic/ Screenshot: https://swipefile.design/_astro/000.6zBtgtt2.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing Large monochrome cards group reflective activities and writing prompts with restrained supporting text. Publisher previews: - Morning reflection choices: https://swipefile.design/_astro/000.6zBtgtt2.webp - Sleep content grid: https://swipefile.design/_astro/001.76n8YFQ9.webp - Writing prompt selection: https://swipefile.design/_astro/002.gbJ7vqgW.webp Useful for: Study morning reflection choices, sleep content grid, writing prompt selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Morning reflection choices · Sleep content grid · Writing prompt selection - nav: Named activity cards and writing shortcuts provide distinct starting points. - layout: Large monochrome cards group reflective activities and writing prompts with restrained supporting text. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black, white, and soft gray with simple symbolic illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Stoic Source: https://apps.apple.com/us/app/id1312926037 Swipefile reference: https://swipefile.design/ref/mobile-stoic/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Morning reflection choices · Sleep content grid · Writing prompt selection - nav: Named activity cards and writing shortcuts provide distinct starting points. - layout: Large monochrome cards group reflective activities and writing prompts with restrained supporting text. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black, white, and soft gray with simple symbolic illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study morning reflection choices, sleep content grid, writing prompt selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 28. Medito Source website: https://apps.apple.com/us/app/id1500780518 Swipefile reference: https://swipefile.design/ref/mobile-medito/ Screenshot: https://swipefile.design/_astro/000.BjiaL0ov.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing A dark home surface places compact shortcuts above colorful course art, then simplifies into a text list on a category page. Publisher previews: - Home shortcuts: https://swipefile.design/_astro/000.BjiaL0ov.webp - Course library: https://swipefile.design/_astro/001.D6gkVKZL.webp - Sleep content categories: https://swipefile.design/_astro/002.Chd-pfw-.webp Useful for: Study home shortcuts, course library, sleep content categories. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Home shortcuts · Course library · Sleep content categories - nav: Home shortcuts lead into course and sleep categories, each with a clear title. - layout: A dark home surface places compact shortcuts above colorful course art, then simplifies into a text list on a category page. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Charcoal surfaces, pale blue selection, and vibrant illustrated covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Medito Source: https://apps.apple.com/us/app/id1500780518 Swipefile reference: https://swipefile.design/ref/mobile-medito/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Home shortcuts · Course library · Sleep content categories - nav: Home shortcuts lead into course and sleep categories, each with a clear title. - layout: A dark home surface places compact shortcuts above colorful course art, then simplifies into a text list on a category page. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Charcoal surfaces, pale blue selection, and vibrant illustrated covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study home shortcuts, course library, sleep content categories. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 29. How We Feel Source website: https://apps.apple.com/us/app/id1562706384 Swipefile reference: https://swipefile.design/ref/mobile-how-we-feel/ Screenshot: https://swipefile.design/_astro/000.CZ-T9KR4.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing Large colored emotion labels lead into image-led journal cards and a compact calendar of previous check-ins. Publisher previews: - Emotion word map: https://swipefile.design/_astro/000.CZ-T9KR4.webp - Journal entries: https://swipefile.design/_astro/001.DVG21ln7.webp - Monthly history: https://swipefile.design/_astro/002.DmlN7lKR.webp Useful for: Study emotion word map, journal entries, monthly history. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Emotion word map · Journal entries · Monthly history - nav: The entry list exposes a plus control; the monthly view provides a separate historical overview. - layout: Large colored emotion labels lead into image-led journal cards and a compact calendar of previous check-ins. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black backgrounds with yellow, red, blue, and green emotion accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: How We Feel Source: https://apps.apple.com/us/app/id1562706384 Swipefile reference: https://swipefile.design/ref/mobile-how-we-feel/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Emotion word map · Journal entries · Monthly history - nav: The entry list exposes a plus control; the monthly view provides a separate historical overview. - layout: Large colored emotion labels lead into image-led journal cards and a compact calendar of previous check-ins. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black backgrounds with yellow, red, blue, and green emotion accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study emotion word map, journal entries, monthly history. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 30. Reflectly Source website: https://apps.apple.com/us/app/id1241229134 Swipefile reference: https://swipefile.design/ref/mobile-reflectly/ Screenshot: https://swipefile.design/_astro/000.OcyYGLYU.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Wellbeing A friendly character, a short prompt, and a simple slider keep each screen focused on one response. Publisher previews: - Welcome screen: https://swipefile.design/_astro/000.OcyYGLYU.webp - Daily journaling card: https://swipefile.design/_astro/001.TmxINcnM.webp - Mood question: https://swipefile.design/_astro/002.GLogJt8s.webp Useful for: Study welcome screen, daily journaling card, mood question. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Welcome screen · Daily journaling card · Mood question - nav: Welcome and daily-entry surfaces use a prominent lower action and limited secondary controls. - layout: A friendly character, a short prompt, and a simple slider keep each screen focused on one response. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Purple gradients and rounded white cards. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Reflectly Source: https://apps.apple.com/us/app/id1241229134 Swipefile reference: https://swipefile.design/ref/mobile-reflectly/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Welcome screen · Daily journaling card · Mood question - nav: Welcome and daily-entry surfaces use a prominent lower action and limited secondary controls. - layout: A friendly character, a short prompt, and a simple slider keep each screen focused on one response. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Purple gradients and rounded white cards. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Check-ins & journaling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study welcome screen, daily journaling card, mood question. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 31. Strava Source website: https://apps.apple.com/us/app/id426826309 Swipefile reference: https://swipefile.design/ref/mobile-strava/ Screenshot: https://swipefile.design/_astro/000.DFuPlmFQ.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Activity cards combine photography and social feedback, while a recording screen gives the route map most of the space. Publisher previews: - Activity feed: https://swipefile.design/_astro/000.DFuPlmFQ.webp - Club discussion: https://swipefile.design/_astro/001.CXDxI8yV.webp - Workout recording: https://swipefile.design/_astro/002.D8i5JDRv.webp Useful for: Study activity feed, club discussion, workout recording. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Activity feed · Club discussion · Workout recording - nav: Bottom navigation separates feed, mapping, recording, groups, and personal activity. - layout: Activity cards combine photography and social feedback, while a recording screen gives the route map most of the space. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Charcoal surfaces with orange route and action accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Activity & notifications - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Strava Source: https://apps.apple.com/us/app/id426826309 Swipefile reference: https://swipefile.design/ref/mobile-strava/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Activity feed · Club discussion · Workout recording - nav: Bottom navigation separates feed, mapping, recording, groups, and personal activity. - layout: Activity cards combine photography and social feedback, while a recording screen gives the route map most of the space. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Charcoal surfaces with orange route and action accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Activity & notifications - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study activity feed, club discussion, workout recording. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 32. Nike Run Club Source website: https://apps.apple.com/us/app/id387771637 Swipefile reference: https://swipefile.design/ref/mobile-nike-run-club/ Screenshot: https://swipefile.design/_astro/000.B2nfjyu7.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Large distance totals and a small bar chart summarize progress; vivid artwork distinguishes a guided run from a plan card. Publisher previews: - Running activity summary: https://swipefile.design/_astro/000.B2nfjyu7.webp - Guided run detail: https://swipefile.design/_astro/001.1126Fifb.webp - Training plan: https://swipefile.design/_astro/002.DJC1okXb.webp Useful for: Study running activity summary, guided run detail, training plan. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Running activity summary · Guided run detail · Training plan - nav: Bottom destinations expose activity and plans, while the run detail centers a Start control. - layout: Large distance totals and a small bar chart summarize progress; vivid artwork distinguishes a guided run from a plan card. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White reporting surfaces and bold orange running artwork. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Nike Run Club Source: https://apps.apple.com/us/app/id387771637 Swipefile reference: https://swipefile.design/ref/mobile-nike-run-club/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Running activity summary · Guided run detail · Training plan - nav: Bottom destinations expose activity and plans, while the run detail centers a Start control. - layout: Large distance totals and a small bar chart summarize progress; vivid artwork distinguishes a guided run from a plan card. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White reporting surfaces and bold orange running artwork. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Habits & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study running activity summary, guided run detail, training plan. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 33. Nike Training Club Source website: https://apps.apple.com/us/app/id301521403 Swipefile reference: https://swipefile.design/ref/mobile-nike-training-club/ Screenshot: https://swipefile.design/_astro/000.FzNMLF4D.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Workout rows use thumbnail imagery and brief metadata; broad categories use larger photographic cards. Publisher previews: - Workout list: https://swipefile.design/_astro/000.FzNMLF4D.webp - Workout categories: https://swipefile.design/_astro/001.CPSgul0z.webp - Activity history: https://swipefile.design/_astro/002.BGq4KNLa.webp Useful for: Study workout list, workout categories, activity history. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Workout list · Workout categories · Activity history - nav: Bottom tabs distinguish discovery, workouts, and recorded activity. - layout: Workout rows use thumbnail imagery and brief metadata; broad categories use larger photographic cards. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content surfaces, black text, and photographic covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Nike Training Club Source: https://apps.apple.com/us/app/id301521403 Swipefile reference: https://swipefile.design/ref/mobile-nike-training-club/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Workout list · Workout categories · Activity history - nav: Bottom tabs distinguish discovery, workouts, and recorded activity. - layout: Workout rows use thumbnail imagery and brief metadata; broad categories use larger photographic cards. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content surfaces, black text, and photographic covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study workout list, workout categories, activity history. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 34. AllTrails Source website: https://apps.apple.com/us/app/id405075943 Swipefile reference: https://swipefile.design/ref/mobile-alltrails/ Screenshot: https://swipefile.design/_astro/000.Cdcmsrls.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Photographic trail cards lead into a detail sheet with route statistics, then a larger photo view with an elevation graph. Publisher previews: - Trail discovery: https://swipefile.design/_astro/000.Cdcmsrls.webp - Trail detail: https://swipefile.design/_astro/001.Cw7W0xg1.webp - Photo tour and elevation: https://swipefile.design/_astro/002.DR7FUZ2V.webp Useful for: Study trail discovery, trail detail, photo tour and elevation. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Trail discovery · Trail detail · Photo tour and elevation - nav: Search, category chips, and a Map control provide clear ways to narrow exploration. - layout: Photographic trail cards lead into a detail sheet with route statistics, then a larger photo view with an elevation graph. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, green actions, and outdoor photography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: AllTrails Source: https://apps.apple.com/us/app/id405075943 Swipefile reference: https://swipefile.design/ref/mobile-alltrails/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Trail discovery · Trail detail · Photo tour and elevation - nav: Search, category chips, and a Map control provide clear ways to narrow exploration. - layout: Photographic trail cards lead into a detail sheet with route statistics, then a larger photo view with an elevation graph. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, green actions, and outdoor photography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study trail discovery, trail detail, photo tour and elevation. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 35. Komoot Source website: https://apps.apple.com/us/app/id447374873 Swipefile reference: https://swipefile.design/ref/mobile-komoot/ Screenshot: https://swipefile.design/_astro/000.BjDbdPuO.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors A route map shares space with terrain, elevation, waypoint, and weather information in layered panels. Publisher previews: - Route detail and terrain: https://swipefile.design/_astro/000.BjDbdPuO.webp - Route navigation: https://swipefile.design/_astro/001.v6VpWRTY.webp - Route information: https://swipefile.design/_astro/002.DPR42Chs.webp Useful for: Study route detail and terrain, route navigation, route information. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Route detail and terrain · Route navigation · Route information - nav: Named detail tabs and lower Save or Navigate controls separate inspection from following a route. - layout: A route map shares space with terrain, elevation, waypoint, and weather information in layered panels. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Muted green maps, cream surfaces, and olive controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Komoot Source: https://apps.apple.com/us/app/id447374873 Swipefile reference: https://swipefile.design/ref/mobile-komoot/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Route detail and terrain · Route navigation · Route information - nav: Named detail tabs and lower Save or Navigate controls separate inspection from following a route. - layout: A route map shares space with terrain, elevation, waypoint, and weather information in layered panels. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Muted green maps, cream surfaces, and olive controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study route detail and terrain, route navigation, route information. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 36. Peloton Source website: https://apps.apple.com/us/app/id792750948 Swipefile reference: https://swipefile.design/ref/mobile-peloton/ Screenshot: https://swipefile.design/_astro/000.C5R6V_q-.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Progress rings and a featured class introduce the day; a separate list uses filters and a plan summary groups days by activity. Publisher previews: - Daily workout recommendation: https://swipefile.design/_astro/000.C5R6V_q-.webp - Workout discovery: https://swipefile.design/_astro/001.C_VLHHcV.webp - Weekly plan preview: https://swipefile.design/_astro/002.NYcc1O1a.webp Useful for: Study daily workout recommendation, workout discovery, weekly plan preview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Daily workout recommendation · Workout discovery · Weekly plan preview - nav: Bottom destinations and top category chips support browsing without losing the main workout context. - layout: Progress rings and a featured class introduce the day; a separate list uses filters and a plan summary groups days by activity. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Near-black panels, violet accents, and trainer photography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Peloton Source: https://apps.apple.com/us/app/id792750948 Swipefile reference: https://swipefile.design/ref/mobile-peloton/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Daily workout recommendation · Workout discovery · Weekly plan preview - nav: Bottom destinations and top category chips support browsing without losing the main workout context. - layout: Progress rings and a featured class introduce the day; a separate list uses filters and a plan summary groups days by activity. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Near-black panels, violet accents, and trainer photography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study daily workout recommendation, workout discovery, weekly plan preview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 37. Fitbod Source website: https://apps.apple.com/us/app/id1041517543 Swipefile reference: https://swipefile.design/ref/mobile-fitbod/ Screenshot: https://swipefile.design/_astro/000.DhNyQQV4.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Exercise rows and a set table make entry compact, while a body diagram summarizes which muscle groups were recently trained. Publisher previews: - Workout exercise list: https://swipefile.design/_astro/000.DhNyQQV4.webp - Exercise sets: https://swipefile.design/_astro/001.CoYPjUrx.webp - Muscle recovery visualization: https://swipefile.design/_astro/002.CgLLh-7W.webp Useful for: Study workout exercise list, exercise sets, muscle recovery visualization. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Workout exercise list · Exercise sets · Muscle recovery visualization - nav: Workout controls lead into exercise details with contextual set editing. - layout: Exercise rows and a set table make entry compact, while a body diagram summarizes which muscle groups were recently trained. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark blue-gray surfaces with pink muscle highlights and small colored controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Fitbod Source: https://apps.apple.com/us/app/id1041517543 Swipefile reference: https://swipefile.design/ref/mobile-fitbod/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Workout exercise list · Exercise sets · Muscle recovery visualization - nav: Workout controls lead into exercise details with contextual set editing. - layout: Exercise rows and a set table make entry compact, while a body diagram summarizes which muscle groups were recently trained. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark blue-gray surfaces with pink muscle highlights and small colored controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study workout exercise list, exercise sets, muscle recovery visualization. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 38. Hevy Source website: https://apps.apple.com/us/app/id1458862350 Swipefile reference: https://swipefile.design/ref/mobile-hevy/ Screenshot: https://swipefile.design/_astro/000.DPCkwkUj.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors A compact sets table uses completion marks, a progress view emphasizes one chart, and routine cards expose a Start action. Publisher previews: - Workout set logging: https://swipefile.design/_astro/000.DPCkwkUj.webp - Exercise progress chart: https://swipefile.design/_astro/001.DTZupY_U.webp - Routine selection: https://swipefile.design/_astro/002.BL1Yg_Mc.webp Useful for: Study workout set logging, exercise progress chart, routine selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Workout set logging · Exercise progress chart · Routine selection - nav: Workout, exercise analysis, and routine surfaces separate logging from planning. - layout: A compact sets table uses completion marks, a progress view emphasizes one chart, and routine cards expose a Start action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, blue controls, and green completion highlights. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Hevy Source: https://apps.apple.com/us/app/id1458862350 Swipefile reference: https://swipefile.design/ref/mobile-hevy/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Workout set logging · Exercise progress chart · Routine selection - nav: Workout, exercise analysis, and routine surfaces separate logging from planning. - layout: A compact sets table uses completion marks, a progress view emphasizes one chart, and routine cards expose a Start action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, blue controls, and green completion highlights. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study workout set logging, exercise progress chart, routine selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 39. Strong Source website: https://apps.apple.com/us/app/id464254577 Swipefile reference: https://swipefile.design/ref/mobile-strong/ Screenshot: https://swipefile.design/_astro/000.DgmU2WMc.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Set rows expose weight, repetitions, and completion; an exercise page adds instructions, while a calculator appears in a sheet. Publisher previews: - Workout logging: https://swipefile.design/_astro/000.DgmU2WMc.webp - Exercise instructions: https://swipefile.design/_astro/001.xUjURgWF.webp - Plate calculator: https://swipefile.design/_astro/002.DyLYZ6Fo.webp Useful for: Study workout logging, exercise instructions, plate calculator. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Workout logging · Exercise instructions · Plate calculator - nav: Exercise detail tabs distinguish instructions, history, charts, and records. - layout: Set rows expose weight, repetitions, and completion; an exercise page adds instructions, while a calculator appears in a sheet. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with blue navigation and green completion controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Strong Source: https://apps.apple.com/us/app/id464254577 Swipefile reference: https://swipefile.design/ref/mobile-strong/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Workout logging · Exercise instructions · Plate calculator - nav: Exercise detail tabs distinguish instructions, history, charts, and records. - layout: Set rows expose weight, repetitions, and completion; an exercise page adds instructions, while a calculator appears in a sheet. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with blue navigation and green completion controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study workout logging, exercise instructions, plate calculator. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 40. MyFitnessPal Source website: https://apps.apple.com/us/app/id341232718 Swipefile reference: https://swipefile.design/ref/mobile-myfitnesspal/ Screenshot: https://swipefile.design/_astro/000.DkMKiAnj.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Fitness & outdoors Stacked nutrient bars summarize a period, while food capture presents an editable list before a logging action. Publisher previews: - Nutrition chart: https://swipefile.design/_astro/000.DkMKiAnj.webp - Food scan results: https://swipefile.design/_astro/001.BV9OEr7w.webp - Voice logging: https://swipefile.design/_astro/002.Bnh-OfUi.webp Useful for: Study nutrition chart, food scan results, voice logging. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Nutrition chart · Food scan results · Voice logging - nav: Report tabs, capture controls, and a focused voice sheet separate overview from adding data. - layout: Stacked nutrient bars summarize a period, while food capture presents an editable list before a logging action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with blue actions and multicolored chart segments. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: MyFitnessPal Source: https://apps.apple.com/us/app/id341232718 Swipefile reference: https://swipefile.design/ref/mobile-myfitnesspal/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Nutrition chart · Food scan results · Voice logging - nav: Report tabs, capture controls, and a focused voice sheet separate overview from adding data. - layout: Stacked nutrient bars summarize a period, while food capture presents an editable list before a logging action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with blue actions and multicolored chart segments. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Logging & tracking - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study nutrition chart, food scan results, voice logging. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 41. Airbnb Source website: https://apps.apple.com/us/app/id401626263 Swipefile reference: https://swipefile.design/ref/mobile-airbnb/ Screenshot: https://swipefile.design/_astro/000.DsfGrqUn.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel Large rounded photos, compact ratings, and small category illustrations make different travel offerings easy to scan. Publisher previews: - Home discovery: https://swipefile.design/_astro/000.DsfGrqUn.webp - Stay search results: https://swipefile.design/_astro/001.SUhYDMDq.webp - Experience discovery: https://swipefile.design/_astro/002.BNeBYMZH.webp Useful for: Study home discovery, stay search results, experience discovery. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Home discovery · Stay search results · Experience discovery - nav: A prominent search pill and named Homes, Experiences, and Services destinations orient browsing. - layout: Large rounded photos, compact ratings, and small category illustrations make different travel offerings easy to scan. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white surfaces with content-driven photography and small pink accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Airbnb Source: https://apps.apple.com/us/app/id401626263 Swipefile reference: https://swipefile.design/ref/mobile-airbnb/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Home discovery · Stay search results · Experience discovery - nav: A prominent search pill and named Homes, Experiences, and Services destinations orient browsing. - layout: Large rounded photos, compact ratings, and small category illustrations make different travel offerings easy to scan. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white surfaces with content-driven photography and small pink accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study home discovery, stay search results, experience discovery. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 42. Booking.com Source website: https://apps.apple.com/us/app/id367003839 Swipefile reference: https://swipefile.design/ref/mobile-booking-com/ Screenshot: https://swipefile.design/_astro/000.Bd7ZRx7P.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel Destination, dates, and guests form a compact search panel; result rows expose ratings before a property detail adds price and room selection. Publisher previews: - Trip search form: https://swipefile.design/_astro/000.Bd7ZRx7P.webp - Hotel results: https://swipefile.design/_astro/001.lNwKlCmc.webp - Hotel detail: https://swipefile.design/_astro/002.vcdjOjwM.webp Useful for: Study trip search form, hotel results, hotel detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Trip search form · Hotel results · Hotel detail - nav: Travel-type tabs precede search, with sort and filter controls above results. - layout: Destination, dates, and guests form a compact search panel; result rows expose ratings before a property detail adds price and room selection. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue headers, yellow field emphasis, and white content. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Booking.com Source: https://apps.apple.com/us/app/id367003839 Swipefile reference: https://swipefile.design/ref/mobile-booking-com/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Trip search form · Hotel results · Hotel detail - nav: Travel-type tabs precede search, with sort and filter controls above results. - layout: Destination, dates, and guests form a compact search panel; result rows expose ratings before a property detail adds price and room selection. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue headers, yellow field emphasis, and white content. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study trip search form, hotel results, hotel detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 43. Expedia Source website: https://apps.apple.com/us/app/id427916203 Swipefile reference: https://swipefile.design/ref/mobile-expedia/ Screenshot: https://swipefile.design/_astro/000.Bc2s4yNZ.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel Structured search fields lead into image-led listings, then a property page groups dates, travelers, and room options. Publisher previews: - Trip search: https://swipefile.design/_astro/000.Bc2s4yNZ.webp - Stay results: https://swipefile.design/_astro/001.JH2oQmoT.webp - Stay detail and room selection: https://swipefile.design/_astro/002.CRq_TYOJ.webp Useful for: Study trip search, stay results, stay detail and room selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Trip search · Stay results · Stay detail and room selection - nav: Named travel modes and filter chips keep the selected search context visible. - layout: Structured search fields lead into image-led listings, then a property page groups dates, travelers, and room options. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and cream surfaces with blue actions and yellow accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Expedia Source: https://apps.apple.com/us/app/id427916203 Swipefile reference: https://swipefile.design/ref/mobile-expedia/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Trip search · Stay results · Stay detail and room selection - nav: Named travel modes and filter chips keep the selected search context visible. - layout: Structured search fields lead into image-led listings, then a property page groups dates, travelers, and room options. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and cream surfaces with blue actions and yellow accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study trip search, stay results, stay detail and room selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 44. Tripadvisor Source website: https://apps.apple.com/us/app/id284876795 Swipefile reference: https://swipefile.design/ref/mobile-tripadvisor/ Screenshot: https://swipefile.design/_astro/000.ByUSGf2Y.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel Property imagery leads into a review distribution, while a nearby map uses category chips and cards below the map. Publisher previews: - Hotel detail: https://swipefile.design/_astro/000.ByUSGf2Y.webp - Review breakdown: https://swipefile.design/_astro/001.CWNaGj0N.webp - Nearby map discovery: https://swipefile.design/_astro/002.DVAvWJD7.webp Useful for: Study hotel detail, review breakdown, nearby map discovery. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Hotel detail · Review breakdown · Nearby map discovery - nav: Bottom destinations and explicit Discover, Saves, and Restaurants chips distinguish browsing routes. - layout: Property imagery leads into a review distribution, while a nearby map uses category chips and cards below the map. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, deep green controls, and bright green promotional framing. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Ratings & reviews - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Tripadvisor Source: https://apps.apple.com/us/app/id284876795 Swipefile reference: https://swipefile.design/ref/mobile-tripadvisor/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Hotel detail · Review breakdown · Nearby map discovery - nav: Bottom destinations and explicit Discover, Saves, and Restaurants chips distinguish browsing routes. - layout: Property imagery leads into a review distribution, while a nearby map uses category chips and cards below the map. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, deep green controls, and bright green promotional framing. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Ratings & reviews - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study hotel detail, review breakdown, nearby map discovery. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 45. Hopper Source website: https://apps.apple.com/us/app/id904052407 Swipefile reference: https://swipefile.design/ref/mobile-hopper/ Screenshot: https://swipefile.design/_astro/000.Dm4AUEYX.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel A calendar uses a color legend to compare dates; a raised explanation card presents a watch action above the trip details. Publisher previews: - Travel discovery: https://swipefile.design/_astro/000.Dm4AUEYX.webp - Date price calendar: https://swipefile.design/_astro/001.C4RY4k2e.webp - Price-watch prompt: https://swipefile.design/_astro/002.Diox-s59.webp Useful for: Study travel discovery, date price calendar, price-watch prompt. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Travel discovery · Date price calendar · Price-watch prompt - nav: Travel categories and a dedicated date-selection surface separate destination browsing from timing. - layout: A calendar uses a color legend to compare dates; a raised explanation card presents a watch action above the trip details. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content with coral controls and multicolored date cells. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Hopper Source: https://apps.apple.com/us/app/id904052407 Swipefile reference: https://swipefile.design/ref/mobile-hopper/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Travel discovery · Date price calendar · Price-watch prompt - nav: Travel categories and a dedicated date-selection surface separate destination browsing from timing. - layout: A calendar uses a color legend to compare dates; a raised explanation card presents a watch action above the trip details. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content with coral controls and multicolored date cells. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study travel discovery, date price calendar, price-watch prompt. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 46. KAYAK Source website: https://apps.apple.com/us/app/id305204535 Swipefile reference: https://swipefile.design/ref/mobile-kayak/ Screenshot: https://swipefile.design/_astro/000.CNg83Ja3.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel A compact travel home leads into a date grid and dense flight rows with times, stops, prices, and a clear action. Publisher previews: - Travel home: https://swipefile.design/_astro/000.CNg83Ja3.webp - Date price comparison: https://swipefile.design/_astro/001.CmbLddA2.webp - Flight results: https://swipefile.design/_astro/002.qfUPbB14.webp Useful for: Study travel home, date price comparison, flight results. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Travel home · Date price comparison · Flight results - nav: Travel-mode icons, result sorting, and filter chips keep comparisons organized. - layout: A compact travel home leads into a date grid and dense flight rows with times, stops, prices, and a clear action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and pale gray surfaces with orange actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: KAYAK Source: https://apps.apple.com/us/app/id305204535 Swipefile reference: https://swipefile.design/ref/mobile-kayak/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Travel home · Date price comparison · Flight results - nav: Travel-mode icons, result sorting, and filter chips keep comparisons organized. - layout: A compact travel home leads into a date grid and dense flight rows with times, stops, prices, and a clear action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and pale gray surfaces with orange actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study travel home, date price comparison, flight results. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 47. TripIt Source website: https://apps.apple.com/us/app/id311035142 Swipefile reference: https://swipefile.design/ref/mobile-tripit/ Screenshot: https://swipefile.design/_astro/000.oYEdNIxL.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel A map and chronological itinerary organize the journey, while a separate list groups saved trips. Publisher previews: - Trip map: https://swipefile.design/_astro/000.oYEdNIxL.webp - Itinerary timeline: https://swipefile.design/_astro/001.CAtR6bam.webp - Saved trip list: https://swipefile.design/_astro/002.BsvRjdcq.webp Useful for: Study trip map, itinerary timeline, saved trip list. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Trip map · Itinerary timeline · Saved trip list - nav: Trip-level views keep location context distinct from the sequence of booked activities. - layout: A map and chronological itinerary organize the journey, while a separate list groups saved trips. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, blue framing, and green itinerary accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: TripIt Source: https://apps.apple.com/us/app/id311035142 Swipefile reference: https://swipefile.design/ref/mobile-tripit/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Trip map · Itinerary timeline · Saved trip list - nav: Trip-level views keep location context distinct from the sequence of booked activities. - layout: A map and chronological itinerary organize the journey, while a separate list groups saved trips. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, blue framing, and green itinerary accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Calendars & scheduling - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study trip map, itinerary timeline, saved trip list. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 48. Flighty Source website: https://apps.apple.com/us/app/id1358823008 Swipefile reference: https://swipefile.design/ref/mobile-flighty/ Screenshot: https://swipefile.design/_astro/000.BZa0Ocz-.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel A globe and compact flight rows provide the overview; a status card condenses flight progress for the lock screen. Publisher previews: - Upcoming flight list: https://swipefile.design/_astro/000.BZa0Ocz-.webp - Live Activity previews: https://swipefile.design/_astro/001.b3mKzF1v.webp - Inbound aircraft detail: https://swipefile.design/_astro/002.Cl3eVE1G.webp Useful for: Study upcoming flight list, live activity previews, inbound aircraft detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Upcoming flight list · Live Activity previews · Inbound aircraft detail - nav: Flight rows lead into aircraft and status details with a map above the supporting information. - layout: A globe and compact flight rows provide the overview; a status card condenses flight progress for the lock screen. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White flight lists, dark maps, and green or red status accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Flighty Source: https://apps.apple.com/us/app/id1358823008 Swipefile reference: https://swipefile.design/ref/mobile-flighty/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Upcoming flight list · Live Activity previews · Inbound aircraft detail - nav: Flight rows lead into aircraft and status details with a map above the supporting information. - layout: A globe and compact flight rows provide the overview; a status card condenses flight progress for the lock screen. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White flight lists, dark maps, and green or red status accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study upcoming flight list, live activity previews, inbound aircraft detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 49. Uber Source website: https://apps.apple.com/us/app/id368677368 Swipefile reference: https://swipefile.design/ref/mobile-uber/ Screenshot: https://swipefile.design/_astro/000.CXUnEGDM.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel A map labels the pickup point, a search form collects the destination, and a compact vehicle list compares ride options. Publisher previews: - Pickup guidance: https://swipefile.design/_astro/000.CXUnEGDM.webp - Destination entry: https://swipefile.design/_astro/001.1-wVUDGK.webp - Ride selection: https://swipefile.design/_astro/002.CUVAPjCG.webp Useful for: Study pickup guidance, destination entry, ride selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Pickup guidance · Destination entry · Ride selection - nav: Back controls and explicit destination fields keep the trip context visible across the shown surfaces. - layout: A map labels the pickup point, a search form collects the destination, and a compact vehicle list compares ride options. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and black controls with subdued map colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Uber Source: https://apps.apple.com/us/app/id368677368 Swipefile reference: https://swipefile.design/ref/mobile-uber/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Pickup guidance · Destination entry · Ride selection - nav: Back controls and explicit destination fields keep the trip context visible across the shown surfaces. - layout: A map labels the pickup point, a search form collects the destination, and a compact vehicle list compares ride options. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and black controls with subdued map colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study pickup guidance, destination entry, ride selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 50. Lyft Source website: https://apps.apple.com/us/app/id529379082 Swipefile reference: https://swipefile.design/ref/mobile-lyft/ Screenshot: https://swipefile.design/_astro/000.DhTdQkwP.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Travel A route map sits above ride options, while bike reservation combines the nearby vehicle location with a lower detail sheet. Publisher previews: - Ride choices: https://swipefile.design/_astro/000.DhTdQkwP.webp - Expanded ride choices: https://swipefile.design/_astro/001.DvTYV9nw.webp - Bike reservation: https://swipefile.design/_astro/002.C1y7kVEl.webp Useful for: Study ride choices, expanded ride choices, bike reservation. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Ride choices · Expanded ride choices · Bike reservation - nav: Search and map controls remain above selection cards with a clear reservation action. - layout: A route map sits above ride options, while bike reservation combines the nearby vehicle location with a lower detail sheet. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with purple routes and actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Lyft Source: https://apps.apple.com/us/app/id529379082 Swipefile reference: https://swipefile.design/ref/mobile-lyft/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Ride choices · Expanded ride choices · Bike reservation - nav: Search and map controls remain above selection cards with a clear reservation action. - layout: A route map sits above ride options, while bike reservation combines the nearby vehicle location with a lower detail sheet. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with purple routes and actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study ride choices, expanded ride choices, bike reservation. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 51. Google Maps Source website: https://apps.apple.com/us/app/id585027354 Swipefile reference: https://swipefile.design/ref/mobile-google-maps/ Screenshot: https://swipefile.design/_astro/000.CYql21oZ.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather A large map keeps the route visible behind maneuver instructions and a compact lower trip summary. Publisher previews: - Turn-by-turn navigation: https://swipefile.design/_astro/000.CYql21oZ.webp - Route question and options: https://swipefile.design/_astro/001.B2XQ_MVU.webp - Traffic-aware route: https://swipefile.design/_astro/002.DHHWBTeP.webp Useful for: Study turn-by-turn navigation, route question and options, traffic-aware route. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Turn-by-turn navigation · Route question and options · Traffic-aware route - nav: Floating map controls and a bottom information sheet separate map manipulation from trip details. - layout: A large map keeps the route visible behind maneuver instructions and a compact lower trip summary. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Pale maps, blue routes, green instructions, and red traffic accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Google Maps Source: https://apps.apple.com/us/app/id585027354 Swipefile reference: https://swipefile.design/ref/mobile-google-maps/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Turn-by-turn navigation · Route question and options · Traffic-aware route - nav: Floating map controls and a bottom information sheet separate map manipulation from trip details. - layout: A large map keeps the route visible behind maneuver instructions and a compact lower trip summary. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Pale maps, blue routes, green instructions, and red traffic accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study turn-by-turn navigation, route question and options, traffic-aware route. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 52. Waze Source website: https://apps.apple.com/us/app/id323229106 Swipefile reference: https://swipefile.design/ref/mobile-waze/ Screenshot: https://swipefile.design/_astro/000.Dui-2Ysp.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather A maneuver banner sits above the route while a lower card reports an incident and offers simple feedback choices. Publisher previews: - Route guidance: https://swipefile.design/_astro/000.Dui-2Ysp.webp - Road incident alert: https://swipefile.design/_astro/001.DMFii-J3.webp - Night navigation alert: https://swipefile.design/_astro/002.DYIUB278.webp Useful for: Study route guidance, road incident alert, night navigation alert. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Route guidance · Road incident alert · Night navigation alert - nav: Map controls remain secondary to the next turn and trip timing. - layout: A maneuver banner sits above the route while a lower card reports an incident and offers simple feedback choices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White or dark maps with purple routes and blue feedback controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Waze Source: https://apps.apple.com/us/app/id323229106 Swipefile reference: https://swipefile.design/ref/mobile-waze/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Route guidance · Road incident alert · Night navigation alert - nav: Map controls remain secondary to the next turn and trip timing. - layout: A maneuver banner sits above the route while a lower card reports an incident and offers simple feedback choices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White or dark maps with purple routes and blue feedback controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study route guidance, road incident alert, night navigation alert. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 53. Citymapper Source website: https://apps.apple.com/us/app/id469463298 Swipefile reference: https://swipefile.design/ref/mobile-citymapper/ Screenshot: https://swipefile.design/_astro/000.p1hw72Vk.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather A transit map and route choices combine transport icons with duration information. Publisher previews: - Transit home: https://swipefile.design/_astro/000.p1hw72Vk.webp - Route comparison: https://swipefile.design/_astro/001.MWzAuzG6.webp - Journey instructions: https://swipefile.design/_astro/002.DiclZUha.webp Useful for: Study transit home, route comparison, journey instructions. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Transit home · Route comparison · Journey instructions - nav: Search and transport-mode controls lead into route comparisons. - layout: A transit map and route choices combine transport icons with duration information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Green accents, white panels, and multicolored transport markers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Citymapper Source: https://apps.apple.com/us/app/id469463298 Swipefile reference: https://swipefile.design/ref/mobile-citymapper/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Transit home · Route comparison · Journey instructions - nav: Search and transport-mode controls lead into route comparisons. - layout: A transit map and route choices combine transport icons with duration information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Green accents, white panels, and multicolored transport markers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study transit home, route comparison, journey instructions. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 54. Transit Source website: https://apps.apple.com/us/app/id498151501 Swipefile reference: https://swipefile.design/ref/mobile-transit/ Screenshot: https://swipefile.design/_astro/000.BQgjly2U.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather Bold route-colored rows emphasize the next departure, while a detail view combines a map with arrival estimates and disruption notices. Publisher previews: - Nearby departures: https://swipefile.design/_astro/000.BQgjly2U.webp - Vehicle arrivals: https://swipefile.design/_astro/001.F_DOH3Ie.webp - Service disruption: https://swipefile.design/_astro/002.BV-1Qwfb.webp Useful for: Study nearby departures, vehicle arrivals, service disruption. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Nearby departures · Vehicle arrivals · Service disruption - nav: A destination field sits between map and route list; route details expose a clear close control. - layout: Bold route-colored rows emphasize the next departure, while a detail view combines a map with arrival estimates and disruption notices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Yellow, red, blue, and green route colors on white or map surfaces. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Transit Source: https://apps.apple.com/us/app/id498151501 Swipefile reference: https://swipefile.design/ref/mobile-transit/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Nearby departures · Vehicle arrivals · Service disruption - nav: A destination field sits between map and route list; route details expose a clear close control. - layout: Bold route-colored rows emphasize the next departure, while a detail view combines a map with arrival estimates and disruption notices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Yellow, red, blue, and green route colors on white or map surfaces. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study nearby departures, vehicle arrivals, service disruption. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 55. Moovit Source website: https://apps.apple.com/us/app/id498477945 Swipefile reference: https://swipefile.design/ref/mobile-moovit/ Screenshot: https://swipefile.design/_astro/000.bJcKRAor.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather Origin and destination fields lead into route summaries with transport icons, durations, and a nearby map. Publisher previews: - Route search: https://swipefile.design/_astro/000.bJcKRAor.webp - Transit route options: https://swipefile.design/_astro/001.nTpKoZ5J.webp - Nearby lines: https://swipefile.design/_astro/002.D832FPp3.webp Useful for: Study route search, transit route options, nearby lines. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Route search · Transit route options · Nearby lines - nav: Search and route-selection surfaces preserve the trip endpoints above the options. - layout: Origin and destination fields lead into route summaries with transport icons, durations, and a nearby map. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, dark blue framing, and varied transport colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Moovit Source: https://apps.apple.com/us/app/id498477945 Swipefile reference: https://swipefile.design/ref/mobile-moovit/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Route search · Transit route options · Nearby lines - nav: Search and route-selection surfaces preserve the trip endpoints above the options. - layout: Origin and destination fields lead into route summaries with transport icons, durations, and a nearby map. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, dark blue framing, and varied transport colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study route search, transit route options, nearby lines. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 56. Rome2Rio Source website: https://apps.apple.com/us/app/id569793256 Swipefile reference: https://swipefile.design/ref/mobile-rome2rio/ Screenshot: https://swipefile.design/_astro/000.CHWb_beW.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather A map and plain transport rows compare modes by time and price, while a search panel collects endpoints and date. Publisher previews: - Route overview: https://swipefile.design/_astro/000.CHWb_beW.webp - Transport comparison: https://swipefile.design/_astro/001.CvOztFeX.webp - Trip search: https://swipefile.design/_astro/002.DcHhe48K.webp Useful for: Study route overview, transport comparison, trip search. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Route overview · Transport comparison · Trip search - nav: Back navigation and a swap control make the origin-destination relationship explicit. - layout: A map and plain transport rows compare modes by time and price, while a search panel collects endpoints and date. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, mint framing, and magenta search actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Rome2Rio Source: https://apps.apple.com/us/app/id569793256 Swipefile reference: https://swipefile.design/ref/mobile-rome2rio/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Route overview · Transport comparison · Trip search - nav: Back navigation and a swap control make the origin-destination relationship explicit. - layout: A map and plain transport rows compare modes by time and price, while a search panel collects endpoints and date. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, mint framing, and magenta search actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study route overview, transport comparison, trip search. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 57. MAPS.ME Source website: https://apps.apple.com/us/app/id510623322 Swipefile reference: https://swipefile.design/ref/mobile-maps-me/ Screenshot: https://swipefile.design/_astro/000.CvxVZ2QD.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather Large maneuver cues sit over the route, while the hiking surface pairs a map with elevation and distance information. Publisher previews: - Driving guidance: https://swipefile.design/_astro/000.CvxVZ2QD.webp - Hiking route and elevation: https://swipefile.design/_astro/001.ByRQ0hy3.webp - Map style comparison: https://swipefile.design/_astro/002.D5NuEHql.webp Useful for: Study driving guidance, hiking route and elevation, map style comparison. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Driving guidance · Hiking route and elevation · Map style comparison - nav: Floating map controls leave most of the screen available for location context. - layout: Large maneuver cues sit over the route, while the hiking surface pairs a map with elevation and distance information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Pale green terrain, blue route highlights, and high-contrast maneuver badges. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: MAPS.ME Source: https://apps.apple.com/us/app/id510623322 Swipefile reference: https://swipefile.design/ref/mobile-maps-me/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Driving guidance · Hiking route and elevation · Map style comparison - nav: Floating map controls leave most of the screen available for location context. - layout: Large maneuver cues sit over the route, while the hiking surface pairs a map with elevation and distance information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Pale green terrain, blue route highlights, and high-contrast maneuver badges. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study driving guidance, hiking route and elevation, map style comparison. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 58. Organic Maps Source website: https://apps.apple.com/us/app/id1567437057 Swipefile reference: https://swipefile.design/ref/mobile-organic-maps/ Screenshot: https://swipefile.design/_astro/000.DqCL9vKs.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather A place sheet, an elevation chart, and a maneuver banner each add relevant detail without replacing the map. Publisher previews: - Place detail: https://swipefile.design/_astro/000.DqCL9vKs.webp - Trail elevation profile: https://swipefile.design/_astro/001.mPjdt-5_.webp - Night route guidance: https://swipefile.design/_astro/002.Cx__T0zW.webp Useful for: Study place detail, trail elevation profile, night route guidance. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Place detail · Trail elevation profile · Night route guidance - nav: Compact lower actions cover routing, saving, and place-level tasks. - layout: A place sheet, an elevation chart, and a maneuver banner each add relevant detail without replacing the map. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Muted maps, blue route highlights, and a dark navigation theme. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Organic Maps Source: https://apps.apple.com/us/app/id1567437057 Swipefile reference: https://swipefile.design/ref/mobile-organic-maps/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Place detail · Trail elevation profile · Night route guidance - nav: Compact lower actions cover routing, saving, and place-level tasks. - layout: A place sheet, an elevation chart, and a maneuver banner each add relevant detail without replacing the map. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Muted maps, blue route highlights, and a dark navigation theme. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Maps & navigation - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study place detail, trail elevation profile, night route guidance. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 59. CARROT Weather Source website: https://apps.apple.com/us/app/id961390574 Swipefile reference: https://swipefile.design/ref/mobile-carrot-weather/ Screenshot: https://swipefile.design/_astro/000.Db_TUW9i.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather Large temperature typography and a horizontal forecast contrast with a radar map and its color scale. Publisher previews: - Current weather: https://swipefile.design/_astro/000.Db_TUW9i.webp - Weather radar: https://swipefile.design/_astro/001.C6akusAl.webp - Home-screen widgets: https://swipefile.design/_astro/002.Css_mhdT.webp Useful for: Study current weather, weather radar, home-screen widgets. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Current weather · Weather radar · Home-screen widgets - nav: Location and weather-view controls keep the current place identifiable. - layout: Large temperature typography and a horizontal forecast contrast with a radar map and its color scale. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Bright blue forecast surfaces and a dark multicolored radar map. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: CARROT Weather Source: https://apps.apple.com/us/app/id961390574 Swipefile reference: https://swipefile.design/ref/mobile-carrot-weather/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Current weather · Weather radar · Home-screen widgets - nav: Location and weather-view controls keep the current place identifiable. - layout: Large temperature typography and a horizontal forecast contrast with a radar map and its color scale. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Bright blue forecast surfaces and a dark multicolored radar map. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study current weather, weather radar, home-screen widgets. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 60. AccuWeather Source website: https://apps.apple.com/us/app/id300048137 Swipefile reference: https://swipefile.design/ref/mobile-accuweather/ Screenshot: https://swipefile.design/_astro/000.C652imzR.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Maps & weather A circular precipitation display emphasizes the current reading, while a separate list uses labeled scales for environmental indices. Publisher previews: - Minute precipitation forecast: https://swipefile.design/_astro/000.C652imzR.webp - Health-related weather indices: https://swipefile.design/_astro/001.BLMwAHDc.webp - Severe weather alerts: https://swipefile.design/_astro/002.BUZdRdb4.webp Useful for: Study minute precipitation forecast, health-related weather indices, severe weather alerts. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Minute precipitation forecast · Health-related weather indices · Severe weather alerts - nav: Location stays at the top of each view, above the detailed conditions. - layout: A circular precipitation display emphasizes the current reading, while a separate list uses labeled scales for environmental indices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark blue surfaces with orange branding and colored condition scales. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: AccuWeather Source: https://apps.apple.com/us/app/id300048137 Swipefile reference: https://swipefile.design/ref/mobile-accuweather/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Minute precipitation forecast · Health-related weather indices · Severe weather alerts - nav: Location stays at the top of each view, above the detailed conditions. - layout: A circular precipitation display emphasizes the current reading, while a separate list uses labeled scales for environmental indices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark blue surfaces with orange branding and colored condition scales. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study minute precipitation forecast, health-related weather indices, severe weather alerts. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 61. YNAB Source website: https://apps.apple.com/us/app/id1010865877 Swipefile reference: https://swipefile.design/ref/mobile-ynab/ Screenshot: https://swipefile.design/_astro/000.BJJvXEg6.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance Priority rows, a plan total, and category funding bars create three levels of budget detail. Publisher previews: - Budget home: https://swipefile.design/_astro/000.BJJvXEg6.webp - Plan editor: https://swipefile.design/_astro/001.CSkoFXJS.webp - Category funding: https://swipefile.design/_astro/002.Ce9ueoIA.webp Useful for: Study budget home, plan editor, category funding. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Budget home · Plan editor · Category funding - nav: Home and plan surfaces separate the overview from assigning amounts to categories. - layout: Priority rows, a plan total, and category funding bars create three levels of budget detail. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and dark blue surfaces with bright green allocation highlights. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: YNAB Source: https://apps.apple.com/us/app/id1010865877 Swipefile reference: https://swipefile.design/ref/mobile-ynab/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Budget home · Plan editor · Category funding - nav: Home and plan surfaces separate the overview from assigning amounts to categories. - layout: Priority rows, a plan total, and category funding bars create three levels of budget detail. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and dark blue surfaces with bright green allocation highlights. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study budget home, plan editor, category funding. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 62. Monarch Money Source website: https://apps.apple.com/us/app/id1459319842 Swipefile reference: https://swipefile.design/ref/mobile-monarch-money/ Screenshot: https://swipefile.design/_astro/000.C3Nh5TmP.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance An account trend, a flow diagram, and category progress bars each explain a different scale of financial information. Publisher previews: - Account overview: https://swipefile.design/_astro/000.C3Nh5TmP.webp - Cash-flow diagram: https://swipefile.design/_astro/001.G0CXfH1F.webp - Budget categories: https://swipefile.design/_astro/002.Cuo-UlVP.webp Useful for: Study account overview, cash-flow diagram, budget categories. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Account overview · Cash-flow diagram · Budget categories - nav: Report and budget headings clarify the purpose of each view. - layout: An account trend, a flow diagram, and category progress bars each explain a different scale of financial information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white surfaces with green, coral, and category-colored charts. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Monarch Money Source: https://apps.apple.com/us/app/id1459319842 Swipefile reference: https://swipefile.design/ref/mobile-monarch-money/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Account overview · Cash-flow diagram · Budget categories - nav: Report and budget headings clarify the purpose of each view. - layout: An account trend, a flow diagram, and category progress bars each explain a different scale of financial information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white surfaces with green, coral, and category-colored charts. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study account overview, cash-flow diagram, budget categories. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 63. Copilot Money Source website: https://apps.apple.com/us/app/id1447330651 Swipefile reference: https://swipefile.design/ref/mobile-copilot-money/ Screenshot: https://swipefile.design/_astro/000.DgZbxTiA.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance A dashboard combines small charts and category rings; dedicated views enlarge cash flow and spending history. Publisher previews: - Spending dashboard: https://swipefile.design/_astro/000.DgZbxTiA.webp - Cash-flow charts: https://swipefile.design/_astro/001.D1awAYUp.webp - Transaction category detail: https://swipefile.design/_astro/002.C4Srm7pp.webp Useful for: Study spending dashboard, cash-flow charts, transaction category detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Spending dashboard · Cash-flow charts · Transaction category detail - nav: Dashboard, cash-flow, and transaction surfaces move from overview to detail. - layout: A dashboard combines small charts and category rings; dedicated views enlarge cash flow and spending history. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Deep navy backgrounds with green charts and bright category colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Copilot Money Source: https://apps.apple.com/us/app/id1447330651 Swipefile reference: https://swipefile.design/ref/mobile-copilot-money/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Spending dashboard · Cash-flow charts · Transaction category detail - nav: Dashboard, cash-flow, and transaction surfaces move from overview to detail. - layout: A dashboard combines small charts and category rings; dedicated views enlarge cash flow and spending history. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Deep navy backgrounds with green charts and bright category colors. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study spending dashboard, cash-flow charts, transaction category detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 64. Rocket Money Source website: https://apps.apple.com/us/app/id1130616675 Swipefile reference: https://swipefile.design/ref/mobile-rocket-money/ Screenshot: https://swipefile.design/_astro/000.pfQx9ZXi.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance A small calendar and upcoming-charge list organize recurring activity; other screens use conversation and a focused next-step explanation. Publisher previews: - Recurring bills: https://swipefile.design/_astro/000.pfQx9ZXi.webp - Assistant conversation: https://swipefile.design/_astro/001.DN_TNc8b.webp - Cancellation introduction: https://swipefile.design/_astro/002.C4XSdJdv.webp Useful for: Study recurring bills, assistant conversation, cancellation introduction. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Recurring bills · Assistant conversation · Cancellation introduction - nav: Recurring tabs distinguish upcoming items, while the cancellation screen presents one clear starting action. - layout: A small calendar and upcoming-charge list organize recurring activity; other screens use conversation and a focused next-step explanation. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, red section color, and black primary buttons. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Activity & notifications - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Rocket Money Source: https://apps.apple.com/us/app/id1130616675 Swipefile reference: https://swipefile.design/ref/mobile-rocket-money/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Recurring bills · Assistant conversation · Cancellation introduction - nav: Recurring tabs distinguish upcoming items, while the cancellation screen presents one clear starting action. - layout: A small calendar and upcoming-charge list organize recurring activity; other screens use conversation and a focused next-step explanation. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, red section color, and black primary buttons. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Activity & notifications - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study recurring bills, assistant conversation, cancellation introduction. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 65. Wise Source website: https://apps.apple.com/us/app/id612261027 Swipefile reference: https://swipefile.design/ref/mobile-wise/ Screenshot: https://swipefile.design/_astro/000.WlWRceAV.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance Balances and quick actions form a compact account page; the transfer quote makes currencies, amounts, and fees visible together. Publisher previews: - Account balances: https://swipefile.design/_astro/000.WlWRceAV.webp - Transfer quote: https://swipefile.design/_astro/001.C55Xe-0n.webp - Explore information card: https://swipefile.design/_astro/002.BhY2A2Ma.webp Useful for: Study account balances, transfer quote, explore information card. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Account balances · Transfer quote · Explore information card - nav: Account actions and bottom destinations are separated from the transfer confirmation control. - layout: Balances and quick actions form a compact account page; the transfer quote makes currencies, amounts, and fees visible together. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, vivid green controls, and strong amount typography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Wise Source: https://apps.apple.com/us/app/id612261027 Swipefile reference: https://swipefile.design/ref/mobile-wise/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Account balances · Transfer quote · Explore information card - nav: Account actions and bottom destinations are separated from the transfer confirmation control. - layout: Balances and quick actions form a compact account page; the transfer quote makes currencies, amounts, and fees visible together. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, vivid green controls, and strong amount typography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study account balances, transfer quote, explore information card. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 66. Revolut Source website: https://apps.apple.com/us/app/id932493382 Swipefile reference: https://swipefile.design/ref/mobile-revolut/ Screenshot: https://swipefile.design/_astro/000.BH2zU_0k.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance A prominent balance and lower action tiles contrast with a person-centered payment conversation. Publisher previews: - Savings overview: https://swipefile.design/_astro/000.BH2zU_0k.webp - Payment conversation: https://swipefile.design/_astro/001.i558fOLC.webp - Card personalization: https://swipefile.design/_astro/002.3DYPZWsL.webp Useful for: Study savings overview, payment conversation, card personalization. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Savings overview · Payment conversation · Card personalization - nav: Account controls and a dedicated send surface distinguish managing money from paying a contact. - layout: A prominent balance and lower action tiles contrast with a person-centered payment conversation. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark surfaces, white controls, and bright payment-card accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Revolut Source: https://apps.apple.com/us/app/id932493382 Swipefile reference: https://swipefile.design/ref/mobile-revolut/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Savings overview · Payment conversation · Card personalization - nav: Account controls and a dedicated send surface distinguish managing money from paying a contact. - layout: A prominent balance and lower action tiles contrast with a person-centered payment conversation. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark surfaces, white controls, and bright payment-card accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study savings overview, payment conversation, card personalization. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 67. Venmo Source website: https://apps.apple.com/us/app/id351727428 Swipefile reference: https://swipefile.design/ref/mobile-venmo/ Screenshot: https://swipefile.design/_astro/000.C17G1d6S.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance A large amount, recipient identity, and short note precede clearly separated Request and Pay actions. Publisher previews: - Payment amount entry: https://swipefile.design/_astro/000.C17G1d6S.webp - Card balance: https://swipefile.design/_astro/001.DbrxaS-S.webp - Direct deposit details: https://swipefile.design/_astro/002.D6wgZ30j.webp Useful for: Study payment amount entry, card balance, direct deposit details. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Payment amount entry · Card balance · Direct deposit details - nav: The payment sheet keeps its keypad below the decision controls. - layout: A large amount, recipient identity, and short note precede clearly separated Request and Pay actions. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with blue actions and restrained gray metadata. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Venmo Source: https://apps.apple.com/us/app/id351727428 Swipefile reference: https://swipefile.design/ref/mobile-venmo/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Payment amount entry · Card balance · Direct deposit details - nav: The payment sheet keeps its keypad below the decision controls. - layout: A large amount, recipient identity, and short note precede clearly separated Request and Pay actions. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with blue actions and restrained gray metadata. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study payment amount entry, card balance, direct deposit details. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 68. PayPal Source website: https://apps.apple.com/us/app/id283646709 Swipefile reference: https://swipefile.design/ref/mobile-paypal/ Screenshot: https://swipefile.design/_astro/000.WNyz-Raz.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance A product discovery view contrasts with a focused payment amount and a grid of spending categories. Publisher previews: - Shopping destinations: https://swipefile.design/_astro/000.WNyz-Raz.webp - Payment amount entry: https://swipefile.design/_astro/001.CNCkBntM.webp - Card and reward categories: https://swipefile.design/_astro/002.DWaLpVvC.webp Useful for: Study shopping destinations, payment amount entry, card and reward categories. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Shopping destinations · Payment amount entry · Card and reward categories - nav: Named destinations and paired Request and Send controls explain the main choices. - layout: A product discovery view contrasts with a focused payment amount and a grid of spending categories. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black and white surfaces with deep blue branding. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: PayPal Source: https://apps.apple.com/us/app/id283646709 Swipefile reference: https://swipefile.design/ref/mobile-paypal/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Shopping destinations · Payment amount entry · Card and reward categories - nav: Named destinations and paired Request and Send controls explain the main choices. - layout: A product discovery view contrasts with a focused payment amount and a grid of spending categories. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black and white surfaces with deep blue branding. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study shopping destinations, payment amount entry, card and reward categories. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 69. Cash App Source website: https://apps.apple.com/us/app/id711923939 Swipefile reference: https://swipefile.design/ref/mobile-cash-app/ Screenshot: https://swipefile.design/_astro/000.D4ABb5F-.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance A compact account overview gives way to a large amount keypad, while a circular goal display summarizes savings progress. Publisher previews: - Money overview: https://swipefile.design/_astro/000.D4ABb5F-.webp - Payment keypad: https://swipefile.design/_astro/001.DBo51lyF.webp - Savings goal: https://swipefile.design/_astro/002.DE5MhdgZ.webp Useful for: Study money overview, payment keypad, savings goal. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Money overview · Payment keypad · Savings goal - nav: Lower account destinations and explicit transfer controls separate overview from moving funds. - layout: A compact account overview gives way to a large amount keypad, while a circular goal display summarizes savings progress. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black, white, and bright green with prominent amount typography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Cash App Source: https://apps.apple.com/us/app/id711923939 Swipefile reference: https://swipefile.design/ref/mobile-cash-app/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Money overview · Payment keypad · Savings goal - nav: Lower account destinations and explicit transfer controls separate overview from moving funds. - layout: A compact account overview gives way to a large amount keypad, while a circular goal display summarizes savings progress. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black, white, and bright green with prominent amount typography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Payments & transfers - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study money overview, payment keypad, savings goal. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 70. Coinbase Source website: https://apps.apple.com/us/app/id886427730 Swipefile reference: https://swipefile.design/ref/mobile-coinbase/ Screenshot: https://swipefile.design/_astro/000.CFMKqTQS.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Finance Asset rows use small trend lines; an account overview groups frequent actions, and a success card confirms a completed transaction. Publisher previews: - Asset list: https://swipefile.design/_astro/000.CFMKqTQS.webp - Account dashboard: https://swipefile.design/_astro/001.vQdHHX0-.webp - Transaction success: https://swipefile.design/_astro/002.DsN5x4qI.webp Useful for: Study asset list, account dashboard, transaction success. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Asset list · Account dashboard · Transaction success - nav: Search and quick actions provide access to assets without hiding the account balance. - layout: Asset rows use small trend lines; an account overview groups frequent actions, and a success card confirms a completed transaction. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, blue actions, and a high-contrast confirmation mark. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Coinbase Source: https://apps.apple.com/us/app/id886427730 Swipefile reference: https://swipefile.design/ref/mobile-coinbase/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Asset list · Account dashboard · Transaction success - nav: Search and quick actions provide access to assets without hiding the account balance. - layout: Asset rows use small trend lines; an account overview groups frequent actions, and a success card confirms a completed transaction. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, blue actions, and a high-contrast confirmation mark. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study asset list, account dashboard, transaction success. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 71. Spotify Source website: https://apps.apple.com/us/app/id324684580 Swipefile reference: https://swipefile.design/ref/mobile-spotify/ Screenshot: https://swipefile.design/_astro/000.BWwBzwqH.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio A dark library mixes compact shortcuts with larger cover art; a player emphasizes playback, while a playlist becomes a scannable track list. Publisher previews: - Library discovery: https://swipefile.design/_astro/000.BWwBzwqH.webp - Podcast player: https://swipefile.design/_astro/001.DaxSjOgP.webp - Playlist detail: https://swipefile.design/_astro/002.DeUDkiiE.webp Useful for: Study library discovery, podcast player, playlist detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Library discovery · Podcast player · Playlist detail - nav: Category chips and back controls distinguish discovery from the current listening context. - layout: A dark library mixes compact shortcuts with larger cover art; a player emphasizes playback, while a playlist becomes a scannable track list. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Near-black surfaces, green playback accents, and colorful cover art. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Media playback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Spotify Source: https://apps.apple.com/us/app/id324684580 Swipefile reference: https://swipefile.design/ref/mobile-spotify/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Library discovery · Podcast player · Playlist detail - nav: Category chips and back controls distinguish discovery from the current listening context. - layout: A dark library mixes compact shortcuts with larger cover art; a player emphasizes playback, while a playlist becomes a scannable track list. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Near-black surfaces, green playback accents, and colorful cover art. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Media playback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study library discovery, podcast player, playlist detail. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 72. Pocket Casts Source website: https://apps.apple.com/us/app/id414834813 Swipefile reference: https://swipefile.design/ref/mobile-pocket-casts/ Screenshot: https://swipefile.design/_astro/000.BcpqtZgM.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio Large episode artwork gives way to a grid of subscriptions and a compact sheet for speed and audio settings. Publisher previews: - Now playing: https://swipefile.design/_astro/000.BcpqtZgM.webp - Podcast library: https://swipefile.design/_astro/001.w8iWSY7y.webp - Playback effects: https://swipefile.design/_astro/002.rb8Dz44H.webp Useful for: Study now playing, podcast library, playback effects. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Now playing · Podcast library · Playback effects - nav: Bottom destinations separate library and discovery, while playback settings stay within the player. - layout: Large episode artwork gives way to a grid of subscriptions and a compact sheet for speed and audio settings. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark playback surfaces, a white library, and restrained teal accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Media playback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Pocket Casts Source: https://apps.apple.com/us/app/id414834813 Swipefile reference: https://swipefile.design/ref/mobile-pocket-casts/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Now playing · Podcast library · Playback effects - nav: Bottom destinations separate library and discovery, while playback settings stay within the player. - layout: Large episode artwork gives way to a grid of subscriptions and a compact sheet for speed and audio settings. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark playback surfaces, a white library, and restrained teal accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Media playback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study now playing, podcast library, playback effects. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 73. Overcast Source website: https://apps.apple.com/us/app/id888422857 Swipefile reference: https://swipefile.design/ref/mobile-overcast/ Screenshot: https://swipefile.design/_astro/000.BXyrXF8t.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio Recent episodes, circular playlist shortcuts, and a plain podcast list provide three ways to resume listening on one screen. Publisher previews: - Podcast home: https://swipefile.design/_astro/000.BXyrXF8t.webp Useful for: Study podcast home. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Podcast home - nav: Settings and search sit at the top; named playlists and a Current/All switch organize the library. - layout: Recent episodes, circular playlist shortcuts, and a plain podcast list provide three ways to resume listening on one screen. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White background with orange, purple, blue, and green playlist icons. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Overcast Source: https://apps.apple.com/us/app/id888422857 Swipefile reference: https://swipefile.design/ref/mobile-overcast/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Podcast home - nav: Settings and search sit at the top; named playlists and a Current/All switch organize the library. - layout: Recent episodes, circular playlist shortcuts, and a plain podcast list provide three ways to resume listening on one screen. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White background with orange, purple, blue, and green playlist icons. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study podcast home. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 74. Audible Source website: https://apps.apple.com/us/app/id379693831 Swipefile reference: https://swipefile.design/ref/mobile-audible/ Screenshot: https://swipefile.design/_astro/000.gdeOSgG0.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio Large covers introduce recommendations; a contextual item menu exposes sharing, and the player prioritizes a progress bar and transport controls. Publisher previews: - Audiobook discovery: https://swipefile.design/_astro/000.gdeOSgG0.webp - Library item actions: https://swipefile.design/_astro/001.CEzYghuA.webp - Audiobook player: https://swipefile.design/_astro/002.DuS6RMXv.webp Useful for: Study audiobook discovery, library item actions, audiobook player. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Audiobook discovery · Library item actions · Audiobook player - nav: Library search and item-level actions keep collection management separate from playback. - layout: Large covers introduce recommendations; a contextual item menu exposes sharing, and the player prioritizes a progress bar and transport controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Deep blue and black surfaces with white text and cover-driven color. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Media playback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Audible Source: https://apps.apple.com/us/app/id379693831 Swipefile reference: https://swipefile.design/ref/mobile-audible/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Audiobook discovery · Library item actions · Audiobook player - nav: Library search and item-level actions keep collection management separate from playback. - layout: Large covers introduce recommendations; a contextual item menu exposes sharing, and the player prioritizes a progress bar and transport controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Deep blue and black surfaces with white text and cover-driven color. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Media playback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study audiobook discovery, library item actions, audiobook player. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 75. Kindle Source website: https://apps.apple.com/us/app/id302584613 Swipefile reference: https://swipefile.design/ref/mobile-kindle/ Screenshot: https://swipefile.design/_astro/000.Ccfe5BSJ.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio A cover grid, a reading-history calendar, and a typography settings sheet present collection, progress, and reading preferences separately. Publisher previews: - Book library: https://swipefile.design/_astro/000.Ccfe5BSJ.webp - Reading challenges: https://swipefile.design/_astro/001.DkVlIfc-.webp - Reading appearance settings: https://swipefile.design/_astro/002.OPCVx-QL.webp Useful for: Study book library, reading challenges, reading appearance settings. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Book library · Reading challenges · Reading appearance settings - nav: Library search and reading-setting tabs provide direct access to content and appearance. - layout: A cover grid, a reading-history calendar, and a typography settings sheet present collection, progress, and reading preferences separately. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark reading surfaces, white progress cards, and colorful book covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Reading & typography - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Kindle Source: https://apps.apple.com/us/app/id302584613 Swipefile reference: https://swipefile.design/ref/mobile-kindle/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Book library · Reading challenges · Reading appearance settings - nav: Library search and reading-setting tabs provide direct access to content and appearance. - layout: A cover grid, a reading-history calendar, and a typography settings sheet present collection, progress, and reading preferences separately. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Dark reading surfaces, white progress cards, and colorful book covers. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Reading & typography - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study book library, reading challenges, reading appearance settings. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 76. Libby Source website: https://apps.apple.com/us/app/id1076402606 Swipefile reference: https://swipefile.design/ref/mobile-libby/ Screenshot: https://swipefile.design/_astro/000.BjBudVhU.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio A welcoming message leads into a local library page with sorting chips, then a book list with availability and hold information. Publisher previews: - Library welcome: https://swipefile.design/_astro/000.BjBudVhU.webp - Library discovery: https://swipefile.design/_astro/001.d8A2-I9a.webp - Curated book list: https://swipefile.design/_astro/002.YNTnFVf2.webp Useful for: Study library welcome, library discovery, curated book list. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Library welcome · Library discovery · Curated book list - nav: Library-level back navigation and clear list controls preserve the selected library context. - layout: A welcoming message leads into a local library page with sorting chips, then a book list with availability and hold information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm cream, burgundy, and turquoise surfaces with book-cover imagery. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Libby Source: https://apps.apple.com/us/app/id1076402606 Swipefile reference: https://swipefile.design/ref/mobile-libby/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Library welcome · Library discovery · Curated book list - nav: Library-level back navigation and clear list controls preserve the selected library context. - layout: A welcoming message leads into a local library page with sorting chips, then a book list with availability and hold information. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm cream, burgundy, and turquoise surfaces with book-cover imagery. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Content discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study library welcome, library discovery, curated book list. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 77. The StoryGraph Source website: https://apps.apple.com/us/app/id1570489264 Swipefile reference: https://swipefile.design/ref/mobile-the-storygraph/ Screenshot: https://swipefile.design/_astro/000.CDYy13MW.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio Book rows expose reading status, while bar and line charts summarize patterns over time. Publisher previews: - Reading list: https://swipefile.design/_astro/000.CDYy13MW.webp - Reading mood chart: https://swipefile.design/_astro/001.D6kF39dl.webp - Reading history charts: https://swipefile.design/_astro/002.DEqlZ5Cy.webp Useful for: Study reading list, reading mood chart, reading history charts. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Reading list · Reading mood chart · Reading history charts - nav: A search field and persistent lower destinations distinguish book management from statistics. - layout: Book rows expose reading status, while bar and line charts summarize patterns over time. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, teal controls, and multicolored chart series. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: The StoryGraph Source: https://apps.apple.com/us/app/id1570489264 Swipefile reference: https://swipefile.design/ref/mobile-the-storygraph/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Reading list · Reading mood chart · Reading history charts - nav: A search field and persistent lower destinations distinguish book management from statistics. - layout: Book rows expose reading status, while bar and line charts summarize patterns over time. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, teal controls, and multicolored chart series. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Data visualization - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study reading list, reading mood chart, reading history charts. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 78. Goodreads Source website: https://apps.apple.com/us/app/id355833469 Swipefile reference: https://swipefile.design/ref/mobile-goodreads/ Screenshot: https://swipefile.design/_astro/000.xtE5k8GI.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio Shelf rows summarize reading progress, recommendation cards emphasize covers, and review rows expose stars and community feedback. Publisher previews: - Reading shelves: https://swipefile.design/_astro/000.xtE5k8GI.webp - Book recommendations: https://swipefile.design/_astro/001.Ch6e_IqK.webp - Reader reviews: https://swipefile.design/_astro/002.C0sudG_V.webp Useful for: Study reading shelves, book recommendations, reader reviews. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Reading shelves · Book recommendations · Reader reviews - nav: Search stays prominent above shelves and recommendations. - layout: Shelf rows summarize reading progress, recommendation cards emphasize covers, and review rows expose stars and community feedback. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and cream panels with green reading controls and book-cover color. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Ratings & reviews - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Goodreads Source: https://apps.apple.com/us/app/id355833469 Swipefile reference: https://swipefile.design/ref/mobile-goodreads/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Reading shelves · Book recommendations · Reader reviews - nav: Search stays prominent above shelves and recommendations. - layout: Shelf rows summarize reading progress, recommendation cards emphasize covers, and review rows expose stars and community feedback. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and cream panels with green reading controls and book-cover color. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Ratings & reviews - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study reading shelves, book recommendations, reader reviews. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 79. Medium Source website: https://apps.apple.com/us/app/id828256236 Swipefile reference: https://swipefile.design/ref/mobile-medium/ Screenshot: https://swipefile.design/_astro/000.DAaXD_xA.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio A narrow article column contrasts with editorial cards and compact topic chips in a personalization screen. Publisher previews: - Article reading: https://swipefile.design/_astro/000.DAaXD_xA.webp - Story discovery: https://swipefile.design/_astro/001.CXdvGJXT.webp - Topic selection: https://swipefile.design/_astro/002.D6HQuCQn.webp Useful for: Study article reading, story discovery, topic selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Article reading · Story discovery · Topic selection - nav: Story controls sit near the reading context; topic selection ends with a clear Continue action. - layout: A narrow article column contrasts with editorial cards and compact topic chips in a personalization screen. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white pages, black typography, and restrained green accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Reading & typography - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Medium Source: https://apps.apple.com/us/app/id828256236 Swipefile reference: https://swipefile.design/ref/mobile-medium/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Article reading · Story discovery · Topic selection - nav: Story controls sit near the reading context; topic selection ends with a clear Continue action. - layout: A narrow article column contrasts with editorial cards and compact topic chips in a personalization screen. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white pages, black typography, and restrained green accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Reading & typography - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study article reading, story discovery, topic selection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 80. The New York Times Source website: https://apps.apple.com/us/app/id284862083 Swipefile reference: https://swipefile.design/ref/mobile-the-new-york-times/ Screenshot: https://swipefile.design/_astro/000.DxWOJxJI.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Reading & audio Serif headlines establish article hierarchy, an image grid supports lifestyle discovery, and a separate player reduces an audio story to cover and controls. Publisher previews: - News article: https://swipefile.design/_astro/000.DxWOJxJI.webp - Lifestyle discovery: https://swipefile.design/_astro/001.Bo8KVPb8.webp - Audio story player: https://swipefile.design/_astro/002.Bi4Abpt0.webp Useful for: Study news article, lifestyle discovery, audio story player. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: News article · Lifestyle discovery · Audio story player - nav: Section labels organize editorial content, while the player gives transport controls clear priority. - layout: Serif headlines establish article hierarchy, an image grid supports lifestyle discovery, and a separate player reduces an audio story to cover and controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black and white editorial surfaces with photography and podcast artwork. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Reading & typography - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: The New York Times Source: https://apps.apple.com/us/app/id284862083 Swipefile reference: https://swipefile.design/ref/mobile-the-new-york-times/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: News article · Lifestyle discovery · Audio story player - nav: Section labels organize editorial content, while the player gives transport controls clear priority. - layout: Serif headlines establish article hierarchy, an image grid supports lifestyle discovery, and a separate player reduces an audio story to cover and controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black and white editorial surfaces with photography and podcast artwork. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Reading & typography - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study news article, lifestyle discovery, audio story player. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 81. Duolingo Source website: https://apps.apple.com/us/app/id570060128 Swipefile reference: https://swipefile.design/ref/mobile-duolingo/ Screenshot: https://swipefile.design/_astro/000.BbQgZ-iz.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning A plain course list leads into exercises with a progress bar, large answer targets, and an illustrated task area. Publisher previews: - Course selection: https://swipefile.design/_astro/000.BbQgZ-iz.webp - Image-choice lesson: https://swipefile.design/_astro/001.DuEJxzVW.webp - Chess exercise: https://swipefile.design/_astro/002.Cz9-llK9.webp Useful for: Study course selection, image-choice lesson, chess exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Course selection · Image-choice lesson · Chess exercise - nav: A close control and visible lesson progress frame the task without adding competing destinations. - layout: A plain course list leads into exercises with a progress bar, large answer targets, and an illustrated task area. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, green progress, pastel answer cards, and playful illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Duolingo Source: https://apps.apple.com/us/app/id570060128 Swipefile reference: https://swipefile.design/ref/mobile-duolingo/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Course selection · Image-choice lesson · Chess exercise - nav: A close control and visible lesson progress frame the task without adding competing destinations. - layout: A plain course list leads into exercises with a progress bar, large answer targets, and an illustrated task area. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, green progress, pastel answer cards, and playful illustrations. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study course selection, image-choice lesson, chess exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 82. Babbel Source website: https://apps.apple.com/us/app/id829587759 Swipefile reference: https://swipefile.design/ref/mobile-babbel/ Screenshot: https://swipefile.design/_astro/000.CpyHKfh4.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning Short prompts combine audio controls with a large microphone action, while the plan uses compact lesson tiles and progress marks. Publisher previews: - Speaking exercise: https://swipefile.design/_astro/000.CpyHKfh4.webp - Learning plan: https://swipefile.design/_astro/001.CTTHR3Vx.webp - Dialogue practice: https://swipefile.design/_astro/002.DV7fwxPi.webp Useful for: Study speaking exercise, learning plan, dialogue practice. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Speaking exercise · Learning plan · Dialogue practice - nav: Back and next controls guide exercises; the plan provides a separate overview. - layout: Short prompts combine audio controls with a large microphone action, while the plan uses compact lesson tiles and progress marks. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and cream surfaces, orange speech controls, and pale green lesson cards. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Babbel Source: https://apps.apple.com/us/app/id829587759 Swipefile reference: https://swipefile.design/ref/mobile-babbel/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Speaking exercise · Learning plan · Dialogue practice - nav: Back and next controls guide exercises; the plan provides a separate overview. - layout: Short prompts combine audio controls with a large microphone action, while the plan uses compact lesson tiles and progress marks. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White and cream surfaces, orange speech controls, and pale green lesson cards. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study speaking exercise, learning plan, dialogue practice. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 83. Busuu Source website: https://apps.apple.com/us/app/id379968583 Swipefile reference: https://swipefile.design/ref/mobile-busuu/ Screenshot: https://swipefile.design/_astro/000.BtTB8sIC.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning A language list becomes a video-backed question with two answers, followed by an illustrated completion summary. Publisher previews: - Language choice: https://swipefile.design/_astro/000.BtTB8sIC.webp - Video question: https://swipefile.design/_astro/001.SIzv_-ve.webp - Lesson completion: https://swipefile.design/_astro/002.BkAGtqeN.webp Useful for: Study language choice, video question, lesson completion. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Language choice · Video question · Lesson completion - nav: A progress bar and close control bound the lesson; the result surface summarizes the outcome. - layout: A language list becomes a video-backed question with two answers, followed by an illustrated completion summary. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue and white surfaces with green progress and colorful success illustration. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Busuu Source: https://apps.apple.com/us/app/id379968583 Swipefile reference: https://swipefile.design/ref/mobile-busuu/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Language choice · Video question · Lesson completion - nav: A progress bar and close control bound the lesson; the result surface summarizes the outcome. - layout: A language list becomes a video-backed question with two answers, followed by an illustrated completion summary. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Blue and white surfaces with green progress and colorful success illustration. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study language choice, video question, lesson completion. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 84. Memrise Source website: https://apps.apple.com/us/app/id635966718 Swipefile reference: https://swipefile.design/ref/mobile-memrise/ Screenshot: https://swipefile.design/_astro/000.CMQAlEd0.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning Topic cards connect learning to situations, video questions place answers beneath a speaker, and a word list supports revisiting material. Publisher previews: - Topic selection: https://swipefile.design/_astro/000.CMQAlEd0.webp - Video vocabulary exercise: https://swipefile.design/_astro/001.SOCWML4W.webp - Saved vocabulary: https://swipefile.design/_astro/002.CeQ2rBFn.webp Useful for: Study topic selection, video vocabulary exercise, saved vocabulary. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Topic selection · Video vocabulary exercise · Saved vocabulary - nav: Learn and Practice tabs, topic search, and audio controls separate discovery from review. - layout: Topic cards connect learning to situations, video questions place answers beneath a speaker, and a word list supports revisiting material. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with yellow topic cards and green video framing. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Memrise Source: https://apps.apple.com/us/app/id635966718 Swipefile reference: https://swipefile.design/ref/mobile-memrise/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Topic selection · Video vocabulary exercise · Saved vocabulary - nav: Learn and Practice tabs, topic search, and audio controls separate discovery from review. - layout: Topic cards connect learning to situations, video questions place answers beneath a speaker, and a word list supports revisiting material. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with yellow topic cards and green video framing. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study topic selection, video vocabulary exercise, saved vocabulary. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 85. Drops Source website: https://apps.apple.com/us/app/id939540371 Swipefile reference: https://swipefile.design/ref/mobile-drops/ Screenshot: https://swipefile.design/_astro/000.C5O4DRRq.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning Language rows, an illustrated vocabulary card, and circular letter choices keep each activity focused on a small unit. Publisher previews: - Language list: https://swipefile.design/_astro/000.C5O4DRRq.webp - Vocabulary detail: https://swipefile.design/_astro/001.bZy3Kctf.webp - Word-building exercise: https://swipefile.design/_astro/002.Bh5G9_Mn.webp Useful for: Study language list, vocabulary detail, word-building exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Language list · Vocabulary detail · Word-building exercise - nav: Back and audio controls provide context around a word or exercise. - layout: Language rows, an illustrated vocabulary card, and circular letter choices keep each activity focused on a small unit. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Purple and blue surfaces with soft pink letter controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Drops Source: https://apps.apple.com/us/app/id939540371 Swipefile reference: https://swipefile.design/ref/mobile-drops/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Language list · Vocabulary detail · Word-building exercise - nav: Back and audio controls provide context around a word or exercise. - layout: Language rows, an illustrated vocabulary card, and circular letter choices keep each activity focused on a small unit. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Purple and blue surfaces with soft pink letter controls. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study language list, vocabulary detail, word-building exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 86. Brilliant Source website: https://apps.apple.com/us/app/id913335252 Swipefile reference: https://swipefile.design/ref/mobile-brilliant/ Screenshot: https://swipefile.design/_astro/000.BXck8K8P.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning Diagrams carry the mathematical explanation, with short conversational hints and a visible answer outcome. Publisher previews: - Visual algebra prompt: https://swipefile.design/_astro/000.BXck8K8P.webp - Geometry exercise feedback: https://swipefile.design/_astro/001.C9ZxnB_5.webp - Graph exercise success: https://swipefile.design/_astro/002.C4QY5UA8.webp Useful for: Study visual algebra prompt, geometry exercise feedback, graph exercise success. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Visual algebra prompt · Geometry exercise feedback · Graph exercise success - nav: The exercise stays central while feedback appears close to the diagram. - layout: Diagrams carry the mathematical explanation, with short conversational hints and a visible answer outcome. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, green feedback, and purple or orange diagram regions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Brilliant Source: https://apps.apple.com/us/app/id913335252 Swipefile reference: https://swipefile.design/ref/mobile-brilliant/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Visual algebra prompt · Geometry exercise feedback · Graph exercise success - nav: The exercise stays central while feedback appears close to the diagram. - layout: Diagrams carry the mathematical explanation, with short conversational hints and a visible answer outcome. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White space, green feedback, and purple or orange diagram regions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study visual algebra prompt, geometry exercise feedback, graph exercise success. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 87. Khan Academy Source website: https://apps.apple.com/us/app/id469863705 Swipefile reference: https://swipefile.design/ref/mobile-khan-academy/ Screenshot: https://swipefile.design/_astro/000.Df_4bSUp.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning A plain subject list leads into course mastery and a multiple-choice exercise with hint and check controls. Publisher previews: - Subject browsing: https://swipefile.design/_astro/000.Df_4bSUp.webp - Course progress: https://swipefile.design/_astro/001.Qx2eK436.webp - Practice question: https://swipefile.design/_astro/002.8KFkr-t4.webp Useful for: Study subject browsing, course progress, practice question. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Subject browsing · Course progress · Practice question - nav: Search and bottom destinations organize discovery; exercise controls remain at the lower edge. - layout: A plain subject list leads into course mastery and a multiple-choice exercise with hint and check controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content, navy headers, and blue or green progress accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Khan Academy Source: https://apps.apple.com/us/app/id469863705 Swipefile reference: https://swipefile.design/ref/mobile-khan-academy/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Subject browsing · Course progress · Practice question - nav: Search and bottom destinations organize discovery; exercise controls remain at the lower edge. - layout: A plain subject list leads into course mastery and a multiple-choice exercise with hint and check controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content, navy headers, and blue or green progress accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study subject browsing, course progress, practice question. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 88. Coursera Source website: https://apps.apple.com/us/app/id736535961 Swipefile reference: https://swipefile.design/ref/mobile-coursera/ Screenshot: https://swipefile.design/_astro/000.MbxW7ODu.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning A lesson pairs video with a transcript, while a career path groups courses into labeled learning stages. Publisher previews: - Lesson video and transcript: https://swipefile.design/_astro/000.MbxW7ODu.webp - Career learning path: https://swipefile.design/_astro/001.DnPM0oUd.webp Useful for: Study lesson video and transcript, career learning path. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Lesson video and transcript · Career learning path - nav: Lesson tabs separate overview, notes, and transcript; a back control returns from a path. - layout: A lesson pairs video with a transcript, while a career path groups courses into labeled learning stages. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with blue navigation and colored learning-path bands. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Coursera Source: https://apps.apple.com/us/app/id736535961 Swipefile reference: https://swipefile.design/ref/mobile-coursera/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Lesson video and transcript · Career learning path - nav: Lesson tabs separate overview, notes, and transcript; a back control returns from a path. - layout: A lesson pairs video with a transcript, while a career path groups courses into labeled learning stages. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces with blue navigation and colored learning-path bands. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study lesson video and transcript, career learning path. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 89. Quizlet Source website: https://apps.apple.com/us/app/id546473125 Swipefile reference: https://swipefile.design/ref/mobile-quizlet/ Screenshot: https://swipefile.design/_astro/000.Dl9HTy0U.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning A large flashcard, a compact concept guide, and numbered solution steps show different levels of learning detail. Publisher previews: - Flashcard feedback: https://swipefile.design/_astro/000.Dl9HTy0U.webp - Study guide: https://swipefile.design/_astro/001.D2XTsn27.webp - Worked solution: https://swipefile.design/_astro/002.ywY5SS9n.webp Useful for: Study flashcard feedback, study guide, worked solution. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Flashcard feedback · Study guide · Worked solution - nav: Progress and close controls frame cards, while a back control returns from a solution. - layout: A large flashcard, a compact concept guide, and numbered solution steps show different levels of learning detail. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White study surfaces with green feedback and blue-purple framing. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Quizlet Source: https://apps.apple.com/us/app/id546473125 Swipefile reference: https://swipefile.design/ref/mobile-quizlet/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Flashcard feedback · Study guide · Worked solution - nav: Progress and close controls frame cards, while a back control returns from a solution. - layout: A large flashcard, a compact concept guide, and numbered solution steps show different levels of learning detail. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White study surfaces with green feedback and blue-purple framing. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study flashcard feedback, study guide, worked solution. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 90. Elevate Source website: https://apps.apple.com/us/app/id875063456 Swipefile reference: https://swipefile.design/ref/mobile-elevate/ Screenshot: https://swipefile.design/_astro/000.B02vLLB7.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Learning Color-coded training rows lead into simple exercises with a small number of large choices. Publisher previews: - Training activity list: https://swipefile.design/_astro/000.B02vLLB7.webp - Vocabulary exercise: https://swipefile.design/_astro/001.CbEhcxIp.webp - Writing exercise: https://swipefile.design/_astro/002.CGhg55GH.webp Useful for: Study training activity list, vocabulary exercise, writing exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Training activity list · Vocabulary exercise · Writing exercise - nav: An activity overview and focused exercise surfaces separate choosing practice from completing it. - layout: Color-coded training rows lead into simple exercises with a small number of large choices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Bright blue and orange framing with colorful task tiles. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Elevate Source: https://apps.apple.com/us/app/id875063456 Swipefile reference: https://swipefile.design/ref/mobile-elevate/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Training activity list · Vocabulary exercise · Writing exercise - nav: An activity overview and focused exercise surfaces separate choosing practice from completing it. - layout: Color-coded training rows lead into simple exercises with a small number of large choices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Bright blue and orange framing with colorful task tiles. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Learning & feedback - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study training activity list, vocabulary exercise, writing exercise. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 91. Pinterest Source website: https://apps.apple.com/us/app/id429047995 Swipefile reference: https://swipefile.design/ref/mobile-pinterest/ Screenshot: https://swipefile.design/_astro/000.CwKnfopZ.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Labels over an image identify visual attributes, while related-image grids and filter chips narrow the next choice. Publisher previews: - Visual search details: https://swipefile.design/_astro/000.CwKnfopZ.webp - Similar product discovery: https://swipefile.design/_astro/001.4I01rjLM.webp - Filtered inspiration results: https://swipefile.design/_astro/002.B405vtEj.webp Useful for: Study visual search details, similar product discovery, filtered inspiration results. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Visual search details · Similar product discovery · Filtered inspiration results - nav: Search, close/back controls, and a lower related-results panel keep the original visual context available. - layout: Labels over an image identify visual attributes, while related-image grids and filter chips narrow the next choice. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White controls over photography with subtle pastel filter chips. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Pinterest Source: https://apps.apple.com/us/app/id429047995 Swipefile reference: https://swipefile.design/ref/mobile-pinterest/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Visual search details · Similar product discovery · Filtered inspiration results - nav: Search, close/back controls, and a lower related-results panel keep the original visual context available. - layout: Labels over an image identify visual attributes, while related-image grids and filter chips narrow the next choice. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White controls over photography with subtle pastel filter chips. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study visual search details, similar product discovery, filtered inspiration results. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 92. Etsy Source website: https://apps.apple.com/us/app/id477128284 Swipefile reference: https://swipefile.design/ref/mobile-etsy/ Screenshot: https://swipefile.design/_astro/000.CrvWCxJf.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Rounded product photos combine with search and themed gift cards to support browsing by recipient or interest. Publisher previews: - Personalized shopping home: https://swipefile.design/_astro/000.CrvWCxJf.webp - Gift discovery: https://swipefile.design/_astro/001.Cbjb6N9v.webp - Gift collection: https://swipefile.design/_astro/002.ZahBEWvL.webp Useful for: Study personalized shopping home, gift discovery, gift collection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Personalized shopping home · Gift discovery · Gift collection - nav: A prominent search field leads into gift topics and a specific collection. - layout: Rounded product photos combine with search and themed gift cards to support browsing by recipient or interest. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white content with orange branding and colorful gift tiles. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Etsy Source: https://apps.apple.com/us/app/id477128284 Swipefile reference: https://swipefile.design/ref/mobile-etsy/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Personalized shopping home · Gift discovery · Gift collection - nav: A prominent search field leads into gift topics and a specific collection. - layout: Rounded product photos combine with search and themed gift cards to support browsing by recipient or interest. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Warm white content with orange branding and colorful gift tiles. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Search & discovery - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study personalized shopping home, gift discovery, gift collection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 93. eBay Source website: https://apps.apple.com/us/app/id282614216 Swipefile reference: https://swipefile.design/ref/mobile-ebay/ Screenshot: https://swipefile.design/_astro/000.B1YhlF-Q.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food A live video surface, a focused photo prompt, and a two-column product grid expose distinct shopping and selling tasks. Publisher previews: - Live shopping: https://swipefile.design/_astro/000.B1YhlF-Q.webp - Photo-based listing prompt: https://swipefile.design/_astro/001.BMRIOtl_.webp - Product collection: https://swipefile.design/_astro/002.PV78_opu.webp Useful for: Study live shopping, photo-based listing prompt, product collection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Live shopping · Photo-based listing prompt · Product collection - nav: Close/back controls and item-level save buttons give the shown surfaces clear exits and actions. - layout: A live video surface, a focused photo prompt, and a two-column product grid expose distinct shopping and selling tasks. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White product grids, dark camera framing, and image-led content. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: eBay Source: https://apps.apple.com/us/app/id282614216 Swipefile reference: https://swipefile.design/ref/mobile-ebay/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Live shopping · Photo-based listing prompt · Product collection - nav: Close/back controls and item-level save buttons give the shown surfaces clear exits and actions. - layout: A live video surface, a focused photo prompt, and a two-column product grid expose distinct shopping and selling tasks. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White product grids, dark camera framing, and image-led content. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study live shopping, photo-based listing prompt, product collection. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 94. Amazon Shopping Source website: https://apps.apple.com/us/app/id297606951 Swipefile reference: https://swipefile.design/ref/mobile-amazon-shopping/ Screenshot: https://swipefile.design/_astro/000.TSUWEaHg.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Dense shopping modules sit below persistent search, with a product grid for comparison and a sheet explaining voice controls. Publisher previews: - Shopping home: https://swipefile.design/_astro/000.TSUWEaHg.webp - Product results: https://swipefile.design/_astro/001.B9bD1YbF.webp - Voice feature introduction: https://swipefile.design/_astro/002.ct4j2899.webp Useful for: Study shopping home, product results, voice feature introduction. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Shopping home · Product results · Voice feature introduction - nav: Top search and lower account/cart destinations remain separate from a temporary explanatory sheet. - layout: Dense shopping modules sit below persistent search, with a product grid for comparison and a sheet explaining voice controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, pale teal navigation, and blue actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Amazon Shopping Source: https://apps.apple.com/us/app/id297606951 Swipefile reference: https://swipefile.design/ref/mobile-amazon-shopping/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Shopping home · Product results · Voice feature introduction - nav: Top search and lower account/cart destinations remain separate from a temporary explanatory sheet. - layout: Dense shopping modules sit below persistent search, with a product grid for comparison and a sheet explaining voice controls. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, pale teal navigation, and blue actions. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study shopping home, product results, voice feature introduction. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 95. Nike Source website: https://apps.apple.com/us/app/id1095459556 Swipefile reference: https://swipefile.design/ref/mobile-nike/ Screenshot: https://swipefile.design/_astro/000.Dr3XxD8q.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Campaign artwork leads into category tiles and a restrained product grid with short names and prices. Publisher previews: - Campaign discovery: https://swipefile.design/_astro/000.Dr3XxD8q.webp - Shopping categories: https://swipefile.design/_astro/001.BYFYl0uu.webp - New product grid: https://swipefile.design/_astro/002.COV-oe3O.webp Useful for: Study campaign discovery, shopping categories, new product grid. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Campaign discovery · Shopping categories · New product grid - nav: Persistent bottom destinations and category filters give editorial browsing a conventional shopping structure. - layout: Campaign artwork leads into category tiles and a restrained product grid with short names and prices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black and white controls with vivid campaign and product imagery. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Nike Source: https://apps.apple.com/us/app/id1095459556 Swipefile reference: https://swipefile.design/ref/mobile-nike/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Campaign discovery · Shopping categories · New product grid - nav: Persistent bottom destinations and category filters give editorial browsing a conventional shopping structure. - layout: Campaign artwork leads into category tiles and a restrained product grid with short names and prices. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: Black and white controls with vivid campaign and product imagery. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study campaign discovery, shopping categories, new product grid. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 96. Sephora Source website: https://apps.apple.com/us/app/id393328150 Swipefile reference: https://swipefile.design/ref/mobile-sephora/ Screenshot: https://swipefile.design/_astro/000.BY4a_RXI.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Colored fulfillment rows precede product cards; a detail page places delivery choices above an Add to Basket action. Publisher previews: - Fulfillment choices: https://swipefile.design/_astro/000.BY4a_RXI.webp - Product discovery: https://swipefile.design/_astro/001.BhqXMidR.webp - Product and delivery options: https://swipefile.design/_astro/002.CGITwQ72.webp Useful for: Study fulfillment choices, product discovery, product and delivery options. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Fulfillment choices · Product discovery · Product and delivery options - nav: Top search and lower shopping destinations remain visible around the product content. - layout: Colored fulfillment rows precede product cards; a detail page places delivery choices above an Add to Basket action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, pastel service rows, and a red purchase action. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Sephora Source: https://apps.apple.com/us/app/id393328150 Swipefile reference: https://swipefile.design/ref/mobile-sephora/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Fulfillment choices · Product discovery · Product and delivery options - nav: Top search and lower shopping destinations remain visible around the product content. - layout: Colored fulfillment rows precede product cards; a detail page places delivery choices above an Add to Basket action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels, pastel service rows, and a red purchase action. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study fulfillment choices, product discovery, product and delivery options. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 97. Target Source website: https://apps.apple.com/us/app/id297430070 Swipefile reference: https://swipefile.design/ref/mobile-target/ Screenshot: https://swipefile.design/_astro/000.CCM-05sl.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Image-led offers, category shortcuts, and a member summary organize shopping at different levels of detail. Publisher previews: - Shopping home: https://swipefile.design/_astro/000.CCM-05sl.webp - Deals browsing: https://swipefile.design/_astro/001.DAQMu6Tv.webp - Membership overview: https://swipefile.design/_astro/002.CfgPd-kd.webp Useful for: Study shopping home, deals browsing, membership overview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Shopping home · Deals browsing · Membership overview - nav: Bottom destinations and deal categories provide consistent routes through the promotional content. - layout: Image-led offers, category shortcuts, and a member summary organize shopping at different levels of detail. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with red actions and colorful merchandise imagery. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Target Source: https://apps.apple.com/us/app/id297430070 Swipefile reference: https://swipefile.design/ref/mobile-target/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Shopping home · Deals browsing · Membership overview - nav: Bottom destinations and deal categories provide consistent routes through the promotional content. - layout: Image-led offers, category shortcuts, and a member summary organize shopping at different levels of detail. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White panels with red actions and colorful merchandise imagery. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study shopping home, deals browsing, membership overview. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 98. DoorDash Source website: https://apps.apple.com/us/app/id719972451 Swipefile reference: https://swipefile.design/ref/mobile-doordash/ Screenshot: https://swipefile.design/_astro/000.uQnDLoVu.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Store categories and promotional cards lead into a status panel that shows order progress above additional shopping options. Publisher previews: - Store discovery: https://swipefile.design/_astro/000.uQnDLoVu.webp - Order confirmation status: https://swipefile.design/_astro/001.C7vE4G_W.webp - Offer discovery: https://swipefile.design/_astro/002.DfVDnuTk.webp Useful for: Study store discovery, order confirmation status, offer discovery. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Store discovery · Order confirmation status · Offer discovery - nav: Search, category icons, and persistent lower destinations keep discovery accessible. - layout: Store categories and promotional cards lead into a status panel that shows order progress above additional shopping options. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, black text, and red brand accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: DoorDash Source: https://apps.apple.com/us/app/id719972451 Swipefile reference: https://swipefile.design/ref/mobile-doordash/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Store discovery · Order confirmation status · Offer discovery - nav: Search, category icons, and persistent lower destinations keep discovery accessible. - layout: Store categories and promotional cards lead into a status panel that shows order progress above additional shopping options. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White surfaces, black text, and red brand accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study store discovery, order confirmation status, offer discovery. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 99. Uber Eats Source website: https://apps.apple.com/us/app/id1058959277 Swipefile reference: https://swipefile.design/ref/mobile-uber-eats/ Screenshot: https://swipefile.design/_astro/000.dTQg1xHv.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Category chips and offer cards lead into a grouped cart with editable items, a savings summary, and a clear checkout action. Publisher previews: - Store discovery: https://swipefile.design/_astro/000.dTQg1xHv.webp - Restaurant offers: https://swipefile.design/_astro/001.CXWG2nHM.webp - Bundled cart: https://swipefile.design/_astro/002.R3UfXEEV.webp Useful for: Study store discovery, restaurant offers, bundled cart. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Store discovery · Restaurant offers · Bundled cart - nav: Search and bottom destinations support browsing; the cart has a separate close control and primary action. - layout: Category chips and offer cards lead into a grouped cart with editable items, a savings summary, and a clear checkout action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content, black actions, and green offer accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Uber Eats Source: https://apps.apple.com/us/app/id1058959277 Swipefile reference: https://swipefile.design/ref/mobile-uber-eats/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Store discovery · Restaurant offers · Bundled cart - nav: Search and bottom destinations support browsing; the cart has a separate close control and primary action. - layout: Category chips and offer cards lead into a grouped cart with editable items, a savings summary, and a clear checkout action. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White content, black actions, and green offer accents. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Shopping & checkout - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study store discovery, restaurant offers, bundled cart. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ ## 100. Too Good To Go Source website: https://apps.apple.com/us/app/id1060683933 Swipefile reference: https://swipefile.design/ref/mobile-too-good-to-go/ Screenshot: https://swipefile.design/_astro/000.BdurUIF8.webp Captured: 2026-09-09 | Scope: store-preview | Type: app | Style: Shopping & food Nearby cards show pickup information; a detail surface adds ratings and a Reserve action, followed by a clear thank-you state. Publisher previews: - Nearby food offers: https://swipefile.design/_astro/000.BdurUIF8.webp - Offer detail and reservation: https://swipefile.design/_astro/001.B28hHYs2.webp - Collection confirmation: https://swipefile.design/_astro/002.B4UGmKGR.webp Useful for: Study nearby food offers, offer detail and reservation, collection confirmation. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. - surface: Nearby food offers · Offer detail and reservation · Collection confirmation - nav: Bottom discovery destinations give way to a focused reservation and confirmation surface. - layout: Nearby cards show pickup information; a detail surface adds ratings and a Reserve action, followed by a clear thank-you state. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White cards with deep teal actions and warm food photography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. ### Design adaptation prompt ~~~text # Design reference: Too Good To Go Source: https://apps.apple.com/us/app/id1060683933 Swipefile reference: https://swipefile.design/ref/mobile-too-good-to-go/ Captured: 2026-09-09. This is a dated reference, not a claim about the current live product. Source scope: publisher-provided App Store previews. Promotional framing is retained. These are static examples, not a tested or recorded user flow. Do not infer unseen interactions. ## Objective Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets. ## Reference notes - surface: Nearby food offers · Offer detail and reservation · Collection confirmation - nav: Bottom discovery destinations give way to a focused reservation and confirmation surface. - layout: Nearby cards show pickup information; a detail surface adds ratings and a Reserve action, followed by a clear thank-you state. - density: Compare the space reserved for the primary task with secondary metadata. The previews retain promotional framing; evaluate target sizes in your implemented screen. - color: White cards with deep teal actions and warm food photography. - typography: Use clear heading, body, and metadata levels. Keep interface text scalable and verify readability with the device text-size settings. - pattern: Status & progress - states: Static publisher previews only. Loading, empty, error, offline, permission, and keyboard behavior have not been tested. Specify and verify those states in your own implementation. - dont: Do not copy the app identity, proprietary artwork, or promotional claims. Screenshot order is not a verified flow, and the listing version does not date every image. Useful for: Study nearby food offers, offer detail and reservation, collection confirmation. Compare the hierarchy and controls shown in these publisher previews, then test the corresponding behavior in your own app. ## Acceptance criteria - Existing project conventions, design tokens, working functionality, and unrelated changes are preserved. - Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product. - Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap. - Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled. - Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported. - Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service. ## Quality bar Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence. ~~~ View board: https://swipefile.design/board/mobile-app-ui/ Swipefile: https://swipefile.design/