AI Levels the Student App Contest: More Women, Non-Coders, but Shallow Solutions

Thoughts on Judging the Student Mobile App Competition

Over the past three days, I had the honor of serving as a judge for the 2026 "China Collegiate Computing Contest — Mobile Application Innovation Competition," which has long been supported by Apple. This event has been running for 11 years, with over 1,000 universities and tens of thousands of student participants this year.

Although participating meant missing the historic moment when my hometown team lifted the league championship trophy at home, the face-to-face exchanges with many young contestants made it well worth the trip. I gained a great deal.

The democratization and rapid advancement of AI have not only dramatically improved the visual and functional polish of the entries, but are also changing who participates. Based on my observations on site, at least one-third to one-half of the contestants in this competition were women. As a long-time weekly newsletter author who follows the developer ecosystem, I know this ratio is significantly higher than the proportion of women in traditional technical communities. More intriguingly, contestants with computer science backgrounds no longer seem to dominate as absolutely. Many teams consisted entirely of students with no prior development experience, with design majors being the most common. As more and more people without programming backgrounds can independently complete app development, the boundary of the "Coder" identity may be blurring at an unimaginable pace.

However, while AI has flattened technical barriers, it has also exposed several issues worth heeding. Because implementation costs have been drastically reduced, some teams lost restraint during development, piling up seemingly useful but indistinct mediocre features. Other teams over-relied on AI to replace real research and interviews, leading to strikingly similar pain points and solutions for their target audiences. This "stereotyped demand" stitched together by AI is especially visible in projects aimed at vulnerable groups. Additionally, due to a lack of solid engineering fundamentals, some teams, even with excellent ideas, struggled to deepen their implementation or build technical moats, ultimately stopping at a "contest demo" rather than growing into mature products that genuinely serve real people.

This year also introduced a new elementary and middle school division. Some elementary school students' works brought me even more surprises and emotional resonance. On one hand, their creative goals were extremely pure, with inspiration possibly coming from a casual remark by a classmate or a whimsical imagination — the kind of brilliance that only emerges at that age. On the other hand, many children still insisted on writing code line by line in Swift Playgrounds. Though their works contain dated syntax, messy file organization, and various immature implementations, compared to some finely crafted results that rely on AI polish, this process of continuous trial, error, and correction may give them a more solid foundation for growth and become the most precious memory for later years.

The student phase is perhaps the golden window in every developer's life to create the most non-utilitarian works. Create from genuine feeling, pay attention to and solve the real, visible small problems around you. After all, once you enter society, the various constraints and considerations in reality may never again allow us to have such a spontaneous, pure, and sincere mindset to build a product.

In any case, the energy and inspiration displayed by the contestants have taught me a lot. More importantly, this experience made me truly feel that an era in which everyone can participate in software creation is coming.

Current Issue | Previous Issue | All Weekly Lists

Recent Recommendations

SwiftPM: Supporting Multiple Major Versions of the Same Package

SwiftPM has long had a limitation that frustrates developers: within the same dependency graph, if Package A and B both depend on Package C, SwiftPM must choose a single version of C that satisfies both A's and B's version constraints. When version requirements are incompatible, developers are forced to restrict dependency versions, coordinate upstream upgrades, or even fork and rename repositories to resolve conflicts. Bri Peticca has proposed an improvement: allowing different major versions of the same package to coexist in the dependency graph. The proposal plans to adjust the dependency resolution algorithm and avoid module naming conflicts via automatically generated module aliases.

The proposal is still in the pitch phase, with plenty of room for discussion on version isolation, binary size, runtime behavior, and other issues. If you've encountered similar dependency conflicts in your projects, or have thoughts on multi-version coexistence, you're welcome to join the discussion on Swift Forums.

---

Server-Sent Events in Vapor

Server-Sent Events (SSE) is an HTTP-based technology for servers to continuously push events to clients. Its core characteristic: the client initiates a single HTTP request, the server keeps the response connection open, and sends messages whenever new data arrives. For scenarios that only need one-way data transmission, SSE is often simpler and more direct than WebSocket.

Kyle Browning demonstrates, using Vapor as an example, how to build a lightweight SSE protocol wrapper on top of the general-purpose Streaming API, and shares his open-source library vapor-sse. With req.sse, developers can directly send strings or Encodable data in async closures without manually handling response headers, event formatting, or underlying stream management. The entire library is only about 200 lines of code, yet covers the key details of SSE protocol wrapping.

---

SwiftData Pitfall: Rollback Trap After a Failed Save

When ModelContext in SwiftData throws an error during a save() operation, the unsaved modifications do not automatically disappear and may persist in the context. If the error comes from the data itself being saved, these problematic data can cause subsequent unrelated modifications to fail as well; if the error is only temporary, the previously failed modifications might be accidentally committed on a later save. This is especially likely to cause subtle data consistency issues in SwiftData apps that enable autosave and share the same ModelContext across multiple pages.

Roland Leth found that rollback() also doesn't work as expected in all scenarios. In his fault-injection tests, directly rolling back unprocessed deletions caused the recovered objects to crash when read; calling processPendingChanges() before rollback avoided the problem. The article also introduces a highly instructive fault-injection method: using @TaskLocal to actively trigger save failures during tests, verifying the app's recovery logic while avoiding interference between parallel tests.

Compared to Core Data, SwiftData still offers limited error information and handling methods when exceptions occur. My personal habit is to wrap persistence operations in a ModelActor and create separate actor instances for each group of operations, executing a series of modifications in a private ModelContext as a transaction, then saving at the end. This clarifies operation boundaries and prevents failed modifications from lingering in a long-lived shared context, simplifying rollback and error recovery.

---

Building a Blazing-Fast PSB Decoder in Swift 6

For an image measuring 69,536 × 22,230 pixels with a file size of 4.6 GB, Apple's ImageIO takes 7.4 seconds to generate a thumbnail suitable for screen display, while Joachim Rütter's Swift decoder completes the same task in 0.73 seconds. The key performance difference lies in exploiting the PSD/PSB file structure: the file contains multiple sections with explicit lengths, and the flattened composite used for previews sits at the end of the file.

Joachim shares how he uses the length information of each section to skip layer data, reads the required regions directly via RLE row indices, and performs downsampling in parallel during reading, avoiding loading the full image into memory. Though the idea seems straightforward, the implementation involves Swift 6, UnsafeBufferPointer, pread, parallel computing, memory control, and binary format parsing — a distinctive and highly targeted engineering practice.

---

The Underlying Mechanics of SwiftUI Animation: How It Differs from UIKit and Across Platforms

In Weekly Issue #154, I covered a discussion about whether SwiftUI animations are truly "native." SwiftUI co-creator Kyle Macomber explained at the time that SwiftUI deliberately chooses to advance animations within the app process, rather than delegating animation execution to the Render Server as traditional Core Animation does. But does client-side animation necessarily mean animation is affected by main-thread blocking?

Mihaela Mihaljević Jakić conducted an in-depth verification using hook layer methods, analyzing thread call stacks, inspecting Core Animation private objects and shared memory, combined with simulator and real-device screen recordings. The results show that in the tested macOS environment, SwiftUI animations are indeed continuously advanced by the main thread, and blocking the main thread causes animation to pause. However, on iOS/iPadOS, SwiftUI uses a separate AsyncRenderer thread to compute animation values, so animations continue even when the main thread is blocked. When the researcher deliberately blocked the AsyncRenderer thread, SwiftUI animations also stopped.

Compared to the experimental conclusions themselves, the way Mihaela explored the problem might be more valuable. From discovering that measurement tools interfered with observations, to continuously revising experimental methods, cross-validating data, and clearly listing unresolved issues, the entire article demonstrates a rigorous and honest technical exploration process.

---

Understanding the Layout Mechanism of layoutPriority in SwiftUI Containers

As the name suggests, layoutPriority in SwiftUI marks a view's priority in a layout container, but how this information is used depends on the parent container's layout strategy. There is no universal rule that applies to all containers.

Natalia Panferova shows the role of layoutPriority in different layout containers: HStack and VStack allocate available space based on priority; ZStack uses the highest-priority child to determine its own size. The article also explains how to read priority information in a custom Layout and implement your own layout strategy based on it.

In SwiftUI, it's not uncommon for modifiers to provide information only, with the actual behavior determined by the parent container. This is an important design pattern. Understanding this helps developers not only gain a deeper grasp of the API but also design custom containers that fit SwiftUI's style.

---

Tech Stack Choices in the AI Era: Why I Still Choose Swift and Kotlin

A few days ago, Skip co-founder and former Swift Android working group member Marc Prud’hommeaux announced he was shifting focus to Rust. He argued that when AI can handle more code-writing work, language friendliness to human developers matters less, and portability deserves higher priority.

Junda Ong, however, arrives at a different conclusion from the same premise: since AI reduces the cost of writing and maintaining code, why not use Swift/SwiftUI and Kotlin/Compose to build separate native apps? For simple business logic, maintaining two implementations and verifying consistency through shared test cases may be cheaper than adopting an additional cross-platform stack.

Shopify recently announced it was shifting its mobile app development strategy from React Native back to native Swift and Kotlin, citing the same reason: AI lowers the cost of maintaining two native codebases. Interestingly, AI makes cross-platform sharing solutions like Rust easier on one hand, while also making it unnecessary to sacrifice native advantages just to reduce duplicate code. Technology paths are not converging because of AI; they may be becoming more diverse.

---

The AI Assistant Paradox: Apple Can Build the Platform, but Will Developers Buy In?

In the just-released iOS 27.3 beta, Apple opened up Siri AI integration to third-party developers and introduced a Skills mechanism, allowing developers to compose multiple operations via App Intents to help Siri AI complete more complex tasks. Combined with Apple's infrastructure — the operating system, identity authentication, app permissions, and secure payments — it seems to have many conditions for building a personal AI assistant ecosystem. But does technical readiness mean developers are willing to expose their core business capabilities?

Erk Ekin believes the problem goes beyond the extra effort of adapting and maintaining App Intents; it's about how AI assistants may change the relationship between businesses and users. When users can bypass the app interface and directly let an agent handle shopping, booking, and other operations, businesses may lose opportunities to recommend products, promote subscriptions, and build user relationships. In contrast, independent agents like OpenClaw can directly operate existing services through interface automation, without waiting for developers to adapt, but they face more complex security and authorization issues.

This article does not simply conclude that Apple's path will necessarily fail, or that independent agents will definitely win. In the end, both paths may converge on a similar architecture: services accessed through multiple means, while relying on trusted infrastructure to constrain agent operations.

Tools

MockMini: A Minimalist Network Proxy Core in C and Swift

Developed by yezicheng, MockMini is a free, open-source, early-stage experimental network proxy core. The project implements user-space TCP/UDP packet handling and support for multiple proxy protocols in about 2,600 lines of C and Swift. The C layer handles TCP connection state management, data reassembly, and retransmission, while the Swift layer implements protocols like Shadowsocks, VMess, Trojan, and VLESS, using Apple platforms' Network.framework and CryptoKit for network connections and some cryptographic operations.

Compared to full-featured mature proxy cores, MockMini's noteworthy aspects are its lean implementation size and clear division of responsibilities. The project organizes protocol handling, transport encapsulation, and connection management into layers, allowing developers to trace data flow within a relatively focused codebase and understand the internal mechanisms of network proxies.

Past Issues

• Rapidly Disappearing Disk Space - #160
• When Apps No Longer Belong to a Specific Operating System - #159
• Who Is the Real Threat to AI-relay Apps - #158
• When Build in Public Goes Back Underground - #157

💝 Support and Feedback

If this weekly issue has helped you, please:

• 👍 Like - Let more developers see it
• 💬 Comment - Share your thoughts or questions
• 🔄 Forward - Help peers grow together

---

🚀 Expand Your Swift Horizons

• 📮 Email Subscription | weekly.fatbobman.com for exclusive technical insights
• 👥 Developer Community | Discord for real-time exchange
• 📚 Original Tutorials | fatbobman.com to learn Swift/SwiftUI best practices