# Automatic App Landing Page: a Jekyll theme that builds your iOS landing page from an App ID > Fork the repository, put an iOS App ID in _config.yml, and GitHub Pages serves a landing page with the app icon, price and App Store link. It is a static Jekyll site with no build pipeline to maintain, and no way to work with anything other than a public App Store listing. **emilbaehr/automatic-app-landing-page** — A Jekyll theme for automatically generating and deploying landing page sites for mobile apps. - Repository: https://github.com/emilbaehr/automatic-app-landing-page - Website: https://emilbaehr.github.io/automatic-app-landing-page/ - Stars: 3,629 · Forks: 1,788 - Language: SCSS - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/emilbaehr-automatic-app-landing-page ## The problem: a landing page you would otherwise hand-build for every app Most iOS developers need one page per app: an icon, a name, a price, an App Store button, a screenshot or a video, a privacy policy, a changelog. Building that by hand means writing HTML and CSS, then rebuilding it every time the price changes or a new screenshot ships. Automatic App Landing Page removes the HTML and CSS step entirely. The README describes the workflow as forking the repo, entering the iOS App ID in _config.yml, uploading a video preview or screenshot, and customising the site in _config.yml. The stated target is GitHub Pages, and the README's own framing is that the site becomes live at the repository URL, for example https://your-username.github.io/your-repo-name/. The audience is narrow on purpose. The theme is built around an iOS App Store listing, so it fits an indie developer or a small studio that ships iOS apps and wants a page per app without maintaining a site generator. It is a poor fit for anyone who needs a marketing site with a blog, analytics, forms or a CMS, because none of that is in the repository layout. ## How the App ID becomes an icon, a price and an App Store link The mechanism is Jekyll plus one configuration value. You enter your iOS app ID in the ios_app_id field in _config.yml and commit; according to the README, the site then rebuilds automatically with your app icon, name, price and a link to the App Store. That single field is what separates this theme from a generic Jekyll template: the app metadata is not something you type in, it is looked up from the store listing. Everything else is configuration. The README lists what can be customised 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 colour, background colour, text colours, iPhone device colour, your name or company name, a link to your website, social links and contact info, and a feature list with title, text and icon. Note that the Play Store link is a configured field rather than a lookup, so the Android side is a manual link, not generated metadata. The repository layout matches that story: _config.yml at the root, index.html, main.scss, and the directories _includes/, _layouts/, _pages/, _sass/ and assets/. Pages live in _pages/ as markdown, and the theme ships two of them, privacypolicy.md and CHANGELOG.md. Each markdown file carries front matter keys: include_in_header and include_in_footer, both booleans, plus a title. The README states that by default only the Changelog is included in the top navigation, and that pages are included in the footer by default. ## Forking it and getting a first page live There is no package to install. The README's quick start is a fork, a config edit and a commit. After forking, the README says your site will be live immediately on your personal GitHub Pages account, and it warns to make sure GitHub Pages is enabled for the repo and that propagation can take some time. The only required edit is the app ID. Open _config.yml and set the ios_app_id field to your own iOS app ID, then commit. The README states the site rebuilds automatically with your app icon, name, price and App Store link. If the page still shows placeholder content, the first thing to check is that GitHub Pages is enabled for your fork, since the README calls that out explicitly. Next, add media. For a screenshot, upload a .png or .jpg into assets/screenshot/; the README says the file name does not matter, but you must delete the placeholder yourscreenshot.png. For video, upload into assets/videos/, and because of browser format support you need two files, one for Safari and one for Chrome and Firefox. Chrome and Firefox take .webm or .ogg; Safari takes .mp4 or .mov. The README gives three accepted resolutions: 828x1792, 1125x2436 and 1242x2688. Finally, the two shipped pages. Edit _pages/privacypolicy.md and _pages/CHANGELOG.md. The README notes that the Privacy Policy and Changelog are written using dummy text and must be adapted, and that you can drop the pages entirely by deleting the two files. You can also add new markdown pages by creating .md files in _pages/ the same way, and the README states that include_in_header and include_in_footer in each markdown file control whether a page appears in the top navigation and the footer links. ## Where this theme stops working The App ID lookup is the theme's whole value, and it is also its boundary. If your app is not on the public App Store, there is no listing to read, so the automatic icon, name, price and link do not appear and you are left filling in the fields by hand. An unreleased app, a TestFlight build, an enterprise-distributed app or an Android-only app all fall outside the model. The README's Play Store link is a field you set yourself, which confirms the Android path is manual. Media handling is another constraint. The README requires video in two formats because of browser support, so a single .mp4 upload is not enough for Chrome and Firefox. Screenshots and video must match one of the three listed resolutions, which rules out a screenshot taken on a device or simulator that does not produce those sizes. The README does not document any scaling or cropping step, so an off-size image is a problem you resolve before uploading, not after. There is no documented rollback or preview story. The README does not describe a local build command, a staging branch or a way to preview changes before they go live, so the commit is the deploy. That is fine for a small landing page and uncomfortable if you are editing a live page with traffic. ## How it compares with a general-purpose Jekyll landing theme A generic Jekyll landing page theme, or a hand-written Jekyll site, gives you the same static output and the same GitHub Pages deployment. The difference is where the data comes from. With a general theme you write the app name, price, icon path and store URL into the config or the page yourself, and you update them when they change. Automatic App Landing Page reads those from the App Store listing via ios_app_id, so the price and the icon follow the listing rather than your memory. The trade is flexibility. A general Jekyll theme can be shaped into any layout, and it does not care what you are selling. This one ships a fixed structure aimed at a single app: a cover image, an iPhone device colour, a feature list, and the two markdown pages. If your page needs a different information architecture, you are editing _layouts/, _includes/ and _sass/ anyway, at which point the automatic part is the only thing you kept. Against a hosted landing page builder, the difference is the dependency. This is a static Jekyll site in your own repository under the MIT License, with GitHub Pages doing the serving. Nothing here requires an account with a third-party builder, and nothing here stops working because a vendor changed a plan. ## Maintenance, licence and the cost of staying current The repository was last pushed on 2026-09-05 and is not archived, so it is current enough that a fork will not look abandoned. That is not the same as a maintenance promise. The README's feedback section points to opening an issue, messaging the author on Twitter or sending an email, and there are no retrieved releases, so there is no versioned upgrade path to follow. In practice your fork diverges the moment you edit _config.yml, and pulling upstream changes later means reconciling your customisations against the theme. The dependency surface is small, which keeps the upgrade cost low: Jekyll, FontAwesome, GitHub Pages, and the App Store listing itself. The risk sits in the last one. If the App Store lookup stops returning what the theme expects, the page degrades to whatever fallback exists, and the README does not describe that fallback. The MIT License is permissive and the theme is a starting point you copy into your own repository, but the licence covers the theme code, not the app icon, screenshots or video you upload, and not the dummy Privacy Policy text, which the README tells you to replace with your own. Whether that replacement satisfies App Store requirements is a question for your own review, not something the theme answers. ## Conclusion Fork it if you ship an iOS app on the public App Store and want a landing page you never have to build. Do not fork it if your app is Android-only, unreleased, or distributed outside the App Store, because the theme's central feature is reading a public App Store listing by ID. Before you commit, check the three screenshot resolutions the README lists, confirm GitHub Pages is enabled on your fork, and replace the dummy text in _pages/privacypolicy.md and _pages/CHANGELOG.md. ## FAQ ### What is a mobile app landing page in Automatic App Landing Page? It is a static Jekyll site generated from the repository and served on GitHub Pages, showing the app icon, name, price and an App Store link pulled from the iOS App ID you set in _config.yml. It also carries a screenshot or video, a Privacy Policy page and a Changelog page. ### How do I install Automatic App Landing Page? There is no install step. The README's quick start is to fork the repository, make sure GitHub Pages is enabled, and edit _config.yml, after which the site is live at your GitHub Pages repository URL. ### Which screenshot and video resolutions does Automatic App Landing Page accept? The README lists 828x1792, 1125x2436 and 1242x2688 for both screenshots and videos. Video needs two files for browser support: .webm or .ogg for Chrome and Firefox, and .mp4 or .mov for Safari. ### Can I use Automatic App Landing Page for an Android app? Only partly. The automatic lookup is driven by the iOS App ID, and the README's Play Store link is a field you fill in yourself in _config.yml, so the Android side is a manual link rather than generated metadata. ### Do I need to write HTML or CSS to customise Automatic App Landing Page? The README states you customise the site in _config.yml with no HTML or CSS, covering the app name, icon, description, price, store links, cover image, colours, social links and feature list. The Privacy Policy and Changelog are edited as markdown files in _pages/. ## Sources - [emilbaehr/automatic-app-landing-page on GitHub](https://github.com/emilbaehr/automatic-app-landing-page) - [Issues](https://github.com/emilbaehr/automatic-app-landing-page/issues) - [License: MIT](https://github.com/emilbaehr/automatic-app-landing-page/blob/master/LICENSE) - [Project website](https://emilbaehr.github.io/automatic-app-landing-page/) - [README](https://github.com/emilbaehr/automatic-app-landing-page/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/emilbaehr-automatic-app-landing-page