On Host Names

For important background information, read Extra-ordinary Networking before reading this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

On Host Names

I commonly see questions like How do I get the device’s host name? This question doesn’t make sense without more context. Apple systems have a variety of things that you might consider to be the host name:

• The user-assigned device name — This is a user-visible value, for example, Guy Smiley. People set this in Settings > General > About > Name.

• The local host name — This is a DNS name used by Bonjour, for example, guy-smiley.local. By default this is algorithmically derived from the user-assigned device name. On macOS, people can override this in Settings > General > Sharing > Local hostname.

• The reverse DNS name associated with the various IP addresses assigned to the device’s various network interfaces

That last one is pretty much useless. You can’t get a single host name because there isn’t a single IP address. For more on that, see Don’t Try to Get the Device’s IP Address.

The other two have well-defined answers, although those answers vary by platform. I’ll talk more about that below.

Before getting to that, however, let’s look at the big picture.

Big Picture

The use cases for the user-assigned device name are pretty clear. I rarely see folks confused about that.

Another use case for this stuff is that you’ve started a server and you want to tell the user how to connect to it. I discuss this in detail in Showing Connection Information in an iOS Server.

However, most folks who run into problems like this do so because they’re suffering from one of the following misconceptions:

• The device has a DNS name.

• Its DNS name is unique.

• Its DNS name doesn’t change.

• Its DNS name is in some way useful for networking.

Some of these may be true in some specific circumstances, but none of them are true in all circumstances.

These issues are not unique to Apple platforms — if you look at the Posix spec for gethostname, it says nothing about DNS! — but folks tend to notice these problems more on Apple platforms because Apple devices are often deployed to highly dynamic network environments.

So, before you start using the APIs discussed in this post, think carefully about your assumptions.

And if you actually do want to work with DNS, there are two cases to consider:

• If you’re looking for the local host name, use the APIs discussed above.

• In other cases, it’s likely that the APIs in this post will not be helpful and you’d be better off focusing on DNS APIs [1].

[1] The API I recommend for this is DNS-SD. See the DNS section in TN3151 Choosing the right networking API.

macOS

To get the user-assigned device name, call the SCDynamicStoreCopyComputerName(_:_:) function. For example:

let userAssignedDeviceName = SCDynamicStoreCopyComputerName(nil, nil) as String?

To get the local host name, call the SCDynamicStoreCopyLocalHostName(_:) function. For example:

let localHostName = SCDynamicStoreCopyLocalHostName(nil) as String?

IMPORTANT This returns just the name label. To form a local host name, append .local..

Both routines return an optional result; code defensively!

If you’re displaying these values to the user, use the System Configuration framework dynamic store notification mechanism to keep your UI up to date.

iOS and Friends

On iOS, iPadOS, tvOS, and visionOS, get the user-assigned device name from the name property on UIDevice.

IMPORTANT Access to this is now restricted. For more on that, see the documentation for the com.apple.developer.device-information.user-assigned-device-name entitlement.

There is no direct mechanism to get the local host name.

Other APIs

There are a wide variety of other APIs that purport to return the host name. These include:

• gethostname

• The name property on NSHost [1]

• The hostName property on NSProcessInfo (ProcessInfo in Swift)

These are problematic for a number of reasons:

• They have a complex implementation that makes it hard to predict what value you’ll get back.

• They might end up trying to infer the host name from the network environment.

• The existing behaviour is hard to change due to compatibility concerns.

• Some of them are marked as to-be-deprecated.

IMPORTANT The second issue is particularly problematic, because it involves synchronous DNS requests [2]. That’s slow in general. Worse yet, if the network environment is restricted in some way, these calls can be very slow, taking about 30 seconds to time out.

Given these problems, it’s generally best to avoid calling these routines at all.

[1] It also has a names property, which is a little closer to reality but still not particularly useful.

[2] Actually, that’s not true for gethostname. Rather, that call just returns whatever was last set by sethostname. This is always fast. The System Configuration framework infrastructure calls sethostname to update the host name as the system state changes.