Building the B&Q Mobile Apps:
A Journey Through Modern App Mobile Development
I previously wrote about my experiences building the TradePoint mobile apps as Principal Software Engineer. However, before that journey began, I was part of the programme that delivered the apps to the app stores. Time ran short over the summer of 2024 as we finalised the delivery of the new B&Q apps, preventing me from sharing this story earlier so consider this offering, the prequel to my TradePoint article.
The Rebuild — How It All Began
As recently as late 2022, already had a app presence on the app stores for both iOS and Android. Our initial brief seemed simple: deliver two new apps for , (B&Q’s traders wing), which had no app store presence at all. However, twelve weeks into the programme in early 2023, everything changed. In true software development fashion, we pivoted. The new direction? Rebuild the B&Q apps before creating the TradePoint apps, as Tennyson once wrote “ Theirs not to reason why”, a sentiment I’m happy to subscribe to in such matters.
Kingfisher PLC Mobile Apps — A Short History
The B&Q mobile apps first built in 2016, had morphed into a white-label solution to be shared across Kingfisher’s banners in France and Poland, the apps highlighted both the strengths and weaknesses of a centralised, multi-geographical approach. On one hand, a white-label solution provided a baseline of consistency and cost efficiency, allowing multiple markets to share foundational features and resources. However, the one-size-fits-all nature of the architecture proved increasingly difficult to adapt to the unique needs of the disparate markets across the EU.
Customising features for specific regions often involved lengthy development cycles and complicated approval processes, as all changes needed to align with the broader framework used by other countries. This centralised model also struggled to balance competing stakeholder requirements from diverse geographical markets. For example, features that resonated with customers in Krakow, Poland might not align with the expectations of UK customers in say Leamington Spa, creating friction in prioritisation and delivery.
As customer expectations evolved, the rigidity of the architecture slowed innovation significantly. Simple changes became disproportionately expensive and time-consuming, leaving the B&Q app unable to meet the fast-changing demands of its market. Ultimately, this revealed the inherent challenge of managing diverse stakeholder requirements within a centralised development function, where compromises often hindered local responsiveness and market-specific innovation.
Group Decentralisation Strategy
There was also a desire to shift from a wholly centralised approach to a more decentralised tech operating model, which marked a pivotal transformation in how we managed app development across Kingfisher’s banners, including B&Q. The centralised model, while arguably cost-effective and consistent, often struggled to accommodate the unique demands of diverse geographical markets. Local banners like B&Q found themselves unable to rapidly adapt their apps to meet the specific needs of UK customers.
Under the centralised system, all development decisions were funnelled through a core team, leading to prolonged development cycles and competing priorities among markets. Stakeholders from different regions frequently vied for resources, resulting in compromises that diluted the effectiveness of solutions for individual markets.
Decentralisation offered a solution. By empowering local banners to prioritise their own digital strategies, B&Q could tailor features and updates specifically to the UK market. This approach allowed teams to respond swiftly to customer feedback, experiment with new ideas, and iterate more rapidly, fostering a culture of ownership and innovation. For example, B&Q could independently roll out features like improved product search or streamlined checkout flows without waiting for alignment with other banners.
The Price of Independence
To strike a balance, we explored a hybrid model. Core platform elements, such as shared business logic through Kotlin Multiplatform and GraphQL APIs, remained centralised to maintain consistency and efficiency. Meanwhile, UI development and market-specific features were handled locally, enabling differentiation and faster execution. This hybrid approach would combine the best of both worlds: retaining efficiency at the group level while allowing individual banners to innovate and excel within their own markets.
Why Rebuild? A Tale of Technical Revolution
The B&Q apps of 2016 were a product of their time. Built with a mixture of early Swift and legacy Objective-C code for iOS and Java/Kotlin for Android, they required significant manual intervention to maintain. For example, creating something as basic as a product card involved juggling multiple files and verbose code. Developers had to contend with XML layouts for Android or Interface Builder for iOS, both of which added layers of complexity.
By 2022, however, the industry had moved on. SwiftUI, Jetpack Compose, and Kotlin Multiplatform (KMP) were proving out as more than trends but bona fide game-changers. These modern frameworks promised faster development, cleaner code, and greater flexibility. With these tools in hand, rebuilding the B&Q apps wasn’t just an upgrade — it was a chance to future-proof our mobile platform.
This wasn’t a decision we took lightly. Rebuilding an app is a significant investment of time and resources. But the potential benefits — from faster feature delivery to a better customer experience — made it a clear choice.
Interlude: The Anatomy of an eCommerce App
I spoke about the DNA of an eCommerce app, in this section I will explore the typical features and capabilities generally found in retail apps.
It’s sound advice to become well versed in the business in which you will be asked to deliver software, it sounds obvious but it still surprises me how many developers cruise through careers in IT without fully grasping the business eco-system they are employed within.
A successful retail app is much more than a simple exercise in promoting a brand. Multiple elements plays a vital role in creating a seamless shopping experience. Let’s explore the key features that make up a modern retail app.
Home Screen: The Digital Storefront
The home screen is the generally the first interaction on launch of an app and serves as a customer’s first impression and primary entry point. Like a well-designed store window, it needs to showcase current promotions, seasonal offerings, and popular products. This is where retailers highlight their best deals, new arrivals, and trending items. The home screen must balance promotional content with personalized recommendations, helping customers quickly find what’s relevant to them while also discovering new products they might like.
Navigation: The Store Layout
Just as physical stores need clear aisle signs and logical department layouts, digital navigation is crucial for helping customers find their way around. Modern retail apps require intuitive navigation patterns that help users move between categories, access their basket, and find important features like store finders or their account settings. The challenge lies in organising thousands of products and features in a way that feels natural and effortless to customers.
Search and Browse: The Digital Shopping Assistant
Search functionality is often the fastest path to purchase for customers who know what they want. Modern retail apps require sophisticated search capabilities that understand customer intent, handle misspellings, and provide relevant results. This includes features like autocomplete suggestions, recent searches, and the ability to filter results by various attributes like price, brand, or customer ratings. Browse functionality, on the other hand, helps customers explore categories and discover products they might not have been specifically looking for.
Product Listing Pages: A Digital Shelf
Whether reached through search, categories, or promotions, product listing pages are where customers compare and choose between similar items. These pages need to balance showing enough products to give choice with providing enough information about each product to make that choice informed. Smart filtering and sorting options help customers narrow down their options based on their specific needs.
Product Details Page: The Product Examination
This is where customers make their purchase decisions. Like picking up and examining a product in store, the product details page needs to provide all the information a customer might need: detailed descriptions, high-quality images, price, availability, specifications, and customer reviews. For home improvement products, this might include installation guides, required tools, and related items needed to complete a project.
The Basket: The Beating Heart of Retail Apps
The Basket or Cart in Americanised terminology is more than just a list of items — it’s a sophisticated system that manages the entire shopping session. It needs to handle scenarios like checking stock levels across multiple stores, applying promotional discounts, calculating delivery options, and maintaining state across devices. The basket needs to be easily accessible throughout the shopping journey while not being intrusive.
Authentication: The Customer Identity System
Modern customers expect a shopping experience, which starts with knowing who they are. The identity system needs to balance security with convenience, offering options like guest checkout for casual shoppers while providing enhanced features for registered users. This system forms the foundation for personalisation, order history, and saved preferences.
Checkout and Payments: The Digital Cash Register
The checkout process can make or break a sale. It needs to be streamlined yet secure, offering multiple payment options while ensuring transaction safety. Modern retail apps need to handle various payment methods, from traditional credit cards to digital wallets, while managing delivery slot booking, address verification, and order confirmation.
My Account: The Customer’s Hub
The My Account section serves as a customer’s personal home within the app. It’s where they manage their profile, view order history, save their favorite items, and maintain delivery preferences. This section needs to provide easy access to past purchases, saved lists, delivery tracking, and account settings. For retail apps, this section is crucial for building long-term customer relationships by providing a sense of continuity and personalisation across shopping sessions.
Bringing It All Together
Each of these elements must work in harmony to create a cohesive shopping experience. The success of a retail app often depends not just on having these features, but on how well they’re integrated and how seamlessly they work together. Just as a physical store needs to consider the entire customer journey, from entry to checkout, a digital retail experience must carefully orchestrate these components and their associated teams to create a smooth, intuitive shopping experience.
The diagram below depicts the teams that support the development, maintenance and capabilities of the Kingfisher PLC mobile apps.
Non-functional Considerations
Beyond customer-facing features, a modern e-commerce app requires a robust foundation of non-functional capabilities. Security plays a pivotal role in protecting the platform and its users. Bot detection and anti-hacking mechanisms ensure that automated threats are mitigated without impacting genuine user experiences. API gateways provide an additional layer of security and manage API traffic efficiently, ensuring consistent performance under high loads.
Analytics and monitoring are essential for maintaining the health and performance of the app. Tools for crash reporting and performance monitoring, like Firebase Crashlytics and Dynatrace, allow teams to proactively identify and resolve issues before they affect users. These systems are complemented by backend logging and real-time alerts to monitor API performance and identify bottlenecks.
Operational excellence is supported by well-coordinated support teams who oversee the smooth integration of all these elements. Collaboration between developers, DevOps engineers, and customer service teams ensures the app runs reliably and adapts to evolving requirements. For instance, incident management workflows enable swift resolution of production issues, minimising downtime.
Finally, integrating these non-functional components into the app requires rigorous coordination. Deployment pipelines, automated testing, and staged rollouts help deliver these capabilities without disrupting the customer experience. These measures ensure that the app remains secure, performant, and scalable, providing a reliable foundation for both customers and operational teams.
Deep Dive: A Technical Revolution (2016–2024)
To truly appreciate how far mobile development has come, let’s look at implementing a product listing screen — a fundamental feature of any e-commerce app. In 2016, this required coordinating multiple files and handling complex view recycling logic.
iOS (2016)
Here’s what a typical Product Listing Page (PLP), may look when written in Objective-C.
// ProductListViewController.h
@interface ProductListViewController : UIViewController <UITableViewDelegate, UITableViewDataSource>
@property (weak, nonatomic) IBOutlet UITableView *tableView;
@property (strong, nonatomic) NSArray<Product *> *products;
@end
// ProductListViewController.m
@implementation ProductListViewController
- (void)viewDidLoad {
[super viewDidLoad];
[self.tableView registerNib:[UINib nibWithNibName:@"ProductCell" bundle:nil]
forCellReuseIdentifier:@"ProductCell"];
[self loadProducts];
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return self.products.count;
}
- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath {
ProductCell *cell = [tableView dequeueReusableCellWithIdentifier:@"ProductCell"];
Product *product = self.products[indexPath.row];
[cell configureWithProduct:product];
return cell;
}
- (void)loadProducts {
// Network call to fetch products...
}
@end
// ProductCell.h
@interface ProductCell : UITableViewCell
@property (weak, nonatomic) IBOutlet UIImageView *productImageView;
@property (weak, nonatomic) IBOutlet UILabel *nameLabel;
@property (weak, nonatomic) IBOutlet UILabel *priceLabel;
- (void)configureWithProduct:(Product *)product;
@end
// ProductCell.m
@implementation ProductCell
- (void)configureWithProduct:(Product *)product {
self.nameLabel.text = product.name;
self.priceLabel.text = [NSString stringWithFormat:@"£%.2f", product.price];
// Image loading with third-party library...
}
@endOn top of this it wasn’t uncommon to use Interface Builder to design the interface containing dozens of lines of XML and constraint definitions.
<!-- Main.storyboard -->
<?xml version="1.0" encoding="UTF-8"?>
<document type="com.apple.InterfaceBuilder3.CocoaTouch.Storyboard.XIB" version="3.0" toolsVersion="14460.31" targetRuntime="iOS.CocoaTouch">
<scenes>
<!--Product List View Controller-->
<scene sceneID="tne-QT-ifu">
<objects>
<viewController id="BYZ-38-t0r" customClass="ProductListViewController">
<view key="view" contentMode="scaleToFill" id="8bC-Xf-vdC">
<rect key="frame" x="0.0" y="0.0" width="375" height="667"/>
<autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/>
<subviews>
<tableView clipsSubviews="YES" contentMode="scaleToFill" alwaysBounceVertical="YES" dataMode="prototypes" style="plain" separatorStyle="default" rowHeight="-1" estimatedRowHeight="-1" sectionHeaderHeight="28" sectionFooterHeight="28" translatesAutoresizingMaskIntoConstraints="NO" id="Xft-lZ-gH7">
<rect key="frame" x="0.0" y="0.0" width="375" height="667"/>
<color key="backgroundColor" white="1" alpha="1" colorSpace="custom" customColorSpace="genericGamma22GrayColorSpace"/>
<connections>
<outlet property="dataSource" destination="BYZ-38-t0r" id="data-source-connection"/>
<outlet property="delegate" destination="BYZ-38-t0r" id="delegate-connection"/>
</connections>
</tableView>
</subviews>
<color key="backgroundColor" red="1" green="1" blue="1" alpha="1" colorSpace="custom" customColorSpace="sRGB"/>
<constraints>
<constraint firstItem="Xft-lZ-gH7" firstAttribute="leading" secondItem="6Tk-OE-BBY" secondAttribute="leading" id="tableview-leading"/>
<constraint firstItem="6Tk-OE-BBY" firstAttribute="trailing" secondItem="Xft-lZ-gH7" secondAttribute="trailing" id="tableview-trailing"/>
<constraint firstItem="Xft-lZ-gH7" firstAttribute="top" secondItem="6Tk-OE-BBY" secondAttribute="top" id="tableview-top"/>
<constraint firstItem="6Tk-OE-BBY" firstAttribute="bottom" secondItem="Xft-lZ-gH7" secondAttribute="bottom" id="tableview-bottom"/>
</constraints>
<viewLayoutGuide key="safeArea" id="6Tk-OE-BBY"/>
</view>
<connections>
<outlet property="tableView" destination="Xft-lZ-gH7" id="tableview-outlet"/>
</connections>
</viewController>
<placeholder placeholderIdentifier="IBFirstResponder" id="dkx-z0-nzr" sceneMemberID="firstResponder"/>
</objects>
</scene>
</scenes>
</document>Now, let’s look at the same functionality in SwiftUI to create a PLP, which introduces several powerful design patterns:
iOS (2024)
struct ProductListView: View {
@StateObject private var viewModel = ProductListViewModel()
var body: some View {
List(viewModel.products) { product in
ProductRow(product: product)
}
.task {
await viewModel.loadProducts()
}
}
}
struct ProductRow: View {
let product: Product
var body: some View {
HStack {
AsyncImage(url: product.imageURL)
.frame(width: 100, height: 100)
VStack(alignment: .leading) {
Text(product.name)
.font(.headline)
Text(product.price.formatted(.currency(code: "GBP")))
.font(.subheadline)
}
}
}
}The contrast is striking. What once required multiple files and over 200 lines of code now takes just one file with 30 lines of clear code syntax.
All be it, a fairly generalised example, it brings home the modernisation of the languages leveraged in creating apps in 2024. The amount of code is greatly reduced, hence the amount of defects and time taken for execution and testing is minimised.
This SwiftUI implementation introduces several key design patterns that transform how we build UIs.
Data-Driven Views: Views are a function of their state. When data changes, the UI updates automatically.
Composition: Complex UIs are built by combining smaller, reusable views. Each view is a self-contained unit that can be tested and previewed independently.
Declarative Syntax: Instead of telling the system how to update the UI, we declare what we want it to look like. SwiftUI handles the rest, including efficient updates and animations.
Beyond the code reduction, the new architecture has brought significant performance enhancements and testability improvements and has been similarily mirrored across the Android versions of the mobile apps.
Orchestrating an eCommerce App
Rebuilding the B&Q apps has had a transformative impact on both the development process and the customer experience. By adopting modern frameworks and architectural patterns, we’ve created a system that can evolve with customer needs and market demands. Developers now spend less time on repetitive tasks and more time crafting meaningful features. This has not only improved internal efficiency but also the overall speed at which new features are shipped.
For customers, the difference is tangible, thanks no part in the opportunity taken by the in-house design team to upgrade the customer journeys and transitions. The app now offers a smoother, faster, and more reliable shopping experience. Whether it’s searching for a product, checking stock availability, or completing a checkout, interaction feel slicker more natural.
These improvements extend beyond the app itself. By integrating with backend for frontend systems like GraphQL and leveraging Kotlin Multiplatform, we’ve built a foundation that supports consistent behaviour across platforms while remaining adaptable to future innovations. As a result, the app is not just a tool for today but a scalable solution for tomorrow’s retail challenges.
This wasn’t just a technical project; it was a cultural shift in how we approach mobile development.
July 2024 — Delivering to the App Stores
It was in the summer of 2024 that we released the new B&Q apps to the Apple and Google stores. Unlike TradePoint, which were brand new apps to the App Stores, the B&Q apps landed as updates to the existing apps. The more astute may have noticed a bump up from the previous versioning of 9.x.x to 10.00.
Releasing new digital products into customer hands comes with its own risks. We mitigated these with a phased rollout and a back out plan.
When a new version is available, we don’t like to always make it immediately mandatory for a customer to download & install it. This meant an overlap for a period of weeks in supporting both the legacy and new versions of the apps. As the customer base slowly ticked up to 90% active users on the new versions, we mopped up the stragglers with a forced update, effectively sun-setting the previous generations of the B&Q mobile apps.
The Path Ahead
The retail landscape will continue to evolve, but with a modern, flexible architecture, we’re ready to evolve with it.
B&Q have moved into the arena of Marketplace, that is selling product of third party sellers, similar to the Amazon model, now millions of products are available to buy in the apps.
A key advantage of B&Q, over other marketplace retail apps, such as Temu, are the availability of physical stores, which allow same day collection based on availability, the time taken to purchase and have a product in hand is squashed into a few taps on a screen and a quick trip to local store.
The B&Q apps powered by the Kingfisher PLC engineering core now have a solid foundation to build upon. The framework and essentials of an eCommerce app are in place, this took the best part of 18 months to deliver. The journey doesn’t end there. The scene is set through iteration to build more purchasing nuances into the apps. It has been proven that customers that purchase through mobile apps tend to be more loyal and offer higher conversions, the next 18 months will be to consolidate and build on these customer experiences. The expected increase revenue will place the B&Q apps in a strong market position for the coming years. its satisfying to say the technology will not be the limiting factor in this period.
The process of conceiving, bootstrapping, building and delivering the B&Q apps, gave us a significant head start when it came to the TradePoint apps. By leveraging the code, technical solutions and people already in situ, we were able to turnaround the delivery of the TradePoint Apps in little over three months, which were released to the app stores in September 2024.
Thanks for sticking to the end, look out for more articles 2025. Contact me on for further insights.
If you would like to be part of the future of Kingfisher PLC engineering, take a look at our .
B&Q: Available on the App Stores
and
