So I know a bit about how that data is packaged by the FAA and distributed, and what's required to create a *legal* IFR database.
First, as noted above, the charts and plates from SA are simply georeferenced images, NOT IFR approach data. That's what georeferencing is...the ability to precisely position an *image* with reference to real-world positions. If they wanted, they could georeference satellite imagery and use it, or ocean bathymetry, or anything, really. But there's no approach course information contained in the image itself. They're actually .png files, and you can load them into any image viewer if you want and edit away...this example is pasted in directly from the download folder SA uses on my computer (after a bit of editing in Paint
):
Second, the entirety of the National Airspace System data is, or at least was when I worked on aviation GPS receivers, available as ARINC datasets. One or more lines of data per item, where an item can be an airport, a navaid, a fix, an intersection, an airway segment, and on and on and on. The manufacturers develop their software to convert those gazillion entries to their database formats, and *that* software has to be certified, as well, and proven to accurately transform the data without error. Then, the software on-board (as well as the hardware) to read, display, select, manipulate and manage that data has to be certified.
An approach, in the ARINC format, consists of multiple lines of data which specify references to the entries for the fixes, the altitudes, airport, navaids, and so on. Those entries are somewhere in the database, not replicated for each approach or airway or whatever that uses them. So you can see this gets fairly complex (not overly so, but it's not like each approach in the database contains within itself everything about that approach). Same goes for SIDs and STARs.
That's in stark contrast to what, it appears, the Dynon Nav data contains: A single entry for everything it displays (granted, with a LOT of info on most of them, like airports), but not the higher-level structure.
Could Dynon create a certified GPS navigator, including the database? Sure, anybody can. But it's ***expensive*** and time-consuming, usually years of design, development, verification and validation, and certification.
The simple answer to your question "why Dynon has not coded the Skyview system to allow it to consume the position data from a "certified IFR Navigator" from one vendor, and the approach data from another vendor?" is that there
is no approach data from another vendor, if what you're referring to is the SA approach plates. (And just to be thorough, the CDI and GS display on the Skyview is getting that information from whatever certified IFR navigator you're using, via the ARINC box...it's not computing anything on its own. Check out the ARINC messages that your navigator is sending to it, and you'll see XTE and such in the set).
ETA: Let me also correct this statement: "If the FAA does not convert these approach plates to a format that can be used as a data file, then it would be up to individual vendors to do that". The FAA doesn't convert approach plates to a data file. They *start* with the data files, and then those are turned into data plates (images) either by the FAA or whatever the national cartographic service is these days. These then get published as the TPPs in PDF format. This is exactly the same thing Jepp does for their paper or electronic plates, AFAIK. (I believe the FAA TPPs are vector-based PDFs).