In Norway, a growing number of waste bins don't open with a key. They open with a phone. A resident taps a button in an app, an electronic lock clicks open, and the system knows exactly how much waste that household has thrown away, because the billing model is pay-as-you-throw.
I've been leading the development of this system for several years now, working with Fieldata, a Norwegian software development company. Fieldata has the direct relationship with the end client, a waste management company, and ALLWIN builds the product alongside Fieldata's own team. The mobile app that opens those locks is what I want to talk about, since it's a good example of what cross-platform development actually looks like when there's no shortcut available.
We'd already solved this exact problem once before, with a Progressive Web App that let service staff open the same electronic locks. It worked well. But around the time we needed to bring this functionality to consumers, Apple was signaling that it might drop PWA support entirely. For a feature aimed at the general public, that risk was not acceptable.
Fieldata's entire technology stack runs on Microsoft technologies, so .NET MAUI was the natural fit for a native, cross-platform alternative. The only problem: while we had experience with Xamarin, MAUI is a flavor that we haven't tried in production apps before.
I started where most people start with an unfamiliar framework: tutorials, YouTube, official docs. The basic app structure, navigation, and overall architecture ported over quickly. MAUI is well-documented for the fundamentals, and a lot of the patterns translate directly from other XAML-based frameworks.
Where it got difficult was permissions. Bluetooth and location access behave differently across Android API versions, and the documentation for it is scattered across many different sources, so it's a lengthy puzzle to put together. Getting consistent behavior across device versions took real trial and error.
iOS brought a different version of the same problem, on the deployment side instead of the runtime side. Getting a MAUI app signed, built, and reliably published to the App Store through Azure DevOps pipelines is its own puzzle of certificates, provisioning profiles, and platform quirks that have nothing to do with the app's actual logic.
Tamás Tárnok, our Platform Engineering Team Lead, wrote up exactly how we approached that part of the puzzle: MAUI iOS Azure DevOps pipelines, build and publish for App Store review.
And then there was the part with no tutorial at all: building a reliable connection between a physical IoT lock and the cloud. This is not your everyday app. If you expect AI to solve it for you, you are in trouble. We had to design and test the communication layer from scratch, with the lock's real-world behavior as our only feedback loop.
"You can follow a tutorial for the UI. Nobody has a tutorial for getting a physical lock and a cloud backend to agree on what just happened."
Before that physical lock ever reached my desk, we solved this problem a different way. For a while, there was a laptop sitting on a test bench in Trondheim, wired up to the actual locks. I would remote desktop into it from Hungary, running my code locally and reaching the real hardware through that laptop's Bluetooth connection to the lock. It worked, for a while.
It stopped working once development reached the point where the app needed to behave identically on both Android and Apple devices. Testing two platforms through a single remote laptop, over a Bluetooth connection, several thousand kilometers away, became unsustainable fast. We needed an actual lock on Hungarian soil, and shipping one through customs the normal way would have taken about three weeks. We didn't have three weeks. Our co-founder happened to be heading to a client visit in Trondheim around that time, so he simply brought a lock back with him personally. From there, Fieldata forwarded it to our Budapest office, and our back-office team sent it on to me in southern Hungary.
A few days later, I had a real IoT lock sitting on my desk, ready to be wired into the system I was building hundreds of kilometers from both Fieldata and our own headquarters.
It's a small logistical detail, but it says something about how this partnership actually works. Distance isn't an obstacle we work around. It's a problem we just solve, whatever that takes. If a piece of hardware is sitting three weeks out at customs and a developer needs it now, someone finds a faster way, even if that means a co-founder carries it through an airport personally. That kind of commitment is, in my experience, what actually keeps a T&M project running smoothly for years rather than just shipping one lock once.
Here's the part worth being honest about. At the time we built this, AI tools weren't particularly strong with MAUI. It's a smaller, less-documented ecosystem compared to more mainstream frameworks, and the coding agents available back then weren't as mature as they are now. Building the MAUI implementation from zero, with AI as a guide, was slow going.
What actually worked was different. We already had a complete, working implementation of this exact feature in JavaScript, from the earlier PWA version. Instead of asking AI to build a new MAUI implementation from scratch, I used it to bridge the gap between languages and architectures: translating the logic we already knew worked into the native platform's patterns and idioms.
That distinction matters. AI didn't write new logic for us so much as help us carry forward logic we'd already validated, into a technology stack we hadn't used before. That's a narrower, more reliable way to use the tool than asking it to invent something from nothing. It accelerated work we'd already figured out, instead of guessing at work we hadn't.
Fieldata's end client plans to roll this out to the general population in Norway, with potential expansion into other European markets. We're talking about hundreds of thousands of users, potentially scaling into the millions. The app replaces a physical RFID key that residents previously had to carry separately. That's one less thing to lose, and one less piece of hardware to issue and replace.
And it's a foundation, not a finished product. The roadmap includes features like real-time container fill-level visibility, personal usage statistics, and cost tracking. All of these become possible once the lock, the app, and the cloud are reliably talking to each other.
Cross-platform frameworks are well-documented for the 80% of an app that looks like every other app: navigation, layout, basic data binding. The other 20% is different. That's the device-specific permission quirks, the hardware-to-cloud communication, anything that touches the physical world. It's where the real engineering happens, and where no amount of tutorials or AI code generation will save you.
That's also where experience compounds. The reason this project moved as fast as it did wasn't a new framework or a smarter tool. It was a JavaScript implementation we'd already built and trusted, carried forward into a new technology with the right kind of help at the right moment.
.jpeg)