An instance of MobileFormatter is created in ApiMobileView.php, ApiParseExtender.php and includes/MobileFrontend.body.php

There is lots of overlap in the work they do.
The code in includes/MobileFrontend.body.php does work inside MobileFormatter that is repeated by ApiMobileView.php

I see several possible improvements here that could be made by distangling these two things.

• There is memcached caching inside ApiMobileView.php - let's move this to MobileFormatter. If you view a page Foo in the mobile site and then request it via the API, the same code should not be run again - they should share a cache.
• The code for creating the structured data entity should be moved to MobileFormatter to allow the SkinMinerva to use it.
• Skins should be generated via the structured data entity rather than stitching and calculating data themselves. The API does additional processing to split the page into sections and provide a nice JSON of all the information needed to render a page. This would be extremely useful for the skin which duplicates a lot of this logic (for example it checks whether a page has languages and it should render a language button, it relies on the HTML output to construct its sections.
• Edit icon rendering should be moved out of the MobileFormatter and into the Skin. This would bring us more in line with how apps do this.
• For development purposes and to encourage us to be consistent with the mobile content service, the MobileFormatted API should be consistent in output and interchangeable. As demonstrated by the POC patch we should be able to use real world content on our local development wikis by doing this.
• In future we may want to experiment with using the mobile content service for all requests

Composer library?

As HtmlFormatter has been moved to a composer library, in order to make MobileFrontend leaner, and improve the consistency of the api, modularity and quality of the formatter, we want to extract it to a composer library.

Overview

• Create composer package with boilerplate
  • Get it into CI
  • Migrate MobileFrontend's code and tests to the library
    • Decouple from MobileFrontend's globals and code
    • Thoroughly document changes for later migration
  • Ensure library is continuously tested and works well
• Swap implementation in MobileFrontend for the composer library
  • Security review?
  • Verify all is well
• Iterate on mobile formatter to improve the quality of the code
  • Make the external api consistent (for example, use constructor configuration everywhere instead of using some times setters and some times not, etc)
  • ...