It appears that this branch/PR contains 3-4 types of changes:

1. Code cleanup & minor functional changes that have subsequently been done in master. Thus, merging master into this branch will make those differences go away.
2. Moving large chunks of code (mostly whole functions, but in a few cases, pulling existing functionality out of functions in Manager and creating new functions in KeymanWebViewController.
3. Changing the relative order of many of the moved functions (which might be more logical, but makes it much harder to see what actually changed using Diff. I have attempted to create some diff-able temp files where I have put the moved functions back in the original order, but because of (1), it is still difficult to diff them well.).
4. Possibly other significant functional changes that are obscured by the other changes (which is the point of doing a diff).
   Since this claims to be a "refactor", what we want/need to know is whether there are any changes that fall into category 4. If not, then we merely need to judge the merits of the move (2) and reorder (3).

After a couple failed attempts to try to merge all the changes on master into this branch and resolve the conflicts, I'm going to punt for now. There are two possible ways forward, and it's not clear which one will be easier and less error prone:

1. Merge master into this branch. Since there are significant conflicts (currently 11 chunks where changes on master occurred in code that is being deleted or moved), I think the best strategy for resolving them is to look through the history for the past several months, one commit at a time to understand the individual changes. Wherever they affect code that is moving, make the corresponding changes in the code in KeymanWebViewController. Then resolve all conflicts (I think it will be easiest to do this manually in XCode) by deleting the moved bits and keeping the change bits.
2. Abandon this branch and create a new one with the same purpose, based off the current version of master. Apply the changes manually from each of the commits done on the original branch. Though it might be harder to keep track of everything, I think it might be easier/better to do one PR where nothing is functionally changed, just to move all the functions in Manager into a single place in the file, ordered as they will be in KeymanWebViewController. That will be "hard" to review, but as long as we can guarantee no actual code changes were made, we can accept the change. Then a separate PR can be done where all those functions are moved and the necessary changes are made to get it to compile. At least then it will be possible to diff the affected chunk of code by pasting the deleted chunk into a file and the added chunk into a file and comparing the two files to see the actual code changes.

Turns out that this will be quite useful for moving forward with #1045, so I took the time to figure out the merge. I've gotten it working for the most part, though in-app rotation isn't exactly in the best condition at times. Of course, that's exactly what #1045 seeks to address. (It does appear to cause significant in-app regression at present, while the system keyboard seems fine.)

There are a few small parts of the in-app keyboard that need to be worked out in advance - sometimes swapping a keyboard in-app will cause the keyboard to completely disappear. (It can then be refreshed from selecting an alternate view, like the "info" or "getting started" views.)

I think I'd like to see the disappearing keyboard in-app resolved before we go ahead with a merge of this.

@mcdurdin Did you test it and see this still happen? I added code to help prevent that, and it's not been occurring since the last commit for me.

@jahorton no -- I was going off your comment :)