[VarshithaPamisetty]

Description of changes:

Step 5 of the connect HTTP datasource page served TypeScript client code (client.mutations.addPost, client.queries.getPost, in files titled App.tsx) to all nine platforms, because the section had no InlineFilter. Added Swift, Android, and Flutter sections using raw GraphQL, and scoped the existing TypeScript example to the JS platforms.

Each native section defines a type matching the Post return type, then a BlockSwitcher with the four custom operations, mirroring the structure of the parent custom business logic page. Steps 1 through 4 are unchanged: those snippets define the Gen 2 backend, which is TypeScript on every platform.

Checks

• yarn build succeeds with no errors
• Deployed the page's schema and resolvers to a sandbox and ran all twelve documents against the live AppSync endpoint; each is accepted and schema-validated, and the live Post type matches the types shown

Refs #7922

[cadivus]

Keep Swift response properties at internal access

Post is declared with the default internal access level, so exposing it through the public addPost property violates Swift access control and makes the example fail to compile. The get, update, and delete response wrappers repeat the same pattern.

Suggested change

	struct AddPostResponse: Codable {
	public let addPost: Post
	}
	struct AddPostResponse: Codable {
	let addPost: Post
	}

[VarshithaPamisetty]

Can't reproduce the compile failure. All five declarations type-check at top level:

swiftc -typecheck all.swift    exit=0    (Apple Swift 6.3.3)

Swift rejects a public member only when the type is more restrictive. Control confirms the check works:

private struct P: Codable { let a: String }
struct R: Codable { public let p: P }
-> error: property cannot be declared public because its type uses a private type

The same shape is merged at custom-business-logic/index.mdx:364 and type-checks too.

Leaving as is, since the example compiles as written.

[cadivus]

Check Android GraphQL errors before parsing data

A successful HTTP exchange can invoke this callback with GraphQL errors and null data, but the example immediately parses and dereferences it.data. Resolver errors therefore turn into a null parse or dereference instead of being reported; all four Android examples repeat this handling.

[VarshithaPamisetty]

Fixed in all four Android blocks.

Verified: AppSyncGraphQLOperation.java:165 calls onResponse.accept(...) unconditionally on HTTP success, and a live run returned errors=1 data={"getPost":null} on 9 of 12 documents.

[cadivus]

Handle nullable Flutter GraphQL response data

GraphQLResponse.data is nullable and is commonly null when the response contains GraphQL errors, so response.data! throws before the errors can be inspected. The query, update, and delete snippets repeat the same force unwrap.

Suggested change

	final response = await Amplify.API.mutate(request: request).response;
	Map<String, dynamic> jsonMap = json.decode(response.data!);
	final post = Post.fromJson(jsonMap['addPost']);
	safePrint(post.author);
	final response = await Amplify.API.mutate(request: request).response;
	final data = response.data;
	if (data == null) {
	safePrint('errors: ${response.errors}');
	} else {
	final jsonMap = json.decode(data) as Map<String, dynamic>;
	final post = Post.fromJson(jsonMap['addPost']);
	safePrint(post.author);
	}

[VarshithaPamisetty]

Fixed in all four, using hasErrors rather than the suggested null check.

Live AppSync returns data={"getPost":null} with errors non-empty, so if (data == null) never fires. Replaying that body against the suggestion:

Unhandled exception: type 'Null' is not a subtype of type 'Map<String, dynamic>'