Building iFood's iOS Cart Experience
Article Summary
iFood's iOS team built a checkout system that handles 25+ feature plugins without turning into spaghetti code. Here's how they architected a platform that lets multiple teams ship independently.
iFood, one of Latin America's largest food delivery platforms, rebuilt their iOS checkout as a plugin-based architecture. Their engineering team needed to support dozens of features from different squads while keeping the codebase maintainable and the user experience seamless.
Key Takeaways
- Plugin architecture supports 25+ independent features with unique business logic
- Remote config controls plugin composition without requiring app releases
- Observer pattern enables cross-plugin communication via NotificationCenter
- VIP architecture keeps plugins testable and prevents massive view controllers
- Hardcoded fallback configs ensure checkout works when services fail
iFood's plugin-based checkout lets multiple teams ship features independently while maintaining code quality through strict protocols, remote configuration, and comprehensive documentation including RFCs.
About This Article
iFood's checkout needs to handle restaurants, groceries, and express orders all in one system. Features interact in complex ways, and the team has over 25 plugins to manage. They needed a structure that wouldn't duplicate code across plugins and could still be tested properly.
Leo's team built a plugin architecture using Swift UIKit with the VIP pattern. Each plugin follows PluginProtocol and gets State Providers and Bridges injected into it. This lets different teams work on plugins independently without creating tight dependencies.
Multiple squads can now ship features on their own schedule using remote configuration to compose the checkout. The system has hardcoded fallback structures built in, so checkout keeps working even if backend services go down or remote configs fail to parse.
