iOS 13 Features for Developers: What to Know

iOS 13 was a major app-development release centered on SwiftUI, Dark Mode, Sign in with Apple, and advances in ARKit 3, Core ML 3, and Siri. The practical takeaway for developers is to assess both interface design and framework changes, then check Apple’s release notes for the exact SDK and OS versions your app supports before changing compatibility assumptions.

Apple announced that the iOS 13 SDK was bundled with Xcode 11. Its release notes advise developers to update apps for new features and test against API changes. This guide explains the release’s main developer themes and how to evaluate them; it is an overview, not a substitute for feature-specific API documentation.

1. What changed for developers in iOS 13?

Area	What to evaluate
SwiftUI	A new framework and a central topic in Apple’s WWDC 2019 developer material. Review Apple’s sessions and documentation for implementation details.
Dark Mode	Whether screens, colors, images, and text remain legible and intentional when the system appearance changes.
Interface patterns	Card-style modal sheets and contextual menus, which affect how people navigate and act in an app.
Authentication	Sign in with Apple, one of the capabilities Apple highlighted for iOS 13 apps.
Advanced frameworks	ARKit 3 and Core ML 3, also highlighted in Apple’s announcement; investigate their dedicated documentation before designing an integration.
Compatibility	New API behavior, deprecations, known issues, and target OS behavior documented in the release notes.

Apple’s September 10, 2019 announcement highlighted Dark Mode, Sign in with Apple, and advances in ARKit 3, Core ML 3, and Siri. Apple’s announcement provides the dated release context.

2. SwiftUI: evaluate the framework and your app’s constraints

SwiftUI was one of the central developer subjects in Apple’s WWDC 2019 material. Apple’s platform overview and session catalog include sessions such as “Introducing SwiftUI: Building Your First App,” “SwiftUI Essentials,” and “Integrating SwiftUI.” Use these resources to understand the framework; this article does not infer API behavior from session titles.

Before adopting SwiftUI in an app, write down the requirements that will decide whether and where to use it:

Which OS versions must the app support?
Will the new work be a contained screen or part of a broader UI architecture change?
Which views, interactions, and accessibility behaviors must the feature deliver?
What does the relevant iOS 13 release-note entry say about API changes, deprecations, and known issues?

The iOS 13 release notes record SwiftUI changes and known issues. They also describe a weak-linking workaround for apps that need to run on earlier OS versions without SwiftUI. Treat that as a specific compatibility concern to verify against the exact release-note entry and deployment setup, rather than assuming one back-deployment rule fits every app.

Start with Apple’s Platforms State of the Union — WWDC19, the Apple Developer Documentation, and the iOS 13 Release Notes. The documentation and notes, rather than this overview, should guide code and availability decisions.

3. Dark Mode and interface design changes

Dark Mode is a system appearance that apps can respond to. Review screens in both appearances; a theme switch alone does not guarantee a readable or coherent interface. Apple’s design session specifically discusses adapting colors, images, and text for Dark Mode, as well as card-style sheets and contextual menus.

Design review checklist

Inventory key screens, dialogs, and content-heavy views.
Review foreground and background colors in both appearances, including secondary text and controls.
Inspect images and other visual assets for contrast or backgrounds that look out of place in the alternate appearance.
Check that text remains readable and important state is not communicated through color alone.
Review modal presentation and contextual actions: do card-style sheets and menus make the action and dismissal behavior clear?
Test the app’s relevant flows on the OS versions and devices in your support matrix.

Apple’s What’s New in iOS Design — WWDC19 is the primary design reference for these iOS 13-era changes.

Apple’s announcement identifies Sign in with Apple and advances in ARKit 3, Core ML 3, and Siri as capabilities for iOS 13 apps. At this overview level, the useful action is to identify whether one of these capabilities serves a product requirement, then consult its specific Apple documentation for implementation details and availability.

This source set does not establish detailed entitlement requirements, API behavior, or availability matrices for these technologies. Do not make implementation or compatibility decisions from a high-level feature list; verify the relevant primary documentation for the API and target OS you intend to use.

5. Read release notes before setting compatibility or migration plans

Apple’s iOS 13 release notes include new features, deprecations, and known issues. Apple’s guidance is direct: “Update your apps to use new features, and test your apps against API changes.” Read the notes for the exact OS and SDK context relevant to your build. For example, the notes state that UIApplicationExitsOnSuspend is no longer supported and include SwiftUI changes and a back-deployment workaround. A note tied to a beta or specific release must not be generalized without checking its scope.

A practical review sequence

Record your deployment target, SDK/Xcode version, and supported device and OS matrix.
Read the relevant iOS 13 release-note entries for APIs your app uses and features you plan to adopt.
Separate general API changes from entries scoped to a particular release or beta.
Update and build in the intended toolchain, then test affected flows on supported OS versions.
Document unresolved known issues and compatibility decisions so they are reviewable during release planning.

Use Apple’s iOS 13 Release Notes as the source of truth for those checks.

6. Historical App Store submission context

Apple’s September 10, 2019 announcement said that starting in April 2020, all new apps and app updates would need to be built with the iOS 13 SDK and support the all-screen design of iPhone XS Max or later. That was a dated, prospective requirement announced in 2019. It is historical context, not a statement of current App Store submission policy. Check Apple’s current policy before making a present-day compliance decision.

7. Capture screenshots while reviewing iOS 13-era interfaces

Visual review is useful when comparing screens, documenting Dark Mode and light appearance, or sharing a page in a design discussion. If the material you need to capture is a website, you can use a browser automation library or a screenshot API. A website capture does not replace testing an iOS app on the OS versions and devices in its support matrix.

DIY browser capture with Playwright (Node.js)

Install Playwright and its Chromium browser, then save this as capture.mjs. It captures a full-page image of a target website and emulates a dark color scheme. Change the URL and color scheme as needed.

npm init -y
npm install playwright
npx playwright install chromium

// capture.mjs
import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({
  viewport: { width: 1440, height: 1000 },
  deviceScaleFactor: 1,
  colorScheme: 'dark'
});

try {
  await page.goto('https://example.com', {
    waitUntil: 'networkidle',
    timeout: 60000
  });
  await page.screenshot({ path: 'page-dark.png', fullPage: true });
} finally {
  await browser.close();
}

For a light appearance, set colorScheme: 'light'. If a page keeps making network requests, use a more appropriate readiness condition for that page and wait for a known selector instead of relying on network idle.

Equivalent captures with cURL, Python, and Node.js

These ScreenshotNeo examples capture a website page. They are useful for website visuals and documentation; they do not test a native iOS app or establish how an app behaves on a particular iOS release. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media. One GET request can return a PNG, JPEG, WebP, or PDF. For website captures, its cleanup accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status.

An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Yearly billing gives two months free, and every feature is on every plan.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python and Node.js examples, plus the API options, are in the ScreenshotNeo documentation. ScreenshotNeo also supports full-page and selector capture, dark mode, device presets and custom viewports, retina scale, PDF settings, custom CSS and JavaScript, waits, request blocking, headers, cookies, user agents, geolocation, timezone, resizing, caching with a chosen TTL, signed image links, async jobs and signed webhooks, bulk capture, usage lookup, and an OpenAPI specification. Parameters used by other screenshot APIs also work, making migration easier.

See ScreenshotNeo for the product. Sign up for 1,000 free screenshots a month with no card.

9. Performance, reliability, and cost considerations

App work: This overview makes no performance claims about SwiftUI or the other frameworks. Evaluate the actual app flows and APIs you plan to use, on the OS and SDK versions that matter to your release.
Visual review: A website screenshot is a captured page state, not evidence that a native app works across devices. Keep device and OS testing in your validation plan.
Browser automation: Full-page capture can require more rendering and waiting than a viewport capture. Choose a viewport and readiness condition that match the question you are answering; use a selector wait when network activity never settles.
Screenshot API billing: ScreenshotNeo says bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its response includes X-Page-Verdict and X-Billed headers, so inspect those when reconciling capture outcomes.
Plan selection: ScreenshotNeo lists Free at 1,000 shots/month, Starter at $5 for 3,000, Growth at $15 for 15,000, Pro at $39 for 60,000, Scale at $99 for 250,000, and Business at $249 for 1,000,000. Yearly billing gives two months free; every feature is on every plan.

10. Troubleshooting

Symptom	Likely cause	What to do
A feature or symbol is unavailable for a target OS	The chosen API or framework may not be available in that deployment context, or the compatibility approach may differ.	Check the specific API documentation and release notes for the exact OS and SDK; verify any back-deployment guidance rather than assuming availability.
SwiftUI behavior differs from expectations	The overview or a session title is being treated as a complete API specification.	Use the relevant Apple documentation and iOS 13 release-note entry; test the feature on the target versions.
Dark appearance has unreadable text or awkward imagery	Colors, image assets, or text treatments were reviewed in only one appearance.	Review both appearances, including secondary content and key flows, following Apple’s design guidance.
A release-note warning seems to conflict with current behavior	The note may apply to a particular release, beta, or SDK context.	Read the complete entry and confirm its scope before applying it to another version.
Playwright times out waiting for `networkidle`	The page may keep long-lived requests or background network activity open.	Use a page-appropriate readiness condition or wait for a specific selector, then capture after the relevant content appears.
Screenshot output is blank or incomplete	The page may not have rendered the desired content before capture, or the target may be a native app rather than a website.	Wait for the page content you need and confirm the URL. Use device/OS testing for native app screens.
An API capture is not billed as expected	The result may be a cache hit, bot check, CAPTCHA, blank page, timeout, or failed load.	Check the response’s `X-Page-Verdict` and `X-Billed` headers to see the reported outcome.

11. Frequently asked questions

Was the April 2020 SDK requirement announced for current submissions?

No. It was a prospective requirement Apple announced in September 2019 for April 2020. Consult current Apple policy for present-day submissions.

Does this overview provide a SwiftUI migration recipe?

No. SwiftUI implementation and compatibility choices depend on the APIs and OS versions involved. Use Apple’s documentation, sessions, and release notes for those decisions.

Can a website screenshot verify Dark Mode in a native iOS app?

No. It can document a website appearance. Native app behavior needs to be reviewed in the relevant app and device environment.

Where should I start for the iOS 13 API details?

Start with Apple’s iOS 13 release notes, then follow the feature-specific Apple documentation linked from the relevant framework or API reference.