Hi all, In Swift, I often see static helper functions grouped in an enum without any cases, like this: enum StringUtils { static func camelCaseToSnakeCase(_ input: String) -> String { // implementation } } Since this enum has no cases, it cannot be instantiated – which is exactly the point. It’s meant to group related functionality without any stored state, and without the need for instantiation. This pattern avoids writing a struct with a private init() and makes the intent clearer: "This is just a static utility, not an object." You’ll often see this used for things like: AnalyticsEvents.track(_:) My question: Is this use of a case-less enum considered good practice in Swift when building static-only helpers? Or is there a better alternative for expressing intent and preventing instantiation? I’d appreciate any insight – especially if there’s official guidance or references from the Swift core team. Thanks!

Hi all, I'm working on a use case where a customer checks in at a point of service (e.g., a cafeteria or restaurant) using their Apple Wallet pass (e.g., a digital employee badge). In this scenario, we would like to use an iPhone (with a custom iOS app) as the NFC terminal to read the pass directly from the customer's iPhone over NFC. I’m aware that "Tap to Pay on iPhone" allows NFC-based payment acceptance, but it’s unclear if similar functionality is available or permitted for reading access-type passes from another iPhone via NFC. Key questions: Is it technically possible for an iPhone to act as an NFC reader for a Wallet pass on another iPhone? If not, is this restricted due to Secure Element isolation or protocol limitations? Is there any Apple-supported path for building such a solution — or is certified external hardware (e.g., HID, Wavelynx) the only option? I’ve reviewed the Core NFC and PassKit documentation but couldn't find a definitive answer. Thanks in advance for your clarification!