-
Did developers ever really push Apple’s on-device Foundation Models anywhere near their actual potential? A lot of the discussion around Apple Intelligence focused on Siri not feeling competitive enough. There were even rumors that Apple’s AI lack of strength played a role in the leadership transition to John Ternus. We don’t dismiss a race car because…
-
At some point in every project, someone asks “how hard would it be to add X?” The answer to that question is a direct measurement of how well the codebase was designed. Take the Smart Kitchen app for example. In a tightly coupled, monolithic app, adding a new feature would have meant digging through one…
-
Accessibility is often treated as a compliance checkbox — something you add at the end of a project because someone in legal asked for it. That framing misses why it matters. Approximately 15% of the world’s population lives with some form of disability. In the context of an iOS app, that means users who are…
-
When you unbox a smart appliance and set it up for the first time, something that feels like magic happens: your phone finds the device, connects it to your home WiFi, and suddenly you can control it from anywhere. But this process has an interesting problem at its core. The appliance needs your WiFi password…
-
Shipping an app is not the end of the story. It’s the beginning of a question: is it working? For consumer apps, “working” means users aren’t hitting errors, flows are completing, and the app isn’t doing something unexpected in the wild that you never caught in testing. For an IoT app specifically, it also means:…
-
Unit tests are only useful if they’re fast and reliable. A test that takes 10 seconds because it’s hitting a real server isn’t something you run on every code change. A test that fails randomly because the server was temporarily unreachable isn’t something you trust. A test that only passes when your laptop is on…
-
The Single Responsibility Principle says a class should have one reason to change. It’s easy to agree with in the abstract and surprisingly hard to apply when you’re building something real. When this app was first designed, the obvious approach was one DeviceViewModel responsible for everything: loading devices, managing oven state, managing fridge state, managing…
-
HTTP is a request-response protocol. Your app asks, the server answers, the connection closes. That’s perfect for most things — logging in, submitting a form, fetching a list of devices. But it breaks down the moment data on the server changes continuously and your app needs to know about it immediately. For an IoT app…
-
Before reactive programming was common in iOS, updating a UI worked like a conversation where you did all the talking. You’d call a function to load data, store it somewhere, then manually tell the UI to refresh. If data could change again later, you’d set up a timer and poll — checking every few seconds…
-
Every class needs things to do its job. An oven ViewModel needs a network client to call the API. A fridge ViewModel needs to know when a door has been open too long, which means it needs a way to send notifications. A login screen needs something to authenticate against. The naive way to get…