One caveat with my answer (applies to most of the others, too): I don't know the purpose of your application. If it is a throwaway application to troubleshoot one particular problem, or to understand networking better, never to be used again, then relying on the first letter of the interface may be a great quick-and-dirty option. If you are planning to write the next competitor to Wireshark or tcpdump, you need to be sure you get it right for all kinds of edge cases.
And if the application you are writing falls somewhere between those extremes, only you (and your customers) can know how carefully you need to implement your logic.
Others have already pointed out that the names are never reliable, for any number of reasons. The ultimate problem is a very common one in software: hard-coding assumptions instead of relying on known/documented facts.
The second issue that hasn't been mentioned is also based on an assumption about your requirements: that the list of interfaces you want to list is always exactly "hardware ethernet interfaces" and "wifi interfaces".
The third issue is yet another assumption: that all interface will fall into the categories you can think of right now. How about Infiniband, as mentioned by @user4556274? How about tunnel interfaces for a VPN? How about bridged interfaces? How about bridged interfaces that combine physical and logical interfaces?
But there may be options to accomplish what you are looking for. First, define exactly what characterizes an interface you want to list, vs one that you don't.
In most cases, one characteristic you can rely on is the routing table (however, this will only work as long as the interface is up, so it may not be what you are actually looking for).
Any interface that has a default route (i.e., a route to 0.0.0.0) is likely to be one you are looking for.
Note that even this is still based on an assumption, just a more reliable one: it is conceivable that a system is configured to route all outbound traffic through a virtual machine or a docker container (for instance, if there is a container running a firewall). And the reverse is also true: a sysadmin could potentially lock down outside traffic by deleting the default route.
Another option is to go by the actual hardware and see which driver it uses. You can then exclude certain well-known drivers