FedKit: Enabling Cross-Platform Federated Learning for Android and iOS

To enable model creation in Python, we begin by converting models into formats compatible with Android (TensorFlow Lite or TFLite) and iOS (Core ML). Core ML defines a fixed model structure and provides the official converter CoreMLTools. For TFLite, we standardized a model format, and then developed a compliant TensorFlow converter. This standardized format includes four essential FL methods (train, infer, parameters, and restore).

FedKit provides TFLite Trainer and Core ML Trainer to train the converted models on Android and iOS devices, utilizing GPU and NPU acceleration. Moreover, both trainers expose unified APIs for retrieving and setting model parameters, model fitting, and evaluation. On Android, these APIs invoke the TFLite interpreter to call our standardized methods defined in Model Conversion. However, on iOS, our experimentation revealed that Core ML forbids directly setting parameters, which could impede FL. To overcome this constraint, we apply a mostly undocumented method that modifies the underlying ProtoBuf representations of Core ML models. Specifically, we employ Swift code generated from the relevant ProtoBuf definition files, and navigate nested model definitions to access parameters on iOS. Consequently, our unified training APIs exhibit comparable functionality on both iOS and Android platforms.

Aggregation necessitates uniform parameter representations, posing primary challenges in retrieving and setting parameters for Core ML and TFLite. 1) Core ML permits only specific layers to be updatable and only provides their parameters post-training. Thus, to obtain other layers’ parameters, we implemented a solution using ProtoBuf manipulation. This approach involves recording layer information in Model Conversion and utilizing it during training. 2) The TFLite interpreter only accepts inputs/outputs as maps from names to tensors. Therefore, during Model Conversion, we assign index-based names to each parameter layer and dynamically generate the concrete methods that accept these arguments. During training, we call the methods with these index-based names to access parameters. Finally, these unified parameters enable seamless cross-platform aggregation.

Traditionally, models for on-device training are embedded into client apps. However, this approach couples model delivery with app updates, resulting in complexities when submitting apps to app stores and garnering user adoption.

Circumventing this complexity, FedKit enables continuous model delivery without app updates by decoupling models from clients through Model Request, which allows new model deployment by uploading to the Backend. Specifically, clients request the Backend for a model (TFLite/Core ML) aligned with their platform (Android/iOS) and training data type. The Backend selects the appropriate model $M$ from the database and responds with detailed model information. Consequently, Model Request delivers the TFLite or Core ML model to clients for FL training.

FedKit manages continuous FL training by allowing multiple parallel FL training sessions through FL Server Setup. When clients request an FL Server to train their chosen model $M$, the Backend either reuses a suitable FL Server $S_{\mathrm{F}}$ if it exists, or spawns a new one. Each FL Server operates as an independent Python subprocess of the Django Backend, occupying its own port that clients connect to for FL Training. This dynamic approach ensures that newly delivered models can be immediately trained with new FL Servers without affecting ongoing ones. Furthermore, these FL Servers employ the Flower FL Framework [4] for scheduling training and evaluation. This decision empowers our FL Servers to leverage Flower’s flexibility and allow for FL algorithm customizations in Python.