Change Details

Our new explore behavior will at least partially (but possibly heavily) touch WMFAppViewController, which is a legacy Objective-C class that is difficult to maintain. There are two parts to this task, each should be estimated separately: 1. [3] Port WMFAppViewController.m over to Swift, but do not change the method ordering or refactor to Coordinators. You may delete dead code but otherwise, maintain the same methods and ordering. This is so that it is easily review-able in a PR. 2. Unify WMFAppViewController and WMFAppViewController+Extensions methods. Refactor WMFAppViewController feature-specific logic into coordinators. We want each of the 6 root tab views (Explore, Places, Saved, Activity, Search, and Settings when Explore is turned off) to instantiate through their own coordinator class. There are also other feature-specific handling methods which should live in a coordinator (for example, the WMFWatchlistDelegate methods). Once complete, ensure no regressions occur with the launch sequence and deep linking. ### Eng Notes - Tab Coordinator, which holds onto array of root feature coordinators - Ensure these coordinators are retained correctly, watch out for retain cycles.

Our new explore behavior will at least partially (but possibly heavily) touch WMFAppViewController, which is a legacy Objective-C class that is difficult to maintain. There are two parts to this task, each should be estimated separately: 1. [3] Port WMFAppViewController.m over to Swift, but do not change the method ordering or refactor to Coordinators. You may delete dead code but otherwise, maintain the same methods and ordering. This is so that it is easily review-able in a PR. 2. [5] Unify WMFAppViewController and WMFAppViewController+Extensions methods. Refactor WMFAppViewController feature-specific logic into coordinators. We want each of the 6 root tab views (Explore, Places, Saved, Activity, Search, and Settings when Explore is turned off) to instantiate through their own coordinator class. There are also other feature-specific handling methods which should live in a coordinator (for example, the WMFWatchlistDelegate methods). Once complete, ensure no regressions occur with the launch sequence and deep linking. ### Eng Notes - Tab Coordinator, which holds onto array of root feature coordinators - Ensure these coordinators are retained correctly, watch out for retain cycles.

Our new explore behavior will at least partially (but possibly heavily) touch WMFAppViewController, which is a legacy Objective-C class that is difficult to maintain. There are two parts to this task, each should be estimated separately: 1. [3] Port WMFAppViewController.m over to Swift, but do not change the method ordering or refactor to Coordinators. You may delete dead code but otherwise, maintain the same methods and ordering. This is so that it is easily review-able in a PR. 2. [5] Unify WMFAppViewController and WMFAppViewController+Extensions methods. Refactor WMFAppViewController feature-specific logic into coordinators. We want each of the 6 root tab views (Explore, Places, Saved, Activity, Search, and Settings when Explore is turned off) to instantiate through their own coordinator class. There are also other feature-specific handling methods which should live in a coordinator (for example, the WMFWatchlistDelegate methods). Once complete, ensure no regressions occur with the launch sequence and deep linking. ### Eng Notes - Tab Coordinator, which holds onto array of root feature coordinators - Ensure these coordinators are retained correctly, watch out for retain cycles.