Open Letter to Apple Leadership To: John Ternus, Chief Executive Officer Craig Federighi, Senior Vice President of Software Engineering Greg “Joz” Joswiak, Senior Vice President of Worldwide Marketing Apple Developer Relations & App Store Small Business Review Teams Subject: PCC & Developer Continuity: Implementing a Paid Tier for Private Cloud Compute (PCC) Dear John, Craig, Greg, and the Apple Developer Relations Team, I write to you as a new developer community member. While developing several Apple applications, I was glad to find deeply integrated applications through Apple Intelligence and the Private Cloud Compute (PCC) architecture that can be used to add features and capabilities to these applications. By eliminating early-stage cloud API friction, you gave indie developers the exact "on-ramp" needed to build incredible, localized AI tools. However, the current off-ramp mechanism built into the App Store Small Business Program enrollment is actively penalizing developer success. Your documentation outlines a rigid, unyielding pipeline for growing applications: "If any app subsequently exceeds the 2 million first-time downloads threshold, or the developer is no longer enrolled in the App Store Small Business Program, the developer will be notified and must migrate to an alternative solution within 6 months." While I know that it is highly unlikely that my downloads will exceed 2 million (shoot for the moon though, one never knows), since Apple does not distribute its frontier-tier server model weights, developers who reach this milestone will be forced to migrate their core features onto third-party infrastructure like AWS, OpenAI, or Microsoft Azure. This policy introduces a severe, counterproductive paradox into the Apple ecosystem: This will force successful devs to move to third party AI providers and away from Apple's tools. I am sure this is not a desired result at Apple. Or, it will have a chilling effect: developers will not use PCC if this a potential hurdle they might have to jump in the future. Why bother at all to begin with if this might be the end result. *Forced Migration Breaks Developer Continuity: Forcing growing apps off PCC means developers must completely swap out backend configurations. Instead of focusing on enhancing their apps for your new hardware, developers must waste critical engineering cycles rebuilding infrastructure on third-party clouds. Abandoning the Privacy Promise: Apple built its reputation on an uncompromising commitment to user privacy. PCC extends the secure enclave to the cloud. Forcing a developer to move their traffic to a third-party server means forcing users to trust external corporate entities with data that could have stayed inside Apple’s secure ecosystem. The "Success Tax": For mid-sized developers, the transition is a massive financial cliff. A commercial AWS instance capable of running an open-weight equivalent model introduces steep fixed baseline costs. My Proposal: A Predictable, Commercial Pay-As-You-Go PCC Tier after the limit, rather than an off-ramp to Apple's competitors: Instead of forcing growing developers onto AWS, Google Cloud, or OpenAI, Apple should allow developers to transition to a paid PCC commercial plan upon crossing the 2 million download or small business revenue thresholds. Whether structured as a metered developer API cost or an explicit tier integrated into Xcode and App Store Connect, developers want the option to pay Apple directly to stay on your hardware. This achieves your goal of preventing data centers from becoming a subsidized utility while ensuring our apps don't break when they go viral. Apple has always championed the idea that the best experiences happen when hardware, software, and services are vertically integrated. Forcing your most successful developers to sever that integration and hand their infrastructure over to external cloud providers at the exact moment they achieve scale undermines the ecosystem you’ve worked so hard to build. Please give us a path to grow with Apple, not away from it. Sincerely, The Apple Developer Community

I've been trying to get the bash/script version of DeepFaceLab to work with Apple Silicon Macs, but this was original a Windows project that even now has non-existent support for MacOs/Apple Silicon. I am thinking of converting everything into a native macOS app using Swift, specifically optimized for Apple Silicon GPUs. Here's what I got from ChatGPT. Any help/advice on how to do this would be greatly appreciated. I don't have any Swift programming experience, but I have experience with some coding and can generally figure things out. I know that this is probably not feasible for a single individual with little programming experience, but I wanted to throw this out there to see what others think. Thank you Here's a high-level overview of the steps involved in porting DeepFaceLab to Swift with a graphical UI: Understand DeepFaceLab: Thoroughly study the DeepFaceLab project, its Python scripts, and the overall architecture to grasp its functionalities and dependencies. Choose a Swift Framework: Decide on the UI framework you want to use for the macOS app. SwiftUI is Apple's latest UI framework that works across all Apple platforms, including macOS. Alternatively, you can use AppKit for a more traditional approach. Rewrite Python to Swift: Convert the Python code from DeepFaceLab into Swift. You'll need to rewrite all the image processing, deep learning, and video manipulation code in Swift, potentially using third-party Swift libraries or native macOS frameworks. Deep Learning Integration: Replace the Python-based deep learning library used in DeepFaceLab with an appropriate Swift-compatible deep learning framework. TensorFlow and PyTorch both offer Swift APIs, but you may need to adapt the specific model implementation to Swift. Image Processing: Find equivalent Swift libraries or frameworks for image processing tasks used in DeepFaceLab. UI Development: Design and implement the graphical user interface using SwiftUI or AppKit. You'll need to create views, controls, and navigation elements to interact with the underlying Swift code. Integration: Connect the Swift code with the UI components, ensuring that actions in the GUI trigger the appropriate Swift functions and display results back to the user. Testing and Debugging: Rigorously test the Swift application and debug any issues that arise during the porting process. Optimization: Ensure that the Swift app performs efficiently and effectively on macOS devices.