Design and Development Tools by Platform

Choosing a platform for an interface project is only half the decision. The other half is choosing the toolchain — the combination of design, prototyping, coding, debugging, and testing tools that will carry an idea from a sketch on paper to a running application in a user's hands. Toolchains are not neutral. Each one encodes assumptions about how interfaces should be structured, what interaction patterns are "normal", and how much control a developer has over pixels, gestures, and timing. A team that prototypes in Figma using the iOS Human Interface Guidelines UI kit and then builds in SwiftUI will almost automatically produce an interface that feels native to iPhone users. A team that prototypes generic rectangles and builds in Electron will almost automatically produce something that feels like a website in a window. Neither outcome is wrong in every context, but both are consequences of tooling decisions made early, often casually, and expensive to reverse later.

This topic surveys the tools that matter for the four primary platforms considered in this module — Android, iOS, Windows desktop, and the web — plus the cross-platform frameworks that attempt to span them. The aim is not to make you an expert in any single tool, but to give you enough informed judgement to assemble a defensible toolchain for a specific project, and to articulate why that toolchain fits the users, constraints, and success criteria you have defined.

Design and prototyping tools sit at the front of every toolchain, regardless of platform. They are where interaction ideas are made visible and testable before any expensive engineering is committed. The dominant tool in contemporary practice is Figma, a browser-based design environment that supports vector design, component systems, interactive prototyping, and developer handoff in a single file. Figma's defining characteristic is that it is collaborative in real time: multiple designers, developers, and stakeholders can open the same file simultaneously, see each other's cursors, leave threaded comments pinned to specific elements, and branch a file to explore an alternative without destroying the original. For a student project this matters because it removes the version-control problem that plagued older desktop design tools — there is no final_v3_REALLY_final.sketch circulating by email.

Figma is platform-agnostic in the sense that it does not generate code for any particular platform, which is exactly why it works for all four. It produces specifications: measured spacing, colour tokens, type styles, asset exports at multiple densities, and clickable prototypes that demonstrate flow. A developer opening a Figma file in Dev Mode can inspect an element and read off its dimensions in density-independent pixels for Android, points for iOS, or effective pixels for Windows, and can copy generated CSS, Swift, or XML snippets as a starting point. The handoff is never fully automatic — generated code is a hint, not a deliverable — but it eliminates a large class of "the button is three pixels off" conversations.

The second reason Figma is central to platform-aware design is the ecosystem of platform-specific UI kits. These are published, maintained component libraries that mirror each platform's official design language:

• Material Design (Android) — Google publishes an official Material 3 Design Kit containing buttons, navigation bars, FABs, bottom sheets, chips, snackbars, and the full Material type scale and dynamic colour system. Using it means your prototype's touch targets are already 48dp, your bottom navigation already holds three to five destinations, and your elevation shadows already follow the Material surface hierarchy.
• iOS Human Interface Guidelines — Apple publishes an official Apple Design Resources library for Figma covering iOS, iPadOS, macOS, watchOS, and visionOS, including SF Symbols, the San Francisco type family, tab bars, navigation bars with large titles, action sheets, and standard alerts.
• Fluent Design (Windows) — Microsoft publishes Fluent 2 UI kits covering Windows 11 controls, Mica and Acrylic materials, the Segoe UI Variable type ramp, navigation views, command bars, and content dialogs.

The HCI value of these kits is that they make convention compliance the path of least resistance. A designer who drags in an official iOS tab bar does not have to remember that iOS places primary navigation at the bottom with a maximum of five items, or that destructive actions are rendered in red in an action sheet — the component already embodies that knowledge. Conversely, when a designer deliberately departs from a kit component, that departure becomes visible and discussable rather than accidental. A practical workflow is to begin from the platform kit, document every deviation in a comment, and justify each deviation against a user need.

Before any of this high-fidelity work, however, there is a strong argument for low-fidelity wireframing, and tools such as Balsamiq exist precisely to enforce it. Balsamiq renders everything in a deliberately sketchy, hand-drawn style with a single ugly typeface and no colour palette worth speaking of. This is a feature, not a limitation. Three well-documented effects follow from low fidelity:

• Feedback shifts from surface to structure. Stakeholders shown a polished mock-up comment on the shade of blue; stakeholders shown a sketch comment on whether the checkout flow has too many steps. The deliberately unfinished look signals that the design is still open to change.
• Sunk-cost attachment is reduced. A wireframe that took eight minutes to produce can be thrown away without regret. A high-fidelity screen that took four hours tends to survive longer than it deserves.
• Iteration velocity rises. It is realistic to generate six alternative layouts for a dashboard in an hour and hold a comparison session, which is how genuinely different structural ideas get surfaced.

A sensible sequence for a semester project is therefore: paper or whiteboard sketches → Balsamiq (or Figma used in a deliberately low-fidelity mode, e.g. greyscale boxes) for structure and flow → Figma high-fidelity with the relevant platform UI kit → interactive prototype for usability testing → handoff to implementation. Skipping the low-fidelity stage is the single most common cause of projects that look good and work badly.

Finally, a prototyping tool is only useful if it supports the interaction patterns native to the chosen platform. A clickable prototype that only models tap-to-navigate will validate information architecture but will tell you nothing about whether your gesture vocabulary is learnable. Platform-native interactions worth prototyping explicitly include:

• Android: the system Back gesture or button, swipe-to-dismiss on notifications and cards, bottom-sheet drag states, pull-to-refresh, and long-press contextual action modes.
• iOS: the interactive edge-swipe back gesture, sheet presentations with detents (half-height and full-height stops), swipe actions on list rows, context menus on long press, and the large-title navigation bar that collapses on scroll.
• Windows desktop: hover states, right-click context menus, keyboard focus order and tab traversal, resizable and adaptive window layouts, and multi-select with Ctrl and Shift.
• Web: hover and focus states, browser back/forward behaviour, URL-addressable states, responsive reflow at breakpoints, and keyboard accessibility.

Figma's "smart animate", component variants, drag interactions, and scroll-overflow settings can approximate most of these. Where a prototyping tool genuinely cannot express a pattern — true inertial scrolling physics, haptic feedback, voice input — the honest answer is to build a small code spike on the real platform rather than pretend the prototype has validated it. A worked example: a team designing a photo-triage app prototyped "swipe left to delete, swipe right to keep" in Figma using drag interactions and discovered in testing that participants expected the opposite mapping because of a dating-app convention they had internalised. That finding cost two hours in a prototype; it would have cost two weeks in code.

Android development tools centre on Android Studio, the official IDE built on JetBrains IntelliJ IDEA and distributed free by Google for Windows, macOS, Linux, and ChromeOS. It is a large, opinionated environment that bundles far more than a text editor. Its principal facilities are:

• Layout tools. For traditional XML-based views, a drag-and-drop Layout Editor with a constraint-based visual canvas, a blueprint mode showing the constraint graph, and live preview across device sizes, locales, themes, and API levels simultaneously.
• The Gradle build system, which manages dependencies, build variants (e.g. free vs. paid, staging vs. production), code shrinking with R8, and signing configurations.
• Debugging and profiling. Breakpoint debugging, the Logcat log viewer, the Layout Inspector for examining the live view hierarchy on a running device, and profilers for CPU, memory, network, and energy — the last being directly relevant to mobile HCI, since battery drain is a usability problem.
• Accessibility and quality checks. Lint rules that flag missing content descriptions, insufficient colour contrast, and touch targets below the 48dp minimum, plus integration with the Accessibility Scanner.

The language of modern Android development is Kotlin. Google declared Kotlin the preferred language for Android in 2019, and new platform APIs, samples, and documentation are Kotlin-first. Kotlin interoperates completely with Java — a project can contain both, and Kotlin can call Java libraries directly — but new work should be Kotlin. Its practical advantages over legacy Java for UI work include null safety enforced by the type system (eliminating a large share of the NullPointerException crashes that historically plagued Android), far less boilerplate, extension functions, and coroutines for structured concurrency. Coroutines matter for HCI directly: the main thread on Android must stay free to render at 60 or 120 frames per second, and any blocking work on it produces jank or an "Application Not Responding" dialog. Coroutines make it straightforward to move work off the main thread and back again without callback nesting.

// Kotlin coroutine keeping the UI thread responsive
viewModelScope.launch {
    _uiState.value = UiState.Loading
    val result = withContext(Dispatchers.IO) {
        repository.fetchArticles()   // network / disk work, off the main thread
    }
    _uiState.value = UiState.Success(result)   // back on the main thread
}

Jetpack Compose is Google's modern declarative UI toolkit and the recommended way to build new Android interfaces. Instead of defining a static XML layout and then imperatively mutating it from code (findViewById(R.id.title).text = "Hello"), you write composable functions that describe what the UI should look like for a given state. When the state changes, Compose recomposes the affected parts of the tree automatically. This removes an entire category of bugs in which the visible interface drifts out of sync with the underlying data.

@Composable
fun ArticleCard(article: Article, onBookmark: (Article) -> Unit) {
    Card(modifier = Modifier.fillMaxWidth().padding(16.dp)) {
        Column(modifier = Modifier.padding(16.dp)) {
            Text(text = article.title, style = MaterialTheme.typography.titleLarge)
            Spacer(Modifier.height(8.dp))
            Text(text = article.summary, style = MaterialTheme.typography.bodyMedium)
            IconButton(onClick = { onBookmark(article) }) {
                Icon(
                    imageVector = Icons.Default.BookmarkBorder,
                    contentDescription = "Bookmark ${article.title}"
                )
            }
        }
    }
}

Note two HCI-relevant details in that snippet. MaterialTheme.typography pulls type styles from the Material 3 theme, so the app inherits the platform type scale and respects the user's system font-size preference. contentDescription supplies the label that TalkBack, Android's screen reader, will announce — omitting it leaves a blind user with an unlabelled button. Compose also provides @Preview annotations that render composables directly in Android Studio without deploying to a device, which tightens the design iteration loop considerably, and it supports Material 3 dynamic colour, where the app palette is derived from the user's wallpaper.

The Android Emulator completes the toolchain. It runs a full virtualised Android system image, hardware-accelerated on modern CPUs, and allows a developer to create virtual devices spanning the fragmentation that defines Android: a small 5-inch phone at 720p, a 6.7-inch flagship at 1440p, a 10-inch tablet, a foldable with a hinge and two postures, Wear OS watches, Android TV, and Android Automotive. Beyond screen size, the emulator can simulate conditions that are tedious to reproduce physically — GPS coordinates and route playback, incoming calls and SMS interrupting a flow, poor network (2G, high latency, packet loss), battery level and charging state, device rotation, locale and right-to-left layout, dark mode, and large font scaling. Testing a layout at 200% font scale with a long German string in RTL mirroring will surface more real defects in ten minutes than an hour of tapping around in the happy path. The emulator does not replace physical devices entirely — real touch ergonomics, thermal behaviour, camera quality, haptics, and genuine one-handed reach can only be assessed on hardware — but it makes broad configuration coverage feasible for a student team with one phone between them.

iOS development tools are more tightly constrained, and the first constraint is a hard logistical one: Xcode is the required IDE for building, signing, and submitting iOS applications, and Xcode runs only on macOS. There is no supported Windows or Linux version. This single fact must be surfaced during project planning, because a team without access to a Mac (or a legitimately licensed cloud-Mac service, or a university lab machine) cannot ship a native iOS app at all. It is a classic example of a tooling constraint that should appear explicitly in a project scope document as a risk with a mitigation, not be discovered in week nine.

Xcode itself bundles the compiler toolchain, Interface Builder (for legacy UIKit storyboards and XIBs), SwiftUI live previews, the Simulator, Instruments for performance profiling, an accessibility inspector, test runners for unit and UI tests, and the signing and provisioning machinery needed to install builds on real devices and submit to App Store Connect. Code signing deserves specific mention because it reliably consumes a day of a first-time team's schedule: running on a physical iPhone requires an Apple ID and a provisioning profile, and distributing to external testers requires a paid Apple Developer Program membership and TestFlight.

Swift is Apple's modern language for all its platforms, introduced in 2014 and now thoroughly dominant over Objective-C for new work. It is statically typed, memory-safe through automatic reference counting, and designed for clarity at the point of use. Relevant features include optionals (making the possible absence of a value explicit in the type system), value-type structs and enums with associated values for precise state modelling, protocol-oriented design, and async/await with actors for safe concurrency — the same main-thread-responsiveness concern described for Android applies identically here.

SwiftUI is the declarative UI framework and the recommended starting point for new iOS projects. Conceptually it is very close to Jetpack Compose: UI is a function of state, state changes trigger re-rendering, and layout is expressed by composing small views with modifiers.

struct ArticleCard: View {
    let article: Article
    @State private var isBookmarked = false

    var body: some View {
        VStack(alignment: .leading, spacing: 8) {
            Text(article.title)
                .font(.headline)
            Text(article.summary)
                .font(.body)
                .foregroundStyle(.secondary)
            Button {
                isBookmarked.toggle()
            } label: {
                Label("Bookmark", systemImage: isBookmarked ? "bookmark.fill" : "bookmark")
            }
            .accessibilityLabel("Bookmark \(article.title)")
        }
        .padding()
    }
}

SwiftUI's strongest HCI argument is that it inherits platform behaviour by default. Using .font(.headline) rather than a fixed point size means the text automatically honours Dynamic Type, so a user who has enlarged system text for low vision gets a larger headline without any further work. Using Label with an SF Symbol gives an icon that scales with text and matches system weight. Standard controls get VoiceOver support, Dark Mode, high-contrast variants, and right-to-left mirroring essentially for free. Xcode's live previews render SwiftUI views beside the code and update as you type, and preview variants let you check a view simultaneously in light and dark mode, at the largest accessibility text size, and in several locales. Many teams still encounter UIKit, the older imperative framework, because it remains more mature for certain complex cases (highly customised collection layouts, intricate camera interfaces) and because existing codebases use it; the two interoperate through representable wrappers.

The iOS Simulator provides virtual iPhone and iPad models across screen sizes and iOS versions, launching far faster than the Android emulator because it runs the app natively on the Mac rather than emulating ARM hardware. It supports simulated location, rotation, Dynamic Type size changes, colour-blindness filters, Dark Mode toggling, slow-animation mode for inspecting transitions, and recording of video and screenshots for reports. Its limitations are significant and should be stated explicitly in any test plan: the Simulator has no real camera, no genuine Bluetooth or cellular radio, no haptic feedback, no Face ID hardware (only a simulated enrol/match menu), unreliable performance characteristics, and no way to assess thumb reach on a physically large handset. Device testing before release is therefore not optional.

Windows development tools revolve around Visual Studio, Microsoft's full-featured IDE (distinct from the lighter-weight Visual Studio Code). The Community edition is free for students, individuals, and small teams. Visual Studio provides project templates, a XAML designer with live visual tree inspection and hot reload, IntelliSense code completion, an exceptionally capable debugger with edit-and-continue, memory and CPU profilers, test runners, and integrated packaging tooling for MSIX installers and Microsoft Store submission.

The recommended modern native stack is C# with WinUI 3. C# is a mature, statically typed, garbage-collected language with first-class async/await, LINQ for data querying, and strong tooling. WinUI 3 is the current native UI framework for Windows, providing the Fluent Design control set that matches Windows 11: NavigationView for the standard left navigation pane with its hamburger collapse behaviour, CommandBar, TeachingTip for contextual onboarding, InfoBar for inline status messages, ContentDialog for modals, and materials such as Mica (a subtle wallpaper-derived window backdrop) and Acrylic (translucent blur for transient surfaces). Using these controls means an application automatically respects the user's light/dark theme, accent colour, animation-reduction setting, and high-contrast themes.

WinUI 3 ships as part of the Windows App SDK, which is the decoupling layer that solved a long-standing Windows problem. Historically, a developer could only use UI features present in the version of Windows the user had installed, which meant waiting years for adoption before new controls were usable. The Windows App SDK packages the modern UI stack and a unified set of APIs — windowing, app lifecycle, notifications, resource management, dynamic dependencies, and DWriteCore text rendering — with the application itself, so it works consistently across supported Windows 10 and Windows 11 versions and can be updated on the app's schedule rather than the operating system's. It also deliberately does not replace Win32: existing Win32, WPF, and WinForms applications can adopt individual Windows App SDK features incrementally, which matters in enterprise contexts where a twelve-year-old line-of-business application cannot be rewritten.

XAML (eXtensible Application Markup Language) is the declarative markup used to define WinUI layouts. It separates UI structure from behaviour, and its data-binding system connects UI elements to view-model properties so the interface updates when data changes — the same state-driven principle as Compose and SwiftUI, expressed in markup rather than code.

<StackPanel Padding="16" Spacing="8">
    <TextBlock Text="{x:Bind ViewModel.Title, Mode=OneWay}"
               Style="{StaticResource TitleTextBlockStyle}" />
    <TextBox Header="Project name"
             PlaceholderText="e.g. Campus Navigator"
             Text="{x:Bind ViewModel.ProjectName, Mode=TwoWay}" />
    <Button Content="Create project"
            Command="{x:Bind ViewModel.CreateCommand}"
            Style="{StaticResource AccentButtonStyle}"
            AutomationProperties.HelpText="Creates a new project with the entered name" />
</StackPanel>

Several desktop-specific HCI concerns are handled through XAML attributes: AutomationProperties feed the UI Automation tree used by the Narrator screen reader; TabIndex and KeyboardAccelerator define keyboard traversal and shortcuts, which desktop users expect far more strongly than mobile users; and AdaptiveTrigger with VisualStateManager lets a single layout reflow as the window is resized from a narrow snapped pane to a full 4K display. It is also worth noting the alternative Windows stacks you will encounter: WPF (mature, XAML-based, still widely used in enterprise), WinForms (legacy, drag-and-drop, fine for simple internal tools), and .NET MAUI (cross-platform, sharing C# and XAML across Windows, macOS, Android, and iOS, and itself built on WinUI 3 on Windows).

Web development tools have the lowest barrier to entry of any platform, which is a large part of why the web is so often the pragmatic choice for a time-boxed project. The common editor is Visual Studio Code: free, open-source, and available on Windows, macOS, and Linux. It is a text editor rather than a full IDE, but its extension marketplace closes most of the gap — syntax support for essentially every language, Prettier and ESLint for formatting and linting, Live Server for instant reload, Git integration, Docker and remote-container support, debugger integration with Chrome and Node.js, and accessibility linters such as axe or the webhint extension that flag missing alt text and ARIA misuse as you type. Its cross-platform availability also means a mixed team on different operating systems can share an identical configuration through a committed .vscode folder.

Underneath every framework and build tool, the web rests on three foundational technologies, and understanding them is non-negotiable:

• HTML provides structure and, critically, semantics. Using <button>, <nav>, <main>, <label>, and heading levels correctly gives screen readers a navigable document outline and gives keyboard users working focus and activation behaviour for free. A <div onclick> styled to look like a button has none of that and must have role, tabindex, and key handling added manually — which is why semantic HTML is an accessibility decision before it is a coding style.
• CSS controls presentation and responsive behaviour. Flexbox and Grid handle two-dimensional layout; media queries and container queries adapt to viewport or component size; custom properties implement design tokens shared with Figma; and prefers-color-scheme, prefers-reduced-motion, and prefers-contrast let a site respect user accessibility preferences expressed at the operating-system level.
• JavaScript supplies behaviour, asynchronous data fetching, and state management, running in a single-threaded event loop where long synchronous work blocks rendering and input handling — the web's equivalent of main-thread jank.

<!-- Semantic, accessible by default -->
<label for="search">Search articles</label>
<input id="search" type="search" name="q" autocomplete="off">
<button type="submit">Search</button>

<!-- Visually identical, behaviourally broken -->
<div class="label">Search articles</div>
<div class="input" contenteditable="true"></div>
<div class="button" onclick="search()">Search</div>

Frameworks such as React, Vue, and Angular sit on top of these foundations. They all solve the same core problem — keeping a complex UI synchronised with changing application state — using the same declarative, component-based idea seen in Compose, SwiftUI, and XAML binding. They differ in philosophy and weight:

The honest trade-off is that frameworks accelerate development only once the learning cost has been paid. For a four-week project in which no team member has used Angular, adopting Angular will almost certainly slow you down; the time goes into dependency injection and build configuration rather than into user research and iteration. For a ten-week project building a dashboard with thirty interactive components and shared state, writing it in hand-rolled DOM manipulation will slow you down instead, because you will reinvent a worse version of what the framework already provides. A defensible rule of thumb: match framework weight to interface complexity and existing team skill, and prefer the simplest option that will not require a rewrite. A largely static informational site may need no framework at all, or only a static-site generator.

Browser developer tools in Chrome and Firefox are the web's debugging, profiling, and auditing environment, and they are essential rather than optional. The panels that matter most for interface work are:

• Elements/Inspector — live inspection and editing of the DOM and CSS, with the box model, computed styles, Flexbox and Grid overlays, and a colour picker that reports WCAG contrast ratios against the background and will suggest a compliant colour.
• Console — logging, error messages, and an interactive JavaScript REPL against the live page.
• Network — request waterfalls, payload sizes, caching behaviour, and throttling presets that simulate slow 3G or offline, which is how you discover that your 2 MB hero image makes the page unusable on a bus.
• Performance — frame-by-frame recording of scripting, layout, and paint, exposing long tasks that block input and the layout thrashing that causes jank.
• Device toolbar / Responsive Design Mode — emulated viewports, device pixel ratios, touch input, and orientation for responsive testing.
• Accessibility panel — the accessibility tree, computed roles and names, focus order inspection, and colour-vision deficiency simulation (Chrome also simulates blurred vision).
• Lighthouse (Chrome) — automated audits producing scores for performance, accessibility, best practices, and SEO, including Core Web Vitals such as Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. These map directly onto user-perceived responsiveness and visual stability, making them useful, measurable success criteria for a project.

Automated audits catch perhaps a third to a half of real accessibility defects; they will flag a missing alt attribute but not an unhelpful one, and they cannot tell you whether a flow makes sense. They are a floor, not a ceiling, and must be paired with keyboard-only walkthroughs and screen-reader testing.

Cross-platform tools and frameworks exist to amortise effort across targets. Flutter, from Google, builds Android and iOS applications (plus web, Windows, macOS, and Linux) from a single Dart codebase. Its distinguishing architectural choice is that it does not use the host platform's native widgets; it ships its own rendering engine (Impeller, formerly Skia) and draws every pixel itself. The consequences are double-edged: you get pixel-identical output everywhere, a very fast hot-reload development loop, and excellent control over custom-branded design; but you also inherit responsibility for platform fidelity, because a Flutter widget only behaves like an iOS control if the framework's Cupertino library happens to replicate the current behaviour accurately. Flutter does provide both Material and Cupertino widget sets to mitigate this.

// Flutter: declarative UI in Dart
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: const Text('Articles')),
    body: ListView.builder(
      itemCount: articles.length,
      itemBuilder: (context, i) => ListTile(
        title: Text(articles[i].title),
        subtitle: Text(articles[i].summary),
        onTap: () => openArticle(articles[i]),
      ),
    ),
  );
}

React Native, from Meta, takes the opposite approach: JavaScript (usually with React and TypeScript) drives actual native platform components, so a <Switch> renders as a real Android Material switch and a real iOS toggle, with each platform's own animation and accessibility behaviour. This buys better native feel and lets web-skilled teams reuse their React knowledge and much of their business logic. The costs are a bridge/interop layer between JavaScript and native code that can become a performance bottleneck for animation-heavy or computation-heavy screens, a dependency on third-party native modules of variable quality, and more complex upgrade paths. Expo, a managed toolchain around React Native, substantially reduces setup friction and is a common choice for student projects — though note that even with Expo, producing a signed iOS build for the App Store still ultimately requires Apple's tooling and a developer account, via a cloud build service if not a local Mac.

Electron wraps a web application — Chromium for rendering plus Node.js for system access — into a desktop application for Windows, macOS, and Linux. It is the technology behind Visual Studio Code, Slack, Discord, Figma's desktop client, and Obsidian, which demonstrates that excellent products can be built this way. Its advantages are that a web team can ship a desktop app with existing skills, gain file-system, menu-bar, tray, and auto-update capabilities, and maintain one codebase for three desktop operating systems. Its costs are equally well documented: each app bundles an entire browser, so installers run to 80–150 MB and idle memory use is high; startup is slower than native; and the app does not automatically honour platform conventions such as macOS menu-bar placement, Windows accent colours, or native context menus unless the developer implements them deliberately. Tauri is a newer, lighter alternative that uses the operating system's built-in webview and a Rust backend, producing much smaller binaries.

The central HCI trade-off across all of these is that cross-platform tools may sacrifice platform-specific UI conventions, and that sacrifice is paid by users, not developers. Users do not experience your codebase; they experience whether the Back gesture works, whether the date picker looks like the one in every other app on their phone, whether Ctrl+W closes the window, whether the screen reader announces controls properly, and whether a new OS feature appears in your app this year or in two years. Jakob's Law — users spend most of their time on other products and therefore expect yours to work the same way — is the principle at stake. Concrete symptoms of convention drift include Android-style overflow menus appearing on iOS, missing support for iOS swipe-back, non-native text-selection and context menus, scroll physics and overscroll behaviour that feel subtly wrong, delayed support for new system font sizes or dark-mode variants, and inconsistent haptics.

The following comparison summarises how the options trade off against each other:

A practical way to decide is to ask a short series of questions and record the answers as justification. Who are the users and what devices do they actually hold? What is the team's existing skill set, and how much of the timeline can be spent learning? Is a Mac available? How much of the interface is standard platform chrome versus custom-drawn content — a game or a drawing canvas loses little by going cross-platform, whereas a form-heavy productivity tool loses a great deal? Does the app need capabilities that are awkward outside native code, such as background location, widgets, deep OS integration, or specialised sensors? How critical is accessibility, and can you test it adequately in the chosen stack? What are the distribution constraints and timeline for updates? A team that answers these honestly and writes the answers down has a defensible toolchain decision; a team that picks Flutter because a tutorial was convenient has a guess.

A final, often-overlooked point: the toolchain extends beyond design and coding tools to version control (Git with GitHub or GitLab), issue tracking, continuous integration for automated builds and tests, crash and analytics reporting, and user-testing infrastructure such as screen-recording or remote testing platforms. For a small project these can be lightweight, but choosing them deliberately — and noting them in the project scope — prevents the common failure mode in which three weeks of work exists only on one laptop.

Alignment with Learning Outcomes

• MO1: The topic supports this outcome by exposing the concrete design constraints that each platform's tooling embodies — Material Design and 48dp touch targets on Android, the Human Interface Guidelines and Dynamic Type on iOS, Fluent controls and keyboard traversal on Windows, and semantic HTML with responsive breakpoints on the web — giving students a tool-level basis for comparing platforms against target user needs.
• MO2: The comparison of native, cross-platform, and web stacks, together with the trade-off table and the decision questions on team skill, device access, UI fidelity, and distribution, provides the evidence base students need to select a platform and toolchain and justify that selection against stated project requirements.
• MO3: The topic feeds scope definition by identifying tooling constraints and risks that belong in a scope document — the macOS requirement for Xcode, framework learning curves, emulator versus physical-device testing limits — and by supplying measurable success criteria such as Lighthouse accessibility and Core Web Vitals scores.

Once you have a rough idea of what your project should do and who it is for, the next practical question is: what will you actually build it with? Every platform — Android, iOS, Windows, and the web — comes with its own expected toolchain, from design and prototyping software through to IDEs, UI frameworks, and testing tools. Choosing well early saves rework later; choosing poorly can lock your team into a workflow that fights your design goals or your available skills.

This topic surveys those options in two layers. The first is design and prototyping: tools like Figma that let you sketch, wire up, and test an interface before any code exists, so usability problems surface cheaply. The second is implementation: the native tool sets for each platform (Android Studio and Kotlin, Xcode and Swift, Visual Studio and .NET, plus the browser-based web stack) and the cross-platform frameworks such as Flutter, React Native, .NET MAUI, and Compose Multiplatform that promise one codebase across several targets.

As you watch, keep your own project in mind. Note what each tool assumes about your team's skills, what it makes easy versus awkward, and how much control it gives you over platform-specific interaction conventions. Pay attention to the trade-offs discussed around cross-platform work — code reuse, performance, access to native UI patterns — because those trade-offs are exactly the kind of justification you will need to write into your scope document.

Aliena Cai · 6:06 · 214,087 views · 1y ago · captions — Watch on YouTube

About this video

A short beginner tutorial on building an interactive prototype in Figma, covering how to link frames, set up interactions and transitions, and play back the result. It is aimed at people new to the tool and focuses on the prototyping mode rather than advanced design systems. Expect a quick, hands-on walkthrough rather than a deep reference.

Why this video

Figma is the de facto standard for interface design and prototyping across platforms, and this video gives a compact entry point into the prototyping subtopic from a UX-focused channel, so you can mock up and test screens before committing to a development toolchain.

Tastemaker Design · 19:29 · 124,161 views · 6mo ago · captions — Watch on YouTube

About this video

The creator builds the same application six times using Flutter, React Native, .NET MAUI, SwiftUI, Capacitor, and Compose Multiplatform, then compares the experience and results. Expect discussion of setup, developer experience, UI capability, and the practical differences between native and cross-platform approaches. It is a comparison piece rather than a tutorial on any single framework.

Why this video

This directly serves the cross-platform tools subtopic and also touches the native iOS and Windows stacks, giving you a side-by-side basis for arguing why one toolchain suits your project better than another.

Flutter · 13:43 · 218,630 views · 3y ago · captions — Watch on YouTube

About this video

An official Flutter video that introduces Flutter by mapping its concepts onto what an iOS developer already knows, covering ideas such as widgets, layout, and navigation in comparison to native iOS development. It is framed as an orientation rather than a full course. Viewers unfamiliar with iOS can still use it as a contrast between a native and a cross-platform mental model.

Why this video

Coming from the Flutter team itself, it is an authoritative look at how a cross-platform framework relates to a native platform's tooling and conventions — useful context when weighing iOS development tools against a shared-codebase approach.

Together these videos move from design tooling to implementation tooling, which is the bridge between deciding on a platform and planning the work. The Figma tutorial supports MO3 by showing how prototypes can make objectives and success criteria concrete before development starts. The six-framework comparison and the Flutter-for-iOS orientation support MO1 and MO2 by exposing the real constraints of each platform's toolchain — native UI fidelity, code reuse, and developer effort — so your platform choice can be justified against stated project requirements rather than preference alone.

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.