Auto Layout 是个好起点，但只把所有控件拉宽通常不够。展开后先检查文字、按钮和图片有没有被拉得太宽，折叠或半折叠时有没有挤在一起或被中间的折痕区域影响。可以根据当前的可用宽度和 size class 调整布局：外屏用紧凑布局，内屏空间足够时再展示更宽的内容。建议在 iPhone Duo 模拟器里测试合上、展开和半折叠几种状态。只支持竖屏本身不代表一定不能通过审核，关键是每种状态下内容仍然完整、可用。Apple 的设计指南也建议让布局随设备姿态变化，而不是只依赖固定尺寸：https://developer.apple.com/design/human-interface-guidelines/designing-for-iphone-duo

Since you already fixed the rejection and resubmitted, I’d first confirm the current version and build are the ones attached to the submission and that App Store Connect shows Waiting for Review, with no action requested in the Resolution Center. Apple’s 24/48-hour review figures are goals, not a guarantee, and it says first submissions can take longer. At 10 days, it’s reasonable to follow up once through your existing support case and ask whether the submission is correctly queued or needs anything from you. I’d avoid withdrawing and resubmitting just to restart the clock. Apple’s status guide: https://developer.apple.com/help/app-review/after-submitting-for-review/review-status

A week in Waiting for Review does not necessarily mean you filled something out incorrectly. Apple says that status means they received the submission but have not started reviewing it, and first submissions can take longer. I’d check the App Review section for any message or missing review information, then give it a little more time. If it stays there, contact Apple through App Store Connect with the app version and submission details. I wouldn’t withdraw and resubmit just to reset the queue. Apple’s status guide is here: https://developer.apple.com/help/app-review/after-submitting-for-review/review-status

The renewal path depends on how you originally joined. If you enrolled in the Apple Developer app, membership renews as an App Store subscription, so check Settings > your name > Subscriptions while signed in to the Apple Account used there. If you enrolled on the web, sign in to developer.apple.com with the enrollment account and look under Membership Details; manual renewal is available during the 30 days before expiry. For an organization, only the Account Holder can renew. Apple's guide covers both paths: https://developer.apple.com/help/account/membership/renewal/ . Since you're only seven days from expiry and the button is missing, reply to your existing Support case with a screenshot of Membership Details and ask them to confirm which renewal route applies after the individual-to-organization conversion. Keep the case or account details private.

I'd keep your Enrollment ID for Apple Support and avoid posting it here. Apple's enrollment help says to include that ID when you contact them: https://developer.apple.com/help/account/membership/program-enrollment/ . Since it fails across browsers, take a screenshot of the error and note when it happened. Then try the direct contact page from another device or network: https://developer.apple.com/contact/ . If the form still fails, mention that the support form itself is returning an error so they can route it. Does it fail before you submit, or after?

There usually isn't a way to force enrollment to move to payment. Since Apple says they are reviewing it, keep this enrollment open and follow up with Developer Support using your Enrollment ID there, not in a public post. Include the enrollment date and a screenshot of the Pending status, and ask whether they need anything else from you. Check your Apple Account email, including spam, for any verification request. I wouldn't start a second enrollment while this one is pending.

Apple's WWDC25 session on the Declared Age Range API explains this cache behavior. On the device, go to Settings > Privacy & Security > Age Range for Apps, select your app, then tap Share Age Range again. Apple says this clears the cached response so the next request can show the sharing flow again. For a child account, the parent or guardian can manage sharing from Family settings. The choices include Always Share, Ask First, and Never Share, so the prompt may not appear every time even when the integration is working. Apple's session is here: https://developer.apple.com/videos/play/wwdc2025/299/

I do not believe there is a public iOS API for shaping or rate-limiting traffic forwarded by Personal Hotspot. Network Extension APIs cover specific use cases, but NEHotspotHelper is for captive-portal style Wi-Fi authentication, not controlling tethered clients' throughput. If you need a hard per-device limit, it would need to be enforced by the upstream network or router. A VPN or Network Extension on the iPhone would not give your app a supported hook to throttle only Personal Hotspot clients while leaving the iPhone's own traffic untouched.

I would start with a small group of people who actually use cars day to day, rather than chasing lots of installs. A local car-owner group or a community for people who track maintenance is more likely to give you useful feedback than a general app-testing group. A public link is convenient, and you can add device or OS criteria and cap the number of testers while you learn what works. For the first round, give testers two or three real things to try, such as adding a vehicle, logging a fill-up, and finding the next service date. Keep the What to Test notes short and ask where they got confused, not just whether they liked it. TestFlight screenshot feedback is a good place to start. A simple form can help if you want structured answers, but I would avoid asking people to fill out both unless there is a reason. I would send a short note when a new build is ready saying what changed and what you want them to check. That gives people a reason to come back without making every build feel like homework. For the 90-day limit, set a calendar reminder a couple of weeks before expiry and upload a new build when there is something worth testing. The first build sent to external testers needs TestFlight review, so it is worth submitting that early.

The blank area is there because the template shows the full canvas and the safe area where the important artwork should stay. It isn't a small export size: use the whole canvas for the background, but keep logos, text, and the main subject inside the safe area so they don't get cropped on different devices and orientations. The preview in App Store Connect is useful for checking this. The export depends on the placement. Apple lists product page header images as 3840 × 1646 (21:9) or 5244 × 2950 (16:9 PNG). Search result images are 1920 × 1280 to 3840 × 2560 (3:2), or 5244 × 2950 (16:9 PNG). JPEG or PNG is fine for the listed image sizes, and the file must not have transparency. If you're using a video, the formats and lengths are different, so check the specs for that placement. I'd use the export settings in the matching Figma, Photoshop, or Pixelmator template rather than cropping the canvas to the safe-area box. Apple's asset best practices and creative asset specifications show the safe areas and exact sizes.

I would be cautious about using MusicKit JS this way. Apple's public MusicKit pages describe playback on the web in terms of users streaming from a website, but I couldn't find a statement that headless Chromium on embedded Linux is a supported environment. The docs also don't answer whether a loopback origin is acceptable for the developer token's origin claim. Since this is going into a product, I'd get confirmation from Apple Developer Support about the headless use case and the MusicKit terms before building around it. Include the exact origin, how the user authorizes the device, and how playback is presented or controlled. Also check whether the target Chromium build supports the playback and DRM requirements; MFi and AirPlay 2 approval alone may not cover this separate MusicKit JS use.

Since it's been nearly three weeks, I would contact Apple Developer Support through the enrollment support page and include your Enrollment ID and payment/order confirmation. Also check the email address on your Apple Account for any verification request. Matching your address and bank details does not necessarily mean enrollment will activate immediately, and other forum users can't see the reason for the hold. Don't post your address, bank details, or receipt publicly.

If the status has been unchanged since the 16th, first check App Store Connect for any message in the submission and confirm the required agreements are active. Waiting for Review means it is queued, and there isn't a button to move it forward yourself. If it has been sitting longer than Apple's current review estimate, contact Developer Support with the app name, version and submission ID. I wouldn't cancel and resubmit just to reset the queue.

Since you’ve already sent three status requests, I’d keep everything in the existing case and avoid opening more duplicates. Reply with the submission ID and ask Support to confirm whether anything is blocking the queue or if it is still waiting to be picked up. I wouldn’t withdraw and resubmit just to reset the clock, since that can put it back in the queue. An expedited review request isn’t a guaranteed start time, and only Apple can check the submission internally.

Since this is already with Developer Support, I’d keep the follow-up in that case and ask them to confirm the documents were received and whether anything else is needed from you. If App Store Connect still shows In Review with no request or rejection, I wouldn’t upload the same documents again unless Support asks. The forum can’t see the compliance review, so only Apple can confirm whether it is still pending or needs a status update.