Hi there, Here’s how the Screen Time API functions and what you need to begin: Public use of “Time Screen” APIs (Screen Time API Family Controls, Managed Settings, Device Activity) requires Apple approval. You need to submit a request form—found here—for distribution entitlements: https://developer.apple.com/contact/request/family-controls-distribution Request separately for each app/extension target, and only the Organization account holder can submit. Expect a review process of 1–5 weeks. The APIs do work for educational environments — you can use individual authorization instead of family mode. So schools or centers can use it, not just parents. Development builds work without limitations, but you’ll need entitlement approval before distributing via TestFlight or App Store. Hope it helps!

Hi there, Apple tends to tie a lot of things (like billing and auto-renew) to the personal Apple ID, even for developer accounts. To separate your company developer account billing from your personal iCloud: Make sure your LLC's developer account is associated with a dedicated Apple ID (not your personal one). This helps avoid any cross-account confusion. Sign in to Apple Developer using that separate Apple ID. Go to “Membership” > “View Billing Information”. Update the payment method directly under that account – you should be able to add your company credit card there. Just make sure you’re not in your personal Apple ID settings when doing this. For auto-renew, it’s unfortunately still tied to the Apple ID level, so if you used your personal Apple ID to enroll the business, Apple sees it as the same entity. In that case, you might need to transfer the developer account to a dedicated Apple ID owned by the LLC. Here's Apple's support article on transferring a developer account. 👉 Transfer Your Account: https://developer.apple.com/help/account/access/transfer-the-account-holder-role/ If you want to keep personal and business information completely separate, setting up a dedicated Apple ID for the LLC and migrating your developer membership there is the cleanest approach. Hope it helps!

Hi Mathéo, This appears to be a classic issue that can occur when migrating to a new major Xcode beta, particularly when Swift compiler internals (such as SwiftShims) or PCH configurations change between versions. Here are a few suggestions that may help: Double-check C99 mode Try explicitly setting the * GCC_C_LANGUAGE_STANDARD * to * gnu99 * or * gnu11 * in your target’s Build Settings to ensure compatibility with any residual PCH references. Remove old PCH references Even though you cleared DerivedData and ModuleCache, some * .pch * files may be retained in * ~/Library/Developer/Xcode/PrecompiledHeaders/. * Try deleting that directory too, and restarting Xcode-beta. 3.SwiftShims missing module This can occur if Swift module interfaces are incompatible across versions. Make sure there are no leftovers. * .swiftmodule * files in your project directory or Carthage/CocoaPods builds that may have been compiled using the previous stable Xcode. If you’re using a 3rd-party dependency manager, clean & rebuild from scratch with Xcode-beta. Hope it helps!

Hey there, I’m really sorry you’re dealing with that — sounds incredibly frustrating. Unfortunately, iOS betas can sometimes cause serious instability, including boot issues like what you're seeing. Since the phone is showing charging but won’t turn on, it’s possible the system crashed during installation and now won’t boot. Here’s what I’d suggest trying: Force Recovery Mode -Try entering recovery mode by pressing: Volume Up (quick press) Volume Down (quick press) Then hold the Side button until you see a cable icon and a Mac/PC symbol. (Might take 20–30 seconds.) OR: Connect to Finder/iTunes. Once in recovery mode, plug into your Mac or PC. You should see an option to Update or Restore. Use Restore (will erase your data, sadly). BUT... If that doesn’t work Try DFU mode — it’s a deeper restore method. Beta software is always risky, especially on your main device. I’d recommend using a spare device for these early builds if possible in the future. Hope it helps!

Japanese: こんにちは、 現在の推奨事項は次のとおりです。 Intune で RestrictAppleIntelligence ペイロードを適用する。 デバイスをテストし、どの機能が無効になっているかを確認する。 Apple の MDM 制限に関するドキュメントを確認する。今後の iOS アップデートで、よりきめ細かな制御が追加される可能性があります。 お役に立てれば幸いです。 EN: Hi there, My current recommendation is: Apply the RestrictAppleIntelligence payload in Intune. Test devices to confirm which features are disabled. Monitor Apple’s MDM Restrictions docs — they will likely add finer-grained controls in future iOS updates. Hope it helps!

Hi there, The error usually means the iPad can’t reach Apple’s cloud configuration server — check network access, MDM assignment in ABM, and make sure Apple’s services are up. Hope it helps!

Hi there! Great question — this can definitely be a bit confusing the first time. If your Apple Distribution Certificate has expired or is about to, just creating a new one in the Developer Portal is the first step. But yes, you’ll need to update your project with the new certificate as well: Download and install the new certificate from the Apple Developer Portal to your Mac (double-click to add to Keychain). Open your app in Xcode, go to your project settings → Signing & Capabilities, and make sure Xcode is using the new certificate. Re-archive and rebuild your app, then re-upload it to App Store Connect if you’re submitting a new version. Unfortunately, distribution certificates can’t be renewed or extended — they always expire after one year and must be manually replaced. Hope this helps!

Hi there, when you update your Apple ID phone number, it doesn’t automatically remove the old number from all services right away. Here are a few steps you can take to ensure the new number is fully updated: 1. Check Apple ID Settings: Go to appleid.apple.com, log in, and under “Sign-In & Security,” make sure your new phone number is listed as both your trusted number and verification method. You can remove the old number there too. 2. Update on All Devices: If you’re using multiple Apple devices, make sure you’ve updated the number in Settings > [Your Name] > Sign-In & Security > Trusted Phone Number on each one. 3. iMessage & FaceTime: Sometimes the old number still shows up in iMessage/FaceTime settings. Go to Settings > Messages > Send & Receive and make sure the new number is checked and the old one is removed. 4. Still Receiving Codes on Old Number? If codes are still being sent to the old number, it might still be listed as a trusted number. Removing it manually should fix the issue — no need to wait. If none of this works, I’d recommend contacting Apple Support directly — they’re usually pretty responsive with account-related issues. Hope this helps!

Hi Garrin, Here are a few things you might want to double-check: 1. App Review Status: If the app hasn’t passed review yet, your in-app purchases (IAPs) might not be fully available to external testers. Even if linked properly in App Store Connect, they might not show up outside internal TestFlight builds. 2. IAP Availability: Make sure your subscription products are: • In the “Ready to Submit” or “Approved” state (not just created). • Properly linked under your app version in the “In-App Purchases” section. • Cleared for sale. 3. Sandbox vs Production: TestFlight uses sandbox mode, while external testers may be triggering App Store production behavior (especially after submission). If your IAPs aren’t approved yet, that could block product info from loading. 4. Receipt / App Store Environment Checks: Ensure that your app handles failures gracefully if the StoreKit environment doesn’t return product info. Check logs to confirm if the app’s fetching the correct product identifiers. I don’t think it’s necessarily an account glitch — more likely a state mismatch between review/test/staging status. Once the review issue is resolved and the build is approved, I suspect things may sync up properly. Hope this helps — good luck!

It seems that this issue is affecting many of us at the moment. I would strongly recommend using the iOS Beta on a dedicated test device, rather than your primary one, to prevent any unforeseen bugs or potential impacts on your warranty.