Developer Checkpoints for App and Web Projects

Polished apps are not built in one feature sprint — they are built from hundreds of small, repeatable decisions. This guide is a developer checkpoint list for app and web projects: the things easy to skip under deadline pressure but painful to fix after release.

Use it as a pre-release walkthrough with your team. Tick each section before you cut a build for QA, beta, or production. For layout and measurement specifics, pair this with our App Screen Design guide.

Quick reference

Area	What to verify
App properties	Name, package/bundle ID, icons, splash, naming conventions
Page properties	Typography, colours, spacing, dialogs, backgrounds
Component properties	Alignment, validation, images, text scaling
Dependencies	Permissions, libraries, Firebase, analytics
Build & deploy	APIs, database, testing, versioning, Git

---

App-level properties

These settings define your app identity in stores, on devices, and in your codebase.

App name

• Choose a name that reflects the product’s main purpose — not an internal codename.
• Search the Play Store and App Store to avoid collisions with existing apps.
• Keep store listing title and in-app branding aligned.

Package / bundle identifier

• Use reverse-domain notation: com.yourcompany.appname (Android) or com.yourcompany.appname (iOS bundle ID).
• Never change the package name after release without a migration plan — it is treated as a different app on both stores.
• Match naming across modules, Firebase projects, and push notification configs.

Splash screen

• Keep splash text short and on-brand; avoid long marketing copy.
• Use a logo or illustration sized for multiple densities (mdpi through xxxhdpi on Android; @2x/@3x on iOS).
• On Android 12+, follow SplashScreen API guidelines instead of a legacy full-screen activity where possible.

App icons

• Design a recognizable icon that reads at small sizes (home screen, notifications, settings).
• Export all required sizes — Play Console and App Store Connect list exact dimensions.
• Follow Material Design icon guidelines (Android) and Apple app icon HIG (iOS).

Naming standards for code identifiers

Element	Convention (Kotlin / Java)	Example
Classes / composables	PascalCase	LoginViewModel, ProfileScreen
Functions / variables	camelCase	fetchUserProfile(), isLoading
Constants	UPPER_SNAKE_CASE	MAX_RETRY_COUNT
Layout / resource files	snake_case	activity_main.xml, ic_back_arrow
String resources	Descriptive keys	login_error_invalid_email

Consistent naming makes code review faster and reduces merge conflicts. Align with your MVVM or Clean Architecture layers so ViewModels, repositories, and UI names tell the same story.

---

Page and screen properties

Every screen should feel like part of one product — not a collection of one-off layouts.

Typography and headings

• Pick one heading style (size, weight, padding) and reuse it on every screen.
• Decide on title casing up front: Title Case or Sentence case — do not mix both in navigation and dialogs.
• Use platform-relative units: sp on Android, Dynamic Type on iOS, rem on web.

Colours and actions

• Define a primary colour (app bar, main CTAs) and secondary accent for less prominent actions.
• Use the same action colour and icon set for equivalent operations (save, delete, back) everywhere.
• Document colours in a shared theme file — Material 3 ColorScheme, Compose MaterialTheme, or CSS variables for web.

Layout spacing

• Set standard margins and padding (e.g. 16 dp horizontal screen inset, 8 dp between stacked fields).
• Keep button heights and corner radii consistent — see measurement tables in App Screen Design.
• Avoid different background colours per screen unless the design system explicitly calls for it.

Dialogs and alerts

• Use the same heading style for alerts, bottom sheets, and confirmation dialogs.
• Write short, actionable messages: what happened + what the user can do.
• Destructive actions (delete account, remove data) require explicit confirmation copy — not a generic “Are you sure?”

Checklist before shipping a new screen

• Heading style matches existing screens
• Primary and secondary colours from theme — no hard-coded hex in layouts
• Margins and padding match the design grid
• Dialog copy reviewed for clarity and tone
• Tested on at least one small phone and one large phone / tablet

---

Component properties

Components are where inconsistency shows up first — misaligned fields, mixed validation styles, blurry images.

Alignment and spacing

• Align labels, inputs, and buttons to the same vertical or horizontal grid.
• Maintain minimum 48 dp touch targets on Android (Material touch targets).
• Leave enough space between tappable elements to prevent mis-taps.

Colours and parent containers

• Buttons, text fields, and chips should pull colours from the theme — not local overrides per screen.
• Nested components should respect parent padding; avoid double margins from both parent and child.

Names, strings, and validation

• Externalise all user-visible text in strings.xml (Android), Localizable.strings (iOS), or i18n files (web).
• Use descriptive string keys — error_network_timeout, not string_42.
• Apply the same validation rules and error message pattern on every form (inline under field vs. snackbar — pick one).

Images and text scaling

• Provide density-specific drawables or vector assets; avoid upscaling small PNGs.
• Use sp / Dynamic Type for body text so accessibility font scaling works.
• Test layouts at largest accessibility text size — especially login, checkout, and settings flows.

---

Dependencies and integrations

Third-party SDKs and permissions are a common source of store rejection and security review failures.

Permissions

• Request only permissions required for core functionality.
• Remove unused permissions from AndroidManifest.xml and iOS Info.plist — leftover entries trigger privacy audits.
• Show a rationale before the system permission dialog when the reason is not obvious (location, camera, contacts).

Libraries

• Audit Gradle / CocoaPods / npm dependencies quarterly.
• Remove unused libraries — they increase APK/IPA size and attack surface.
• Pin versions in lockfiles; document why each major dependency exists.

Storage and security

• Prefer app-internal storage for sensitive data; encrypt tokens and PII at rest.
• If using external storage or downloads, validate paths and sanitize filenames.
• Never log passwords, tokens, or personal data in production builds.

Firebase, analytics, and third-party SDKs

Service	Checkpoint
Firebase	google-services.json / GoogleService-Info.plist matches the correct bundle ID; security rules reviewed
Google Analytics / GA4	Events named consistently; no PII in event parameters
Crash reporting	Symbol files uploaded for release builds (dSYM on iOS, mapping file on Android)
Other SDKs	API keys not committed to Git; use build-time secrets or remote config

---

Config, build, and deployment

The last mile — APIs, databases, tests, and release hygiene — determines whether a good UI survives production traffic.

Middleware and third-party APIs

• Verify base URLs, API keys, and OAuth redirect URIs for staging and production environments.
• Implement timeouts, retry with backoff, and user-visible error states when APIs fail.
• Rotate credentials on a schedule; never ship debug endpoints in release builds.

Database configuration

• Index columns used in frequent queries; profile slow queries before launch.
• Validate and sanitize all inputs — parameterized queries only, no string-concatenated SQL.
• Plan migrations with backward-compatible schema changes when users already have local data.

Software and library versions

• Track Kotlin, Android Gradle Plugin, Xcode, Node, and major library versions in your README or wiki.
• Upgrade dependencies in a dedicated branch with full regression — not the day before release.
• Keep compile SDK / target SDK current for Play Store and App Store requirements.

Testing before release

Layer	Minimum bar
Unit tests	Core business logic, validators, mappers
Integration tests	API clients, repository layer, database
UI / manual	Happy path + offline + permission denied flows
Regression	Smoke test on previous release’s critical flows

Automate what you can; keep a short manual smoke checklist for what automation misses (push notifications, deep links, IAP restore).

Versioning and release notes

• Increment versionCode (Android) and CFBundleVersion (iOS) on every store upload.
• Use semantic versioning for user-visible version names (1.4.2).
• Maintain CHANGELOG.md or release notes: new features, fixes, known issues — not marketing fluff.
• Tag Git releases matching store versions for traceability.

Git hygiene

• Commit in small, logical units with messages that explain why, not only what.
• Never commit keystores, .env files, or provisioning profiles.
• Use pull requests and at least one review for production-bound branches.

---

Before you ship — final pass

Walk this list with a teammate who did not write the code:

1. Identity — correct app name, icon, splash, and store listing on a real device
2. Consistency — three random screens look like the same product
3. Forms — validation and error messages behave identically everywhere
4. Permissions & privacy — only required permissions; privacy policy and data collection accurate
5. Build — release build on physical devices; crash-free session rate acceptable in beta
6. Docs — version bumped, changelog updated, Git tagged

Attention to these checkpoints does not replace user research or good architecture — but it prevents the preventable mistakes that make an otherwise solid app feel amateur. Combine this list with Jetpack architecture best practices for structure and iOS submission prerequisites when you are ready for the store.