I don’t know how I missed Orta Therox announcing that CocoaPods is in maintenance mode a couple of weeks ago, but I did! Or, to be accurate, the post clarifies that CocoaPods has been in maintenance for a while now:

Strictly speaking,we don’t plan on changing how we’re maintaining CocoaPods*. We’re just going to start being clear how CocoaPods has been maintained:*

SwiftPM had a slow start. Apple announced it in 2015 but didn’t see significant usage until four years later when they shipped iOS and macOS support. The writing was on the wall for CocoaPods with support for those platforms, but it’s a slow process to convince people they should switch dependency managers. It’s hard for teams to prioritise work like that when the old system isn’t broken, and CocoaPods wasn’t (and isn’t) broken!

That said, we’re now five years further on, and it feels like most teams eventually found time to migrate. SwiftPM is now the dominant dependency management tool for Swift, and that’s a good thing.

Of course, if you still want or need to use CocoaPods, the post has some very good news for you. CocoaPods is not going away any time soon. In fact, the team is committing to biannual maintenance releases to keep up with new versions of Xcode. You can also expect security updates if issues arise. There’s just no feature work planned.

This announcement is a great time to say an enormous thank you to everyone who worked on the CocoaPods team over the years. You made an incredible tool that saved millions of people time and filled a gaping hole in the Objective-C and Swift ecosystems and the project was exceptionally well-operated. Your innovation made things possible for millions of developers.

I also want to thank Orta for making this announcement. It’s never easy to communicate something like this well, and there’s never a right time to do it. I’m really happy that we have clarity on the plan.

Thank you all for your work over the years.

Dave Verwer  

Efficient iOS deployment: 50+ Workflow Recipes for better CI/CD Performance

Looking for ways to speed up builds, automate tests, and release iOS apps faster? Check out Bitrise’s “Masters of Efficiencies,” 50 workflows to save time and deploy higher quality code. This comprehensive guide includes modular code configurations and plug-and-play workflows that streamline mobile development, reduce errors, and boost productivity. Download the guide today.

bitrise.io  

Skip

I had a thought as I felt my scepticism rising while browsing the marketing material for this new cross-platform UI (iOS and Android) solution that uses Swift and SwiftUI. It doesn’t need to be as good as using SwiftUI or Jetpack Compose, it only needs to be better than Flutter, React Native, and friends.

So, is it? I haven’t tried it, but it does sound promising after reading the FAQ. This might be worth a look if you’re staring down the barrel of a new cross-platform app.

skip.tools  

Swift Build Times and Module Verification

Paulo Andrade recommending using Xcode’s Build with Timing Summary feature:

Building with timing summary is your friend. Don’t forget to call it periodically to see what’s up.

He reduced his debug builds from 3.5 minutes to less than a minute. Could you be missing a similar saving?

pfandrade.me  

SwiftOpenAIProxy

What an interesting new package from Ronald Mannak. The readme recaps the tragic story of his OpenAI API key being discovered and used without his permission. It inspired him to create this Hummingbird server app that validates App Store receipts before passing back an API key. This is clearly useful in apps using OpenAI or similar APIs, but you could adapt the concept to any data based on an IAP or subscription. What a great idea!

swiftpackageindex.com  

JavaScript to Swift and back: Bridging location services in WKWebView

This post is not only a tutorial on working around a double pop-up alert situation from location services from an embedded web view. It’s also a nice walkthrough of two-way communication between JavaScript in the web view and Swift in the host app.

swiftlybald.com  

Send data Between iOS Apps and Extensions

No, not NSNotificationCenter and friends, instead Rizwan Ahmed dives a little deeper than that into Darwin notifications. One key benefit is that they aren’t limited to your app’s process, which makes them suitable for IPC with your app extensions.

ohmyswift.com  

Can a broken iPhone screen get a Snapchat account banned?

Finn Voorhees makes a good point in his latest blog post:

After a bit more research, I remembered the DeviceCheck framework. DeviceCheck allows developers to set and query two bits of data per device, which persist across app deletions, reinstalls, factory resets, and even device transfers between users. Apple’s documentation suggests using this for limiting free trials to once per user or banning devices with known fraudulent activity. They even mention that developers are responsible for resetting these bits when a device changes ownership, but it’s unclear how developers could verify that this has occurred.

It’s true that the documentation suggests:

You’re also responsible for determining when to reset the bits for a given device; for example, when a user sells the device to someone else.

Developers have no way for a device to notify them when a device gets sold or reset by Apple as part of a refurbishment. So, if you use these bits, make sure you can reset them if you get a support request like Finn’s!

finnvoorhees.com  

Writing Great Release Notes Doesn't Need to Be Hard

There are some great tips on writing engaging release notes, and in fact on writing anything, in Eli Perkins’ latest blog post. The only slight hiccup is that since Apple switched everyone over to automatic updates, it’s rare for anyone to look at them. I know it’s been many years since I visited that screen.

Don’t give up, though! There are far more effective outlets for letting your most passionate users know what has changed with your software, like an opt-in newsletter, a company blog, or social media. Get writing. ✍️

eliperkins.com  

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)

iOS Engineer @ Pika Earth – We're a high-growth, Sequoia backed climate tech company. iOS is our main user surface area, so you'll be responsible for many high-impact features that touch our core users. There are a ton of interesting technical problems, from offline mode to AR/VR modeling, and we have a world-class team. – On-site (United States in CA or NY) with some remote work (within US timezones)

Don’t forget that you can post any open Swift or Apple platform jobs for free over at iOS Dev Jobs. Get yourself a new colleague who's already subscribed to iOS Dev Weekly. 😂

What’s that in your expansion slot? Is it a Macintosh Plus? 🤷‍♂️