[dcalhoun]

What?

Fix demo app typos and display post type labels rather than slugs.

Why?

Improve demo app quality.

How?

Display the post type's labels attribute rather than its key.

Testing Instructions

Manually testing this demo app change is not that important, but:

1. Open a site with a multi-word custom post type in the demo app
2. Verify the post type picker uses the label, not the slug
3. Select a post type
4. Navigate to Browse
5. Verify the list header uses the post type plural label

The screenshots below are from #794, which adds a multiword post type that benefits from the changes.

Accessibility Testing Instructions

N/A, small demo app change.

Screenshots or screencast

Before	After

---

AI-generated details

The demo apps showed post types by their capitalized slug or REST base, which reads poorly for custom types: #794's test type showed as "Gbk_Templated" in the iOS picker and "Templated-Posts" as the iOS posts list title.

• Picker (iOS and Android): shows each post type's singular label from the REST API, as WP Admin does (Post, Page, Templated Post).
• iOS posts list: the title uses the plural label.
• Fallback: the capitalized slug, as before, when the post types weren't loaded from the site (e.g. the bundled editor).
• Fixes the "No Entires" typo on the iOS empty posts list.
• Demo apps only; PostTypeDetails in the library is unchanged, as the labels stay in each app's view model.

Testing

• The iOS demo app builds, and the Android demo app's Kotlin compiles. Neither app has been run with this change.
• To check: open a site with a custom post type (e.g. feat: apply post type templates to new posts #794's wp-env templated_post), and verify the picker and the iOS posts list title show its labels.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YNDBX7RNXn3NsfDuV1PkNV

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/822")

_{Built from 1b8c139}

[adalpari]

LGTM!

Just noting this point for you to decide whether it's worth fixing.

#	Severity	Location	Issue	Impact
1	🔵 Low	android/app/src/main/java/com/example/gutenbergkit/SitePreparationViewModel.kt:368, ios/Demo-iOS/Sources/Views/SitePreparationView.swift:566	The picker's sort key moved from the slug (unique — it is the REST response map key) to the server-supplied label, which is not unique, and no tiebreaker was added.	A CPT registered with no labels inherits WordPress's defaults (_get_custom_object_labels, wp-includes/post.php), so singular_name is "Post" for a non-hierarchical type and "Page" for a hierarchical one — it then sits next to the built-in type as a second, visually identical row, where trunk showed distinct slugs. Tied rows also reorder between launches on both platforms: the wp_api response map is a Rust HashMap (wp_api/src/post_types.rs:65), which is randomly seeded, so neither Dictionary.values on iOS nor the Kotlin LinkedHashMap gives a stable input order. Verified empirically: six launches of the iOS chain produced six different tie orders, fixed only under SWIFT_DETERMINISTIC_HASHING=1. Selection stays correct (ids/tags key on details), so this is cosmetic — but a user who picks "the second Post" gets a different type than last time. Fix: KeyPathComparator(\.details.postType) as a second comparator on iOS, .thenBy { it.details.postType } on Android.