\n<\/p>\n
I found myself needing to upgrade to macOS Sequoia this week, so I finally got a chance to try Xcode\u2019s new AI-powered \u201cPredictive Code Completion\u201d. \ud83e\udd16<\/p>\n
First things first. How\u2019s the quality and does it \u201challucinate\u201d? I\u2019d say the quality is good, and of course<\/em> it hallucinates. \ud83d\ude02 I believe that eliminating hallucinations in LLM is, at best, extremely challenging and, at worst, impossible<\/a>. Did it produce generally useful, modern, Swift code, though? Absolutely.<\/p>\n I\u2019ve some experience with using GitHub Copilot, both inline in VS Code and via its chat interface and the experience of using Xcode\u2019s predictive code completion felt very<\/em> like Copilot\u2019s inline code completion. Pause typing for a second, and it\u2019ll show some dimmed code. Press tab, and it\u2019ll accept the suggestion. Just like Copilot.<\/p>\n I find Copilot\u2019s single-line completion suggestions to be much more useful than when it suggests a function implementation from a function name or comment, which feels like a gimmick. It\u2019d be impossible for a human<\/em> to write code from a function name for anything but the most trivial function, let alone an AI. But if you think of it as an advanced code completion rather than \u201cwrite my code for me\u201d, it delivers. That\u2019s how Apple is pitching it, too, so that\u2019s good.<\/p>\n One thing I prefer about the Xcode implementation is how it handles multi-line predictions. If Copilot wants to insert a fully formed function or a multi-line block, the entire block is visible but dimmed. In contrast, Xcode shows I will admit that I expected it to be more responsive than Copilot given it\u2019s an on-device model. Copilot needs to do a full round-trip to the Microsoft\/GitHub servers and<\/em> calculate the results, but it turns out that an on-device calculation with a consumer-grade CPU (I run an M1 Max) is about the same speed as a network connection + huge Azure servers. From some very non-scientific tests, performance is about the same or slightly worse than what I see with Copilot.<\/p>\n There are some obvious enhancements, which you\u2019d expect from a first release. Having it explain compiler errors and runtime crashes would be a fantastic enhancement, and should be within reach. I\u2019d also love to see something like Copilot chat where you can have a back and forth conversation about your code. I know that the possibility of going off-topic would be at the top of Apple\u2019s mind when implementing something like this, but Copilot chat is very<\/em> good at not letting the conversation wander away from code. If you have access to it, just try to lead it down a path it doesn\u2019t want to go down. I completely failed.<\/p>\n I also wish Apple would give more information about where they sourced their training data, but I have banged that drum<\/a> quite a lot now and it\u2019s clear that the industry standard is to keep quiet about sourcing data in the vast majority of cases. I expected better from Apple on this point, though. I don\u2019t want citations with every output, but a broad description of where the data was sourced from would be great.<\/p>\n Overall, I think it\u2019s a win, and it\u2019ll only get better over time!<\/p>\n Dave Verwer<\/p>\n RevenueCat Ship-a-ton: Ship apps and make money<\/a><\/p>\n There\u2019s still time to submit your new apps to the RevenueCat hackathon. Get your app featured on over 150 digital billboards throughout San Francisco, or win some of the $25k cash prizes we\u2019re giving out! Join the Ship-a-ton<\/a>.<\/p>\n The Future of Vapor<\/a><\/p>\n Vapor 4 was in a late beta when we first started development on Swift Package Index. It\u2019s hard to believe that we\u2019ve now been using the framework for more than four years, but we have! Tim Condon<\/a> sets out the plan for Vapor 5. It will be based on async\/await, will integrate swift-testing, and potentially include new routing APIs, which all sound good to me!<\/p>\n I just hope the migration for large Vapor 4 projects isn\u2019t too<\/em> painful. \ud83d\ude2c<\/p>\n Revolutionizing Surgery and Medical Treatments with visionOS<\/a><\/p>\n I wrote a few weeks ago about the need for \u201capps that make you put your headset on<\/a>\u201d and here comes Francesco Perchiazzi to help us find some. This write-up covers several visionOS apps being used in places you might not expect. Fascinating.<\/p>\n Extending SwiftPM Metadata<\/a><\/p>\n This post from Alejandro Martinez<\/a> is an interesting glimpse into what might one day be possible with package manifests. The specific example will only be of use to those of you on large teams with apps that have plenty of dependencies, but the concept is interesting. It\u2019s not what I\u2019d call usable at the moment, but maybe one day?<\/p>\n Group container naming in macOS Sequoia<\/a><\/p>\n This might be a little obscure, but is probably worth mentioning. If your Mac app uses group containers to share data between your app and its extensions, depending on how you set it up, you might need to move things around. Unfortunately, in a sandboxed environment that\u2019s not as easy as you might have hoped. John Brayton<\/a> wrote up some instructions for his users, and if you scroll down to the \u201cTechnical Details\u201d section, for fellow Mac developers, too!<\/p>\n The Case of the Crimson Test Suite<\/a><\/p>\n I\u2019ve not had a chance to check this out yet, but I\u2019d imagine that all I need to say is that Daniel Steinberg<\/a> has a new book out covering swift-testing<\/a>. You\u2019ll know immediately if that\u2019s going to be of interest to you.<\/p>\n It\u2019s worth noting that it\u2019s early days for the swift-testing framework, and it\u2019s not yet at a 1.0 release. That may well change with the imminent release of Xcode 16. You\u2019ll be ahead of the game either way!<\/p>\n Mobile Developer (iOS) @ Planning Center<\/a> \u2013 Our Mobile Team works on both iOS and Android. While focuses are leveraged, there is a healthy bit of collaboration in the execution of how things are released. \u2013 Remote (within US timezones) with some on-site work (United States in CA)<\/em><\/p>\n Job postings on iOS Dev Jobs<\/a> are free<\/em> and get distributed to thousands of developers. Do you have open positions in your company that\u2019d appeal to iOS Dev Weekly readers? Get your jobs listed<\/a>.<\/p>\n Has your CI system ever run out of disk space<\/a>?<\/p>\n The script<\/a> is kinda hilarious, too. \ud83d\ude02<\/p>\n{ \u2026 }<\/code> where it wants to insert a block of code, whether that\u2019s a function definition or a block after a guard<\/code> or if<\/code> statement. I think I prefer this because this is closer to the single-line completion I just mentioned.<\/p>\nNews<\/h2>\n
Code<\/h2>\n
Books<\/h2>\n
Jobs<\/h2>\n
And finally…<\/h2>\n