> ## Documentation Index
> Fetch the complete documentation index at: https://setup.despia.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Non-Mobile Design
> Your app was rejected because it looks like a website instead of a native mobile app. Here's how to fix it.
## What is non-mobile design?
**App stores expect apps to look and feel like apps**
Reviewers can instantly tell when an app is just a website wrapped in a native container. The layout, navigation patterns, and interaction design all signal "website" instead of "app."
Common rejection messages:
* "Your app appears to be a repackaged website"
* "The app does not provide a native user experience"
* "This would be better suited as a mobile website"
This rejection is about visual and interaction design, not functionality.
***
## Why this happens
**Web layouts don't translate to mobile apps**
Desktop and responsive web design patterns look wrong on mobile apps. Reviewers see these patterns and immediately flag the submission.
Common mistakes:
* Sidebars or slide-out drawer menus
* Top navigation bars with multiple links
* Hamburger menus in the header
* Desktop-style footers with link columns
* Scrolling headers that hide on scroll
* Browser-specific elements like cookie banners
These work fine on websites. They fail App Store review.
***
## How to fix it
### Understand the mobile app layout pattern
**Native apps follow a consistent structure**
Every successful mobile app uses the same basic layout. Reviewers expect to see this pattern.
**What reviewers expect:**
* Fixed (but CSS realtive) top bar showing current page title (optional back button)
* Scrollable content area in the middle
* Fixed (but CSS realtive) bottom navigation bar with icons for main sections
* No sidebars
* No hamburger menus
* No desktop-style navigation
***
### Foundation architecture
**Applications require a root frame element that establishes viewport boundaries**
```html theme={null}
```
**CSS implementation:**
```css theme={null}
/* Root frame - establishes viewport boundaries */
.app-root {
position: fixed;
top: 0;
left: 0;
right: 0;
bottom: 0;
display: flex;
flex-direction: column;
overflow: hidden;
}
/* Safe area frames - handle device boundaries */
.safe-area-top {
flex-shrink: 0;
height: var(--safe-area-top, env(safe-area-inset-top, 0));
}
.safe-area-bottom {
flex-shrink: 0;
height: var(--safe-area-bottom, env(safe-area-inset-bottom, 0));
}
/* Header frame - fixed positioning */
.app-header {
flex-shrink: 0;
display: flex;
align-items: center;
height: 56px;
padding: 0 1rem;
border-bottom: 1px solid #e5e7eb;
}
/* Content frame - scrollable container */
.app-content {
flex: 1;
overflow-y: auto;
overflow-x: hidden;
-webkit-overflow-scrolling: touch;
overscroll-behavior: contain;
/* Hide scrollbar for native appearance */
scrollbar-width: none;
-ms-overflow-style: none;
}
.app-content::-webkit-scrollbar {
display: none;
}
/* Footer frame - fixed positioning */
.app-footer {
flex-shrink: 0;
border-top: 1px solid #e5e7eb;
}
```
**Key requirements:**
* Use `position: fixed` for root frame (do not use `height: 100vh`)
* Include dedicated safe area spacer elements
* Header and footer use `flex-shrink: 0` (non-scrolling)
* Content area uses `flex: 1` and `overflow-y: auto` (scrollable)
* Apply `scrollbar-width: none` for native appearance
See: [Safe Areas](https://setup.despia.com/lovable/native-features/safe-areas)
***
### Device boundaries
**Safe area variables**
The Despia runtime automatically injects CSS variables for device-specific boundary insets (notches, status bars, home indicators).
```css theme={null}
.element {
padding-top: var(--safe-area-top);
padding-bottom: var(--safe-area-bottom);
}
```
**PWA fallback implementation**
When deployed as a PWA, Despia-specific variables are unavailable. Implement fallback values using standard environment variables.
```css theme={null}
.element {
/* Despia variable → standard env() → default value */
padding-top: var(--safe-area-top, env(safe-area-inset-top, 0));
padding-bottom: var(--safe-area-bottom, env(safe-area-inset-bottom, 0));
}
```
***
### Header design
**Keep it simple and consistent**
Mobile app headers are minimal. They show the current page and maybe a back button.
```html theme={null}
```
```css theme={null}
.app-header {
display: flex;
align-items: center;
height: 56px;
padding: 0 8px;
}
.back-button {
width: 44px;
height: 44px;
display: flex;
align-items: center;
justify-content: center;
background: none;
border: none;
color: #2563eb;
}
.page-title {
flex: 1;
font-size: 17px;
font-weight: 600;
text-align: center;
}
.header-spacer {
width: 44px;
}
```
**What to avoid in headers:**
* Multiple navigation links
* Dropdown menus
* Search bars that span the full width
* Logo images
* Hamburger menu icons
***
### Bottom navigation
**This is the primary navigation pattern for mobile apps**
Bottom navigation is the standard. Users expect it. Reviewers expect it.
```html theme={null}
```
```css theme={null}
.bottom-nav {
display: flex;
justify-content: space-around;
align-items: center;
height: 56px;
background: #ffffff;
}
.nav-item {
display: flex;
flex-direction: column;
align-items: center;
justify-content: center;
gap: 4px;
min-width: 64px;
padding: 8px 0;
color: #6b7280;
background: none;
border: none;
cursor: pointer;
}
.nav-item.active {
color: #2563eb;
}
.nav-item span {
font-size: 10px;
font-weight: 500;
}
```
**Bottom navigation guidelines:**
* Keep to 3-5 items maximum
* Highlight current tab with color or fill change
* Labels are optional but improve usability
* Use consistent icon style (all outline or all filled)
* Icons should be 24x24px
* Tap targets should be at least 44x44px
***
### What to remove
**These elements signal "website" to reviewers**
Delete or replace these patterns:
**Sidebars**
Sidebars don't exist in native mobile apps. Move navigation to the bottom bar or into separate screens.
**Hamburger menus**
The three-line menu icon is a web pattern. Replace with bottom navigation for primary actions. Use a settings screen for secondary options.
**Top navigation bars with links**
Website-style navigation like "Home | About | Contact | Login" doesn't belong. Use bottom navigation instead.
**Desktop footers**
Multi-column footers with links, social icons, and legal text are for websites. Remove entirely or move essential links to a settings screen.
**Cookie banners**
These are web-specific. Remove them from the native app using user agent detection.
**Browser chrome elements**
Address bars, back/forward buttons, refresh icons. These should never appear in your app.
***
### Common layout mistakes
**Side-by-side comparison**
| Website pattern | Mobile app pattern |
| :---------------- | :----------------- |
| Hamburger menu | Bottom navigation |
| Top nav links | Tab bar at bottom |
| Sidebar drawer | Separate screens |
| Desktop footer | Settings screen |
| Scrolling header | Fixed header |
| Full-width search | Search icon in nav |
***
### Testing your layout
**Before submitting, verify these points:**
1. Is the header fixed at the top?
2. Is the navigation at the bottom?
3. Does only the content area scroll?
4. Are safe areas handled for notches?
5. Is the scrollbar hidden?
6. Are there any sidebars visible?
7. Are there any hamburger menus?
8. Does the layout feel like Instagram, Twitter, or other native apps?
***
## Quick checklist
**Layout structure:**
1. Root frame uses `position: fixed`
2. Viewport meta tag includes `viewport-fit=cover`
3. Safe area spacers are present
4. Header is fixed with `flex-shrink: 0`
5. Content area uses `flex: 1` and `overflow-y: auto`
6. Footer is fixed with `flex-shrink: 0`
**Navigation:**
7. Bottom navigation with 3-5 items
8. No sidebars
9. No hamburger menus
10. No top navigation links
**Polish:**
11. Scrollbar is hidden
12. Icons are consistent (outline or filled)
13. Active state is visible on current tab
14. Tap targets are at least 44x44px
***
## Still stuck?
If you keep getting rejected for design issues:
1. Open Instagram, Twitter, or Spotify on your phone. Compare their layout to yours.
2. Screenshot your app and ask: "Does this look like a website or an app?"
3. Contact support: [support@despia.com](mailto:support@despia.com) with:
* Screenshots of your current layout
* Your rejection notice
* Description of navigation patterns you're using