It is not clear what your design constraints are for a solution, so I cannot give a complete answer. I can suggest the following lines of investigation (which are too long for a question-comment so placed here):
If you are looking at it from an attacker / security research perspective then what you could do is to try a custom URL scheme of a popular app, like TikTok, and see if that can be used to expose an application-specific vulnerability (data leak).
If you are trying your second option of specifying a port but are hitting the signing restrictions, then why not buy a DNS host, and use LetsEncrypt to get a proper SSL certificate for it. Then Safari will connect.
If you are trying to commence user engagement, write and deploy an iOS app that the user can install, and then trigger it via the Share Extension. Then you can get arbitrary JSON back from the handset.
There is evidence that browser developers might be able to deploy non-default WebKit experiences on iOS in the future, so there may be a way to add custom functionality there if the mobile browser lockdown policy is loosened. There are regulatory pressures going this direction so it is worth watching out for.
Historical note on Mobile Safari
It used to be the case that Mobile Safari could yield file contents back to the recipient via the Web Share API. It was a security vulnerability since fixed, but a detailed account of this and the relevant techniques employed are in the book The Road To Zero (I am the author.)