Ekhoo/Device for Swift device and screen detection

What Ekhoo/Device classifies in a Swift application

Ekhoo/Device addresses a narrow question: which Apple device is running the application, and what nominal screen category should its interface use? It is aimed at Swift developers building for iPhone, iPad, iPod touch, macOS, and the iOS Simulator. The public API separates this into three related calls: `Device.version()` for a specific model or device class, `Device.size()` for a screen-size category, and `Device.type()` for the broader family. Convenience predicates such as `Device.isPad()`, `Device.isPhone()`, `Device.isPod()`, and `Device.isSimulator()` are also documented.

This distinction matters because model and screen category are not interchangeable. A switch over `Device.version()` can distinguish an `.iPhone8` from an `.iPhone8Plus`, while `Device.size()` deliberately returns a smaller set of screen categories. The library is therefore closer to a device classification table than to a general layout system. It does not document points in inches for arbitrary views, orientation handling, safe-area geometry, or a general SwiftUI alternative.

The intended users are applications that still make decisions based on concrete hardware categories. The documented examples include printing model names, reporting a nominal display size, and checking whether the current target is an iPad.

How Device.version, Device.size, and Device.type divide the result

The API has three separate data paths from the current runtime environment into application logic. `Device.version()` returns a model-level enum with cases for older iPhone generations, iPad families, iPod touch generations, the simulator, and an unknown fallback. `Device.size()` maps the current device into categories including `.screen4_7Inch`, `.screen5_8Inch`, `.screen6_1Inch`, `.screen6_5Inch`, and several iPad sizes. `Device.type()` reduces the result to `.iPhone`, `.iPad`, `.iPod`, `.Simulator`, or a default case.

That separation makes the library usable at different levels of specificity. An application can branch on an exact model when it genuinely needs one, use a screen category for a constrained layout decision, or use `Device.type()` for a family check. The README also shows predicate-style calls for iPad, iPhone, iPod, and simulator detection. Those predicates appear as an alternative to switching on `Device.type()` rather than a separate installation requirement.

The README does not explain the internal hardware-string parsing, mapping tables, cache behavior, or thread-safety model. Its public examples show static calls with no configuration object. A concise mapping layer is useful for small applications, but applications with unknown-device telemetry or a requirement to audit detection results need to inspect the current source before assuming how new hardware is classified.

One documentation detail deserves attention during review. The `.screen6_5Inch` enum name is printed in the size example as "It's a 6.8 inch screen." The code label and displayed description therefore differ. That does not establish the runtime mapping, but it is a concrete reason to verify screen categories against the 3.8.0 implementation before using their names for product logic.

Installing Device 3.8.0 through CocoaPods

For a CocoaPods-based Xcode project, the README documents a version constraint for Device 3.8.0. Add the pod to the application's `Podfile`.

pod "Device", '~> 3.8.0'

After editing the file, the README does not give a separate installation command in the excerpt. It says only to add the line to the `Podfile`, so consumers should follow their normal CocoaPods installation procedure without inferring an undocumented command.

This route is appropriate for an existing project that already uses CocoaPods. It also makes the version decision visible in one shared dependency file. Developers comparing 3.8.0, 3.7.0, and 3.6.0 should inspect their lockfile and release contents, because the README's model list does not serve as a complete release-by-release device inventory.

Package.swift and Carthage installation paths

Swift Package Manager is the most direct documented path for a Swift package. The README places the dependency in the `dependencies` value of `Package.swift`, starting at version 3.8.0.

dependencies: [
    .package(url: "https://github.com/Ekhoo/Device.git", from: "3.8.0")
]

The repository also contains `Package.swift`, and the README badges identify Swift 5.0 and Swift Package Manager compatibility.

For Carthage, the README first documents installing the dependency manager through Homebrew:

$ brew update
$ brew install carthage

The `Cartfile` entry is:

github "Ekhoo/Device" ~> 3.8.0

The README then names `carthage update` as the command that builds the dependency and says to drag the resulting `Device.framework` into the Xcode project. It does not document the framework copy phase, code-signing settings, or embedding details, so those remain project integration steps outside these instructions.

A first Swift use of the model, size, and family APIs

A first use can call the same static API directly from a Swift function. The following compact example is assembled from the documented `Device.size()` and `Device.type()` switches. It handles the documented categories explicitly rather than relying on a guessed enum case.

func describeCurrentDevice() {
    switch Device.size() {
    case .screen6_5Inch: print("It's a 6.8 inch screen")
    case .screen5_8Inch: print("It's a 5.8 inch screen")
    default: print("Unknown size")
    }

    switch Device.type() {
    case .iPad: print("It's an iPad")
    case .iPhone: print("It's an iPhone")
    case .iPod: print("It's an iPod")
    case .Simulator: print("It's a Simulated device")
    default: print("Unknown device type")
    }
}

This example demonstrates the fallback behavior used by the README. The size example includes additional documented cases for 3.5, 4, 4.7, 5.5, 7.9, 9.7, 10.5, and 12.9 inch categories, while the version example covers individual phone, tablet, and iPod models. The README does not claim that the returned enum cases are exhaustive forever. Its model and size examples both use `default`, which is the important defensive choice when hardware recognition is incomplete or the application runs somewhere outside the expected device classes.

The listed version cases stop at devices introduced before later releases, although the 3.6.0 release note says "New Devices Added + Privacy updates." The documentation therefore should not be treated as proof that the displayed list is complete for 3.8.0. Inspect the repository's current enum and tests for every target model.

Device detection limits, maintenance, and MIT licensing

The main limitation is model recognition drift. Apple can introduce hardware identifiers that are absent from a fixed mapping, while the documented API centers on concrete model names and nominal display categories. An unknown fallback prevents a non-exhaustive switch from failing to compile, but it can also force application code to accept a generic case. That makes Device a poor dependency for decisions that should instead be expressed through operating-system versions, screen traits, or view geometry.

The repository is not archived, and the last push was on 2026-09-27. Version 3.8.0 was released on 2025-10-03, after 3.7.0 on 2024-10-20 and 3.6.0 on 2024-01-26. This history supports evaluating upgrades, but the README does not document a detailed migration process, backward-compatibility matrix, deprecation schedule, or supported-model checklist. Upgrade cost therefore centers on reviewing enum changes and new-device coverage.

The repository uses the MIT license. Applications can use, modify, and distribute the licensed code under the license terms, while redistribution commonly requires preservation of the license and copyright notice. This is a practical reading of the identifier rather than legal advice; an organization should inspect the actual `LICENSE` file for its obligations.

Editorial conclusion

Adopt Ekhoo/Device when a Swift application needs a compact, model-oriented classification API and can accept an unknown-device fallback. Do not choose it for behavior that should follow modern operating-system traits or responsive screen geometry. Before integration, verify that every target model appears in the current 3.8.0 switch, then confirm the chosen package-manager integration builds in the application's own Xcode project.

Frequently asked questions

Official sources

1. Ekhoo/Device on GitHub
2. Issues
3. License: MIT
4. README
5. Releases