Privacy nutrition labels on the App Store were a step forward for how informed people could be about what an app is doing with their data, but I’d also bet that a non-trivial amount of them are incorrect in some way. 😬 In the vast amount of cases, I’d expect that to be caused by the inclusion of third-party SDKs.
Privacy manifests aim to fix that problem by allowing package authors to include privacy information in each package, and Xcode 15 has a feature to gather those together for every SDK in your app. Won’t it be great when we don’t need to dig through third-party documentation (or even make guesses from a privacy policy!) to figure out what a vendor is doing or, even better, decide whether to use an SDK? 🎉
Even better, the post also says these manifests will eventually become required. They don’t go into any detail (that I could see) about when or precisely what this means, but I’d expect it to be a pre-flight check when uploading an app to the store.
But that’s not everything, and tucked away at the bottom of the news post was a little note that says everything about how seriously Apple think about this. They say that later this year, they’ll publish “a list of privacy-impacting SDKs (third-party SDKs that have particularly high impact on user privacy)”. I have no idea what they’ll publish or how they will distribute it, but that’s a clear sign that they are a company on the warpath!
Of course, we’re already considering how we will integrate privacy manifest data into package pages on the you-know-what. 👍
Dave Verwer
Cut through the noise of failing tests and unclear boolean results. See exactly what failed in your test and why with a full video replay, console logs + network calls, device details, and more! Check out an example here, and try it with your own app by visiting waldo.com.
With 175 official sessions, knowing where to start with this year’s videos can be overwhelming. How about if someone from Apple had narrowed it down to a list of 45 essential ones? That would help quite a bit!
I don’t usually link to when we support a new Swift version with the Swift Package Index, but we’re so early with this one that I thought it was worth mentioning. All of the compatibility testing is already complete, and if you’re a package author, you can opt-in to have your documentation built with 5.9, too!
Here’s Sarun Wongpatcharapakorn to give us an animated clip overview of everything new in Xcode 15, including improved autocompletion, context awareness, the beautiful new documentation preview view, bookmarks, refactoring improvements, and the fantastic new quick actions/command palette feature. It’s a good year for Xcode!
I don’t know how Paul Hudson does it. We’re only one week after WWDC, and here he is with 83 sample Xcode projects and blog posts covering a host of new goodies. I struggle to think of three things I did this week! 😬
Oh, yes! The new inspector views look fantastic, and great to get a definitive way to handle this layout across multiple device sizes and platforms. Thanks to Matthaus Woolard for doing this quick write-up covering them.
I want to write something more detailed about macros once I have a chance to dig into them more than watching the session videos (1 and 2), and maybe this new repository from Krzysztof Zabłocki is where I should start? It’s a rapidly expanding list that includes packages, macros, educational resources, and tools.
I don’t know how often I’ve written code to show an empty state in an iOS app, but I’ve done it more times than I’d like! If you have a table view, do you use a single cell that takes the whole content area? Or do you replace the entire view? Then, what happens when your view content starts loading? Apple has just put all those conversations to bed and provided a definitive answer to the question, and Lee Kah Seng is here to show us how to use it.
This is an excellent reminder from Daniel Saidi of a technique that is always useful around this time of year!
I’m so happy to see Apple continue to document the App Store Review Guidelines changes as they have done again here. 🎉
iPad Software Engineer @ Liquid Instruments – Liquid Instruments is a startup creating a range of modern test and measurement devices using reconfigurable FPGA hardware. We’re looking for someone to help develop the beautiful iPad user interface that drives it all. – On-site (Australia)
Senior iOS Developer @ komoot – You’ll team up with four world class iOS engineers and take over full responsibility for our iOS app. You’ll develop diverse features for navigation, routing, social interaction and content visualisation that will make your work challenging and fun. – Remote (within European timezones)
Swift Product Engineers @ The Browser Company – Fully remote, diverse team building an all-Swift web browser and bringing Swift to other operating systems. Series A, well-funded and a seasoned engineering team. We’re building a beloved product by thinking differently about how we work and the future of the internet. – Remote (within US timezones)
Is your company hiring? You can post your open positions for free over at iOS Dev Jobs.
I see what you did there, Steve! 😂