SwiftUI List performance

I'm in the final phase before app approval and I'm struggling to implement store kit for in app purchases. I'm using base 44 and really need help finishing this set up. I have an iOS app (SwiftUI + WKWebView) with auto-renewable subscriptions using StoreKit and SubscriptionStoreView. The app was rejected under Guideline 3.1 because payments were defaulting to Stripe instead of storekit. What’s already done: Subscriptions created in App Store Connect (monthly + annual) SubscriptionStoreView implemented and visible in app WKWebView bridge triggers native StoreKit paywall Sandbox test account created Stripe fully disabled on iOS What I need: Verify StoreKit implementation is App Review compliant Confirm subscriptions are correctly attached to the app version Ensure paywall is discoverable by App Review Help me pass App Review (reply guidance + final checks) This is a short engagement (1–3 hours). Looking for someone with real StoreKit + App Review experience + Base44 knowledge.

Hi there. I am trying to figure out how to make a macOS Tahoe app in SwiftUI with a sidebar. The problem I’m having is that the icons are the wrong size. If you visually compare the resulting sidebar with any built-in macOS app (Finder, Notes, Mail, Music, etc.) the built-in apps all have larger icons and the spacing is different from my SwiftUI app, which has too small icons and (I think) wrong spacing. I am trying to figure out what SwiftUI code I need to write to get a sidebar that looks the same as the other built-in macOS Tahoe apps. It’s also important to note that Tahoe sidebars have larger icons at the top level, and in cases where the items have a disclosure triangle with additional items nested within, the nested icons have smaller icons. I have not figured out how to properly replicate this effect either. I have spent quite a lot of time on trial-and-error with various combinations of .frame() and .font() modifiers. However, none of the results look quite right to me, and

I've spent a few months writing an app that uses SwiftData with inheritance. Everything worked well until I tried adding CloudKit support. To do so, I had to make all relationships optional, which exposed what appears to be a bug. Note that this isn't a CloudKit issue -- it happens even when CloudKit is disabled -- but it's due to the requirement for optional relationships. In the code below, I get the following error on the second call to modelContext.save() when the button is clicked: Could not cast value of type 'SwiftData.PersistentIdentifier' (0x1ef510b68) to 'SimplePersistenceIdentifierTest.Computer' (0x1025884e0). I was surprised to find zero hit when Googling Could not cast value of type 'SwiftData.PersistentIdentifier'. Some things to note: Calling teacher.computers?.append(computer) instead of computer.teacher = teacher results in the same error. It only happens when Teacher inherits Person. It only happens if modelContext.save() is called both times. It works if the first modelContext.save() is com

Title: Stuck in a loop between Guideline 2.1 and 2.2: Reviewer refuses to play for 5 minutes. Body: I am an independent developer struggling with a repetitive rejection cycle for over a month. I need advice on how to handle a clear contradiction in the review process. The Loop: Initial Rejection (2.1): Reviewer said they couldn't locate the IAP. My Action: I added a prominent IAP Test button on the title screen to skip gameplay. Second Rejection (2.2): A different reviewer said the IAP Test button is a Beta feature and not appropriate for production. My Action: I removed the button and implemented a Secret Command (Easter Egg) that enables an Assist Mode (extending the timer to 5 minutes) so the reviewer can easily clear the game and reach the IAP screen in about 5-6 minutes. Latest Rejection (2.1): The reviewer now says: While we appreciate you provide an instruction... we require a quicker way to access in-app purchases without spending significant time to play games. The Current Solution: In my next submis

Does DL-TDoA ranging in the Nearby Interaction framework support building a traditional RTLS-style TDoA localization system, where a device’s absolute position is computed from time-difference measurements across multiple deployed anchors, or is DL-TDoA strictly limited to system-managed, relative ranging and direction estimation (distance/direction) between nearby devices? If DL-TDoA ranging in Nearby Interaction is not intended to support traditional RTLS-style TDoA localization, is there any public documentation or reference material that describes the intended DL-TDoA architecture, such as the expected system setup, device roles, and deployment constraints (for example, how ranging is expected to be performed between an iPhone and nearby accessories), beyond the high-level API documentation? Regards.

User spending on mobile apps keeps rising, but competition is growing faster, making App Store Optimization a critical pillar of mobile growth by improving visibility, reducing cost per install, and driving stronger organic performance. This post highlights the most important ASO trends for 2026, including AI driven optimization, user intent focus, localization, creative testing, analytics, and privacy first strategies to help apps grow consistently on the App Store.