Post

Replies

Boosts

Views

Activity

CloudKit private database & developer access to user data
My app does not knowingly capture or retain user data in any form, but I wanted to make sure that I don’t inadvertently have access to user data via CloudKit. I’m reaching out to confirm this. Here’s the basic structure of the app - users can enter information which is then retained for their own use. I’m using SwiftData. @Model data is saved in a CloudKit container, which permits data syncing across iOS devices. I’ve never written any code to make the container database I’m using for the app (or zones within it) anything other than private, so I think (??) by default the data is stored privately. Data syncing does work and my icloud.developer.apple.com dashboard shows a private database subscription but no public or shared subscriptions. My understanding of this design has been that the user’s data was stored in their personal, private iCloud account and I did NOT have access to it (nor do I need or want to have access). However, then I watched this WWDC 2018 video on GDPR compliance (https://developer.apple.com/videos/play/tech-talks/703/), in which Michael Ford presents code that provides “visibility into the data that is saved in CloudKit for the user”, including the private database. This sounds to me like a developer might actually be able to access a user’s private database data. Have I misinterpreted this WWDC 2018 presentation, has a developer’s access to user data in a private database changed since 2018, or do I actually have access to user data via my reliance on CloudKit to save user data? Many thanks for your help!
0
0
587
Mar ’24
Persist and deliver scheduled local notifications after app update
I have an app available for download in the Apple App Store. The app sends local notifications, which are scheduled at the user's request once the app launches. I've recently learned that when new versions of my app are deployed and automatically update on the user's device, previously scheduled local notifications are deleted. Given my app design, the user can re-launch the app in order to re-schedule the local notifications. This is a bit of a problem, though, because part of my app's value is in reminding the user - so after requesting a local notification, the user expects to receive a local notification and then launch the app, not the other way around. Given this, I've been exploring solutions so my app continues to function as expected (including delivering local notifications, even if the app hasn't yet been launched) after an app update. I've explored .backgroundTasks(), but they too are apparently deleted with an app update and require the app to be re-launched first to work as expected. Another solution might be to use push notifications instead of local notifications, but that seems like a very involved solution if I'm just looking to make sure that local notifications persist after an app update. I can't be the only person to have this dilemma - am I overlooking a simple solution?
2
0
338
Jan ’25
iOS app crash when both .backgroundTask() and .scenePhase in App file
I've been having trouble with .backgroundTask(.appRefresh()) causing an intermittent crash when my app is launched. When the crash happens, the app flashes a darkened screen with the home screen device information (time-of-day, battery life, etc) weirdly pivoted landscape and right-justified. This screen shows for a split-second, disappears, and the app does NOT launch. Re-tapping the app icon will often re-launch the app without incident. After much trouble-shooting, I've discovered that commenting out EITHER @Environment(\.scenePhase) private var phase or the .backgroundTask(.appRefresh()) {} code eliminates the crash, so it's somehow caused by having both present at the same time. As you can see in the example below, it's not even necessary to actually use .scenePhase or .backgroundTask to run any other code in order to create the crash. The following minimal reproducible example will create the crash on an actual device, although you may need to launch and quit the app in quick succession 10-20 times to see the crash. (I realize most users aren't likely to do that - sometimes the crash occurs in the actual app on the first launch. But it's an intermittent problem so may require a few testing rounds to appear.) In addition to the code shown here, I've added the "Background Modes" capability with "Background Fetch" to "Signing & Capabilities" and added the "UpdateBadge" task to "Info" as a "Permitted background task scheduler identifier". Any idea what could be causing the crash and how to prevent it? struct ToyBackgroundTasksApp: App { @Environment(\.scenePhase) private var phase var sharedModelContainer: ModelContainer = { let schema = Schema([ Item.self, ]) let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false) do { return try ModelContainer(for: schema, configurations: [modelConfiguration]) } catch { fatalError("Could not create ModelContainer: \(error)") } }() var body: some Scene { WindowGroup { ContentView() } .modelContainer(sharedModelContainer) .backgroundTask(.appRefresh("UpdateBadge")) { print("background task") } } }
3
0
334
Feb ’25