Issue 685

1^st November 2024

Written by Dave Verwer

Comment

Thanks to everyone who responded to last week’s question on what you hope for from WWDC 2025.

There were plenty of interesting responses, but before we get to the specifics I asked how optimistic you all were about Swift and Apple platform development. It can be easy to see only negative comments about a topic, especially if you go anywhere near social media, so I was a little nervous to see these results. 😬

I shouldn’t have worried, though, as your sentiments skewed positive. Swift got an average of 3.5 out of 5 and Apple platform development got a 4.0. It’s interesting to see Swift getting the lower of those two numbers, and from reading the comments, I know why. I filtered to only those people who felt pessimistic about Swift and there was a clear theme. Structured concurrency and language complexity came up in almost every Swift-specific comment. It even featured regularly up in those responses from people who felt optimistic about the language. It was a noticeable trend.

It’s easy to see the downsides of strict concurrency checking right now. We’re right in the middle of the most painful part of the transition. Developers are being asked to do something difficult and time-consuming without the promise of immediate or obvious benefits. It puts a significant burden on developers in an area that maybe wasn’t top of their priority list when planning what to work on next.

Apple’s answer to this would be “you don’t need to opt in”, and they’re completely correct. You can stay in Swift 5 language mode. The biggest problem with this is that deciding to stay with Swift 5 language mode raises questions. When will Swift 5 mode go away? Will some future framework or SDK force me to move to use it? I can see why it’s making people feel pessimistic. No one likes to feel left behind.

That said, the score of 3.5 is great and shows that people still have plenty to love about Swift.

I’m going to break the comment here for the sponsored link, but I’ll be back after that with more. Also, in case you don’t like the format of this issue, please bear with me. This isn’t a permanent change, I’m just experimenting. 🧑‍🔬

Dave Verwer

Article

So let’s get into what you all thought on Apple platform development. I’ll start with a few prominent themes: SwiftUI, AI, and improvements to Xcode.

AI is an obvious one these days, but it’s clear that it means different things to different people. Some wished for improvements to Xcode 16’s AI code completion, while others wished for better integration APIs so users can access app-specific data via natural language. Some even wished for improvements to CreateML, which is an easy framework to forget when everything you read about is so dominated by LLM news. It’s clear that AI is on all your minds, though.

People are also clearly wishing for continued improvements to SwiftUI, but seemed to mostly be happy to take whatever Apple deems to bless us with in this area next year as there were only a few specific suggestions.

It was the same for Xcode, too. Improvements to the quality and performance of Xcode was probably the most common “wish” that I saw in the results, but again there were very few specifics. I hear this every year and it sometimes feels like I’m using a different Xcode to everyone else. It’s by no means perfect, but my experience with it seems nowhere near as bad as other people’s. I do wish the phantom errors would go away, though. 👻

Finally, I want to touch on a couple of specific comments. First, Siamak (Ash) Ashrafi on how he has seen iOS and Android development switch places when it comes to guidance on app architecture. Apple used to firmly encourage an MVC approach, but that has gone these days. Whereas, Android:

In the early days, Android developers faced a lack of guidance on app architecture. With no best practices provided, every developer implemented their own approach, leading to fragmented use of languages, tools, and design principles. This inconsistency resulted in many poorly designed apps on the Play Store, and unfortunately, the blame often fell on Android itself rather than the individual apps — users simply said, “Android sucks.” Fortunately, Google now offers clear guidelines and best practices, helping developers create robust, consistent, and high-quality Android apps.

He offered a link to Google’s Guide to app architecture and I enjoyed reading it. I thought I agreed with Apple’s recent stance of being completely architecture agnostic, especially when it comes to SwiftUI code. It’s hard to give generic advice about app architecture, but this guide does a great job. They have a whole learning pathway on the subject, too.

The topic of documentation came up several times, too. While there wasn’t anything particularly new said, the same old points remain. James Clarke :

Improving API documentation for Apple APIs giving usage examples.

It’s that last part about “examples” that comes up over and over again, and I’m confident it’s why blogs that take an Apple API and add code examples of using it do so well.

Also, from Daniel Steinberg:

Bring back the old Programming Guides. There are big topics that need those overviews and not API by API docs

I miss them too, Daniel! I understand what Apple is trying to do with adding articles in and around the API documentation, and those articles are great! However, as much as Apple might intend them to replace the old programming guides, they don’t do it well enough. I understand that the “book style” format must have been more work to maintain than shorter articles are, but I miss the way they guided you through a topic.

Finally, bless Marius Felkner for echoing my recent take by hoping for:

Opinionated stuff (Swift Format Rules etc)

It was a fascinating glance at what you all think, and I hope you found the results interesting! Thanks for reading.

Dave Verwer

Jobs

Staff Software Engineer - iOS @ NewStore – Join NewStore and be part of a forward-thinking team dedicated to crafting exceptional mobile experiences. We embrace TDD, pairing, and best engineering principles, fostering an environment where you can lead, inspire, and help shape the future of our iOS engineering culture. – Remote (within European timezones) with some on-site work (Germany, Netherlands, or United Kingdom)

Senior iOS Developer @ komoot – You’ll team up with six world-class iOS engineers, take over full responsibility for our iOS app, and develop diverse features for navigation, routing, social interaction, and content visualization that will make your work challenging and fun. – Remote (within European timezones)

And finally...

As I mentioned above, this isn’t a new format for the newsletter and links will be back next week for sure.

I do want to experiment a little though, so if this issue made you feel something positive or negative, please do let me know. Just hit “Reply”.

Issue 685

Comment

Sponsored Link

Article

Jobs

And finally...