\n<\/p>\n
I don\u2019t know how I missed Orta Therox announcing that CocoaPods is in maintenance mode<\/a> 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:<\/p>\n Strictly speaking,<\/em> *we don\u2019t plan on changing how we\u2019re maintaining CocoaPods**<\/strong>. We\u2019re just going to start being clear how CocoaPods has been maintained:*<\/p>\n<\/blockquote>\n SwiftPM had a slow start. Apple announced it in 2015<\/a> but didn\u2019t 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\u2019s a slow process to convince people they should switch dependency managers. It\u2019s hard for teams to prioritise work like that when the old system isn\u2019t broken, and CocoaPods wasn\u2019t (and isn\u2019t) broken!<\/p>\n That said, we\u2019re 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\u2019s a good thing.<\/p>\n 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\u2019s just no feature work planned.<\/p>\n 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.<\/p>\n I also want to thank Orta for making this announcement. It\u2019s never easy to communicate something like this well, and there\u2019s never a right time to do it. I\u2019m really happy that we have clarity on the plan.<\/p>\n Thank you all for your work over the years.<\/p>\n Dave Verwer<\/p>\n Efficient iOS deployment: 50+ Workflow Recipes for better CI\/CD Performance<\/a><\/p>\n Looking for ways to speed up builds, automate tests, and release iOS apps faster? Check out Bitrise\u2019s \u201cMasters of Efficiencies,\u201d 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<\/a>.<\/p>\n Skip<\/a><\/p>\n 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\u2019t need to be as good as using SwiftUI or Jetpack Compose, it only needs to be better than Flutter, React Native, and friends.<\/p>\n So, is it? I haven\u2019t tried it, but it does sound promising after reading the FAQ<\/a>. This might be worth a look if you\u2019re staring down the barrel of a new cross-platform app.<\/p>\n Swift Build Times and Module Verification<\/a><\/p>\n Paulo Andrade<\/a> recommending using Xcode\u2019s Build with Timing Summary<\/a> feature:<\/p>\n Building with timing summary is your friend. Don\u2019t forget to call it periodically to see what\u2019s up.<\/p>\n<\/blockquote>\n He reduced his debug builds from 3.5 minutes to less than a minute. Could you be missing a similar saving?<\/p>\n SwiftOpenAIProxy<\/a><\/p>\n What an interesting new package from Ronald Mannak<\/a>. The readme recaps the tragic story<\/a> of his OpenAI API key being discovered and used without his permission. It inspired him to create this Hummingbird server app<\/a> 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!<\/p>\n JavaScript to Swift and back: Bridging location services in WKWebView<\/a><\/p>\n 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\u2019s also a nice walkthrough of two-way communication between JavaScript in the web view and Swift in the host app.<\/p>\n Send data Between iOS Apps and Extensions<\/a><\/p>\n No, not NSNotificationCenter and friends, instead Rizwan Ahmed<\/a> dives a little deeper than that into Darwin notifications. One key benefit is that they aren\u2019t limited to your app\u2019s process, which makes them suitable for IPC with your app extensions.<\/p>\n Can a broken iPhone screen get a Snapchat account banned?<\/a><\/p>\n Finn Voorhees<\/a> makes a good point in his latest blog post:<\/p>\n 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\u2019s 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\u2019s unclear how developers could verify that this has occurred.<\/strong><\/p>\n<\/blockquote>\n It\u2019s true that the documentation suggests:<\/p>\n You\u2019re also responsible for determining when to reset the bits for a given device; for example, when a user sells the device to someone else.<\/p>\n<\/blockquote>\n 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\u2019s!<\/p>\n Writing Great Release Notes Doesn\u2019t Need to Be Hard<\/a><\/p>\n There are some great tips on writing engaging release notes, and in fact on writing anything, in Eli Perkins<\/a>\u2019 latest blog post. The only slight hiccup is that since Apple switched everyone over to automatic updates, it\u2019s rare for anyone to look at them. I know it\u2019s been many years since I visited that screen.<\/p>\n Don\u2019t 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. \u270d\ufe0f<\/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 iOS Engineer @ Pika Earth<\/a> \u2013 We\u2019re a high-growth, Sequoia backed climate tech company. iOS is our main user surface area, so you\u2019ll 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. \u2013 On-site (United States in CA or NY) with some remote work (within US timezones)<\/em><\/p>\n Don\u2019t forget that you can post any open Swift or Apple platform jobs for free<\/em><\/a> over at iOS Dev Jobs<\/a>. Get yourself a new colleague who\u2019s already subscribed to iOS Dev Weekly. \ud83d\ude02<\/p>\n\n
News<\/h2>\n
\n
Code<\/h2>\n
\n
\n
Business and Marketing<\/h2>\n
Jobs<\/h2>\n
And finally…<\/h2>\n