Sponsored Link
RevenueCat Ship-a-ton: Ship apps and make money
Thereās 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āre giving out! Join the Ship-a-ton.
News
The Future of Vapor
Vapor 4 was in a late beta when we first started development on Swift Package Index. Itās hard to believe that weāve now been using the framework for more than four years, but we have! Tim Condon 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!
I just hope the migration for large Vapor 4 projects isnāt too painful. š¬
Revolutionizing Surgery and Medical Treatments with visionOS
I wrote a few weeks ago about the need for āapps that make you put your headset onā 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.
Code
Extending SwiftPM Metadata
This post from Alejandro Martinez 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ās not what Iād call usable at the moment, but maybe one day?
Group container naming in macOS Sequoia
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ās not as easy as you might have hoped. John Brayton wrote up some instructions for his users, and if you scroll down to the āTechnical Detailsā section, for fellow Mac developers, too!
Books
The Case of the Crimson Test Suite
Iāve not had a chance to check this out yet, but Iād imagine that all I need to say is that Daniel Steinberg has a new book out covering swift-testing. Youāll know immediately if thatās going to be of interest to you.
Itās worth noting that itās early days for the swift-testing framework, and itās not yet at a 1.0 release. That may well change with the imminent release of Xcode 16. Youāll be ahead of the game either way!
Jobs
Mobile Developer (iOS) @ Planning Center ā 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. ā Remote (within US timezones) with some on-site work (United States in CA)
Job postings on iOS Dev Jobs are free and get distributed to thousands of developers. Do you have open positions in your company thatād appeal to iOS Dev Weekly readers? Get your jobs listed.
And finally...
Has your CI system ever run out of disk space?
The script is kinda hilarious, too. š
Update: Youāre never supposed to take anything I say in this section too seriously, but it has been pointed out to me that this technique of executing a script which isn't under your direct control during CI is a terrible idea, no matter what the script does. See this article for more information.
Comment
I found myself needing to upgrade to macOS Sequoia this week, so I finally got a chance to try Xcodeās new AI-powered āPredictive Code Completionā. š¤
First things first. Howās the quality and does it āhallucinateā? Iād say the quality is good, and of course it hallucinates. š I believe that eliminating hallucinations in LLM is, at best, extremely challenging and, at worst, impossible. Did it produce generally useful, modern, Swift code, though? Absolutely.
Iāve some experience with using GitHub Copilot, both inline in VS Code and via its chat interface and the experience of using Xcodeās predictive code completion felt very like Copilotās inline code completion. Pause typing for a second, and itāll show some dimmed code. Press tab, and itāll accept the suggestion. Just like Copilot.
I find Copilotās 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ād be impossible for a human 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 āwrite my code for meā, it delivers. Thatās how Apple is pitching it, too, so thatās good.
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
{ ā¦ }
where it wants to insert a block of code, whether thatās a function definition or a block after aguard
orif
statement. I think I prefer this because this is closer to the single-line completion I just mentioned.I will admit that I expected it to be more responsive than Copilot given itās an on-device model. Copilot needs to do a full round-trip to the Microsoft/GitHub servers and 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.
There are some obvious enhancements, which youād expect from a first release. Having it explain compiler errors and runtime crashes would be a fantastic enhancement, and should be within reach. Iād 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ās mind when implementing something like this, but Copilot chat is very 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āt want to go down. I completely failed.
I also wish Apple would give more information about where they sourced their training data, but I have banged that drum quite a lot now and itās 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āt want citations with every output, but a broad description of where the data was sourced from would be great.
Overall, I think itās a win, and itāll only get better over time!
Dave Verwer