\n<\/p>\n
Thanks to everyone who responded to last week\u2019s question<\/a> on what you hope for from WWDC 2025.<\/p>\n 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. \ud83d\ude2c<\/p>\n I shouldn\u2019t 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\u2019s 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.<\/p>\n It\u2019s easy to see the downsides of strict concurrency checking right now. We\u2019re 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\u2019t top of their priority list when planning what to work on next.<\/p>\n Apple\u2019s answer to this would be \u201cyou don\u2019t need to opt in\u201d, and they\u2019re 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\u2019s making people feel pessimistic. No one likes to feel left behind.<\/p>\n That said, the score of 3.5 is great and shows that people still have plenty to love about Swift.<\/p>\n I\u2019m going to break the comment here for the sponsored link, but I\u2019ll be back after that with more. Also, in case you don\u2019t like the format of this issue, please bear with me. This isn\u2019t a permanent change, I\u2019m just experimenting. \ud83e\uddd1\u200d\ud83d\udd2c<\/p>\n Dave Verwer<\/p>\n Orka Desktop<\/a><\/p>\n Orka Desktop helps iOS and macOS developers to unblock workflows by running builds or test work in a VM on any macOS including Sequoia Beta. Additionally, you can safely run breaking tests on your own machine and improve collaboration with easily shareable images. And best of all it\u2019s FREE to use and easy to learn!<\/p>\n Try Orka Desktop today<\/a>.<\/p>\n So let\u2019s get into what you all thought on Apple platform development. I\u2019ll start with a few prominent themes: SwiftUI, AI, and improvements to Xcode.<\/p>\n AI is an obvious one these days, but it\u2019s clear that it means different things to different people. Some wished for improvements to Xcode 16\u2019s 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\u2019s clear that AI is on all your minds, though.<\/p>\n 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.<\/p>\n It was the same for Xcode, too. Improvements to the quality and performance of Xcode was probably the most common \u201cwish\u201d that I saw in the results, but again there were very few specifics. I hear this every year and it sometimes feels like I\u2019m using a different Xcode to everyone else. It\u2019s by no means perfect, but my experience with it seems nowhere near as bad as other people\u2019s. I do wish the phantom errors would go away, though. \ud83d\udc7b<\/p>\n Finally, I want to touch on a couple of specific comments. First, Siamak (Ash) Ashrafi<\/a> 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:<\/p>\n 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 \u2014 users simply said, \u201cAndroid sucks.\u201d Fortunately, Google now offers clear guidelines and best practices, helping developers create robust, consistent, and high-quality Android apps.<\/p>\n<\/blockquote>\n He offered a link to Google\u2019s Guide to app architecture<\/a> and I enjoyed reading it. I thought I agreed with Apple\u2019s recent stance of being completely architecture agnostic, especially when it comes to SwiftUI code. It\u2019s hard to give generic advice about app architecture, but this guide does a great job. They have a whole learning pathway<\/a> on the subject, too.<\/p>\n The topic of documentation came up several times, too. While there wasn\u2019t anything particularly new said, the same old points remain. James Clarke<\/a> :<\/p>\n Improving API documentation for Apple APIs giving usage examples.<\/p>\n<\/blockquote>\n It\u2019s that last part about \u201cexamples\u201d that comes up over and over again, and I\u2019m confident it\u2019s why blogs that take an Apple API and add code examples of using it do so well.<\/p>\n Also, from Daniel Steinberg<\/a>:<\/p>\n Bring back the old Programming Guides. There are big topics that need those overviews and not API by API docs<\/p>\n<\/blockquote>\n 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\u2019t do it well enough. I understand that the \u201cbook style\u201d format must have been more work to maintain than shorter articles are, but I miss the way they guided you through a topic.<\/p>\n Finally, bless Marius Felkner<\/a> for echoing my recent take<\/a> by hoping for:<\/p>\n Opinionated stuff (Swift Format Rules etc)<\/p>\n<\/blockquote>\n It was a fascinating glance at what you all think, and I hope you found the results interesting! Thanks for reading.<\/p>\n Dave Verwer<\/p>\nArticle<\/h2>\n
\n
\n
\n
\n
Jobs<\/h2>\n