Decouple application password name logic from knowing the OS

[mokagio]

Description

See https://linear.app/a8c/issue/AINFRA-730

Problem: When moving networking from framework to Swift package, the architecture checks no longer work. This is a problem for the current application password name logic:

woocommerce-ios/Networking/Sources/Core/ApplicationPassword/ApplicationPasswordUseCase.swift

Lines 51 to 63 in ae05dab

	private var applicationPasswordName: String {
	get async {
	#if !os(watchOS)
	let bundleIdentifier = Bundle.main.bundleIdentifier ?? "Unknown"
	let model = await UIDevice.current.model
	let identifierForVendor = await UIDevice.current.identifierForVendor?.uuidString ?? ""
	return "\(bundleIdentifier).ios-app-client.\(model).\(identifierForVendor)"
	#endif
	#if os(watchOS)
	return "" // This is not needed on watchOS as the watch does not create application passwords.
	#endif
	}
	}

In practice, this means that when building the watch app we try to access UIDevice which is not available.

I tried replacing #if !os(watchOS) with #if canImport(UIKit) but got the same problem, surprisingly.

Solution: I pushed UIDevice off DefaultApplicationPasswordUseCase, leaving it up to the caller to pass the information. This way, the iOS app target can in a DefaultApplicationPasswordUseCase with the UIDevice data, and the watch code is none the wiser.

See also the documentation comment in the new DeviceModelVersionInfo data transfer object.

Steps to reproduce & Testing information

I'm not too sure how to test this on device, can you help me with that? Notice CI is green in the meantime.

Screenshots

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	30351
	Version	PR #15729
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	4adfc35
	Installation URL	61fjjkhflkhjg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[itsmeichigo]

When you mention pushing UIDevice off DefaultApplicationPasswordUseCase, I thought this check for watchOS would be removed and the usage of UIDevice below would be replaced with DeviceModelIdentifierInfo. @mokagio could you please clarify this again?

[mokagio]

Sorry @itsmeichigo . I simply did not push the rest of the work 🤦‍♂️

[itsmeichigo]

I'm not too sure how to test this on device, can you help me with that? Notice CI is green in the meantime.

DefaultApplicationPasswordUseCase can be tested by trying to log in to a Jurassic Ninja site using site credentials. When creating the JN site, please ensure to disable Jetpack installation on the site to ensure the site credentials login flow succeeds without any security measures blocking it.

[itsmeichigo]

I tested site credential login with a JN site and confirmed that the login was successful after this fix:

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-06-11.at.13.15.09.mp4

I also checked with Proxyman and confirmed that the application name was correct.

[mokagio]

@itsmeichigo thank you!

For what is worth, I also tested it and verified the new code gets called and the subsequent API request is successful resulting a login.