We have a customer, let's call them ABC123 Ltd, who have an existing website on abc123.ie hosted by some hosting provider or other. It's just an informational site with no login\commerce function so currently just runs over HTTP.
Just because it's an information site does not mean it shouldn't be using HTTPS. There are security and privacy reasons to do so, but there are other reasons as well, including getting referral information from HTTPS pages and not being penalized in Google search results.
They now want to implement a web application that will be hosted on-premises under IIS. They will be communicating with this web application using an Android app on tablets, via an IP address and port (the customer has a static external IP).
Using an IP makes life more complicated. As you've seen, it's not a common setup to run TLS without a hostname. It also reduces operational flexibility - it's much easier to switch traffic to a different server when using DNS, which is something you'd want to do while recovering from a machine failure, or while rolling out a new machine, or doing a canary, or for overriding the app to talk to a development server, or any number of other things.
Since they've already got a domain, they can tack on a subdomain to that if they want, or use a new one for internal traffic. If you're concerned about making internal IP addresses visible (but not visitable) externally through DNS records, you can add the record only to the LAN DNS server.
Since you control the clients, you may also consider using client certificates to control access to the service.