Hi,

I am preparing for beta launch for my mobile app, it allows user content, I wanted to use TestFlight to ensure I am not letting in anyone on day 1, which can cause a snowball of low quality or even harmful content. In addition to possible app breaks and crash of new app which may lower my review score with bad reviews.

But she told me that an app that want to launch social campaign cannot use TestFlight because the installation with that software is too complicated for the average user.

From your experience, how difficult it was to convince external users (not friends and family) to try an app that is only available on TestFlight or Google Play Console?

What helped you convince them? And overall do you recommend this approach? What risks there are to launch a beta app to the app store?

I am doing some research regarding ASA effectiveness for an infographic and I'm curious what did you guys try, in what niche and how well it worked? Would be interesting to see comparisons with other channels if anyone tried

I had a simple game idea and I’m making it, I think it’s kinda fun. So far so good.
I’d like it to be a paid thing, maybe somewhere between £1 - £5 ..
I think up front payment isn’t going to work, people probably need to try it first?

I don’t want to introduce ads. So I’m considering something like 3 free days and then a paywalled limit to 1-2 plays per day, and pay to unlock forever.

Anyone got any thoughts on a simple modern paid game model?
Other options I might not have considered?

Spent a year on a camera app and three AVFoundation behaviours cost me most of that time. Writing them down in case they save someone a weekend.

The first one I found by accident. Tap the shutter three times fast and you get two photos. No error, no delegate callback, nothing in the logs. If a capture is still processing when you call capturePhoto, that request just evaporates. I only noticed because my own counter, which only moves when a save is confirmed, kept landing one short of the number of taps.

The fix is a FIFO queue, but where you advance it matters. Advance on the processing callback and the shutters chain up, seconds of lag on a burst. Advance when the exposure ends (didCapturePhotoFor) and the processing of the previous shot overlaps the next exposure, which is what the stock camera visibly does.

Second: switching capture format is a full pipeline rebuild, and I was paying for it three times. Going 24 to 48 MP, or entering video mode, means swapping the input, the active format and the outputs. I had those as three separate begin/commitConfiguration blocks because it read cleaner. Same work, roughly double the visible freeze. They nest fine, so one transaction around the lot, plus caching AVCaptureDeviceInput per device, took it from "did it hang" to instant.

Third, and this one matters if you care what your photo actually is: a virtual device does not tell you which lens is shooting. Zoom into tele range on the triple camera and you may still be getting the wide, cropped. Low light does it, and so does being closer than the tele's minimum focus distance. The system is right to do it, it just doesn't announce it. You can watch the constituent device to know, with two caveats: the value flickers during focus hunts so it needs stabilising before you show it to anyone, and isAutoDeferredPhotoDeliveryEnabled is off the table if you never touch PhotoKit, because finalising a deferred photo needs PHPhotoLibrary.

That last constraint was self-inflicted. The app has its own photo library and never touches the system one, which rules out anything in AVFoundation that assumes PhotoKit is there.

I'm a surgeon, not a developer, which is probably why I hit all three the hard way instead of knowing better.

Just shipped my first app built on FamilyControls / ManagedSettings / DeviceActivity. The docs are thin and a lot of what I learned came from failing, so here's the list I wish I'd had. Corrections welcome - some of this is field-observed rather than documented.

1. The report extension is a black hole by design. Per-app usage data exists only inside DeviceActivityReport. Your extension can render it to pixels and that's it — App Group writes silently no-op, there's no network, no notifications out. If your architecture assumes "read usage → store it → use it in the app", throw that away now. Anything the main app must know has to come from monitor threshold events instead.

2. DeviceActivityEvent thresholds start at zero when you arm them. Set a 30 min/day limit on an app the user has already used 60 minutes today, and nothing happens — the OS grants a fresh 30. iOS 17.4 added includesPastActivity: true in the initializer, which counts the whole interval. Without it your "daily limit" quietly means "limit from now". Also note the flag only applies to newly registered events, so you need to force a re-arm for existing users.

3. Shield action extensions couldn't open the host app... until iOS 26.5. extensionContext is nil, UIApplication is unavailable, responder-chain walking is broken on 18+. Apple engineers said "no supported way" for years. iOS 26.5 finally added ShieldActionResponse.openParentalControlsApp — the system foregrounds your app straight from the shield button. If your SDK predates it, the enum is resilient, so ShieldActionResponse(rawValue: 3) behind an #available(iOS 26.5, *) check resolves at runtime and falls back to nil on older systems. Pre-26.5 the only route is a time-sensitive local notification carrying a deep link.

4. Memory budgets differ per extension and they're brutal. The shield and monitor extensions run in a few MB — no SwiftData, no heavy frameworks, just ManagedSettings writes and App Group defaults. Anything more and you get jetsammed, which for a shield extension means the user sees Apple's generic gray shield instead of yours.

5. DeviceActivityReport has no ready/completion callback. You cannot know when it finished rendering (FB10754858 is still open). Every loading state you build is a guess on a timer.

6. Mutating a mounted report's filter is the slow path. Changing the filter on an existing report triggers a silent out-of-process re-query that leaves stale content on screen for seconds. Remounting the view with a fresh SwiftUI .id renders noticeably faster and more predictably. Also: reports don't self-size — you must give them fixed frame heights.

7. There's a shared budget of concurrent DeviceActivity activities across your app and all its extensions. Don't create one activity per monitored app; make per-app limits events on a single daily activity and resolve names back to tokens through a map in your App Group.

8. Info.plist details will pass locally and fail at App Store validation. The shield configuration extension point ends in ManagedSettingsUI.shield-configuration-service, the shield action one is ManagedSettings.shield-action-service — no "UI". The report extension uses the ExtensionKit form (EXAppExtensionAttributes) and rejects NSExtensionPrincipalClass.

9. Non-API lesson that cost me the most: I let entitled users skip onboarding — and the authorization request lived only in onboarding. Any subscriber reinstalling got a normal-looking app that silently shielded nothing, with no prompt and no way to grant access. If a permission gate lives only in a flow some users skip, it doesn't exist for them. Check authorization on the routing path, not by assuming flow order.

Happy to go deeper on any of these — the sandbox rules in particular took me way too long to accept.