Approach
We treated GH2 as an unstable integration surface and GH1 as the production baseline, then designed for one core and two shells. Business logic lives in a shared library independent of Grasshopper host APIs. Components are unified behind base classes and adapters that map GH1/GH2 differences in structures, trees, and component contracts. Data and UI are harmonized with wrappers and interfaces so algorithms do not branch on platform details everywhere. Compile-time targeting (#if / symbols) builds and tests against GH1 or GH2 quickly as APIs changed.
This kept iteration fast while GH2's API evolved, and limited rework when Karamba3D features needed to land on both versions.
Solution
Decoupled architecture - Core algorithms live in a self-contained library referenced by separate GH1 and GH2 plugin projects. Platform code handles registration, parameters, and canvas behavior; structural and analysis logic stays shared.
Component unification - A unified component system uses base classes and wrapper layers to absorb API and data-structure differences (for example GH_Structure vs Tree), with conditional compilation for platform-specific paths where adapters are not enough.
UI and data structures - Unified interfaces for UI widget management plus a custom DataTree wrapper to align GH1 and GH2 tree handling, so downstream components consume a consistent model.
Adaptability and testing - Build profiles switch GH1 vs GH2 at compile time, enabling side-by-side validation and rapid retargeting when GH2 broke or renamed APIs - essential without published SDK guidance.