Create and deploy an iOS app landing page on GitHub Pages in only five minutes.
Designed for GitHub Pages for super easy set up.
🔧 Fork this repo
🗝 Enter iOS App ID in _config.yml
📲 Upload video preview or screenshot
🎨 Customise site in _config.yml (no HTML/CSS)
📝 Write Privacy Policy as markdown in privacypolicy.md
🕒 Keep a changelog in CHANGELOG.md
✅ Site becomes live at GitHub Pages repository URL, e.g. https://your-username.github.io/your-repo-name/.
After forking the repo, your site will be live immediately on your personal Github Pages account, e.g. https://yourusername.github.io/your-repo-name/.
Make sure GitHub Pages is enabled for your repo. It might take some time for the site to propagate entirely.
Enter your iOS app ID in the ios_app_id field and commit your changes. Your site will automatically rebuild with your app icon, name, price and link to App Store.
You can go on with customising almost anything in the _config.yml file.
Things you can customise in _config.yml:
- App Name
- App Icon
- App Description
- App Price
- App Store Link
- Play Store Link
- Press Kit Download Link
- Cover Image
- Cover Overlay Color
- Background Color
- Text Colors
- iPhone Device Color
- Your Name / Company Name
- Link to Website
- Social Links and Contact Info
- Feature List (Title, text, icon)
Upload a .png or .jpg of your app to the folder assets/screenshot/. The name does not matter. Be sure to delete the placeholder yourscreenshot.png.
Upload your video to the folder assets/videos/. To have support for most browsers, you need to upload two files – one for Safari and one for Chrome/Firefox.
Video formats supported by Chrome and Firefox:
.webm.ogg
Video formats supported by Safari:
.mp4.mov
The videos and screenshots must have one of the following resolutions:
- 828x1792
- 1125x2436
- 1242x2688
Your site automatically includes pages for a Privacy Policy and a Changelog. Change the content of these pages by editing the privacypolicy.md and CHANGELOG.md files in the _pages directory.
In each of the markdown files, you can set the include_in_header: value to either true or false. This determines if the page is included in the top navigation.
By default, only the Changelog is included in the top navigation. The title of the navigation item can also be edited, by editing the title: in each markdown file.
If you need to, you can create additional markdown based pages just by creating an .md file like the privacypolicy.md and CHANGELOG.md files in the _pages directory.
Please note: The Privacy Policy and Changelog provided are written using dummy text, so please adapt each of them for your own app.
You can also choose not to include these pages, by simple deleting the privacypolicy.md and CHANGELOG.md files.
If you have feedback regarding bugs or improvements, open an issue, @ me on Twitter or write me an email. You can find my contact info on my website.
I'd love to see the sites you create using this little tool.
Each entry in _data/locales.yml defines the app's localized app_name, sourced from CFBundleDisplayName in the native app's Countdown/Supporting Files/InfoPlist.xcstrings catalog. These are the app's display names, not translations invented for the website or the longer App Store marketing titles. English and German retain Countdowns; Dutch uses Aftellingen; Hindi uses काउंटडाउन; the other languages use their native app names.
Shared branding and metadata use this name, falling back to _config.yml's app_name for an unknown locale. Keep app references in _data/strings.yml, _data/screenshot_alts.yml, and the validator's native-name baseline in sync when a name changes; complete translated sentences preserve the grammar around each name.
After building, check branding, copy, accessibility text, and metadata across every home, ideas, guide, and Support page:
bundle exec ruby scripts/validate-app-names.rb --site _siteWhen the native repository is available, also pass --native-catalog "/path/to/Countdowns/Countdown/Supporting Files/InfoPlist.xcstrings" to verify the names directly against the app's catalog.
support.md is the English Help Center source. It uses the directory URL /support/, allowing requests to /support to redirect to it. Translations live at <locale folder>/support/index.md and also use directory URLs. Keep the section IDs and order, troubleshooting steps, external-link destinations (using their localized equivalents), and source_version aligned with English when updating translations. Keep native app names intact, adapting the surrounding grammar as needed. Policies remain English-only and opt out of localization with localized: false.
The shared _includes/locale-url.html helper keeps language switching, alternate links, the footer's Help Center link, and sitemap routes consistent. Shared accessibility text and the menu label are translated in _data/strings.yml.
The header keeps the app name visible. At widths of 1120px or less, all navigation moves into a single disclosure menu; its nested language list stays within the scrollable panel. Desktop and compact navigation share _includes/navigation-items.html. The native disclosures work without JavaScript; assets/header.js adds outside-click dismissal, Escape/focus handling, and breakpoint cleanup. Keep its media query in sync with _sass/layout.scss.
After building, validate all 345 localized routes, Support content structure, language links, accessibility labels, internal links, and the sitemap:
bundle exec ruby scripts/validate-localization.rb --site _site
node scripts/validate-header.jsFor a build using a subdirectory, pass the same --baseurl /prefix to the localization validator. Browser checks should also cover narrow screens, long localized names, Devanagari line height, Arabic right-to-left layout, and keyboard navigation.
The 2026-09-07 offline audit covered all 346 generated HTML pages, including the English policies page: 22,065 internal anchors and 2,836 external anchors (116 unique destinations, including email). All internal page and fragment links resolved. Apple Support's 86 unique target URLs include the 85 destinations checked with real GET requests, redirects, and rendered language metadata on 2026-08-31 plus the separately verified Hindi Mac guide.
Support links use _includes/apple-support-url.html and _data/external_links.yml. Keep the article keys shared across translations; the include selects Apple's supported language/region code. This preserves European/Brazilian Portuguese and Simplified/Traditional Chinese and maps Norwegian Bokmål to Apple's no-no routes. Unknown locales fall back to English.
Catalan is a per-article exception: Apple's Mac widgets guide is available in Catalan, but the three standalone articles do not advertise Catalan versions. Those links use English and are labeled “en anglès” with hreflang="en". Hindi follows the same pattern: the Mac widgets guide is available in Hindi, while the three standalone articles currently render English; those links are labeled “अंग्रेज़ी में” with hreflang="en".
| Other destination | Audit result and language handling |
|---|---|
| App Store | Navigation and badges use the country-neutral link with an explicit language hint. Apple still chooses the country/storefront; it may fall back to a supported language or regional variant. See Apple's locale table. Country-specific URLs can improve language matching but also change displayed currency and reviews, so they are not inferred from the site's language. |
| Shayes Apps | English-only site; no localized equivalents were found. Use the canonical shared URL. |
| Facebook and Instagram | Use the verified www profile URLs. No profile-specific language override was verified; retain the provider's own language/account preferences. Public profile text could not be inspected by the automated fetch. |
| Mastodon | Keep the shared profile URL; the provider handles UI language. The public response was a JavaScript application shell, not translated profile content. |
| RevenueCat privacy | English-only destination from the English policies page; unchanged. |
| Google AdMob privacy information | Google supports localized hl values; the only link is on the English policies page, so hl=en is correct. |
mailto:support@shayesapps.com is language-neutral and unchanged. |
The social, developer, RevenueCat, and Google destinations returned HTTP 200 during the audit. HTTP success alone does not prove that social-profile content is translated. App Store JSON-LD sameAs and schema.org are identifiers, not navigation links.
_includes/app-store-url.html applies the audited hints in external_links.yml to the standard country-neutral appstore_link for ios_app_id. Explicit configuration overrides (including campaign, fragment, country-specific, or custom URLs) are preserved unchanged. Unknown locales fall back to the English hint. Use the exact zh-Hant-TW hint for Traditional Chinese and nb-NO for Norwegian Bokmål: the shorter zh-Hant and no forms did not select the intended languages in the audit. These remain best-effort hints, not promises about the visitor's final storefront language.
The original 22 emitted App Store URLs were checked in the 2026-08-31 sweep. Hindi adds ?l=hi, which returned a valid App Store page on 2026-09-07; Apple currently renders that listing in English until Hindi metadata is available. The earlier sweep returned 19 HTTP 200 responses and three temporary Apple rate-limit responses (it, pt, pt-BR), after those exact URLs had already returned valid pages. No 404 or server-error response was observed.
After building, run the offline external-link regression checks along with the localization validator:
bundle exec ruby scripts/validate-external-links.rb --site _site
bundle exec ruby scripts/validate-localization.rb --site _siteNew external destinations must be audited before being added to the validator's known shared exceptions. Recheck provider language support when changing an article or adding a site locale.
Pages use the shared _includes/app-store-badge.html include to select official Apple artwork from _data/app_store_badges.yml. SVGs are stored locally in assets/app-store-badges/, with English as the fallback for an unknown locale. Badge labels use the existing download_badge translations.
Keep Apple's SVG artwork unmodified and follow the App Store badge guidelines. The artwork download endpoint is recorded in the badge map; note that Arabic uses ar-ar, Norwegian Bokmål uses no-no, and Portuguese and Chinese each have separate regional/script variants. Apple's legacy hi-in API endpoint currently returns English artwork, so Hindi uses the untouched black SVG from Apple's current Download Artwork (All Versions) archive instead. These artwork codes are separate from the App Store link hints above.
After building the site, validate the artwork, locale fallback, accessible labels, and every home/ideas/guide page with:
bundle exec ruby scripts/validate-app-store-badges.rb --site _siteFor a build using a subdirectory, pass the same --baseurl /prefix to the validator.