Gains:
- Ability to produce robust interface code for Jetpack Compose and SwiftUI in order of purpose, component, four states (loading/empty/error/full), design system and accessibility
- Ability to produce an interface that is open to all users by defining accessibility from the beginning, with correct labeling, sufficient contrast and appropriate touch.
- Ability to create consistent, multi-language and light/dark theme ready interfaces by reading color and space from the central theme
The success of a mobile app is largely determined by its user interface (UI — the screens the user sees and touches) and user experience (UX — how smooth and enjoyable it is to use). The user does not see the bad code, but feels the bad interface in the first second. AI plays two powerful roles in interface development: on the one hand, it generates design idea, flow and text (UX writing); On the other hand, it directly converts this design into working interface code. In this unit, we will learn how to produce fast, accessible and consistent interfaces with AI, focusing on modern declarative interface tools Jetpack Compose (Android) and SwiftUI (iOS). "Declarative" means that instead of explaining step by step how to draw the screen, you describe "this is how the screen should look in this situation"; The tool does the rest.
From design to code: the right order
Telling AI to "make a beautiful screen" is vague because "beautiful" cannot be measured. Good interface generation follows this order:
- Purpose and content. What does the screen do, what information does it show, what will the user do?
- Component list. Parts such as title, list, button, form field.
- Situations. Loading, empty (no data), error, full — the four basic screen states.
- Design system. Color, typography, spacing rules; generally complying with the Human Interface Guidelines of Material 3 (Android) or iOS.
- Accessibility. Screen reader labels, adequate contrast, touch target size.
- Code. Having said all this, Composable or SwiftUI View generation.
The most frequently skipped step is the third one. Developers only consider the "full" state; whereas in real application the user mostly encounters "loading" and "error" situations. Printing all four states to the AI is the secret to a robust interface.
Tip: Add "generate loading, empty, error, and full separately" at the end of the prompt. This single sentence makes your interface ready for the real world and significantly reduces the number of errors in the QA (quality testing) phase.
Accessibility is non-negotiable
Accessibility — the ability to use the application by users with visual, hearing or motor disabilities — is both an ethical responsibility and a store and legal expectation. AI produces accessible code if desired; Returns a tagless, low-contrast interface if not desired. Three rules of thumb: give each interactive element a meaningful label for the screen reader (contentDescription / accessibilityLabel), adequate color contrast between text and background (at least 4.5:1 ratio), and a touch target of at least 48x48 dp/44x44 pt. Ask the AI these things explicitly.
Caution: AI can also add a long accessibility tag to a decorative icon; This overwhelms the screen reader user with unnecessary chatter. Purely decorative elements should be "hidden from accessibility" (allowed to be skipped by the screen reader). Review the labels produced: let the meaningful speak, let the decorative remain silent.
Consistency: design system and theme
Professional applications do not use random colors and spacing; follows a design system (standard set of colors, fonts, spacing, and components). If you give AI your theme values (main color, secondary color, corner radius, typography scale), all screens will come out consistent. If you don't, each screen will use a different shade of blue and the app will look cluttered. The most efficient way is to first ask the AI to generate a theme/design tokens file, then bind all screens to that theme.
Subject
poor approach
Strong approach
Color
Manually color code each screen
Central theme, screens read from the theme
situations
Only "full" screen
Loading/empty/error/full four states
accessibility
Added later
It is defined in the claim from the beginning
text
embedded in code
Separate source, multi-language ready
three mini cases
Case 1 — Empty case saved. A news app team had the AI print individual screen states. Thanks to the “idle status” screen (“No news saved yet”), 70% of participants in user testing did not leave the app on a blank screen; In the previous version, the blank screen remained white and users thought it was "broken" and left. A small copy increased retention rate.
Case 2 — Contrast rejection. One team applied to the App Store with screens with text in light gray, the brand color. Apple issued a warning on accessibility grounds due to low contrast. When the AI was told to "increase the text-background contrast above 4.5:1", the colors became darker and the problem was solved. If it had been requested from the beginning, there would have been no delay.
Case 3 — Decorative label noise. A visually impaired tester reported that every ornament icon (“line,” “dot,” “shadow”) was read aloud on the AI-generated screen, making the screen unusable. The screen reader experience became fluid when decorative elements were hidden from accessibility. Lesson: accessibility means “the right tags,” not “too many tags.”
Weak prompt / Strong prompt
Weak prompt: "Design a profile screen."
Powerful prompt: "Generate user profile screen for iOS/SwiftUI. Content: avatar, name, email, 'Edit profile' button, settings list. Statuses: loading (skeleton), error (retry button), full. Design: Non-Material, conforming to iOS HIG; system colors, Dynamic Type. Accessibility: accessibilityLabel to each element, decorative icons hidden, touch target min 44pt. Read theme values from a separate file, do not embed color code on the screen. First draw the component tree, then export the code."
Copiable templates
Screen generation template: "Generate [screen name] for [platform/tool]. Content: [elements]. User actions: [actions]. Generate four states separately: loading, empty, error, full. Design system: [Material 3 / iOS HIG], read from theme tokens. Accessibility: labels, contrast >=4.5:1, touch target standard."
Theme/design system template:"Produce a central theme definition for my app ([Compose Theme /a design token structure in SwiftUI]):- Primary color [hex], secondary [hex], error color, surface color- Typography scale (title, body, description)- Spacing scale (4,8,16,24)- Corner radius standardAdd light and dark theme support."
Accessibility audit template:"Check this screen code for accessibility:1) Are there any untagged interactive elements?2) Are contrast ratios adequate?3) Are touch targets large enough?4) Are decorative elements hidden from the screen reader?Suggest fixes for each issue. [code]"
Design to code template: "I describe the following design: [screen description or screenshot]. Translate this into [Compose/SwiftUI] code. Keep spacing and alignment true to the design, but add all four states."
Common mistakes
- Just thinking about the full situation. Most of the time the real user sees the loading/error screen.
- Embedding color and space in code. If the theme is not central, consistency is lost and maintenance becomes difficult.
- Leaving accessibility for last. Adding it later is expensive; It is cost-free if requested from the beginning.
- Overlabeling. Having decorative elements read also disrupts the screen reader experience.
- Embedding text in code. When multilingual support is required, it is necessary to manually change each screen; Keep texts separate.
- Expecting an exact copy from the screenshot. AI design produces approx. Pixel precision is set manually.
In summary
AI is powerful in interface production, but it requires guidance. The correct order: purpose, components, four states (loading/empty/error/full), design system, accessibility, then code. Accessibility is non-negotiable and means “the right label,” not “too many labels.” For consistency, read color and spacing from the central theme, do not embed it in code. The strong will defines all this from the beginning; Thus, the interface is ready for the real world, store approval and all users.
Application task
Using the “Screen generation template” for a settings screen, ask the AI for Compose or SwiftUI code and request all four states. Then have the same code checked with the "Accessibility check template". Find and fix at least one accessibility improvement (missing label, low contrast, or small touch target) and note which status (loading/empty/error) you think will appear most often in real use.
checklist
- [ ] I made the purpose and components of the display clear in the prompt
- [ ] I had the four states (loading/empty/error/full) generated separately
- [ ] I made the color and space read from the central theme, I did not embed it in the code.
- [ ] I wanted accessibility labels and contrast from the beginning
- [ ] I verified that decorative elements are hidden from the screen reader
- [ ] I kept the texts separate, ready for multiple languages