The problem with 10bit H.264 is generally a problem of the hardware decoder manufacturers not wanting to pour money into something that is very much niche in their opinion (they generally tend to be
very stingy on the ASICs anyways). This will most probably continue in the future as well, as HEVC/H.265 already has people wanting to add "best-effort" decoding clauses (
link) to the new standard. And then there's just the problem that ARM isn't exactly as powerful per-clock when compared to "traditional" IA32/x86_64 hardware.
Handbrake is indeed probably one of the best GUI encoders around, but I haven't checked its hardsubbing capabilities as of late. If they're fine, then it and its command line interface of course are quite usable.
Another example I'd like to bring on the table is actually
mpv, the latest in the line of mplayer forks (mplayer2 has more or less died out, most of its developers having moved to mpv). Windows builds are being built by lachs0r and provided
here. It also contains the encoding capabilities coded by divVerent, the documentation for which are
here. Only problem is that it currently cannot do (at least according to the documentation) stream copying of the audio if you wanted to do that.
And some general hints that apply to both pieces of software:
You will want most probably to use a fast x264 preset ('superfast' or 'fast'; both handbrake and mpv should let you set one), and a CRF value that you deem as a good compromise between your eyes and how much it takes space. Start with 23 and go down if it looks bad on the device, or up if it looks good. The highest number that still looks good enough is what you'll be using.
Everything since the (iPhone) 3GS in the Apple sphere supports high profile and level 4.1, so that should not you limit much if at all. If you are encoding for some other devices as well, you might want to see their limitations regarding profile and level, and modify your settings accordingly.