This week I’ve been thinking about...
This week my team discussed how to maintain our UI tests and what alternatives could help us write fewer of them. One interesting option in this issue is to delegate testing to AI agents. The idea has potential, but non-deterministic results and around $100+ for one run of 200 test cases are hard to accept for now 😅
Also, Apple announced the Swift Student Challenge, and the prep includes a session on agentic coding. So can students build their projects with AI? If so, we might see some really cool projects. The code may not be perfect, but the focus will shift from what you can code to what you can come up with. Still, is it fair to judge a project when an agent wrote the code, not the student? At work, we know the responsibility is always on the engineer, but here there’s no responsibility, only authorship... 🤔
What’s New
If you are a student and not working as a full-time developer, this is a great chance to try yourself. You can build your project for any Apple platform. Submissions are open from February 8 to 28, 2027.
Events like this are a great way to test your skills and make new connections. The prize is a trip to Cupertino for WWDC, or one year of the Apple Developer Program for free.
Releases
Must Read
I’ve been thinking about using AI for testing too, and with Xcode’s MCP we can now delegate some manual testing to an agent. Here the author runs around 200 test cases in about 2 hours, and one full run costs $120, which is a lot tbh...
And yeah, the results are not deterministic. That’s why I still prefer native UI tests. My team has around 150-200 UI tests, and they are pretty reliable. I’d say that agent testing is a good option when you have no automated tests or need a quick smoke test.
One possible advantage of this kind of test is that the agent interacts with your app the way a real user does, while UI tests rely on accessibility identifiers, which is not how users see the app.
MVC, MVP, MVVM, VIPER Which Ones Matter for SwiftUI?
This is a classic interview question, both about architecture knowledge and system design, when you need to choose one. It’s also useful when you start a new app and have to pick an architecture. The author goes through each pattern and explains how well it fits SwiftUI.
Spoiler Alert: MVVM wins, and I think everyone knows that. Still, it’s good to understand why the other patterns don’t fit SwiftUI so well. I would also add TCA or another Redux-like architecture to this list. It fits SwiftUI really well too, but it’s more complex, so MVVM is usually the go-to choice.
The effect of fixedSize() on view sizing and layout in SwiftUI
Not gonna lie, I learned about fixedSize() while fixing my text bugs, and I keep forgetting which variant is the right one. I believe it sounds familiar to you 😅 If so, you have to take a look at this one.
What is GlassEffectContainer in SwiftUI and how to use it
I think everyone has noticed how many apps shipped updates with native Liquid Glass lately, and honestly, I really like it. I know a lot of people don’t like this change, but I still recommend following the trends and sticking to Apple’s native components and guidelines. It makes it much easier to adapt to every new release, like we saw with iPhone Duo.
This article covers everything you need to know about the glass effect. By default, glass views don’t see each other, but you can group them with GlassEffectContainer to blend, merge and morph them. You’ll find a lot of other useful tips there too.
Quick Read
Presenting contextual controls with SwiftUI’s inspector
.inspector(isPresented: $isInspectorPresented) { InspectorContent() .presentationDetents([.medium, .large]) }
Video
Effect Systems: a powerful alternative to Dependency Injection
I came across Alex Ozun’s talk recently, and I agree with his main point. Usually we use DI only for tests, because we need one implementation for tests and another one for prod. Adding a design pattern just for testing feels like too much.
Alex presented an idea how we could write plain procedural code without injecting anything. It is not production-ready, but I recommend watching it just to see an alternative approach. Alex always has interesting ideas, like his Type-Driven Design series, and I like how he looks at a problem and finds unusual solutions.
Toolbox
For years I used Paw (later RapidAPI for Mac). It was a native Mac app that worked great, and I enjoyed using it. They also shared a full version every Black Friday, which was awesome!
But Nokia bought RapidAPI, and it looks like we won’t get any more updates. Nokia doesn’t support it on macOS 27, so it’s time to look for an alternative.
Our backend engineers use Bruno, and I like it so far. It saves all your requests as plain files, and you can keep them in your private repo. The app looks nice, it’s easy to use, and it has everything a mobile engineer needs to check how an API works.
Weekly Poll
📊 Last Week’s Poll Results
Will you integrate your app with Siri AI?
Top Answer: Maybe later
Upcoming Conferences
November
19–20 — Swift Bharat (Mumbai 🇮🇳)
20–22 — SwiftSonic 26 (Nashville 🇺🇸)
February 2027
16–18 — ARCTIC Conference (Oulu 🇫🇮)
March 2027
2–4 — try! Swift Tokyo 2027 (Tokyo 🇯🇵)
16–18 — Appdevcon 2027 (Amsterdam 🇳🇱)
April 2027
4–6 — Deep Dish Swift 2027 (Chicago 🇺🇸)
September 2027