Embedded ignoring mobile view styling overrrides

In case this is ever of use to someone else experiencing similar problems with mobile layout in PowerBI embedded, I'm copying below my internal summary of the Pro's and Con's and what our approach will be moving forward.

Mobile Layout pro's: 

• The same elements (charts, tables etc) are shared with the Master layout so if updated in one place (i.e. variables changed) it will automatically be fixed in the other layout. 
• Erm... that's it 

Mobile Layout con's: 

• Embedded does not support dynamic config change from Master to MobilePortrait layouts, you can only switch between MobileLandscape and MobilePortrait (and only if the initial config used in the load() call uses one of those options). This seems arbitrary. 
  • MobileLandscape layout is the same as the Master layout but page view settings (fit to page, fit to width etc.) are ignored and fit to width is always applied so you will frequently need to scroll down to view the whole page. 
  • MobilePortrait layout is also always fit to width. No control for us ISVs! 
  • Mobile layouts seem always to render with a small margin down the right-hand side, even if no space bar is visible, making the whole canvas slightly off-center. 
  • In theory you could setup events to unbind and reinitialise the embed from scratch each time you want to change layout (e.g. from MobilePortrait to Master when a phone is rotated) but you'll lose any filters applied or any other programmatic changes and of course you'll have a horrible delay. 
• PowerBI Desktop / Service allows you to override the styling of individual elements in a mobile layout, e.g. button corner radius, border width, legend position on a chart or even abbreviate some text in a box. This works in Desktop and in the PowerBI mobile app but these overrides are completely ignored when embedded – you are stuck with the Master page styling and only see the elements moved and resized. 
• You have no flexibility to re-arrange your pages – you can only re-use elements from the same Master page on the mobile layout of that page. That's not always the ideal UX and the temptation is then to duplicate elements across Master pages so you can use them where you want in your Mobile layouts, but of course this defeats the only (minor) advantage of Mobile layouts in the first place.
• Embedding with Master layout into a hidden div (while you wait for it to load) works fine, but this technique mysteriously breaks in mobile layouts and causes the PowerBI canvas inside the iframe to be rendered incorrectly outside the viewport and neither visible nor accessible ("missing top half of page in embedded mobile view") is the common symptom. The alternative approach of 'hiding' the div at a very negative absolute position (off viewport) might work – not tested. 

There may be other con's that I can't remember from the wasted couple of days of my life but that should be enough to convince anyone whose primary concern is the best user experience in an embedded scenario. Really, if you're a PowerBI embedded developer, the ONLY case where using mobile page layouts makes any sense is where you also need your report to be accessible via PowerBI mobile app (even then I'd argue it may be unwise to try to multi-purpose like this). If you're focussed on embedded, you will always have more control to deliver a better user experience by creating a set of 'Desktop' master pages and a set of 'Mobile' master pages in the same report, then use your own application code to control which are shown and which are hidden dynamically. 

We will use 16:9 ratio pages in fit-to-page for all landscape vewports, and 1:2 ratio pages in fit-to-page for portrait orientation when viewport width drops below about 570px (based on our own ux testing). Using this approach: 

• We retain control of the user experience and avoid scrolling (no-one like scrolling, data can be missed if users have to scroll to find it, and this also allows us to position nav buttons at the bottom of the page like many mobile apps) 
• We can easily switch between landscape and portrait views by showing/hiding pages when devices are rotated or the browser window is resized, without re-loading the PowerBI or losing any filters applied to the report. 
• We can style portrait ('mobile') views exactly how we want including changing which elements appear on which page if it makes the user experience better.
• The downside is we have to maintain more elements (charts etc) when we make changes to the data model or when there is a new requirement.

We encode 'fallback' instructions into the page names so they are structured a bit like: 

POR/LAN#PageNumToSwitchTo#DisplayName 

Each page identifies itself as Portrait or Landscape and identifies which page in the report our application should switch to if the orientation is changed. We use DisplayName for our own external navigation and display purposes. 

For our needs this approach will work fine but it is disappointing that Embedded is behind the broader PowerBI feature set (or is actually broken in some cases) and does not provide the control that application developers should be able to expect. We pay a lot for our premium embed capacities and I think we should be able to expect better than our second-class citizen status!